今天我们来谈谈移动测试的测试策略与测试架构。

首先我们将移动应用的范围限定在智能移动操作系统（比如Android、iOS、WinPhone等）上，包括手机应用，智能设备应用等。

智能手机和智能设备的普及需要大量的应用来支撑。随着应用数量的增多，业务复杂度的提高，移动应用也越来越需要各种测试来保证应用以及设备本身的正确和稳定运行。因此移动应用测试的需求也越来越大，大量关于移动应用测试的书籍应运而生，比如《Android移动性能实战》，《腾讯iOS测试实践》、《移动APP性能评测与优化》、《深入理解Android自动化测试》、《精通移动App测试实战：技术、工具和案例》等。

这些书都介绍了大量的移动应用测试实践，但是无论看多少本书，学习多少种测试方法、测试技术或者测试工具和框架，首先还是需要学习并使用测试策略与测试架构。如果没有在一开始制定好的测试策略和测试架构，而是盲目进行各种测试，很有可能事倍功半。

对于移动应用，首先它本质上也是软件系统，所以通用的软件测试方法技术都可以使用。其次它又拥有嵌入式的特征，比如开发需要交叉编译、需要远程调试、硬件资源相对不足等。所以移动应用的测试也有其特殊之处，比如也需要交叉编译、远程测试以及各种硬件相关测试等。对应的移动应用的测试策略和测试架构也有其特殊性之处。

制定测试策略

我将移动测试分为三种类型，分别是基础测试、进阶测试和产品测试，其中基础测试是产品能正确并快速交付的基本保障，扩展测试主要是为了增强软件系统的健壮性，而产品测试主要是通过产品角度以及用户角度去思考而进行的测试。下面分别列举了常见的三种类型测试。

基础测试

功能测试 (Function Test)[1] 。
集成测试（Integration Test ）
单元测试（Unit Test）
契约测试（Contract Test）[2]

进阶测试

兼容测试（Compatibility Test）
UI视觉测试（UI Visual Test）
性能轮廓（Profiling）
安全测试（Security Test）
异常测试（Exception Test）[3]
猴子测试（Monkey Test）
安装、升级和卸载测试（Install、Upgrade and Uninstall Test）
耐久测试（Endurance Test）
耗电测试（Power Consumption Test）
流量测试（Network Traffic Test）
其他硬件功能专项测试[4]

产品测试

易用性测试（Usability Test）
A/B测试（A/B Test）
产品在线测试（Product Verification Test or Product Online Test）
用户测试（Customer Test）[5]

对于一个中小型项目来讲，很多时候资源都是十分有限的，很难做到全面类型的测试，大型项目更是如此，更难有足够多的资源做所有类型的测试。而且可能还由于团队人员的技术能力不足，或者所拥有的测试相关的技术栈的局限，以及开发测试环境和软件系统架构的限制，有些类型的测试是无法进行的。

所以，制定测试策略的关键点在于根据质量需求的优先级，并参考团队的各种限制来指定。

首先通过和PO、PM等进行讨论得到产品质量需求的优先级，然后根据优先级指定相应类型的测试。再根据团队的资源、项目周期、技术能力以及各种限制来制定相应的测试方法和测试技术，其中包括使用自动化测试还是手动测试、使用什么测试工具和测试框架、测试的范围和程度等。

下表是一个典型手机应用的测试策略表的样例(这个只是一个模拟项目的样表，真实项目中的各类信息应该更多，并且可以根据具体情况添加新列。并且注意，这些测试并不一定由测试人员或者QA来做，应该由整个团队一起协作完成)：

表中的质量需求优先级的获取是一个比较繁琐的过程，需要和各个利益相关者一起讨论并且协商获得。

根据这个测试优先级表，就知道应该把资源优先投入到高优先级的测试中。等高优先级的测试做到团队可以接受的程度后，再按照优先级做下一个类型的测试。这个表中的优先级在开发过程中不是绝对不变的。如果PO、PM等利益相关者对于产品质量需求的优先级发生了改变，在得到团队同意后，还需要改变这个表中的测试优先级。所以需要经常与团队更新测试进度，并及时获得团队各个角色对于测试和产品质量需求的反馈与更新。

其次可以根据测试金字塔等模型来思考不同类型测试之间的关系和工作量，但是很多情况下也可以不用参考这些测试模型，因为移动应用的复杂度一般不会特别高，并且当前大多数情况下，移动应用中复杂的业务逻辑都会尽量在服务器端进行处理，所以移动应用很多时候只是一个用户交互系统，所以应该尽可能的完成会影响用户使用的E2E流程测试，然后再继续做其他类型的测试。

但是对于在移动应用中实现复杂业务的项目，测试策略还是应该尽量思考测试类型之间测试用例重复的问题，尽量避免重复的用例，降低测试成本。

制定测试架构

通过测试优先级表，我们获得了简易版的测试策略，然后就应该制定测试架构了。由于嵌入式软件的特殊性，其测试架构也与常规的桌面系统和服务器系统有一定的区别。下图为针对上面样列测试策略相对应的功能测试架构：

图中只针对功能测试进行了进一步的详细架构设计，并没有对其他测试比如集成测试、兼容性测试和稳定测试等进行详细架构设计，感兴趣的读者可以根据自己项目的实际情况自己尝试一下。

通过这个架构图，可以比较系统以及直观的了解各种类型测试的分布、关系和测试系统的架构等。

然后配合测试优先级表就可以较好的指导团队进行有效的测试，比如制定更好的测试计划，制定更适合的自动化测试系统等。并且还可以更有效的评估产品质量，比如什么类型的测试没有做，那么那些特定方面就存在较高的风险。

不过任何软件系统都是存在缺陷和风险的，关键是看这些缺陷对于开发商和用户产生的影响有多大，风险是不是在可控范围内的。永远不要尝试去找到所有缺陷并消除，而是要从风险大小、影响程度等各方面综合考虑，增加团队对于产品质量的信心，并且不要对客户产生严重的大范围的影响。

注：

[1]. 后台常住应用测试也属于功能测试。

[2]. 单机应用可以不用考虑做契约测试。

[3]. 异常测试包括弱网测试，比如低速网络信号、网络时断时续，网络切换以及无网络等，突然断电等。

[4]. 其他硬件功能专项测试包括硬件功能关闭，硬件功能异常等。

[5]. 用户测试包括收集用户使用信息，并生成用户真实使用的测试用例来对系统进行测试。

更多精彩洞见，请关注微信公众号：思特沃克

WeChat Sina Weibo Evernote Pocket Instapaper Email LinkedIn Pinterest