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

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

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

自动化测试覆盖率 功能点数量 测试用例数量

(自动化/全部)

自动化测试执行

失败率(平均)

每个测试周期的

人员投入

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方法的应用包括以下步骤:

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

This entry was posted in Agile. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s