对很多企业来说，移动端应用的使用比web端的应用使用率更高。但是迭代速度的加快和迭代版本的增多，每发布一个版本，不仅要测试新功能，还要对整个应用进行完整的回归测试，而且每个版本都需要进行测试。时间真的很紧张。
主要存在的是以下几个难点：
- 移动端的测试效率总是低于web端的测试效率。
- 难以全面覆盖种类繁多的测试设备。
- 移动端的测试很难达到web端测试的颗粒度。
- 移动端测试出现不可预测的场景可能性更大。
- 移动端网上的测试资料不够系统，不够全面。
个人经验：
- 移动端的测试效率总是低于web端的测试效率。
移动端的应用使用场景更广泛，不像办公用的电脑，一般固定在某个网络通畅的位置，而移动设备使用场景多种多样：例如地铁，楼道，山区等网络信号较差的地点；应用打开较多，内存不足，cpu占用较高；手机设备的型号，android版本设备兼容问题等；所以要找到一个合适的切入点，将功能测试尽可能的做到速度快，质量高。不得不承认，selenium对web端的测试支持还是最优的，显示等待隐式等待等机制，可以很好的支持。而移动端的测试往往因为电脑与手机设备间的通信延迟，无线链接很不稳定（推荐使用数据线链接）等问题很影响测试效率。
个人经验：对api接口进行二次封装，提高稳定性，设备之间通过数据线链接，保持网络完好。
- 难以全面覆盖种类繁多的测试设备。
web应用：测试相对简单，一般的只需要测试游览器和版本的区别，而不通的浏览器提供了不同的driver支持。
移动应用：移动设备种类太多，太繁杂，尤其是android设备和版本的碎片化，而且设备的开发商又对android进行了二次封装，要覆盖所有的移动设备种类几乎是不可能的。
个人经验：
测试设备的选取：当前最流行设备的top10，使用人群的top20，使用地区的top10，根据这三个条件基本上就将百分之九十五的人员都覆盖掉了。
兼容性测试从成本出发最好选择云测平台进行测试，机型的选择根据上述3个top选择；
- 移动端的测试很难达到web端测试的颗粒度。
web应用，测试人员能够模拟出几乎所有的用户操作行为，而移动端应用增加了很多复杂的用户手势，例如：放大缩小，按住拖拽，捏拉等，现有的测试框架不支持所有的手势，会有一些手势不能测试。
个人经验：能够回归测试的用自动化，不能够测试的手势人工验证。
- 移动端测试出现不可预测的场景可能性更大
用户出使用场景不同，导致了移动端测试不可预测性大，例如：安装成功了，但是丢失了部分文件，导致不能正常运行，设备连接出现问题等等不可预测的问题；
个人经验：专项测试（后续博客细讲，之前博客也有过专项测试的内容）
例如：第四十届中国软件质量大会：APP专项测试：https://blog.csdn.net/pingsha_luoyan/article/details/103651269
一张图了解app测试点：专项测试：https://blog.csdn.net/pingsha_luoyan/article/details/99556502
- 移动端网上的测试资料不够系统，不够全面。
移动端兴起时间较短，解决方案，框架比较新颖，有待完善。
