敏捷测试过程中的自动化目前在国内来看基本上还只是停留在概念阶段，据我所知，目前不少公司也都在尝试过程中，而实际的实践中能取得比较理想成果的，极为有限。而国外不少同仁也都对此持观望甚至抵触的态度。比如advanced QTP论坛的administrator Meir大大 就认为敏捷过程中的自动化是完全不现实的，理由就是sprint间隔时间内没办法完成一个完整自动化过程的设计，而频繁的变更会导致自动化资源的大量浪费，ROI上无任何前景可言。
从我个人观点来看，没必要保持如此的悲观，但更不能过于乐观。敏捷过程是IT发展的产物，自动化从概念上来看是确认一个sprint成功的重要一关。敏捷过程需要有自动化测试，但却不能盲目让自动化介入，否则很可能适得其反。
个人略作了下小结，由于敏捷模式的种种特色，敏捷过程中的自动化实现所需要满足的条件比常规的自动化测试活动苟刻的多，除了普通自动化过程必须具备的条件之外，主要还有以下几点：
1、对于自动化工程师的要求更高，除了解决种种突发异常的自动化技能以外，还需要对项目的业务知识有比较多的了解。
在敏捷模式中，文档不会像传统的模式中那样完备，测试的case可能会相对简易，不少内容都只是口口相传，敏捷团队的成员也不可能专门派一个人出来辅助自动化工程师解决业务问题，那么就要求自动化工程师对于业务知识比较了解了，就算对项目了解有限，但至少要有背景知识，大多数情况下能理解一句话中所包含甚至是隐含的一系列业务操作。
2、项目成员结构上，自动化工程师需要成为敏捷团队的一员，而不是编外人士。理由很简单，敏捷团队经常会召开类似头脑风暴的会议，一个短暂而激烈的会议足以决定一个变更，然后大家立马投入工作中。这时自动化工程师若作为编外人士，那很可能就得不到这第一手的消息了，很可能吭哧吭哧好不容易码完的脚本还没跑过就得改了。
3、对于项目、产品的要求。被测系统必须是非常适合自动化的，在自动化脚本开发过程中不应当遇到被某个技术实现难倒的问题，敏捷模式下是没可能有几天甚至一周的时间去处理某个自动化的技术细节的。这就需要在接受项目前做自动化可行性评估的时候考虑周全，是否有某些核心的功能无法被自动化，可以接受多少功能不被自动化。
另外各story间不能有太强的依赖，因为很可能自动化工程师无法完成对所有功能的自动化，而一个story的需求变更也不应导致其它story有太多变化。
4、对于BA的要求。BA需要对产品的主要功能非常了解，非常清楚哪些功能是不太会变更，而哪些部分是不太有把握的，同时对客户也要有一定的掌控能力。这样除了提供主要的测试点以外，还能结合变更来给同为最高级别的测试点附加上自动化优先级，在很大的程度上避免自动化工程师的重复劳动。
总的来说，要实施自动化，对团队的成员素质要求非常高，也要求成员间的配合比较默契。说实话，真的很难，但并不是不可实现。
会员 maguschen：
这个问题有点大，我现在所处的公司也是应用了敏捷开发，下面分享一下我们公司做自动化测试的一些经验
首先，敏捷开发并不是部分同学想象中的那样，没有文档没有需求，开发来了就干，干几个月就丢给客户一个版本让他们用去，我们公司一般6个星期是一个release周期，在这6个星期里面，可以做的事情是非常多的
1、需求，需求通常来自于PM，在一个release周期的开始，QA通常没太多事情需要做，比较重要的工作就是跟PM沟通当前feature的一些情况，在这个时候，QA可以做一些自动化测试的准备。例如在某个release里面我知道在接下来的测试当中我需要频繁地比较CSV文件，那么作为QA就应该在项目还不是很紧张的时候就开支准备自动化测试的脚本，例如刚才说的这个CSV文件比较工作
2、开始开发，如果公司是实时TDD开发，那么这个时候QA可以做的事情大概有2个，帮助开发写单元测试用例，并且实施自动化测试（主要是单元测试），另一个是review（虽然不是自动化测试的内容）
3、正式提交测试，OK，这个时候是我们QA比较忙的时候了，这时候很有可能出现几个情况，1. 跟我的预想一样，我真的需要一个CSV文件比较工作，并且只需要这一个工具，并且我已经完成了，那么就可以进行测试了。2. 可能有一些新的自动化测试需求跑出来了，例如每天晚上自动比较几万个CSV文件并且把测试结果发给相关的人，这时候作为QA，在考虑资源允许的情况下，应该尽早完成这个工具，而不是每天晚上爬起来看结果并非法邮件
4、发布完毕以后，回过头来看工具，是否有值得改进的地方，是否能够改进一下就能够给整个Team使用
以上算是一个release周期里面的一些微观的工作，宏观上来说需要做点什么事情呢？
现在提到的敏捷开发，都有一个很突出的特点，就是产品快速交付给客户，为了快速交付这个目的，公司里面每个团队都作出了努力，那么具体到QA团队，肯定就是要在保持测试质量得到保证的前提下，尽可能地缩减测试所需要的时间，使得产品按时按质交付。要达到这个目的，总靠一些AD-HOC的工作（例如刚才提到的突然写个CSV比较工具）是不可能达到要求的，那应该如何进行呢？
敏捷开发也是开发，产品不是孙悟空，不会某一天就从石头里面爆出来了。在产品开发的前期（例如0.1, 0.2版本之类），尽可能地想办法搭建一个自动化回归测试的框架，这个框架的特点有：1. 快速完成回归测试； 2.能够快速地添加测试用例并且跑起来；3.能够随着产品的演化而不断改进（不能是那种用1~2个release就要扔的东西）；4.维护的成本要低（在一个release周期里面如果自动化测试需求有变化，不应该需要超过1个星期的时间才能改好，当然翻天覆地的变化除外）
综上所述， 我认为在敏捷开发里面的自动化测试是有2条路线，并且这2条路是并行的，缺一不可
1、至少一个自动化回归测试框架，保证release前能够对产品进行覆盖较为全面的回归测试
2、工作中*不断地*开发自动化测试工具，提高自己的生产率
以上两点的目的很简单，就是要在保持产品质量处于一个较高水平的情况下，帮助公司尽可能地快速交付新版本的产品。