如何正确地选择移动自动化测试工具

根据Pinch媒体数据2009年进行的研究，一个移动应用程序的平均生命周期只有30天。此后移动应用程序的数量激增，生命周期变得更短了。这些变化趋势要求软件质量保证团队重新改进他们的软件测试方法，并将之与移动应用程序开发团队和客户群紧密相连。客户需要更多的应用程序和功能，因此保证移动应用程序的质量对维护现有客户群并获取新客户都是必不可少的。鉴于软件开发和质量保证（测试）的时间很短，即使有替代策略存在，软件测试自动化从一定程度上在公司的生命周期中是必要的。
　　一家app开发公司会因为各种原因（内部和外部的都有）而决定将其测试工作自动化。不论深层原因，一旦一家公司决定将其测试工作自动化，就需要一个系统的方法来定下自动化流程的工具。测试自动化的成功很大程度上取决于所使用的工具。如今市场上有各种自动化工具，选择正确的工具满足公司特定的测试需求算得上是一个蛮有压力的任务。
　　一个刚开发的产品，相对来说还是不太稳定。在那些阶段，手动测试是一个快速验证产品是否如期运行的好方法。为了验证和确认（V&V），软件测试员应该利用这个阶段熟悉产品规格并编写测试用例。产品规格一完成，测试员应该开始思考他们该如何将测试用例自动化了。软件开发公司经常要在为特定短期客户项目挑选工具并投资挑选工具和为长期项目/产品挑选工具间做出调解，以避免重新加工或后期浪费大笔费用。移动应用程序短暂的生命周期里在形成一个连贯的工具策略时提出了一个管理难题。这种情况下，基于场景的方法可以帮助管理者对连贯的需求投资负责，为他们公司的移动测试自动化做准备，并为战术和战略项目投资正确的工具。

 1.支持移动平台
       无论要求规范是什么，你都需要挑选正确的工具，不仅要支持目标操作系统如iOS，Android，Windows以及它们的不同版本，还要支持底层硬件配置。质量保证团队安排其测试工作时需要考虑许多移动应用程序特有的难题。最根本的问题之一是搞明白一个应用程序（代码库）如何在不同的操作系统，界面上运行。尽管移动平台市场的玩家主要是Google和Apple，但开发者仍需要将Symbian和Windows Phone用户考虑在内。即使是在单个平台内，也有一堆软件版本等因素要考虑。因此，检查最老和最新的平台支持版本极其重要。
       2.支持应用程序类型
一旦初始自动化工具入选，你就需要检查可以用这些工具所管理的应用程序的类型。多数工具都是特定的不能同时支持本地，混合和web应用程序。多数移动测试进程并不是万全之策。因此，很有可能需要在自动化流程链中挑选一些工具。根据被测应用程序的类型，至少80%的测试活动可以被自动化（按照帕累托定律算）。然而考虑到一堆平台上的应用程序的功能，就需要一些特别的手动测试。使用正确的工具就可以帮助提高效率，减少成本，同时可以在部署应用程序或服务时，提供一个客观环境来评估应用程序的质量并预测实际环境中的用户体验。
       3.源代码要求
      为了获得最佳测试质量，本地移动应用程序应该在安装程序内随附一些工具特定框架，这样软件测试员就可以向设备/仿真器发送一些指令直接用本地应用程序执行任务。多数常规浏览器都有它们自己的网络驱动程序，所以测试员可以在这些特定浏览器网络驱动程序的帮助下测试应用程序。在多数情况下，移动应用程序不会带着它们的源代码或框架被交付给测试团队，也就是说，它们可以在不同移动平台上模拟同样的功能。在一些情况下，有用于iOS的App Package一类的方法，尽管该模块并不以和拥有源访问的流程一样的方式提供测试覆盖率，但它却为测试提供比精易应用程序安装本身更多的容量。于是源代码和平台框架是需要考虑在内的重要指南，因为不是总能够获得测试用的源代码，尤其是当测试工作被外包给第三方时。
       4.应用程序重构要求
       移动测试自动化的另一个障碍是修改应用程序的要求，即重构使之可以被自动化工具测试。重构的技巧是能够验证功能被保留了。测试专业需要确保所有变化在重构前后都被验证了。尽管将这个流程自动化没必要，但这在随后的回归中或许有帮助。重构复杂的应用程序或代码模块是一门艺术，将这些元素自动化应该尽最大的努力。挑选的工具应该满足在不同粒度水平交付预期结果所需的可扩展性要求；或许有必要将第三方库包含在测试项目中，建立你的产品的测试版本或改善现有交付测试的app版本。
       5.测试脚本生成
       对于需要大量测试覆盖的移动应用程序，创建实时测试脚本或许会提出一个极大的挑战。尽管测试自动化大大地提高了执行效率，但这些效率提高都伴随着巨大的成本，尤其是开发测试脚本库以确保测试覆盖需求的时候。自动化测试用例脚本生成工具也许能通过帮助创建关于运行需求的脚本测试场景进一步提高效率并扩大测试范围。关于可扩展性，所挑选用来自动化生成测试脚本的工具应该要支持脚本参数。然而该方法通常受限于工具能力且无法交付和编程方法一样的覆盖度，它使用power coding和基本编程语言。编程选项没有自动化测试脚本方法那么快，但是其结果更有效更灵活。因此，有必要评估可用资源以便在工具评估过程中挑选一个方法。

 6.编程语言规范
       广泛地讲，用于开发应用程序的编程语言在质量保证过程中起着重要作用。测试员经常选择过程语言，例如Perl，Python，Ruby等来为自动化测试用例创建脚本，因为这些编程语言通常更容易学，不需要汇编（这就节省了不少时间），拥有大量用户群和库可供选择以解决各种自动化难题。使用一个面向对象的编程语言开发了测试脚本时，自动化经常选用面向对象的语言，如Java，C++，.NET等，这对于解决方案的体系结构十分重要。除了选择正确的工具和编程语言，测试员工分配也很重要。重复利用现有内部知识，经验和技巧比采用新技巧更有效。
       7.运行时对象识别
       功能和负载测试工具有个根本区别。功能测试工具在用户界面层进行，而负载测试工具是在协议层进行的。功能测试工具的运行时对象识别几乎从未达到过100%。如果对象识别成功率低于50%，那么测试自动化团队将执行这么多解决方案以击败测试自动化的对象。在负载测试中，这个问题并不重要。应用程序变化和它们对测试脚本中对象识别的影响对于测试自动化团队往往是个难题。独特的对象识别大大降低了变化的影响并简化了测试脚本维护。你必须了解并评估怎样在运行中使用特定工具进行对象识别，如果有可能的话，获取特定对象以便在收集对象库中的识别性能上轻松进行检查。
      8.数据驱动输入
       如今大多数app都是交互式的，需要用户在某些时候键入一些东西。知道应用程序如何回应各组输入对于将稳定有质量的产品推向市场很有必要。数据驱动测试帮助我们理解应用程序如何应对各种输入。不是让测试员手动将无穷的数据组合或硬-特定代码输入测试脚本，而是测试基础设施框架工作自动从数据源取值，将取出的数据输入应用程序，验证应用程序在用另一组值重复测试前反应正确。自动化数据驱动测试极大地扩大了测试覆盖面，同时减少了创建更多有不同变量的测试的需求。重视对数据驱动测试的使用可以确保应用程序是用来测试限制条件和无效输入的。数据驱动测试常常是基于模型的测试的一部分，具有覆盖广泛输入数据的随机性。为了确保拥有不同数据组合的测试执行，应该要恰当管理数据源。所选测试自动化工具应该包含驱动程序并支持多种数据格式，比如平面文件，电子表格和数据库存储。
       9.结果和错误日志
       在测试用例开发和执行期间，常常有必要记录展示更多开发人员特定信息的内容。可是对于测试经理来说，知道一个特定测试是通过还是失败就足够了。根据要求，或许有必要自动抓取失败测试过程的截图和录像，让开发员可以更轻易地再现问题并找出其根本原因。自动化工具也应该要有必要的过滤器来根据类型，文本，优先级，时间及其他重要属性挖掘日志信息。允许从时间轴上的一个自动化测试运行到另一个查看日志总结并用于配置报告格式的工具也是挑选测试自动化工具时需要考虑的功能。
       10.连续测试
       连续测试方法背后的中心思想是，经常推进代码变化并快速得到关于这些变化对现有系统的影响的反馈。一个强大的测试自动化框架应该能够支持团队合作和自动化测试基础设施组件（比如：集成开发环境即IDE，测试框架，版本控制，测试配置管理，问题追踪，报告生成等等）的集成。连续测试以及使用现有质量保证工具和技术的集成对QA流程效率非常重要。不进行连续测试就会让缺陷有机可乘。发现了缺陷，就要在上面放更多代码，使得对后面所发现缺陷的修复更难更贵。即刻测试变化大大减少了找出缺陷的成本，因此自动化工具应该用每个提交触发生成并自动执行相关测试或一天中隔一段时间执行一次。此外，将测试集分解得更小，平行运行测试集，自动给正在弄已发现缺陷的代码的开发员分配缺陷是获得高质量结果的最便宜最快速的方法。该方法也给开发员提供了尝试的空间，同时从回归保护主代码库。如此，测试每段代码分支都和测试主代码一样严格。这样一个从连续集成到新分支的应用程序一旦建立就可以帮助发现兼容问题并缓解最后的集成。
       11.定价模式
       测试自动化经常被视作成本很高的一个主要原因是：自动化工作是单独完成的，与主开发工作完全分开。有效躲开阻碍测试的设计决策的后果，开发员继续创建几乎无法自动化的软件。有效的敏捷团队（团队中每个参与自动化测试的开发员）打破了这些限制，自动化测试进入一个开发者可以在里面检查他们的代码的常用库。这样就大大减少了测试自动化的成本。有一些免费的开源和专门的测试工具可以用来评估。选好了开源工具，就有机会检查工具评估有多稳定以及那些工具有多快能否支持技术的最新变化。对于专门的解决方案，工具的价格是证明投资和ROI计算时需要考虑的关键因素之一。检查许可模式也很重要，比如按使用次数、节点、站点许可证、有效期等支付。另一个需要重点考虑的是加载项、支持和更新的可用性以及这些功能是否需要额外花费。最后也是最重要的一点，所选工具的易用性。工具的复杂度应该和测试团队接受新工具的能力，公司的编程能力相匹配。