5月底去杭州参加了一次阿里技术沙龙的活动，应会议组织者耿电兄的邀请去做了一个移动app测试的分享（详见）。有点被抓壮丁的感觉，主要是因为觉得我们团队在无线测试方面的积累还很不够，无论是相对于业界还是相对于公司内部的很多移动测试团队。不过倒是很高兴有这样的机会去参加交流，因为要准备PPT，所以也“被逼”着去了解了很多方面的内容，并且在整理的过程中促使自己更加系统化的思考移动app测试的开展。同时，在会场的时候也和很多同行做了比较深入的交流，所以也很感谢阿里给大家提供了这样好的交流的机会。
PPT下载地址：
提起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无论就团队人员还是技术积累都是在发展中的阶段，所以需要我们去做取舍优先做哪些。
你会发现，曾经以为很难做到的事情，
