20140716 讨论、总结

 

一、测试理论

1. 测试的目的是推动质量提升，而不是保证质量；
2. 测试驱动开发的理念，目前实践较少；
3. 漏测率统计（？）；
4. 缺陷修复很可能引发新的缺陷，需要考虑修复缺陷带来的风险；
5. 只有出现了新的问题，才会有对新问题的新的解决方案，问题驱动型的工作方法；
6. 偶现问题的处理方案，采用排除法，分别修改各个条件进行验证，确定不能重现时可观察多个版本进行记录后关闭；

 

二、测试计划

1. 多语言版本的测试中，针对默认、典型配置进行重点测试，其他进行冒烟或主要功能测试；
2. 通过测试经验、统计数据确定测试重点；
3. 多语言系统的界面布局、数据库设计问题；
4. 硬件问题如32位系统升级到64位系统时可能出现的问题，如C语言的高地址转码等；
5. 测试时注意将重点功能压前；
6. 开发与测试沟通过程中可能存在的问题；

 

三、测试设计

1. 测试用例指导测试执行，保证基本功能的覆盖率，进行工作量评估的依据；
2. 测试设计对需求的依赖性，需求变更带来的工作量不可避免；
3. 探索性测试的引入；
4. 验收测试和功能测试中采用的测试用例粒度可以不同，步骤的细化或者灵活性不同；
5. 常见功能列出检查点；
6. 标明系统的优先级、测试用例的优先级和执行时间，根据时间、资源分配测试人员，在测试执行开始前确定；
7. 进行测试用例设计之前要进行工作量初步评估，用例设计完成后进行细化，所以要留出适当的buffer；
8. 在进行工作量评估时给出工作量而不是截止时间；
9. 版本质量差，需要通过缺陷数量等进行数据反馈；
10. 测试用例中过多使用简写、缩写、仅列出功能点没有测试步骤等，不利于复用和交叉执行；
11. 标准化的测试用例和review；
12. 破坏性的测试建议在单独环境或测试后期进行；
13. 用例设计时可以采用模板，其中测试数据部分可列明等价类，而不写明具体数据，方便执行时使用不同数据验证；

 

四、测试执行

1. 提交缺陷时必须注意缺陷的重现步骤；
2. 避免出现缺陷重复，可以采用关键字查询；
3. 业务、开发、需求三方会审，确定缺陷优先级等，可以综合考虑缺陷是由设计引起还是代码错误，明确解决方案；
4. 缺陷定级时候每个人可能有不同的标准；
5. 测试与开发讨论问题后要及时记录缺陷，否则容易遗忘；
6. 开发在修复缺陷时夹带代码的问题；
7. 避免缺陷渐变，在缺陷出现不同表现时要重新提交，不建议在缺陷中修改；
8. 缺陷转需求：将缺陷跟踪转化为需求变更管理；
9. 一个缺陷只对一个问题，避免出现部分修复的缺陷不好管理；
10. 用户体验：细节性或易用性的缺陷很多的话，用户体验也会很差；
11. 测试人员习惯在下班前集中提交缺陷，需要根据版本发布进行与开发协调；
12. 开发和测试存在争议问题时，注意需求依据、环境是否一致，必要时需要有上级推动进行协商；
13. 在描述性能问题时，不要有主观性说明，需要量化，比如打开很慢之类的，最好给出平均打开时间是多少秒这样的描述；

 

五、自动化测试管理工具

1. 虚拟机资源管理；
2. 被测软件和配置软件的安装管理；
3. 软件版本的管理；
4. 执行情况统计。