51Testing软件测试论坛

标题: 移动APP测试浅析 [打印本页]
作者: 测试积点老人    时间: 2019-1-2 14:17
标题: 移动APP测试浅析
本帖最后由 测试积点老人 于 2019-1-2 14:31 编辑

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

App的测试和传统测试相比，面临更多挑战：

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

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

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

二、移动App测试的几个阶段
[attach]120594[/attach]

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

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

由于目前App在不同手机上可能存在严重的兼容适配问题，进行大##版本迭代##，或App底层框架有所调整时，需要进行兼容测试，确保App在绝大多数手机上能够正常运行。购买市面上所有手机来一个个进行测试，无论从时间上还是成本上来说，对普通开发者都是难以承受的，现在市面上已经有不少SAAS服务(SaaS)可以使用，如Testin提供的兼容测试服务。

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

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

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

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

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

2、移动App的自动化测试
在App功能测试中，对于一些固定的用例执行，可以使用自动化测试工具，通过编写自动化测试脚本来执行，减少人员的重复劳动，提高整个测试的效率。
自动化测试分为ui自动化，接口自动化，性能自动化，安全自动化。从流程来说不搭配持续集成的话就不能称为全流程自动化，持续集成包括的不止是自动化测试，还包括环境部署和开发打包等环节。做自动化测试时，可能测试脚本可以做的很好，但是持续集成不是一个测试或者一个测试团队能做好的，需要一个有决策力的人推动才能完成。而目前国内App开发团队的领导人对移动App的自动化测试支持有限。

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

[attach]120595[/attach]

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

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

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

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

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

工具介绍
Testin提供的专业的App内测工具：pre.im主要就是解决以上内测中问题：
只需一步上传，即可生成应用短地址，解决开发人员和测试人员之间传包的问题。
完善的版本记录，方便管理快速迭代的各种App版本。
强大的内测专用SDK，测试者不需要使用任何工具，只需要在出现Bug时摇一摇手机，即可自动完成Bug截屏，并读取当时App的运行Log、内存、CPU等信息，连同Bug截图和描述一同提交给开发者，帮助开发者更精准定位问题。

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

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

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

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

结语:
移动App体验和质量要求越来越高的今天，希望开发者更加重视App的测试，提高程序员对测试的重视，将测试集成到整个开发流程中，同时多采用各类测试工具或服务，进一步提高开发效率和保证App质量。








欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2