一、定义:
所有测试均在开发后期进行。
二、发生时间段
计划和详细文档有一定复杂度的测试项目
项目进度计划复杂,时间足够长使测试被推迟。
三、陷阱表现
项目总体进度计划上,测试排在开发后期执行
测试只在需求工程、架构工程、设计、编码实现后才参与 ,此时所有的缺陷已被创建。(未能预防或产生时发现)
开发周期的早中期,无计划执行单元或集成测试。
当前增量 、迭代构建期间,无足够时间测试, 使当前构建的部分或全部测试推迟到后续的构建过程中。
四、负面后果
进度计划中无足够时间纠正发现的重大缺陷。
难以达到并展现所需的测试覆盖度 。
因系统有很多已经在测试之前集成了,难以找到并定位仍隐藏在系统内部的Bug
测试从一个构建推迟到另一个构建 ,制造了一个不断增长的测试冲击波,永远不能被执行,除非从根本上改变进度计划,推迟除了测试外的其他工作,直到测试追上进度(必要条件)
五、原因
项目使用了传统的、连续的瀑布式模型 ,没有发生需求、架构、设计的测试(即用了单v 而非双v模型 )
管理层未在开发周期的早期阶段配备测试团队人员。
管理层未认识到低 级别(单元、集成)的测试的需要。
在增量、迭代的构建内没有分配足够时间以开发迭代增量并充分测试。
六、建议
准备阶段:
从开发过程早期开始,计划并安排测试进度,以迭代地、增量地、并行地方式进行。
提供增量、迭代测试培训。
在项目的系统工程过程中融入迭代和增量测试。
启用阶段:
在开发过程的早期提供足够测试资源 (人、工具、预算、进度)
执行阶段:
从开发早期开始,以迭代、增量、并行方式执行测试。
测试与开发人员紧密合作,使新的或更新的组件一旦可行就尽快进行单元和集成测试。
验证阶段:
以持续进行的方式(项目重大里程碑点)确定测试是否迭代地增量地并与设计、实现和集成并行进行。
使用测试度量指标确定测试状态和持续进展 。
七、相关Bug
测试和工程过程未集成 , 测试作为一个阶段 ,早期不参与。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。