20140716 讨论、总结
一、测试理论
- 测试的目的是推动质量提升，而不是保证质量；
- 测试驱动开发的理念，目前实践较少；
- 漏测率统计（？）；
- 缺陷修复很可能引发新的缺陷，需要考虑修复缺陷带来的风险；
- 只有出现了新的问题，才会有对新问题的新的解决方案，问题驱动型的工作方法；
- 偶现问题的处理方案，采用排除法，分别修改各个条件进行验证，确定不能重现时可观察多个版本进行记录后关闭；
二、测试计划
- 多语言版本的测试中，针对默认、典型配置进行重点测试，其他进行冒烟或主要功能测试；
- 通过测试经验、统计数据确定测试重点；
- 多语言系统的界面布局、数据库设计问题；
- 硬件问题如32位系统升级到64位系统时可能出现的问题，如C语言的高地址转码等；
- 测试时注意将重点功能压前；
- 开发与测试沟通过程中可能存在的问题；
三、测试设计
- 测试用例指导测试执行，保证基本功能的覆盖率，进行工作量评估的依据；
- 测试设计对需求的依赖性，需求变更带来的工作量不可避免；
- 探索性测试的引入；
- 验收测试和功能测试中采用的测试用例粒度可以不同，步骤的细化或者灵活性不同；
- 常见功能列出检查点；
- 标明系统的优先级、测试用例的优先级和执行时间，根据时间、资源分配测试人员，在测试执行开始前确定；
- 进行测试用例设计之前要进行工作量初步评估，用例设计完成后进行细化，所以要留出适当的buffer；
- 在进行工作量评估时给出工作量而不是截止时间；
- 版本质量差，需要通过缺陷数量等进行数据反馈；
- 测试用例中过多使用简写、缩写、仅列出功能点没有测试步骤等，不利于复用和交叉执行；
- 标准化的测试用例和review；
- 破坏性的测试建议在单独环境或测试后期进行；
- 用例设计时可以采用模板，其中测试数据部分可列明等价类，而不写明具体数据，方便执行时使用不同数据验证；
四、测试执行
- 提交缺陷时必须注意缺陷的重现步骤；
- 避免出现缺陷重复，可以采用关键字查询；
- 业务、开发、需求三方会审，确定缺陷优先级等，可以综合考虑缺陷是由设计引起还是代码错误，明确解决方案；
- 缺陷定级时候每个人可能有不同的标准；
- 测试与开发讨论问题后要及时记录缺陷，否则容易遗忘；
- 开发在修复缺陷时夹带代码的问题；
- 避免缺陷渐变，在缺陷出现不同表现时要重新提交，不建议在缺陷中修改；
- 缺陷转需求：将缺陷跟踪转化为需求变更管理；
- 一个缺陷只对一个问题，避免出现部分修复的缺陷不好管理；
- 用户体验：细节性或易用性的缺陷很多的话，用户体验也会很差；
- 测试人员习惯在下班前集中提交缺陷，需要根据版本发布进行与开发协调；
- 开发和测试存在争议问题时，注意需求依据、环境是否一致，必要时需要有上级推动进行协商；
- 在描述性能问题时，不要有主观性说明，需要量化，比如打开很慢之类的，最好给出平均打开时间是多少秒这样的描述；
五、自动化测试管理工具
- 虚拟机资源管理；
- 被测软件和配置软件的安装管理；
- 软件版本的管理；
- 执行情况统计。