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工具，领域专家可以确定人类可读形式的测试用例的功能。这样一个“故事”拥有如下形式：