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

叁叁肆2018-10-25 16:50

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

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



在这个移动互联网时代,移动端(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的区别