一、定义：

所有测试均在开发后期进行。

二、发生时间段

1. 计划和详细文档有一定复杂度的测试项目

2. 项目进度计划复杂，时间足够长使测试被推迟。

三、陷阱表现

1. 项目总体进度计划上，测试排在开发后期执行

2. 测试只在需求工程、架构工程、设计、编码实现后才参与 ，此时所有的缺陷已被创建。（未能预防或产生时发现）

3. 开发周期的早中期，无计划执行单元或集成测试。

4. 当前增量 、迭代构建期间，无足够时间测试， 使当前构建的部分或全部测试推迟到后续的构建过程中。

四、负面后果

1. 进度计划中无足够时间纠正发现的重大缺陷。

2. 难以达到并展现所需的测试覆盖度 。

3. 因系统有很多已经在测试之前集成了，难以找到并定位仍隐藏在系统内部的Bug

4. 测试从一个构建推迟到另一个构建 ，制造了一个不断增长的测试冲击波，永远不能被执行，除非从根本上改变进度计划，推迟除了测试外的其他工作，直到测试追上进度（必要条件）

五、原因

1. 项目使用了传统的、连续的瀑布式模型 ，没有发生需求、架构、设计的测试（即用了单v 而非双v模型 ）

2. 管理层未在开发周期的早期阶段配备测试团队人员。

3. 管理层未认识到低 级别（单元、集成）的测试的需要。

4. 在增量、迭代的构建内没有分配足够时间以开发迭代增量并充分测试。

六、建议

准备阶段：

• 从开发过程早期开始，计划并安排测试进度，以迭代地、增量地、并行地方式进行。

• 提供增量、迭代测试培训。

• 在项目的系统工程过程中融入迭代和增量测试。

启用阶段：

• 在开发过程的早期提供足够测试资源 （人、工具、预算、进度）

执行阶段：

• 从开发早期开始，以迭代、增量、并行方式执行测试。

• 测试与开发人员紧密合作，使新的或更新的组件一旦可行就尽快进行单元和集成测试。

验证阶段：

• 以持续进行的方式（项目重大里程碑点）确定测试是否迭代地增量地并与设计、实现和集成并行进行。

• 使用测试度量指标确定测试状态和持续进展 。

七、相关Bug

测试和工程过程未集成 ， 测试作为一个阶段 ，早期不参与。