金融行业移动终端自动化测试方案

小小糖

　Parag Kulkarni自2008年就在印度SQS担任测试自动化团队的一名核心成员。他专攻使用各种工具的自动化。
他的核心竞争力包括自动化框架设计和移动自动化。过去的八年，他广泛涉及了CRM，出版，银行和电信领域。
　　如今金融机构使用多渠道方法服务其顾客，且越来越多地都开始使用移动技术了。为金融服务业的顾客
服务需要高度可靠的基层软件。与顾客期望同步的需要，发布周期短暂且需要提供高质量的软件等都是开发
移动软件中的难题——尤其像在app商店中，质量差的一眼就看出来了且对银行的声誉有所影响。所以，测
试尤其是回归测试是app开发中最重要的工作之一。但是如果不给你的顾客“银行标准智能机”，你该如何满
足这些期望呢？使用多平台方法的移动测试自动化是应对该挑战的一个方法。本文中，我们将为你展示我们
成功使用了该方法的一个实例项目的细节。

　　项目内容
　　一家奥地利银行正在寻找移动自动化解决方案以在多个平台（如Android和ios）上测试他们的多个app。
他们也想很好地覆盖其顾客们最常使用的手机和平板。基于该信息，我们想出了一个顾客移动测试策略来
回答下列问题：
　　--必须要测试哪种app？
　　--必须要覆盖哪些设备类型和型号？
　　--必须要覆盖多少测试用例？
　　--迄今回归测试发挥了多少作用——该作用如何作用于该项目的框架的？
　　我们的任务是实验覆盖了两种app的移动测试自动化。第一种：web app，必须在手机或平板上测试，
Android和iOS都要测试。第二种：混合型app，再次在Android和iOS上测试，要在四台手机和四台平板上测
试。为什么会有这样的区别？web app只依赖于web浏览器；而混合型app要考虑基础系统的更多功能，因
此它需要在更多的设备模型上更彻底地测试。设备是根据顾客对其所使用设备的分析而选择的。
　　挑战
　　我们正在进行拥有60个测试用例的回归测试，其三分之二覆盖了web app，剩下的三分之一覆盖了混
合型app。回归测试一年执行四次，即，2种app，60个测试用例，1年4次。但单单如此并不是说你一开始
就要将这些测试用例自动化；它也可能表示完全相反的意思——坚持手动，进行群体测试——如果没有下
面几个“但是”的话：

　　1.我们讲的是银行。银行不热衷将其测试外包到云或群体。一个测试服务供应商就足够了。
　　2.只覆盖了60个测试用例的实验一个季度进行一次——但它只是一个实验。总之，我们将可以重复使
用我们十多个app的测试代码。可重复使用很重要！
　　至于所覆盖的技术，我们必须在ios和Android平台上测试app——当然，要用划算的方法。
　计划
　　进行实验不仅仅意味着将测试自动化。它还意味着进行一次精心研发的实验，其结果将为长达一年的
成功的测试自动化构建基础。因此，在整个项目中我们的项目计划有接下来的四个阶段：

　　工具选择是重要的理论步骤，挑选一个或几个候选工具进行一次多因素的分析。第二阶段是为特定项
目或顾客选择最合适的工具并作出实际评价，设置和首次概念验证。证明了技术上工具能够用于项目中的
话，进行实际自动化是为了试验。只有在首次概念验证中覆盖了测试用例的选择，自动化阶段才能覆盖完
整的测试用例集。自动化意味着软件工程，并不存在没有测试的软件工程（至少应该如此），所以自动化
阶段覆盖了第一轮自动化测试用例的执行。最后一步终于可以证明该方法是否对管理服务方法有效，需要
使软件测试工业化，即用可预见方式使之变得标准且可执行。

　　我们将七个预选工具缩小到（理论上）完全满足顾客需求的一个。为了实践证明理论，我们取60个测
试用例中的9个代表，设置测试环境并进行概念验证（PoC）。不论设置工作，常常，部分顾客背景下的
概念验证是一个要花上不少时间的实验。你可以轻易地看见PoC的学习效果：没必要进行第二次环境设置，
有了PoC的实验，我们可以轻松地从3周9个测试用例增加到4周60个。最终这就是实际项目中的自动化速
度。实验的最后四周都被浓缩成标准的一周测试周期。
　　实施
　　实验阶段开始时我们有七个候选工具，我们最终决定使用Calabash。Calabash是一个基于行为驱动开
发（BDD）想法的开源测试框架。BDD将实际功能测试工作脱离了“代码背后”。这样就可以将测试工作分
给以下两者：
　　--领域专家（SME）：SMEs很了解app的功能，但是多数情况下基本不了解代码。
　　--测试自动化专家（TAE）：TAEs很了解代码，但是多数情况下对app的预期行为了解的要少很多。
　　有了BDD工具，领域专家可以确定人类可读形式的测试用例的功能。这样一个“故事”拥有如下形式：

此例中，我们发现一个混合型方法来测试自动化，该种方法通常被建议用于测试自动化。“混合型方法”意
味着Calabash的测试自动化方法混合了基于动词的测试和数据驱动测试。上例中每一行都可视作一个描述
“我按了Go按钮”一类行为的动词，太没技术含量以至领域专家不需要了解。数据驱动就是说我们不需要为
我们想尝试的每个数据组合编写新的测试用例。反之，我们使用测试用例本身的参数。

　　使用Calabash的移动测试自动化结构，像'When I enterinto"user"field'行——以及一个明确了所考虑
数据组合（下例中的表）的单个数据表。
　　当然，测试用例的运行不会和上述一模一样。在第二步中，测试自动化专家进行实际执行：
　　他们编写由动词触发的技术代码，从技术层面上通过发送信息或点击GUI要素来控制app，收集app
的反馈并对反馈做出评价。下面是一则例子：

　　在解析“测试故事”的代码时，Calabash试着使用正则表达式匹配找出匹配的代码并将之执行。这段
代码是由‘When I enterinto"user"field’行触发的。对于第一轮测试，被"test123@example.com"用测试数
据表中的邮箱地址的第一个数据值替代。调用上述代码时，可变文本被设置成可变文本的第一段，可变
文本字段被设置为我们想访问（用户）的文本字段名。接着代码等待三秒，与web app同步并设置test12
3@example.com用户字段的文本。接着Calabash继续测试故事中的下一行。
　　为了给大量测试用例和移动设备提供有效的测试自动化，有必要创建一个简明通用的测试自动化库
（见图3.使用Calabash3的移动测试自动化结构）。该库包含所有可重复使用的步骤定义，要注意，那些
步骤定义对于不同设备是可重复使用的，这样它们就可以在测试故事中透明使用了。这就避免了必须为
不同设备多次编写并维护同一测试用例的花费。此外，应该充分将可重复使用的步骤库模块化以区别分
别针对特定产品、特定产品线和分支的动词。以这种方式将自动化库模块化可以减少不同项目中部分相
同的库并再次将测试自动化的开发花费最小化。Calabash满足了我们所有的节省费用的需求（它是一个
开源工具，一开始就是免费的）和所支持的平台（IOS或Android）。它也能轻易扩大顾客功能。这对我
们而言很好，因为Calabash是最佳解决方案——但最初它只支持本地和混合型app，并不完美。为了使其
能支持web app，我们创建了一个可以从Calabash内部控制的web浏览器。这意味着我们能够完全满足顾
客需求。
　　经验
　　对于成功进行的四个阶段，我们提出了全面的项目计划。最重要的阶段是所选解决方案的实验阶段，
一个基于Calabash的测试自动化框架。 我们是发现了一些障碍，但是通过使用简单的Calabash拓展可以
相当轻松地将之解决。可重复使用性成了一个对我们的顾客来说和节省费用一样很重要的问题。有了
Calabash，就有可能为ios和Andriod app编写自动化测试用例，为两个平台都重复使用80%的测试代码。
Web对象的代码也可以重复用于web app和混合型app，这样就再次大大减少了自动化工作。

梦想家