一、定义：
测试自动化的数量过少，无法充分回归测试。
二、发生时间段
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
