随着移动客户端产品的快速发展，整体的节奏也在加速，无线事业部技术团队要在1-2周时间内确保一个可以上线的版本而不出大的问题，作为测试人员我们希望跟团队一起在最后能响亮的对产品质量喊出“YES”，而不是“NO”。

　　作为产品质量最后的一道把关者，要如何在短时间的快速迭代中高效保证质量？ 质量问题只有在测试环节才被重视和关注么？那么其他环节测试又能做些什么呢？

　　在最初面对效率与质量，似乎就像鱼和熊掌一样不能兼得的时候，曾不止一次问自己团队类似的问题。在过去的1年里我们也摸索了很多，遇到过很多困难，确实发现了不少问题。最终尝试了这种全过程质量保障的方式，在此想跟大家分享下：为什么我们要跳出单一的测试环节，从整个项目研发的全过程出发去关注效率与质量。

　　产品在进入开发阶段后除了编码引入的bug外，整个过程（打包-提测-发布-监控）都有可能引入质量和用户体验问题。而这些过程引入的问题让我们的技术人员精力分散，效率降低，进而导致质量有所下降。

　　举个例子，在打包环节我们曾遇到过这样的问题：

　　1、以前要测试IOS-App，没有mac设备的童鞋必须要找开发人员线下要测试包；

　　2、IOS-App想要搞内测版，每次必须整理好工程代码打成压缩包上传；

　　3、android-App虽没有设备限制大家可以自主打包，但由于太自由了，导致相互测试与调试的包都不够一致，结果要验证多次。

　　4、android客户端发布前的几百个渠道包，依靠某程序员单机打包得耗上半天；

　　这些问题不是引入bug的罪魁祸首，但却直接影响了找出bug、修复bug的效率。大家希望能有办法让项目组能尽可能的专注。所以我们将它关注起来，出现了摩天轮上的打包系统（摩天轮即为阿里无线内部以提升质量和效率为主的一个工具化平台）。项目打包通过界面配置和系统自动触发的方式，不但将之前投入到这些工作中的人力解放出来，也避免了以前开发/测试获取包信息对应不一致，排查问题对不上座的现象。目前已支持全集团40多个app产品的系统打包。

　　当然提测阶段仍然是我们关注做多的一环节，遇到的各类问题更是层出不穷。我们都知道移动应用的测试，除了client端之外，纵向受网络和服务端的干扰，横向受各种厂商型号的设备兼容性影响。

　　再一起来看看下面我们曾遇到的问题：

　　1、客户端的测试要如何去便捷覆盖服务端逻辑？

　　2、如何从客户端更直观的去检测隐藏在后端的逻辑？

　　3、不同的机型到底要覆盖多少才会有底，具体又要如何去选择覆盖？

　　4、移动平台的多样性带来的自动化维护成本，如何才能快速投入产出？

　　5、稳定性方面的测试投入耗时较多，测试任务繁重。