一、定义：
过分强调功能测试，而非测试质量、数据和接口需求。以及测试架构、设计和实现的约束。
二、发生时间段
非功能性需求中。
三、陷阱表现
1.大多数的测试关注验证功能性表现
2.没有验证质量特性的适当水平（如：可用性、可靠性、健壮性、安全性、保密安全性、易用性）
3.测试工程师、可靠性工程师、安全性工程师、人为因素工程师未执行相关专业测试类型（如未执行***测试）
4.只在系统交付并投入运行后，才确认各种质量特性和其属性的不足水平。
四、负面后果
1.测试无法验证系统是否具有重要质量特性，是否满足所有的相关的质量需求。
2.集成后期或交付后，才确认无法满足数据和接口的需求
3.系统交付延迟，未能满足不可接受的大量的非功能性需求。
五、原因
1. 测试计划和过程文档并没有充分地考虑测试非功能性需求。
2. 无过程需求强制要求对非功能性需求的专门测试
3. 管理层、研发、测试认为：
(1) 测试其他类型的需求（数据、接口、质量及架构、设计、实现或配置约束）比较困难。
(2) 应用测试外的其他方法(分析、审查和评审)来验证质量需求
(3) 因其交叉性质测试这些非功能性需求需花太长时间
(4) 与功能需求相比 ，非功能性需求不是很重要
(5) 非功能性测试会作为测试功能需求的副产品而自然发生
4. 其他类型需求（质量需求）
5. 功能测试是开发合同中规定的唯一的测试。
六、建议
1.准备
在测试计划和过程文档中充分地考虑测试非功能性需求
在合同中包括过程需求，强制规定非功能性需求的专业测试
2. 启用
确保管理层、开发、测试了解非功能性需求及符合架构和设计（通过白盒测试）的重要性
3. 执行
充分地进行其他类型的测试
4. 验证
(1) 确定管理层、开发、测试是否理解测试非功能性需求和符合架构设计、实现和配置约束的重要性
(2) 确定质量工程师是否验证了测试人员测试非功能性需求和约束
(3) 确定测试计划和过程文档是否充分考虑测试非功能性表现
(4) 确定是否度量、分析和报告类型的非功能性缺陷。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
