一、定义：

测试自动化的数量过少，无法充分回归测试。

二、发生时间段

Always

三、陷阱表现

1.大多数测试靠手动执行

四、负面后果

1.手动执行回归测试需消耗过多时间和资源

2.回归测试作为系统测试的最后一个阶段，可有可无，时间不充足，不能够发现更多bug

3.测试工程师手动执行失误不可避免

4.缺乏足够测试自动化使得敏捷开发模式不能有效顺利执行

五、原因

1. 管理层及单元测试开发人员认为，大部分变更是小范围的，系统测试足够发现，从而认为回归测试非必要；而且非技术管理层无法意识到回归测试的重要性、自动化回归测试的价值、敏捷开发模式对测试自动化的依赖。

2. 自动化回归测试并非标准测试过程的一环

3. 测试计划中未体现自动化回归测试

4. 项目计划中未安排时间开发维护自动化测试

5. 项目原自动化测试脚本未及时维护

6. 项目原自动化测试脚本在项目交付时未提供。

六、对自动化回归测试的建议

1.准备阶段

项目开始前需列入计划中，如测试计划、测试过程文档、总体进度计划、WBS

2. 启用阶段

为测试管理层提供关于自动化回归测试的重要性及培训计划

进度计划中计算自动化和维护测试的时间

测试资源或预算考虑到测试自动化工具的支付

3. 执行阶段

（1）自动化回归测试需要对应开发人员的协作支持（测试人员确定回归测试类型、Case标准、Case、测试完成标准等；开发人员创建自动化的回归测试，包括工具的配置、脚本编写等）

（2）自动化测试可以执行更多回归测试

（3）使运行回归测试尽可能简单，可以编写定时脚本在任意时间执行（如定时执行或在非工作时间）

（4）系统版本更新时，及时维护测试脚本

（5）结束时，测试脚本随产品交付。

4. 验证阶段

（1）验证各测试文档（eg.测试计划、测试过程、WBS）充分考虑到自动化的回归测试

（2）验证进度计划中包含自动化和维护测试的时间

（3）验证自动化测试的数量

（4）验证自动化测试的项目可正常运行

（5）验证自动化测试已随产品交付。

本文转自 honzhang 51CTO博客，原文链接:http://blog.51cto.com/hongz/2058979