中国高级测试经理对敏捷测试的理解

对软件测试中的技术和管理工作有独到见解，对软件测试团队管理、自动化测试、性能测试与开发测试有较多研究。

敏捷测试以“快”为目标。在敏捷测试中，“快”有三个方面的含义：

团队能够通过测试快速获知系统当前所处的状态，了解距离可工作的软件还有多远；

能够在一个迭代周期中快速完成回归测试和对新功能的测试；

开发工程师能够从持续的测试中得到快速的关于提交代码反馈。

简而言之，敏捷测试要求测试能够测试在“短的时间间隔内持续发生”且能够在“短时间内完成”。

考虑到纯粹的依赖人工测试基本不可能达到“短的时间间隔内持续发生”和“短时间内完成”这两个目标，而自动化测试在执行效率方面具有天然的优势，在敏捷测试中使用自动化测试技术应该是自然而然的选择。

考察敏捷开发中的一个迭代周期：

在迭代周期开始的时候，团队与客户一起定义本迭代周期内需要完成的功能；

团队建立验收测试验证标准；

开发工程师开始实现新功能，使用 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 个星期更痛苦的调试和修复自动化测试脚本的时间。

随着脚本数量的增加，我的痛苦如日俱增。最后，我不得不放弃了对这些昂贵的自动化测试脚本的维护，转向我情感上不情愿，理智上却不得不做的选择：重回手工测试。

UI 自动化测试带来痛苦的主要根源在于 UI 本身的不稳定性。由于 UI 是应用与用户的直接交互界面，用户的大量需求都直接对应在 UI 本身的改变上，这就导致了 UI 本身的不稳定，建立在 UI 上的自动化测试也因此不稳定。当然，除了不稳定外，UI 自动化测试带来的测试环境的需求也是导致 UI 自动化测试开销剧增的原因之一；另外，UI 自动化测试本身并不能很好的帮助定位缺陷，对开发工程师而言，其在反馈上的价值远不如单元测试。

除了 UI 自动化测试外，在敏捷测试中其他可用的自动化测试还包括单元测试与接口测试（或者叫服务测试）。

自动化测试所涉及的技术非常多，例如在单元测试中经常需要使用到的 Mock 技术，基于针对不同语言而不同的解依赖技术等；在接口测试层面，更是需要根据接口本身的类型和特点确定具体的测试技术；在 UI 层，根据应用的不同（桌面应用，Web 应用，嵌入式应用等），自动化测试技术也存在巨大的差异。

关于各种自动化测试技术的讨论，本文在后续文章中会选择其中的一些进行重点介绍，本文则主要介绍 Diff 技术这种与传统的“比较预期输出与实际输出”略有不同的自动化测试技术。

Diff 技术，顾名思义，其主要关心的是“不同”。以搜索引擎产品的测试为例：以同一个关键字在搜索引擎上进行多次重复测试（查询），随着时间段的变化，搜索引擎的索引数据也在发生变化，即使对同一个关键字，也不太可能在每次测试时给出一个所谓的“预期结果”。

---

资源分享

下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码，朋友们如果需要可以自行免费领取 【保证100%免费】