浅析移动测试：应用上线不“裸奔”的正确方式思维导图

1. 移动App测试的现状及其挑战

现在的App迭代速度非常快，通常一个月一个大版本，两周一个小版本。而开发人员水平参差不齐，基本上都是临近发布前才能提供可测试的版本，给测试人员留出的时间非常有限。这就直接导致了测试人员可能无法对App进行全面的测试，根本无法保证App的质量，所以我们经常看到很多App带着Bug就上线了。

据统计，由于缺乏真实环境下的用户场景，App测试遗漏环节高达20-50%。由于测试人员本身不专业，同时缺乏通用的App测试工具，导致很多App发生了崩溃严重问题时，测试人员很难提供给开发人员精准的崩溃日志，让开发者无法精确定位问题和分析问题。

目前Android机型有几千款之多，加上各种操作系统版本、各种屏幕尺寸、各种厂家自定义ROM，给App带来了严重的兼容适配问题。而随着苹果发布新机的节奏在加快，以及iOS版本不断更新，iOS上的兼容适配问题也开始增多。App的测试人员没有时间，没有能力在所有机型上验证App是否可以正常运行，大多数情况只能挑几个手头能找到的机型做简单的验证测试，就草草发布上线，结果可想而知，就是在最终用户手机上出现各种意想不到的适配问题。

2. 移动App测试的几个阶段

App代码开发完成后，会进入内测阶段。团队内部测试人员会进行功能验证，有能力的团队除了人工黑盒测试外，还会使用自动化工具进行集成测试。

功能验证通过后，可以引入真实用户进行体验测试，根据用户的真实反馈快速响应，迅速调整App的功能。

由于目前App在不同手机上可能存在严重的兼容适配问题，进行大版本迭代，或App底层框架有所调整时，需要进行兼容测试，确保App在绝大多数手机上能够正常运行。购买市面上所有手机来一个个进行测试，无论从时间上还是成本上来说，对普通开发者都是难以承受的。也正因如此，市面上出现了许多第三方服务来帮助开发者们完成兼容性测试。

真实环境的复杂，用户行为的不可预知，导致再完美的测试也不能保证App完美得没有Bug，所以App上线后的质量监控就尤为重要。这时就需要使用质量监控工具，第一时间掌握App在用户端真实发生的各种崩溃闪退等问题。

接下来我们就以上不同阶段具体讲讲移动App测试都是怎么做的。

3. 不同于传统测试的App功能测试

App功能测试一般是团队内部人员执行，通常进行的都是黑盒测试。目前研发团队逐渐通过执行用例测试的方式来完成App基本功能的测试。用例测试的意义在于使得测试有针对性和目标，测试点可以量化，测试行为可以控制。

App的用例测试是从传统软件测试继承下来，早期的测试用例通常比较简单和随意，只是对功能或使用场景做了简单的罗列，较少考虑功能的覆盖、颗粒度大小等问题。而现在的测试用例会越来越多地考虑测试覆盖率、缺陷的发现和执行的效率等方面的影响。

具体的测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法、场景法等，测试人员可以根据实际情况来量体裁衣。

App测试通常会进行以下几个必测项目：UI测试核对RP/效果图；功能测试核对需求文档编写测试用例覆盖全部的功能点，对照需求文档逐一完成验证。这类工作通常都是纯手工进行的，测试者需要维护好App的测试用例，随着App的功能迭代，不断更新App的测试用例，并定期进行全用例测试，保证用例覆盖度以确保App的每个功能点的正确运行。

在App功能测试中，对于一些固定的用例执行，可以使用自动化测试工具，通过编写自动化测试脚本来执行，减少人员的重复劳动，提高整个测试的效率。

自动化测试分为UI自动化、接口自动化、性能自动化和安全自动化。从流程来说不搭配持续集成的话就不能称为全流程自动化，持续集成包含的不止是自动化测试，还有环境部署和开发打包等环节。进行自动化测试时，可能测试脚本可以做得很好。但持续集成不是一个测试或一个测试团队就能做好的，需要一个有决策力的人推动才能完成，而目前国内App开发团队的领导人对移动App的自动化测试支持有限。

同时，App由于迭代速度快，机型多，这就对测试脚本维护提出了很高的要求，又由于自动化测试脚本的代码覆盖度不够，所以即使有了自动化测试，人工参与的功能测试工作量依然很大。这也导致了目前国内App自动化测试整体程度不高，只有部分大厂才有能力建立App的自动化测试团队，而一般的中小开发团队，自动化测试能力基本为0。

目前市面的App自动化测试工具不多，主要是国外的一些自动化测试工具，下面是App自动化测试工具对比：

关于App测试，开发者需要提前做计划，一个好的商业分析、清楚的目标用户群体以及大量的测试可以有效降低App“无人问津”和差评不断的几率。在把App正式发布到最终用户手上之前，开发者得尽可能保证它是完美没有瑕疵的。通常来说，内测阶段分为几个环节：

此阶段主要由开发人员来完成，检查App逻辑连贯性每个功能模块是否按照需求可以跑通，核心功能点能力是否实现。注重于测试软件的功能需求，功能不正确或遗漏；界面错误；输入和输出错误；数据库访问错误；性能错误；初始化和终止错误等。

开发人员在完成内部逻辑验证后，会搭建测试环境供测试者来在测试环境下完成内测。这个测试人员有可能是专职的测试者，也有些团队是动用公司的其他人力资源来完成，如产品经理、BOSS或其他同事。不管是哪些人来完成测试，测试行为必须加以量化，才能真正保证软件质量，而测试用例就是将测试行为具体量化的方法之一。

在开发团队和测试团队完成内部测试后，采用小范围用户测试的方式可以在最小的成本下验证App对目标用户的接受程度。这时需要做好用户反馈收集的渠道，常见的渠道有调查问卷、App中加入吐槽反馈功能、用户交流群等。

移动App测试过程中，由于迭代速度快，App包更新频繁，开发人员和测试人员之间没有很好的工具进行App传送。此外，提交Bug时截图上传比较麻烦，获取App日志需要专门工具，这些对于测试人员已经比较困难，对于引入的灰度测试用户更是难于登天。

针对这些问题，我们进行了解决方案的研发实践。以第三方内测服务pre.im帮助开发者与测试人员解决传包问题，并拥有完善的版本记录，方便管理快速迭代的各种App版本。其内测专用SDK让测试者无需使用任何工具，只需在出现Bug时摇一摇手机，即可自动完成Bug截屏，并读取当时App的运行Log、内存、CPU等信息，连同Bug截图和描述一同提交给开发者，帮助开发者更精准定位问题。

5. 发布后的App质量监控

6. 结语