一、定义：
测试人员除了按照需求文档编写case外，未添加其他项目计划、开发文档等形成的case
二、发生时间段
Always
三、陷阱表现
1.质量需求（易用性、可靠性、健壮性、可移植性、安全性、可维护性等）
2.数据需求（如：统计类需求）
3.接口需求（如：针对迭代需求较少时，容易忽略细微的新增接口，或是测试人员认为不会影响到基线功能）
4.针对异常的系统强制响应（常见的有提交表单时机器卡顿，网络异常）
四、负面后果
1.基于需求的测试不会表现出疏漏的行为和特征。
2.管理层或其他开发人员认为交付的系统会正常运行。
3.测试人员必须与产品或客户经常讨论测试过程中确定的疏漏的需求。
4.疏漏的需求在测试过程中未发现，交付了部署系统
5.疏漏需求导致架构设计不充分，使开发人员排查Bug更加困难。
五、出现原因
1. 产品人员未经专业培训，使形成的需求文档逻辑不足，如不懂质量模型，未描述系统质量特性
2. 发现疏漏需求时，产品人员未及时更新需求池和PRD
3. 测试用例只定义了正常的用例路径 ，未对故障、失效容错做充分定义
4. 项目其他管理人员未评审过需求
5. 产品没有充足的时间和资源对产品进行分析。
六、建议
1. 准备阶段
对于识别出的遗漏需求，对产品进行需求过程相关培训。
2. 启用阶段
为产品人员提供识别遗漏需求的专业培训。
确保测试进度计划中包括足够时间解决测试过程中发现的遗漏需求。
3. 执行阶段
（1）识别遗漏需求方法：端到端的任务线程模型、用例建模、质量模型。
（2）需求文档静态测试，考虑到错误、故障和失效容错 。
（3）需求文档和需求池的内容需要经过专家或业务代表评审
（4）测试过程中发现的疏漏需求要及时通知到产品
4. 验证阶段
（1）检查是否进行了足够的需求建模
（2）检查需求是否充分考虑到错误、故障和失效容错
（3）检查需求池中是否包括适当数量的质量和数据需求
（4）检查是否需求已由足够数量的系统相关人员评审
（5）检查测试过程中发现的所有遗漏需求 ，是否已通知产品人员。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
