敏捷了，自动化测试怎么搞？（2010-8-16）（获奖名单已公布）

velata

这个问题还是得看自动化的目的是什么，不同的目的有不同的做法。
目的1：回归之前的功能，确保之前的功能没有因为本次迭代新开发的代码而损坏。
目的2：测试本次迭代中的新功能。

先说第一种，由于在团队中还有其他的功能测试人员存在，所以当前迭代的功能不需要立即开始自动化编码，可以等到下个迭代，功能、界面稳定后再开始对当前迭代的功能进行实现。在这种情况下自动化测试的压力相对就不会很大了。

对于第二种目的，可能会比较麻烦。根据实践个人觉得有以下两种方式：
1)在开发人员进行新功能开发（或老功能维护）前，跟自动化测试工程师先讨论好开发思路，测试工程师准备case、数据，等新功能开发完成后，测试工程师再开始脚本开发。
2)自动化测试工程师只负责自动化测试框架的搭建、公共功能自动化脚本开发、对开发人员的培训（自动化测试框架方面），当新功能的自动化测试脚本由开发人员来编写。

不论是第一种目的还是第二种都应注意，当敏捷活动中有持续集成，那么自动化测试还需要跟持续集成结合起来，每集成一次，自动化脚本就运行一遍。（如果集成的频率非常高的话，可能要注意自动化测试脚本的效率或者是脚本的裁剪、筛选）

[ 本帖最后由 velata 于 2010-8-22 22:40 编辑 ]

velata

原帖由 michaelwxm 于 2010-8-17 10:42 发表
TDD吧

TDD跟自动化测试是两码事吧？
TDD只是测试驱动开发，先编写测试脚本，通过不断的编写代码使得测试通过，主要还是在单元测试层面的。
而自动化测试会偏向验证功能，其中还有很大一部分是测试场景设计、测试数据设计。

velata

原帖由 danmy 于 2010-8-23 14:18 发表
问题的提出应该是针对系统测试阶段的自动化测试而言，因为敏捷要求的频繁迭代，已经要求有自动化程度非常高的单元测试代码，TDD也是基于此。从另一层面上说，敏捷测试更多强调的是单元测试的成效，所以传统的自动化测 ...

嗯 我倒是对“自动化测试”的理解狭隘了！如果TDD做好、做强大了，也能满足要求。
不管啥活动，都是为了提高项目质量滴。。。