测试质量保障漏测原因和预防

一、什么是漏测？

　　漏测，是指软件产品在测试阶段未被发现，而是在产品发布上线之后，用户在使用过程中发现存在的缺陷。

二、为什么会漏测？

　　谁也不能保证说经过我测试的东西完全没有问题，包括经验丰富、工作多年的资深测试工程师，或多或少的会出现自己没有考虑到的场景，谁也不能把软件所有的功能操作、使用场景想的十分周全，特别是功能复杂、业务关联性比较强的系统。

三、漏测产生原因

漏测大致有如下原因：

需求评审质量低、不规范、设计缺陷、遗漏、描述歧义等

需求变更频繁，PRD或用例未及时更新

技术实现设计缺陷，引入新组件、在未来某一时刻或数据存在问题

开发新功能或修复缺陷从而引入的新缺陷

上游系统不稳定、时好时坏

测试环境和生产环境出入

测试环境或测试数据受限，无法模拟覆盖真实场景

用例设计过于粗狂、覆盖不全

测试过程不规范、未按照测试用例执行

测试思维局限、业务理解不透彻、考虑不足

测试人力资源、时间不足，导致测试不充分，未完全覆盖所有场景

四、如何预防漏测

　　我们知道，缺陷越早被发现，发现和解决缺陷所花费的成本就越小，如果在测试阶段就尽可能发现更多问题，那么所花的成本就小很多。测试是保障软件质量最重要的手段之一，因此，预防漏测、进行漏测分析、使缺陷尽可能在测试早期发现，是非常有意义的，有利于降低软件成本，提高软件产品质量。

需求评审质量提高：

需求评审过程规范、详细的PRD、开发和测试人员参与

需求评审需要有业务熟悉和测试经验丰富的人员参加

每次需求变更及时更新PRD和测试用例

项目流程改进：

测试用例评审（组内评审、开发产品评审）

技术方案评审&codereview

研发提测标注影响范围

研发自测通过

测试质量提升：

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

测试过程中遗漏和启发的用例及时补充

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

提测前充分准备测试数据尽量覆盖所有测试用例

测试数据足够丰富、多样化、特殊数据

业务覆盖、关联模块、相关功能验证

测试需覆盖需求未说明的（提高易用性、提示、校验、页面样式等）

站在用户角度测试（好不好用、符不符合用户习惯、是否易于理解等）

前后端都需要校验（尤其一些涉及用户信息、金额、数量等影响数据安全和资金安全的场景，前端校验同时也能减轻服务器和网络压力）

测试执行过程规范、严谨

必要时进行交叉测试

适当加入探索性测试或随机测试

测试完毕，思考是否测试充分，是否可能存在其他遗漏场景

有效回归测试（包括主流程测试、自动化测试）

专业度提升：

测试人员思维、专业能力提高

组织内部的相关技术培训

组织内部的业务知识培训

多学习、多交流、多总结

环境：

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

保障测试和生产环境数据库、中间件、版本和配置一致

覆盖兼容性问题，如系统、版本、分辨率等

常用测试方法： 等价类、边界值、正交法、因果（场景）、错误推断（经验）

测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

五、总结

出现漏测，必须分析原因，吸取教训，避免其他成员遇到类似情况发生，尽可能减少问题漏测；

版本上线后，及时总结测试过程中遇到的问题并改进

线上问题，定期组织复盘，了解问题根本原因，杜绝问题再次发生，包括流程改进、技术方案优化、测试过程改进等；

漏测是不可能避免的，我们能做的是尽量减少漏测，预防漏测、正确对待问题加以改进，漏测随着我们不断总结和经验的积累，而逐渐减少。