作为被冠以敏捷名称的测试，敏捷测试同样以快为目标。在敏捷测试中，快有三个方面的含义：
- 团队能够通过测试快速获知系统当前所处的状态，了解距离可工作的软件还有多远；
- 能够在一个迭代周期中快速完成回归测试和对新功能的测试；
- 开发工程师能够从持续的测试中得到快速的关于提交代码反馈。
简而言之，敏捷测试要求测试能够测试在短的时间间隔内持续发生且能够在短时间内完成。考虑到纯粹的依赖人工测试基本不可能达到短的时间间隔内持续发生和短时间内完成这两个目标，而自动化测试在执行效率方面具有天然的优势，在敏捷测试中使用自动化测试技术应该是自然而然的选择。
考察敏捷开发中的一个迭代周期：
- 在迭代周期开始的时候，团队与客户一起定义本迭代周期内需要完成的功能；
- 团队建立验收测试验证标准；
- 开发工程师开始实现新功能，使用TDD为产品建立安全网，使用持续集成尽可能保证每一次代码提交不引入新的缺陷；
- 所有新功能被添加后，在RC上运行回归测试保证原有功能的正确性；针对新功能运行测试保证新功能的正确性；
- 执行验收测试验证系统是否达到可交付的标准。
除1和2外，剩下的3个项目都与测试执行密切相关，如果依靠手工测试来进行这些项目，毫无疑问，测试会成为整个敏捷开发的瓶颈。而如果把这些项目中的测试建立在合适的自动化测试基础上的话，测试就可以和开发一起敏捷起来。从这个角度来说，把自动化测试描述成敏捷测试的基石毫不夸张。
自动化测试并不是新鲜事物。从80年代起，对软件自动化测试的研究就从来没有停止过，而自动化测试工具也一直是测试工程师津津乐道的话题。IBM、HP、Borland等许多提供软件开发解决方案的公司都拥有完整的测试解决方案；在开源社区，自动化测试工具的种类也不下于100多种。这么说起来，是不是只要选择了合适的工具在测试中进行部署，就能快速的建立起敏捷测试需要的自动化测试基础了呢？根据美国某组织在2005年开展的一项非正式的调查，在所有参与被调查的200多个自动化测试项目中，完全成功的只有30多个，不到20%；完全失败的却达到100多个，占到了50%的比例。
自动化测试项目为什么会失败？根据调查，不合适的自动化测试目标与从自动化测试中无法获得收益是项目失败的主要原因。希望把自动化测试定义为完全替代手工操作、期望仅仅在UI层建立自动化测试都不是合适的自动化测试目标；尤其是在UI层建立自动化测试这个目标一定会带来无法从自动化测试中获得收益的后果。
UI自动化测试是自动化测试领域中较早被研究的，其主要出发点是使用工具和脚本驱动应用操作，依靠工具对UI层的元素属性进行验证。现有的大部分商业测试工具，如IBM Functional Tester、HP QTP等都属于这一类工具。从好的方面来说，UI自动化测试相对其他自动化测试更接近真实用户；但不得不说的是，UI自动化测试的高昂的投入往往是组织不能持续进行自动化测试原因。
我参与第一个自动化测试项目的时间是在12年前。在那些惨痛的日子里，我会痛苦地看着我苦心建立的自动化测试脚本以高达50%的失败率运行，然后再花上2个星期更痛苦的调试和修复自动化测试脚本的时间。随着脚本数量的增加，我的痛苦如日俱增。最后，我不得不放弃了对这些昂贵的自动化测试脚本的维护，转向我情感上不情愿，理智上却不得不做的选择：重回手工测试。
12年前的例子并不是我唯一经历的UI自动化测试的痛苦，实际上，在10多年的软件测试生涯中，这样的不愉快各种情况下一再重复。下表是前年我们的某个完全依赖于UI自动化测试项目中的自动化测试投入产出比较表。
|
自动化测试覆盖率 |
功能点数量 |
测试用例数量 （自动化/全部） |
自动化测试执行 失败率（平均） |
每个测试周期的 人员投入 |
|
0% |
65 |
0/182 |
- |
2人周 |
|
20% |
83 |
41/210 |
10% |
1.5人周 |
|
44% |
110 |
131/302 |
22% |
2人周 |
|
61% |
120 |
213/350 |
43% |
3.5人周 |
UI自动化测试带来痛苦的主要根源在于UI本身的不稳定性。由于UI是应用与用户的直接交互界面，用户的大量需求都直接对应在UI本身的改变上，这就导致了UI本身的不稳定，建立在UI上的自动化测试也因此不稳定。当然，除了不稳定外，UI自动化测试带来的测试环境的需求也是导致UI自动化测试开销剧增的原因之一；另外，UI自动化测试本身并不能很好的帮助定位缺陷，对开发工程师而言，其在反馈上的价值远不如单元测试。
除了UI自动化测试外，在敏捷测试中其他可用的自动化测试还包括单元测试与接口测试（或者叫服务测试）。下图是敏捷开发中被广泛认可的自动化测试产出金字塔，在相同投入的情况下，单元或是代码级测试能带来最大的收益，而UI层面的收益最小。
自动化测试所涉及的技术非常多，例如在单元测试中经常需要使用到的Mock技术，基于针对不同语言而不同的解依赖技术等；在接口测试层面，更是需要根据接口本身的类型和特点确定具体的测试技术；在UI层，根据应用的不同（桌面应用，Web应用，嵌入式应用等），自动化测试技术也存在巨大的差异。
关于各种自动化测试技术的讨论，本文在后续文章中会选择其中的一些进行重点介绍，本文则主要介绍Diff技术这种与传统的比较预期输出与实际输出略有不同的自动化测试技术。
Diff技术，顾名思义，其主要关心的是不同。以搜索引擎产品的测试为例：以同一个关键字在搜索引擎上进行多次重复测试（查询），随着时间段的变化，搜索引擎的索引数据也在发生变化，即使对同一个关键字，也不太可能在每次测试时给出一个所谓的预期结果。
怎样才能在这种情况下开展测试？一种可行的技术是就是Diff技术。下图展示了Diff方法的应用。
简单来说，Diff方法的应用包括以下步骤：
- 设置两个待比较的版本实例（通常是相邻的两个版本，例如RC和上一个产品版本），两个版本具有相同的数据基础或后端环境；
- 使用发送模块同时向两个版本发送相同请求；
- 比较模块收集两个实例的输出并对其进行比较；
- 比较结果输出为Diff报告。
Diff报告体现的是两个实例之间的不同，不同并非一定是由于缺陷导致，因此Diff报告需要通过人工审阅，判断报告中不一致的原因，决定后续步骤后续步骤通常包括创建一个缺陷，安排探索性测试，或是据此确定回归测试范围等。
Diff测试技术可以在多个测试层面上被应用。例如，在UI层面上，可以通过图片Diff的方式（比较两个版本在相同输入情况下的UI截图）发现应用界面上的变化；对Web应用来说，也可以以文本Diff的方法比较两个实例输出的HTML文档，或是特定页面元素；在接口层面上，可以比较在两个实例上，相同的UI操作导致的前后端通讯的不同
Diff技术甚至可以在测试过程中帮助确定测试范围。例如，对一个RC的全面的Diff发现，所有100个功能点中，有80个功能点的Diff结果与上一个版本没有任何差异，有20个功能点的Diff结果与上一个版本存在差异。基于这个结果，我们可以很容易的将存在差异的20个功能点作为RC测试的重点个人认为，与依靠代码分析确定测试范围相比，这种方式直观有效得多。
当然，在实际项目中应用Diff技术也会遇到很多挑战，如何尽量消除Diff结果中的噪声是一个关键问题。以应用基于图片的Diff技术为例，如何消除图片比较结果中的噪声就是一个既需要技术手段（通过图片比较算法）也需要非技术手段（建立针对每个页面的mask）的话题。