如何有效避免漏测？

漏测，指在产品缺陷在测试过程中没有被发现（尤其是测试环境可以重现的缺陷），而是在版本发布后或者在用户使用后发现并反馈回来的缺陷。可以说，漏测的问题是测试管理者最头痛的问题。因为出现漏测，一来给客户带来了不好的影响和印象，二来增加缺陷修复的成本，三来给测试团队也带来负面和不利的影响。因此，作为测试管理者，测漏分析和预防是必须要做好。

　　漏测的原因分析有以下的几个方面：

　　· 需求评审质量低，或参评人员能力不足，或过程不规范严谨

　　· 需求变更频繁，测试用例无及时更新

　　· 用例设计的过于粗犷，测试步骤不清晰

　　· 测试用例对需求的覆盖面不全，考虑不足

　　· 测试人员测试思维局限，无思考全面

　　· 测试人员执行过程不规范，人为漏测

　　· 测试执行人员质量意识不足，发现的缺陷定义严重性程度低或不认为是问题

　　· 测试环境与生产环境有较大出入

　　· 测试环境或测试数据受限，无法模拟并覆盖执行所有正常和异常的场景分支

　　· 功能回归策略问题

　　· 测试资源有限

　　· ……

　　漏测预防或改进措施有以下几个方面：

　　· 需求评审质量的提高

　　· 需求评审过程必须建立规范的评审流程

　　· 需求评审至少有需求、开发和测试人员参加

　　· 需求评审必须安排业务熟悉和测试经验丰富的测试人员参加

　　· 测试用例的及时更新维护

　　· 每当发起了需求变更必须及时更新测试用例库和做好过程记录及用例评审

　　· 在测试过程中启发的测试用例必须及时更新或录入到测试用例库

　　· 漏测情况出现时，必须分析漏测原因和补充对应的测试用例

　　· 反馈的运维缺陷问题（软件部分）必须分析原因，并补充的测试用例库

　　· 测试用例质量的提高（颗粒度、需求覆盖度、冗余度等）

　　· 测试用例的设计编写必须由有测试经验和业务基础的测试人员设计编写

　　· 着重正常流程测试用例，尤其常用和典型的用户场景和操作的分析

　　· 建立规范的测试用例评审制度（组长评审、同行评审或组、组之间的交叉评审或发起需求和开发进行评审）

　　· 建立通用测试用例库和测试用例框架，建立优质测试用例

　　· 提前并多方面准备充分的测试数据以覆盖到所有测试用例

　　· 测试人员测试思维和测试意识的提高

　　· 组织部门内部的业务知识培训

　　· 组织部门内部的技术技能培训

　　· 组织部门内部的测试交流活动

　　· 测试环境要尽量贴近生产环境

　　· 保证测试环境数据库与生产环境的版本和配置一致

　　· 保证测试环境服务中间件与生产环境的版本和配置一致

　　· 可以的话，保证测试环境主机配置与生产环境主机配置一致

　　· 可以的话，保证或模拟测试环境的网络环境与生产环境的一致

　　· 要注意环境的兼容性测试问题，如系统、版本、分辨率等

　　· 测试执行过程的规范性、严谨性和策略性

　　· 测试过程严格按照测试用例执行

　　· 适时进行结对测试和交叉测试

　　· 适时加入探索性测试或随机测试

　　· 测试前，测试人员必须熟悉业务需求，亦要熟悉软件逻辑

　　· 测试过程中要不断补充遗漏的测试用例

　　· 测试过程尽量贴近用户实际环境去测

　　· 如有不影响实际使用的生产环境提供测试，最好在生产的环境和接口上进行测试

测试策略的制定与及时调整

　　· 测试前根据风险定好测试策略，做好测试安排

　　· 测试过程时刻关注项目进度，随时做好测试调整的准备

　　· 如有充足的测试时间，最后一轮应该进行全面的回归测试

　　· 如有充足的测试时间，可以进行生产环境的beta测试

　　· 回归测试必须重点关注开发的修改范围，以免遗漏新引入的缺陷

　　· 漏测的原因分析及分享和漏测财富库的建立

　　· 每当出现漏测现象，必须分析原因并组内通报，吸取教训

　　· 每当出现漏测，必须将漏测的缺陷及原因分析录入财富库

　　PS：

　　1、当出现因为漏测反馈回来的问题时，测试管理者必须重视，并积极处理。立刻安排测试人员重现缺陷，并分析漏测原因。

　　2、漏测时缺陷一定要进行分析原因，思考总结和吸取经验教训，并在部门内部公开学习，以免其他成员同样情况再次发生，尽可能减低缺陷的漏测量。

　　3、往往实际项目过程中，测试时间一般不会太充分，测试是基于风险和策略去进行测试的。因此，如何在有限的资源（时间，人力等）内进行有效的，充分的测试是每一个测试管理者需要思考的问题。