关于移动app测试的一些思考和实践 - 含PPT下载

5月底去杭州参加了一次阿里技术沙龙的活动,应会议组织者耿电兄的邀请去做了一个移动app测试的分享(详见 http://club.alibabatech.org)。有点被抓壮丁的感觉,主要是因为觉得我们团队在无线测试方面的积累还很不够,无论是相对于业界还是相对于公司内部的很多移动测试团队。不过倒是很高兴有这样的机会去参加交流,因为要准备PPT,所以也“被逼”着去了解了很多方面的内容,并且在整理的过程中促使自己更加系统化的思考移动app测试的开展。同时,在会场的时候也和很多同行做了比较深入的交流,所以也很感谢阿里给大家提供了这样好的交流的机会。


提起app的测试,特别是技术一点的测试,大家立马想到的是各种app自动化的工具和技术,以及开展的方法。其实app的自动化只是测试中的一小部分,实际工作中我倒是建议把自动化放到第二阶段,特别是针对于从网站延伸出来,在app测试上积累还不深的团队,不要急着去弄自动化的工具和框架,而是先把一些基础的东西做起来。这些东西对应整个app的质量,包括app本身的质量和整个运营的质量也许更有直接的影响和效果。

除了PPT里面提到的,还有很多没有列到里面也值得去思考,因为PPT的角度更多从性能和服务的稳定性角度来看的。
下面是我们想到的一些方面,列出来给大家参考也欢迎讨论。
从App的角度来看,其实和传统的测试C/S架构的Client是一样的,很多的方法和思路都可以用上。
1. App端的基本功能当然是我们必须考虑的,对很多团队来说,这也是我们花费人力和时间比较多的地方。这些当然也是最基本的。如果只是从这个角度来看,app没有什么特别的,和其他C/S架构的程序的client是一样的。
2. 兼容和适配的问题。
     这个也是app测试非常关注的问题。这里的兼容和适配包含了几个方面:
     - 硬件的适配。 比如硬件的性能,屏幕的大小,一些依赖的设备比如GPS等。
     - OS版本的兼容,ios和android都有一样的问题,比如如果用了一些新的API在老的系统上不支持会导致crash。
     - 屏幕的分辨率适配。移动设备的分辨率多种多样,如果app没有做比较合适的处理就可能会显示不好,甚至影响功能的操作。
     要做到比较好的覆盖,这些都是很耗费时间的。现在想到的办法主要有3种:
     1. 自行购买或者借用设备来实际验证。 这个方法比较完整,但是受限于财力人力不可能做得很全面。
     2. 一些第三方云测试的解决方法,比如testin.cn这种,可以提供基本的运行情况和一些截图,有助于扩大测试的范围。
     3. 比较白盒的方法。将不兼容的地方整理出来,然后去分析我们的app中可能不兼容的地方。这种方法可以避免像前面的方法一样广撒网碰运气,但是对团队的技术能力的要求比较高,前期也需要花费不少的时间。
     当然,还有一个不是办法是收集用户的反馈,亡羊补牢。
3. app crash的问题
     crash, 或称为闪退的原因有很多,针对这一部分出来分析和测试,还有一个很重要的是能收集到crash的问题,做事后的修补。所以需要确认我们的app有crash上报的能力,无论是公司内部的还是第三方的平台,我们需要定期的知道外网的app crash的次数和crash的基本信息,帮助我们定位和修复。
4. App端本身的性能分析,内存泄漏的分析。
5. 代码覆盖率分析的方法也是很好的参考,无论是App端还是后台服务端。
6. 灰度发布的方案。保护app端发布和提交app store的灰度,也可以是自动更新的提示的灰度。后台服务端也可以做灰度,类似于网站的做法,不过要考虑和app的兼容性。

先写到这么多吧,这一块也是在持续的探索中。大家可能都会有一个感觉是有很多的事情要做,也可以做,但是我了解到的很多情况,app无论就团队人员还是技术积累都是在发展中的阶段,所以需要我们去做取舍优先做哪些。

  • 5
    点赞
  • 11
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值