上篇文章讲了下关于终端自动化的一个探索《终端自动化测试探索之路》，今天来聊聊关于自动化质量评估的维度，包括UI和接口。
误报率
误报率，指的是由于非应用或系统代码缺陷导致的自动化用例执行失败次数占所有自动化用例执行失败次数的比率。简单讲，误报就是应用或系统无代码或功能缺陷但是自动化用例执行失败。误报率是衡量自动化的一个核心指标，体现的是自动化用例的稳定性。一般导致UI自动化和接口自动化误报的主要有以下几个因素：
UI自动化：
- 应用集成频繁，可用测试设备资源不足；
- 网络环境不稳定，网络频繁超时延迟；
- 测试账号被风控；
- 测试设备各种无法预知的系统弹框；
- 外部系统稳定性不可控，如宿主机断电关机、测试设备离线等；
- adb通讯不稳定；
- 自动化用例有Bug造成不稳定；
接口自动化：
- 应用经常发布，导致服务不可用；
- 网络环境不稳定，网络频繁超时延迟；
- 应用依赖外部系统，外部系统稳定性不可控；
- 自动化用例有Bug造成不稳定；
针对以上问题，可以从以下几个方面来提高UI和接口用例运行的稳定性。
UI自动化：
- 可以根据测试设备资源情况更改应用集成触发的频率；
- 尽量给UI自动化设备连接稳定的无线网络；
- 测试账号申请加白名单；
- 通过另起一个服务自动监听识别系统弹框，自动点击关闭；
- 针对断电重启问题，如果没有断电保护设备，那么就需要配置开机自启服务来重启自动化相关进程；
- adb通讯不稳定的问题可以考虑尝试通过docker容器技术的方式来实现；
- 增加失败自动化用例执行重试机制，失败率或次数达到一定指标才明确将用例标为失败；
接口自动化：
- 增加失败自动化用例执行重试机制，失败率或次数达到一定指标才明确将用例标为失败；
- 对外部系统进行mock；
发现率
发现率，是指应用缺陷代码和功能被自动化用例检测出来的概率，影响发现率的主要因素是下面两点：
- 自动化用例校验逻辑有遗漏，检验不全面；
- 自动化用例覆盖率不足；
提高发现率要与自动化投入成本进行平衡，不需要盲目追求发现率。
经过我们一年多的实践，发现UI自动化在BVT（每日版本测试）和MAT（冒烟测试）这两个阶段发现问题的概率比较高。
覆盖率
自动化测试覆盖率主要有以下几个指标。
接口覆盖率，评估对测试接口集合的覆盖度。如果有一条自动化用例能够覆盖该接口的一个正常业务场景的测试，那么该接口就是被自动化覆盖的。
接口/UI功能用例覆盖率，指的是自动化用例在所有接口/UI功能用例中占的比率。接口/UI功能用例中各测试用例具有优先级之分，因此对应的自动化用例覆盖率也会有优先级之分。其中比较重要的是核心用例覆盖率，它指的是P0级场景用例的自动化比例。个人经验上来说建议UI自动化用例覆盖率应该优先追求对核心用例的覆盖，接口自动化测试倒是可以尽可能覆盖100%。
代码覆盖率，是从应用代码层面评估自动化的质量，它的统计方式是运行完接口/UI功能的所有自动化用例后，接口/UI功能实际执行的逻辑代码的覆盖程度。
覆盖率指标优先级从高到低分别是，核心用例覆盖率、接口覆盖率或接口/UI功能用例覆盖率、代码覆盖率。
UI/接口变动
在自动化用例执行的过程中经常会由于业务迭代出现，UI被测元素的变动、需求的变更还有接口的变动，针对UI变动，可以与开发约定代码的边写规范，保证同样的UI元素ID或定位信息不变，接口的新增和删除也要及时同步维护相应的自动化用例。
可维护性
可维护性，衡量新增、修改自动化用例是否方便，自动化是否易于拓展。可以从以下几个方面，来提高可维护性：
- 合理的用例层级和组织；
- 测试数据与脚本分离，可配置化，或者在设计框架时考虑数据驱动体系；
- 自动化用例易于阅读，尽可能地体现接口/UI定义和功能；
- 用例之间尽可能独立隔离，互相之间不产生依赖；
- 合理地抽象自动化基础功能代码，避免大量重复冗余代码；
