引入UI自动化测试

我们要有这样的认知，手工测试到自动化测试是必然的，在团队初期，产品功能相对单一，功能点少，团队中的测试人员通过手工测试来控制BUG流出，保证产品质量。随着产品功能的不断完善，业务逻辑的不断复杂，测试的复杂性越来越大，测试的时间消耗越来越多，特别是回归测试。因为回归测试并不因为当前迭代做的东西少就回归的少，回归是对整个产品功能的回归，全流程的重测，由此所带来的测试成本会随着迭代的增多而越来越高。伴随着团队业务扩张所带来的信息断点问题加剧，为了保证产品品质，单单依靠手工测试已经不行了，此时需要把以人为驱动的测试行为转化为机器执行，以便节省人力、时间、资源，提高测试效率，自动化测试则成为团队下一阶段的必然选择。

1. 实战历程

在我负责的敏捷开发转型实践团队中，UI自动化测试首先从APP团队开始，原因是APP团队的产品是面向C端用户的，用户体量大，发布频次高，对产品的品质和稳定性要求极高，每次回归所占用的时间长，工作量大。在当前阶段，主要依赖手工测试，测试人员虽然经常加班，但是还是感觉测不完，伴随而来的就是测试脱节引起的产品品质问题。从产品角度讲，APP产品逐步趋向成熟，页面元素及业务逻辑相对稳定，切入的时机也比较好，具体的实战步骤如下：

1)       测试人员与自动化实现人员配合梳理目前系统中可以实现UI自动化测试的主流程，计划主流程覆盖率为70%，除与硬件进行交互的流程不覆盖外，其他的要全部覆盖掉。然后基于梳理的主流程，准备相应的测试用例。

2)       自动化实现人员搭建APP UI自动化测试平台，总体规划是采用Appium+Testng+STF+Appetize +Jenkins 实现一键自动化，自动分配可用机型，执行用例，采集性能数据，帮助发现App的BUG和性能瓶颈，然后形成报告，推送到相关负责人的邮箱。

3)       自动化实现人员基于搭建的自动化测试平台，实现DEMO级别的应用还原，保证技术选型的正确与测试框架的稳定。

4)       开发人员修改APP页面元素ID，为UI自动化测试的快速实现提供更加准确的页面元素定位，同时完善主流程自动化的实现方法，依据每次迭代进行优化改进，逐步补强UI自动化测试环节。

自动化代码执行时两台手机同时安装APP，并打开配置好的CASE对应APP页面，两台手机因硬件配置不同 ，执行相同的CASE，反馈速度是不同的，具体参考下图，虽然同时执行登录操作，但是一台手机仍旧停留在弹窗提醒界面，一台手机已经到了接受验证码的界面。

自动化测试报告在Jenkins中可以进行邮件通知母版配置，配制完成后，自动化测试报告会以邮件的方式推送给相应的负责人。

自动化测试报告会挂在邮件附件当中，点击后可以打开看到完整的测试报告，报告清晰直观。在刚才的实例中，我们用的是两台手机，报告中会提供两台不同手机的用例执行结果，对于出错的用例，会提供出错的LOG、运行的LOG 、错误截图、视频录制，如下图所示，举例了一个报告总体情况及一个用例执行报错情况，对于错误视频，可以点击回看。

STF是一款非常便捷的移动设备管理控制工具，转型实践中，我们发现，公司购买了很多手机，分散在不同的团队中，虽然公司有一个手机管理员，管理所有手机的借入与借出，但是时间一长，就乱了，想用手机时，别人在用，或是根本找不到可以使用的手机，手机管理面临管理混乱、管理难的问题，同时设备的利用率低下。后来，自动化测试同学提议，通过STF可以批量的对大量的移动设备进行WEB端管理，把手机集中在手机箱中，通过网络访问来使用手机，指定安装APP与执行相关操作。除减少了指尖的触感外，其他操作相同，对提高手机资源使用效率，非常的有帮助。在实践中，我们发现，团队成员在前期非常的不适用WEB端的操作，还是非要拿手机，说，我就喜欢拿在手上的感觉，如出现这种情况，团队会灵活处理，毕竟，团队成员对新事物的适用需要时间，而手机握在手里的真实触感和方便操作更是团队成员短期内无法突破的习惯障碍，对于STF能否在团队中存活下来，目前还是个疑问。

Appetizer 通过DEX插桩的方法，全自动地向APP内多处插入代码，在程序运行的过程中，监控异常和闪退、搜集主线程卡顿与耗时操作、HTTP/HTTPS请求和响应、CPU和Java堆内存消耗等。采集代码经过调优，对APP运行性能影响小于1%。收集的运行数据存储在设备的本地，完成测试后上传到Appetizer服务端进行分析，产生详细的问题报告、各项指标等。各项数据可以以多种格式导出，JSON， CSV， HTML，支持不同定制化数据分析以及集成服务。在我的敏捷开发转型实践团队中，主要通过Appetizer进行UI自动化测试以及性能分析，展示性能报告，目前主要应用到移动APP端。