一、定义：
测试方法单一，不分测试点关键级别，严格水平相同 。
二、发生时间段
可能发生在任何时间。
三、陷阱表现
测试计划文档只包含通用、模板测试指南，而非适当的、针对系统的具体信息。
所有测试都采用相同方法， 未依据需求类型或所验证系统的类型。
在任务、安全及保密上关键系统或组件，未比其他次关键的组件要求更严格和全面。
只有适用于测试功能性需求的一般技术 ，没有验证质量需求（可用性、容量、性能、可靠性、健壮性、安全性、保密性、易用性需求）的专门类型的测试描述。
四、负面后果
任务性、安全性等关键组件未经充分测试。
没有专门的测试来验证系统或软件具有重要质量特性和属性的足够水平。如没有***测试 或易用性测试。
无足够资源充分测试所有软件 ，有限资源被误用于低优先级的软件 ，而非测试更关键组件。
有些Bug未发现，通过测试进入了部署的系统。
系统不符合非功能性需求（即数据、接口和质量需求，及架构 、设计、实现或配置约束）
系统不足够安全或保密安全。
五、原因
未区分关键与非关键组件的测试过程要求。
测试计划模板和内容或格式标准不完整，未考虑任务、安全关键性对测试的影响。
无工程化质量需求 （安全性与保密安全性）
测试人员不熟悉安全性与保密安全性对测试的影响。（测试的高严格等级要求取得鉴定和认证）
测试人员与安全保密人员间沟通不畅。
六、建议
准备阶段
为软件开发及测试人员培训，考虑包括项目特定的、专业测试信息的需要。
为测试计划和开发文档（流程、指南等）做模板，满足项目和系统特定信息的需要。
启用阶段
更新开发、测试和过程文档的模板或格式内容标准，以解决所需测试的类型、完整性和严密性。
执行阶段
在开发测试计划文档中做到：
测试类型差异或完整性和严密性的程序和任务、安全关键性的关系 。
测试质量需求和专业工程测试方法和技术。
比次关键的组件或系统更完整、更严格的测试。
验证阶段
确定测试的完整性、类型和严密性是否：
在系统开发和测试计划中考虑
系统或子系统的关键性相关
充分，基于被测系统或子系统的关键性程度。
七、相关Bug
测试优先级不足，测试沟通不充分。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
