自动化测试——敏捷测试的基石

作者 段念 发布于 2010年12月27日

领域

过程 & 实践

主题

自动化测试 ,

企业级敏捷 ,

自动化操作 ,

敏捷测试 ,

测试 ,

专栏 ,

敏捷

分享到

在专栏的上一篇文章《什么是敏捷测试》中，我们介绍了敏捷测试的主要特点。作为被冠以“敏捷”名称的测试，敏捷测试同样以“快”为目标。在敏捷测试中，“快”有三个方面的含义：

1. 团队能够通过测试快速获知系统当前所处的状态，了解距离可工作的软件还有多远；
2. 能够在一个迭代周期中快速完成回归测试和对新功能的测试；
3. 开发工程师能够从持续的测试中得到快速的关于提交代码反馈。

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

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

1. 在迭代周期开始的时候，团队与客户一起定义本迭代周期内需要完成的功能；
2. 团队建立验收测试验证标准；
3. 开发工程师开始实现新功能，使用TDD为产品建立安全网，使用持续集成尽可能保证每一次代码提交不引入新的缺陷；
4. 所有新功能被添加后，在RC上运行回归测试保证原有功能的正确性；针对新功能运行测试保证新功能的正确性；
5. 执行验收测试验证系统是否达到可交付的标准。

除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自动化测试项目中的自动化测试投入产出比较表。

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

除了UI自动化测试外，在敏捷测试中其他可用的自动化测试还包括单元测试与接口测试（或者叫服务测试）。下图是敏捷开发中被广泛认可的自动化测试产出金字塔，在相同投入的情况下，单元或是代码级测试能带来最大的收益，而UI层面的收益最小。

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

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

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

怎样才能在这种情况下开展测试？一种可行的技术是就是“Diff”技术。下图展示了Diff方法的应用。

简单来说，Diff方法的应用包括以下步骤：

1. 设置两个待比较的版本实例（通常是相邻的两个版本，例如RC和上一个产品版本），两个版本具有相同的数据基础或后端环境；
2. 使用发送模块同时向两个版本发送相同请求；
3. 比较模块收集两个实例的输出并对其进行比较；
4. 比较结果输出为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）的话题。

关于作者

段念：Google中国高级测试经理，毕业于华中科技大学，先后在通讯、嵌入式软件、互联网等多个行业的国内外知名公司中从事软件开发与测试工作。对软件测试中的技术和管理工作有独到见解，对软件测试团队管理、自动化测试、性能测试与开发测试有较多研究。

感谢张凯峰的策划以及审校。

1. 返回顶部

   关于diff测试&测试人员配备相关

   发表人 王 啸

   1、关于消除噪声。diff测试在大多数情况下是没有问题的，但是消除噪声方面，似乎给测试人员提出了一个挑战。现在有什么工具有比较好的diff功能么？或者说是不是涉及到一些定制性的diff的时候，还是需要QA自己去编写一个小工具来做diff测试？也就是把“测试程序”给模块化
   2、另一个问题和本文关系就不大了
   事实上，现在很多公司招的QA都是女生，做事细心，但是对编程本身毫无兴趣，对技术上也没有探究精神。而玩玩应聘测试职位，也是因为不想做研发，又是软件专业，所以应聘了测试岗位。面对这样的人员配备，应该怎么对待呢？或者说，自动测试对QA在编程方面的要求有多高？在我感觉，有能力去做自动测试的人，都去搞研发了。。。

   回复

2. 返回顶部

   Re: 关于diff测试&测试人员配备相关

   发表人 王 啸

   往往。。。打错字了。。。
   

   1、关于消除噪声。diff测试在大多数情况下是没有问题的，但是消除噪声方面，似乎给测试人员提出了一个挑战。现在有什么工具有比较好的diff功能么？或者说是不是涉及到一些定制性的diff的时候，还是需要QA自己去编写一个小工具来做diff测试？也就是把“测试程序”给模块化
   2、另一个问题和本文关系就不大了
   事实上，现在很多公司招的QA都是女生，做事细心，但是对编程本身毫无兴趣，对技术上也没有探究精神。而往往应聘测试职位，也是因为不想做研发，又是软件专业，所以应聘了测试岗位。面对这样的人员配备，应该怎么对待呢？或者说，自动测试对QA在编程方面的要求有多高？在我感觉，有能力去做自动测试的人，都去搞研发了。。。

   回复

3. 返回顶部

   diff测试可以作为详细测试的第一步，但对于CR还是无用

   发表人 liu jin

   对于web应用或者CS/BS系统的后端的测试 DIFF的测试技术的确可以定位到一些大不同,作为详细测试的第一期。
   不过有以下两个问题：
   1.若相邻两个版本间存在Change Request,则Diff测试此时意义就不大
   2.客户端的测试，这个方法似乎不实用.万恶的UI级自动化测试也解决不了客户端的测试.
   欢迎讨论~

   回复

4. 返回顶部

   Re: 关于diff测试&测试人员配备相关

   发表人 victor cai

   需要组建专门的测试技术团队，关于团队的组建需要慎重挑选人员，当然最重要的就是薪水，往往传统的测试工程师薪水都比同级别的开发工程师低，但是对测试技术团队的成员薪水必须与同级别的研发人员薪水类似甚至更高，这样才能组建成这个团队，但是说到底还是看公司愿不愿意投入成本

   回复

5. 返回顶部

   Re: diff测试可以作为详细测试的第一步，但对于CR还是无用

   发表人 王 啸

   对于web应用或者CS/BS系统的后端的测试 DIFF的测试技术的确可以定位到一些大不同,作为详细测试的第一期。
   不过有以下两个问题：
   1.若相邻两个版本间存在Change Request,则Diff测试此时意义就不大
   2.客户端的测试，这个方法似乎不实用.万恶的UI级自动化测试也解决不了客户端的测试.
   欢迎讨论~

   
   2能不能再解释的详细些？

   回复

6. 返回顶部

   "diff"不能算技术吧，仅仅只是一个测试策略而已

   发表人 马 功磊

   首先是"diff"不能说是技术，就是一个测试策略而已。
   实际上，就是这样做的。
   只不过，测试人员的普遍水平不够，以及整个研发团队（包括产品、开发、测试等等）对测试的考虑不够，导致测试代码的构建质量不高。
   实际操作中，运用"diff"就是格式化输出log就可以了。
   传统的单元测试框架，适当改进都可以。
   包括刚刚兴起的BBD(Behavior Driven Development，比如对于.net的specflow）都算是改进框架。
   
   归根到底，做自动化测试的明白人都知道，就是水平能力和公司投入的问题。
   
   当然，完全自动化确实不可取，部分自动化+部分人工结合，是最高效的方式。

   回复