6步加速移动应用测试

在移动企业，如果你测试和发布app的速度不如竞争对手快，那你就要落后了。哪怕是最古板的保险公司都知道，在移动领域速度会杀人。

不过虽然开发者和QA团队竭尽所能去快速跟进自己的app，Perfecto Mobile研究团队最近进行的一项调查表明，组织仍在与我们所谓的速度拦截器作斗争，后者是指一些妨碍快速迭代发布的测试做法。

无论是什么因素导致了速度放缓，我们认为你都可以从下列加速移动应用测试的最佳实践中找到一种（甚至全部）的补救措施。

实现自动化测试

移动应用开发太慢，人工测试是祸首。几年前，我们的一家客户，美国顶级银行之一因为过多的人工测试而导致测试周期完成时间拖得过长。经常会出现app缺陷没有被发现的情况，这妨碍了转入生产阶段，因为客户的眼睛更是容不得一颗沙子。

后来银行用健壮的脚本和我们的Continuous Qualitylab即服务来对测试进行自动化。此前这家银行的回归测试大概要16到20天的时间，经过自动化以后，回归测试周期时长缩短了90%。以往需要数周完成的周期降到了数小时的时间。这家银行甚至能计算出每测试周期自己节省了4万美元。

公司应该以实现95%测试案例的自动化为目标，这样才能达到覆盖的优化水平，出于效能最大化的考虑，他们还应该使用与自己使用的IDE（Eclipse、Visual Studio、HP UFT）及测试框架（Selenium、Calabash、Appium）兼容的自动化测试解决方案。

别再自己管理设备实验室了

据估计，内部设备管理每年每台设备需要花费6500美元。很大的一个数字。而且随着你需要测试的设备数量不断增长，事情开始变得不可管理，且无法盈利。

当新设备推向市场时，人工进行的内部测试的确会拖你后腿。三星Galaxy S6发布时，你的app是否已经就绪？你能在它发布前、在用户能升级前就能提前拿到测试你的app就更好了。不过这两个问题的答案可能都是否定的。但是拥有合适的设备对于拥有最佳测试覆盖来说又是至关重要的。那么，你的测试实验室怎样才能拿到最新的设备、为在你的用户拿到自己手机钱进行测试在线且就绪呢？

让管理有方的实验室即服务（lab-as-a-service）替你完成这项工作，这样的供应商能够在新设备公开上市前就拿到它。让他们替你管理你的测试实验室，提供测试针对的真正的设备、网络、位置和用户条件。确保他们也能提供SLA（腹服务水平协议），并且有专门的专家帮助你。

你的回报将是可以在设备上市前远程访问到它（不再需要预定，不再需要在发布日买样品了），而且还可以省下很大一笔钱，比每台设备6500美元少得多。

把你的设备测试实验室放到云端

如果你的团队确实要购买设备并使用内部实验室，他们最终将面临把设备实时交给全球测试者的需求。桌上堆满一堆测试设备是很难办的。

我们的客户之一，一家顶级的美国移动运营商，有员工负责获取新上市设备然后运到测试执行地的。如果无法满足时间窗口，员工就得亲自携带设备过去以确保及时送抵合适的测试小组。旅行成本的有限的测试时间搞得整个过程没有效率。

一旦运营商选择把设备放到云端，那么设备成本和截止期限挑战就可以极大减少了。现在他们可以通过可伸缩按需的云端集中管理真实设备了。小组能够在任何地方远程访问的同时确保相同的测试体验，如果设备在他们手中的话。

环境的自动提供

自动化你的测试脚本也许可以加速你的测试和发布，但这还不够。你必须首先确保你的后端服务API足够稳定，能支持自动化测试。当你在一个不够稳定的环境中运行自动化测试时，你的错误报告中会得到假阴性告警。花费时间筛选假阴性会显著延缓发布周期。

自动化测试环境的提供得由你来准备，要确保测试自动化就绪。可通过增加预先测试环节来确认你的环境已经测试就绪，同时还能知道哪些错误是环境不稳定引起的，哪些是一般的测试用例错误。最后，如果你的环境稳定的话，你的测试不会返回假阴性，这可以节省你的时间和金钱。

保证持续质量

随着开发者团队开始采用敏捷实践，QA与开发者之间的反馈回环往往会变得不平衡，因为这个流程是新的。我们的一家旅游网站客户的发布周期需要数月时间，其中3周是开发，最后1周是测试和修复漏洞。这里的问题是最后一周需要完成的事情跟前3周一样多。

该公司可以将品质嵌入到整个开发周期，即所谓的持续质量概念。单元测试令QA反馈总是可见，开发者总能知道自己的代码怎么样，因为代码被不断测试。在整个SDLC阶段维护这样一种对移动应用质量的控制提升了该网站的开发速度，减少了流入生产阶段的缺陷数量，最终导致更高的用户满意度。

让证据成为关键

这是常见的情形：开发者无法复制报告给QA团队的问题。是不是某样独特的东西会影响到设备的性能？是不是因为我的网络更加安全，所以没有返回错误？我是不是按照QA团队相同的步骤去查找漏洞？

保有缺陷的证据至关重要。如果缺乏证据，测试中重新制造错误是很困难的，你很难提供足够的反馈给开发者团队。有工具能记录事务，然后在反馈期让你分享录制的视频给团队成员，错误再现就不会成为问题，然后你的测试过程就可以加速。