测试质量保障-漏测原因和预防
作者：互联网
一、什么是漏测？
漏测，是指软件产品在测试阶段未被发现，而是在产品发布上线之后，用户在使用过程中发现存在的缺陷。
二、为什么会漏测？
谁也不能保证说经过我测试的东西完全没有问题，包括经验丰富、工作多年的资深测试工程师，或多或少的会出现自己没有考虑到的场景，谁也不能把软件所有的功能操作、使用场景想的十分周全，特别是功能复杂、业务关联性比较强的系统。
三、漏测产生原因
漏测大致有如下原因：
需求评审质量低、不规范、设计缺陷、遗漏、描述歧义等
需求变更频繁，PRD或用例未及时更新
技术实现设计缺陷，引入新组件、在未来某一时刻或数据存在问题
开发新功能或修复缺陷从而引入的新缺陷
上游系统不稳定、时好时坏
测试环境和生产环境出入
测试环境或测试数据受限，无法模拟覆盖真实场景
用例设计过于粗狂、覆盖不全
测试过程不规范、未按照测试用例执行
测试思维局限、业务理解不透彻、考虑不足
测试人力资源、时间不足，导致测试不充分，未完全覆盖所有场景
四、如何预防漏测
我们知道，缺陷越早被发现，发现和解决缺陷所花费的成本就越小，如果在测试阶段就尽可能发现更多问题，那么所花的成本就小很多。测试是保障软件质量最重要的手段之一，因此，预防漏测、进行漏测分析、使缺陷尽可能在测试早期发现，是非常有意义的，有利于降低软件成本，提高软件产品质量。
需求评审质量提高：
需求评审过程规范、详细的PRD、开发和测试人员参与
需求评审需要有业务熟悉和测试经验丰富的人员参加
每次需求变更及时更新PRD和测试用例
项目流程改进：
测试用例评审（组内评审、开发产品评审）
技术方案评审&codereview
研发提测标注影响范围
研发自测通过
测试质量提升：
提升测试用例质量（颗粒度、需求覆盖度、冗余度等）
测试过程中遗漏和启发的用例及时补充
建立通用测试用例库和框架、建立优质测试用例
提测前充分准备测试数据尽量覆盖所有测试用例
测试数据足够丰富、多样化、特殊数据
业务覆盖、关联模块、相关功能验证
测试需覆盖需求未说明的（提高易用性、提示、校验、页面样式等）
站在用户角度测试（好不好用、符不符合用户习惯、是否易于理解等）
前后端都需要校验（尤其一些涉及用户信息、金额、数量等影响数据安全和资金安全的场景，前端校验同时也能减轻服务器和网络压力）
测试执行过程规范、严谨
必要时进行交叉测试
适当加入探索性测试或随机测试
测试完毕，思考是否测试充分，是否可能存在其他遗漏场景
有效回归测试（包括主流程测试、自动化测试）
专业度提升：
测试人员思维、专业能力提高
组织内部的相关技术培训
组织内部的业务知识培训
多学习、多交流、多总结
环境：
测试环境尽量贴近生产环境
保障测试和生产环境数据库、中间件、版本和配置一致
覆盖兼容性问题，如系统、版本、分辨率等
常用测试方法： 等价类、边界值、正交法、因果（场景）、错误推断（经验）
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等
五、总结
出现漏测，必须分析原因，吸取教训，避免其他成员遇到类似情况发生，尽可能减少问题漏测；
版本上线后，及时总结测试过程中遇到的问题并改进
线上问题，定期组织复盘，了解问题根本原因，杜绝问题再次发生，包括流程改进、技术方案优化、测试过程改进等；
漏测是不可能避免的，我们能做的是尽量减少漏测，预防漏测、正确对待问题加以改进，漏测随着我们不断总结和经验的积累，而逐渐减少。
标签：场景,漏测,评审,测试用例,测试,缺陷,预防 来源： https://www.cnblogs.com/xiaoxitest/p/16197874.html