移动端业务测试的那些事儿

此文已由作者徐淼授权网易云社区发布。

欢迎访问网易云社区，了解更多网易技术产品运营经验。

在这个移动互联网时代，移动端（iOS/安卓）的测试与web/wap不同，具有以下几方面特点：

• 版本一旦发出便无法收回（即使现在有了jspatch等热更新机制，但实践证明还是尽量少用吧~），这就意味着移动端需要更严格的质量保障，也意味着有更多的逻辑要放到服务端去控制；

• 客户端版本涉及到多方面的依赖：除客户端native功能外，还依赖服务端、H5（wap）等，当然还包括不同项目独有的其他依赖；

• App服务端流量峰谷不明显，每天的晚上会是相对的高峰期；

• 版本周期相对固定，发版频率相对稳定。

     鉴于以上特点，本文将从客户端老版本的兼容问题、依赖的其他工程的发布、服务端数据的Mock和客户端测试上线整体思路几方面，阐述移动端测试独有的那些事儿~

一、 老版本的兼容问题

由于产品、交互不断的需求变动，已发出的版本（老版本）必然会有无法符合产品新需求的情况，那么就要依赖服务端给出一个老版本的兼容模式。关于老版本的兼容，有以下几点：

• 需求/交互评审一定要重视，评审会议中及时提出疑问，并和客户端开发、服务端开发一起评估老版本兼容方案的可行性；

• 在开发接口定义过程中也要适当参与进去，接口定义必然要考虑其扩展性，了解开发的接口实现，更利于qa在测试过程中对老版本进行更全面的测试；

• 必要时和开发一起进行测试用例的评审，评估哪些需求是必须对老版本兼容进行详细测试的；

• 在测试执行的过程中，多问一问自己以及测试团队，老版本兼容会不会有问题？新老版本并存时可能引发什么异常吗？老版本和web端/wap端共存时是否会有兼容性问题？

二、 关于移动端依赖的其他工程

   由于客户端版本会有app服务端、H5等多方面的依赖，项目计划中各端各工程的版本发布可以用下图表示：

• 对于测试人员来说，每次客户端版本提交都要先确保app server、h5等相关依赖（图中的Server-v1.0、H5-v1.0/Server-v2、H5-v2）已经提前发布上线，并且保证这些相关依赖与老版本的正常兼容；

• App server、h5以及其他的一些依赖工程并不一定都是随客户端版本发布的(如图中的Server-v1.1、H5-v1.1版本的发布)，这就要保证每次的发布都能使各历史客户端版本正常运行，qa需要对客户端具有相关修改点的历史版本进行回归。

三、服务端数据的模拟

 如上图所示，一般情况下服务端会在客户端提交之前先上线，然而实际项目进展中很可能没有这样理想的情况。在我们的项目中，就遇到过这种情况：

产品经理：有一个xxx的需求，包括三端（web、wap、app），app的xx版本要支持此需求；

后端开发：目前人手不够，这个需求怕是在app发版本之前无法完成；

项目经理：客户端先把这个功能预埋进去吧，先发了版本，服务端随后支持……

测试人员：客户端做了某项功能，服务端却支持不了，怎样测试？这就需要服务端返回数据的模拟。

具体我们使用的有以下两种方案：（前提条件：测试人员和双方开发人员一起完成功能的具体接口定义，客户端开发按照接口将功能实现）

• 由服务端开发在接口中mock数据返回，做到服务端不去实现逻辑，只返回结果。正是由于需求变更无法预测，大部分的逻辑放在了服务端，客户端很多时候只是做一个对用户的结果展示。因此，这种服务端去mock返回结果的方式是可行的。而作为客户端qa，要考虑测试各种可能结果的表现形式，也就是组织mock结果的用例。为了方便测试，mock结果往往会在工程的配置文件中进行配置（看项目组习惯，也可以通过测试接口进行Mock）。                                   

       这样，可以保证客户端版本按照项目计划按时提交，而后再进行服务端逻辑的测试与上线。

       优点：可以做到与真正接口的返回保持完全一致。

      但是这种方式还是要通过服务端开发去mock数据返回，那么是否可以不依赖服务端去进行数据返回的mock呢?

• 我们搭建了一个Mock server去模拟服务端的接口请求。对客户端的请求做相应修改，对Mock server做相应配置，在客户端的debug模式下，对特定接口、特定账号的请求，直接发往mock server，而放弃对真正server的请求。如图，根据mock server的配置，客户端请求接口1时，访问测试服务器；请求接口2时，进行帐号的判断，对于帐号A，请求测试服务器，对于帐号B，请求Mock Server。而qa可以根据接口的定义，对自己想要的接口的response做各种形式的构造，形成各种用例进行测试。

       优点：不依赖服务端开发的进度，只要接口定义好即可执行客户端的测试。

四、客户端测试上线整体思路

QA要做的不仅仅是测试本身，更是要对整个项目流程的清晰把控并提出合理改进意见。在我们的项目中，每次在版本相对稳定后，都会按照计划让产品、交互、视觉同学进行版本的走查，看是否符合设计同学最初的设计理念，这时往往会有些功能交互视觉上的调整。而这些调整时常会带来一些小问题，也因此而踩过一些坑。经过几个版本的实践，我将移动端测试的执行过程分为这样几个阶段：

• 作为qa，要重视交互/视觉走查阶段的一切交互、视觉修改。和开发一起评估设计同学提出的交互、视觉修改是否存在风险，确认无风险再去修改；

• 此时会发现追求完美的视觉同学们不断去优化视觉效果，而不断的视觉优化难免会改出些问题，因此，发版本前，根据测试情况对交互/视觉走查给出一个明确的deadline, 进而让qa有足够的时间对版本进行完全的回归；

• 不同于web/wap工程，app的服务端流量峰谷不明显，晚上往往是高峰期，因此服务端上线一般选择在白天；

• 在版本提交之前，留出bug bash的时间供团队一起测试来提高版本质量，关于bug bash，这里不再详细赘述，仅对移动端特有的注意事项进行说明： 

       1. 测试环境：会议室里准备好测试wifi
       2. 测试设备：大家自己的手机+测试机，鼓励大家多个手机同时测试，尤其iOS和安卓对比测试，更容易发现潜在bug
       3. 测试内容：打印出客户端安装包二维码，方便大家扫码安装测试

       4. 测试成果：将大家找出的bug按照安卓、iOS、H5、服务端进行归类推进bug的修复

实践证明，以上所述对版本质量保障的效果是显而易见的，既降低了服务端上线可能遇到的风险，又加强了客户端的内测，给予qa完整回归客户端版本的时间。

网易云免费体验馆，0成本体验20+款云产品！ 

更多网易技术、产品、运营经验分享请点击。

相关文章：
【推荐】 硬盘任性丢数据，但分布式存储一定可靠吗？
【推荐】 Dubbo与HadoopRPC的区别