移动测试：App上线不“裸奔”的正确方式

移动化那些事 • 9年前扫码分享

我是创始人李岩：很抱歉！给自己产品做个广告，点击进来看看。

移动互联网走到今天，App寡头化的趋势愈加明显，同时用户的口味也越来越高，这对移动App开发者提出了更高的要求。

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

移动互联网走到今天，App寡头化的趋势已经越来越明显，同时用户的口味越来越高，这对移动App开发者提出了更高的要求。几年前可能你有一个创意，随便做一个App，就算功能简单，Bug很多，也会有不少用户会使用，因为当时的选择少。而现在，如果App的质量不过关，体验不好，还经常崩溃闪退的话，会被好不容易获得的用户立刻卸载掉。这就要求开发者对于App的测试越来越重视，而App的测试和传统测试相比，面临更多挑战：

App迭代速度快，测试时间少。

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

App测试的准确性和问题追踪难以保证。

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

手机机型分裂越来越严重，App兼容问题突出。

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

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

如上图所示，移动App测试根据产品不同阶段分为以下几个阶段：

功能测试

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

体验测试

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

兼容测试

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

质量监控

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

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

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

3.1. 从传统到现在的用例测试

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

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

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

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

3.2. 移动App的自动化测试

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

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

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

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

4. 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质量监控

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

对于开发者来讲，最头疼的问题就是App用户反馈自己手机上出现了崩溃，却始终无法提供具体的崩溃信息。结果开发者明知道问题存在，却只能眼睁睁看着用户流失。

大量的App花费了巨大的市场和研发资源投入，却在应用上线后“裸奔”。它意味着开发者不能第一时间发现应用在运行过程中出现的各类质量问题，如崩溃、闪退、内存泄露等，而此时用户却对这些不佳的产品体验深恶痛绝。

一个好消息是，目前市面上已经有不少专门解决质量监控的工具可以供开发者使用，如友盟就在其SDK中集成了错误捕捉的功能，而对崩溃定位要求较高的开发者也可以使用Testin的崩溃分析SDK，实时收集App在不同环境下的产品体验，从网络、版本、渠道、运营商、设备五个维度深入分析用户的使用情况，帮助开发者快速定位并解决崩溃、闪退、异常等问题，优化App性能，提高App的用户体验和质量，降低用户流失率。