【51CTO译文】对Android或者iOS平台上的应用程序进行检查其实并不像大家想象的那么特别。我们工作的目标是一样的，期望的结果是一样的，操作的过程也是一样的。与桌面平台相比，移动应用测试的主要区别在于我们需要更多地留心细节，而这也正是今天这篇文章所要讨论的重点。
1. 基本原则
在我们深入讨论之前，首先来聊聊关于测试的一些基本原则。除非大家已经透彻了解并且熟知整套测试体系，否则对相关背景知识进行说明能帮助各位快速明确自己有哪些解决思路可供选择。
Android上的挑战
真正让Android得到人们青睐的在于它那不计其数的可能性。在iOS阵营当中，我们能够想到的只有iPhone、iPad以及iPod Touch。它们在样式上有所不同，但却拥有iOS设备所共通的像素密度、屏幕分辨率、处理器速度以及内存大小等等。
但在Android这边，同样的外观尺寸、屏幕分辨率与大小、处理器速度乃至内存容量等可以构建出无数具体组合——而“锦上添花”的是，操作系统版本的碎片化又让这一切变得更加复杂。
说起操作系统的版本，运营商与手机制造商在推出产品之后很快停止为其提供版本更新的作法在Android阵营可以说是屡见不鲜。这到底算不算是问题呢？当然是。感兴趣的朋友可以点击此处查看谷歌官方提供的Android市场份额统计，了解这一问题到底有多严重。
在市场份额下降的项目当中，我们看到了果冻豆（4.1至4.3版本）、姜饼（2.3版本）与冰淇淋三明治（4.0版本）的身影。
相比之下，苹果iOS 7的接受比例则明显理想得多。截至今年一月底，已经有八成iOS设备运行iOS 7。需要提醒大家的是，iOS 7是在去年九月才正式发布的——相较而言，二者的表现可谓判若云泥。
学习、对比与参照
不知道大家有没有真正体验过糟糕的Android应用程序？相较于那些从头到尾一无是处的应用，更为可恶的是那些充斥着无数漏洞、让人根本捉摸不透其运行结果的垃圾。
根据我的个人经验，要让测试过程变得更顺利、更富成效，大家的关注重点起着非常关键的作用——包括我们使用什么、喜欢什么和憎恶什么。虽然憎恶这个词似乎有些太过强烈，但我确信各位在使用过程中的确体会到过这样的感受。
请大家客观回答以下几个问题：
- 你最喜欢的应用程序有哪些？为什么它们能获得你的肯定？
- 你曾经体验过哪些糟糕的应用程序？
- 一款应用程序是靠哪些因素而变得出色的？它们是否在开发过程中注意到了细节？
- 糟糕的应用程序是不是会在运行当中经常卡死？会不会一个劲儿崩溃？或者在设计思路上就存在问题？
了解自己要应对的是哪些Android设备
让我们再说回之前谈到的Android操作系统市场份额参考图表。可以看出，对每一台设备以及每一个Android版本进行测试根本就是痴人说梦、也并无必要。
我的观点是，我们需要考虑发行方面的具体需求。我们的应用程序是什么、面向的又是哪类目标市场？这是一款游戏还是实用工具类应用？
如果这是一款游戏，那么关注重点可能仅仅放在更新、更高端的设备知上。不过对于实用工具类应用程序来说，大家则需要吸引到更为广泛的客户群体并支持数量更庞大的设备类型。
#p#
2. 实施方案
我感觉大多数朋友没能做好测试工作的主要原因在于，我们都与自己的项目太过贴近也太过熟悉。我们很清楚自己的应用程序在何处情况下会出现故障，也知道该如何将其重新扳回运行正轨。有鉴于此，我会刻意让自己站在普通用户的立场之上。我一般会把用户分为两大类——一类是狂点按钮型、另一类才是真正的普通用户。
狂点按钮型
狂点按钮型指的是那些从应用程序启动之后就不断鼓捣屏幕的使用者，他们一会点这个按钮、一点碰那个按钮，一刻也闲不下来。“刚刚点的那个按钮没起作用，我再点别的试试。”
我们对不同用户类型的学习将贯穿整个应用程序的开发周期。如果出现某些情况、接收到某种请求或者发生某种操作，我们的应用程序是否会大量占用处理器资源或者是用尽设备的内存容量？这类情况又是否会导致应用程序陷入崩溃？
另一个值得关注的重要问题是，“我们该如何通知用户即将出现的结果。”为什么他们没有等待，反而选择了直接点触其它按钮？我们能否利用载入界面帮助他们弄清自己该如何操作？
普通用户型
普通用户拥有明确的使用意图。用更好的方式来解释的话，这类用户会花一点时间查看用例并了解应用程序的使用方法。如果提供一套特定任务执行流程，他们会希望加以体验并遵循应用本身给出的操作步骤。
我们需要了解自己的应用程序在为用户提供处理流程或者操作指引方面是否表现得足够明确。借助这种思路，我们会理解用户为何在使用过程中感到迷惑，又有哪些部分值得留意或者重新定义。
我们已经讨论过了努力目标与不同用户类型，但我们能够给出哪些选项、又该如何对其进行测试呢？很幸运，可选方案非常丰富，而且我建议大家尽可能多了解这类可行性选项。
#p#
3.可选方案
给朋友打电话
如果大家没有奢侈到拥有自己的常见问题部门或者测试实验室，那么不妨先从与朋友交流开始。我们需要自己的亲身体验与相关物理设备。
在进行移动应用程序测试时，数量起到的作用其实非常显著，特别是在大家拥有大量可用设备的情况下。
工具与单元测试
自动化测试方案是我们的好朋友。尽管***的测试办法仍然是亲手对应用程序进行完整体验，但了解代码层面的状况以及应用程序会在特定条件下、特别是在压力条件下作出怎样的编程化反应同样非常关键。
更重要的是，单元测试能帮助大家在开发的同时完成测试工作，这会在应用程序真正发布之前为我们节约下大量的测试与常见问题解决时间。
Android SDK
Android SDK为我们提供Android测试框架，这套框架主要由基于JUnit与monkeyrunner的测试API所构成。
Android JUnit扩展允许开发人员针对Android组件编写出单元测试机制，而该Android API还具备面向特定组件的预置测试类。
基于Python的monkeyruuner则是另一套API，允许大家编写出能够以用户的角度出发实现设备控制的程序。这意味着大家可以创建出可以运行在多种设备或者模拟器上的测试方案，向其发送按键点击记录并获取屏幕截图。
其它测试框架
目前市面上可用的测试框架可谓层出不穷。其中一部分的人气相对较高，最典型的代表就是Robolectric与Robotium。
Robolectric是一套运行在我们IDE环境下的单元测试框架，它同时也是一套能够对预建代码进行良好审计的卓越方案。Robotium的测试对象则主要是模拟器环境下的Android API。虽然它在完成测试的时耗方面表现得更长，但大家的应用程序代码将在其帮助下变得更为坚实，效果其实不逊于对设备以及API进行实际测试。
另一套有趣的备选方案则是Espresso。与前面两套选项相比，它主要面向某些较为特殊的测试目标。具体而言，它是一套专门对Android UI进行测试的API。
前面提到的各类选项都相当出色，不过如果大家打算创建一套混合型应用程序，那么它们也许帮不上什么忙。Appium是一套跨平台自动化框架，允许大家构建起能够面向各类语言、两大主流移动平台的测试机制。
报告与分析
多查看一些统计数据也会很有帮助，而且更重要的是，大家应该收集错误与崩溃日志。如果大家拥有多位应用程序测试人员，这种方式将变得更为实用，因为我们可以借此将每一位用户的日志记录收集起来。
除了追踪应用程序使用情况之外，Google Analytics还能够带来一些意外惊喜。Flurry属于另一套测试选项。其实这项功能已经存在了相当一段时间了，其报告与崩溃记录也包含有较为详尽的信息。
尽管它无法在应用程序开发阶段为我们带来帮助，但谷歌能够收集Play Store中应用程序的崩溃记录。
#p#
4. 第三方备选方案
我们都希望拥有几百台物理设备用来测试，正如我们在网站上见过的那些规模庞大的测试实验室一般。然而大家都知道，这明显不切实际。为了解决这个难题，如果大家愿意在测试方面作出投资、那么可用的服务也是很多的。
这些服务可谓五花八门，从一对一人力测试到数百台设备上的全自动测试应有尽有。如果大家愿意选择付费项目，这些方案都是完全可行的。
我自己其实也没体验过那么多方案，但User Testing作为其中之一给我留下了很深的印象。他们会派出一位专员关注我们的测试脚本，并通过应用程序体验给出来自外部的建议与意见。
下面几项服务也都值得认真考虑，感兴趣的朋友请立刻打开搜索引擎吧：
总结
我经历过很多消极的状况，开发者误以为常见问题汇总与测试似乎应该是后期处理工作。但事实上，它们正是开发流程当中非常重要的组成部分。
作为一套拥有众多版本的庞大阵营，Android操作系统似乎看起来难于打理、甚至有些可怕，然而在采用编程化解决方案之后、它完全可以成为开发流程的固有步骤。为此投入额外的时间与精力完全是物有所值，请大家注意——高质量应用程序不会凭空而来。
