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