漫谈自动化测试

前几天看到星球里几位同学在讨论各自所在团队的自动化测试实践案例和踩过的坑，蛮有意思的。

比如为了响应领导号召和满足绩效考核，搞各种各样的覆盖率指标；比如为了赶自动化测试覆盖率进度，每个接口和用例象征性的校验一下(甚至不校验不断言)，各种各样意想不到的操作。

自动化测试是必不可少的质量保障手段目前已经成为了业内共识，但在具体的实践中，往往呈现出两极分化的趋势。

做的好的不仅能很好的保障交付质量，还能借此获得上级认可和个人能力提升。做的不好的大多在低水平的误区打转，比如用什么框架好，自动化测试用 Python 还是 Java 语言，断言要不要用怎么用。

这篇文章，围绕自动化测试这个话题，漫谈一些我的理解和看法。

先聊聊为什么要做自动化测试，这也是很多新手没怎么考虑过的问题。

新手典型的一个技术认知就是，公司要给时间给资源让自己来学习某个技术，否则只做自己岗位职责范围内的事情。以自动化测试来说，很多新手总认为是公司没有让自己做，所以自己不去做或者不学习。

等到公司开始认识到需要自动化测试来提高效率的时候，又往往陷入技术纠结的状态。用什么框架，开源的还是自己造轮子，用 Java 还是 Python。或者围绕绩效去做自动化测试，一切唯指标论。

其实最好的方式是，先利用业余时间主动去学习一些自动化测试相关的知识技能，然后尝试在工作中落地实践，解决眼前遇到的各种问题。等做出一定正向效果了，向上汇报，然后争取资源扩大覆盖范围。

这样做的好处是，自己学习的自动化测试相关技能得到了锻炼，拿到了好结果，又能在上级那里有一个好的印象。上级向他的上级汇报时，也能体现出你主动思考和解决问题的能力，皆大欢喜。

自动化测试需要长期持续的投入和迭代，才能如预期拿到好的结果。技术实践本身就是一个马拉松赛跑，迈出第一步是最难的，坚持下去是第二难。

再聊聊自动化测试分层的问题。

自动化测试目前大部分的执行场景依然是针对许多最小最具体的业务场景，如果要验证复杂的业务场景(比如电商业务的下单场景，背后的业务逻辑涉及到库存扣减，三单匹配，购物车数据更新以及缓存数据的更新同步)，则势必会导致失败后的排查耗时和难度增加。

有过排查问题经验的同学都知道，越是复杂的系统，排查的难度和耗时往往是指数增长的。为了保障自动化测试的执行效率，降低失败后的排查根因耗时，才有了自动化测试的分层理念和实践，即测试同学很熟悉的三层模型。

但从真正的落地实践难度来说，UI 自动化的难度是高于接口自动化测试的。

原因在于，接口自动化除了接口请求本身，主要的难点在于组装数据。而 UI 自动化测试，一方面是 UI 本身的稳定性相较于接口层更差，另一方面则是很多测试同学都去做了接口自动化，都认为 UI 自动化投入产出比更低，导致没人做 UI 层的自动化测试。最后的结果就是做 UI 自动化测试的高手很少，恶性循环。

自动化测试除了所谓的覆盖率，其实稳定性是一个大家长期以来忽视的问题。相比于接口，UI 的稳定性需要多种手段去保障。典型的场景就是没考虑页面加载和数据展示的正确性，自动化点击了没反应，或者被吞掉了，很多人根本没有解题思路，然后各种 sleep，最终的结果就是越来越臃肿。

就像一位同学说的：一边想用它减轻工作负担，一边又想平时不看自动化失败，用的时候好用。

近几年自动化测试的落地实践其实相对来说难度降低了很多，因为框架和工具更丰富更成熟，学习资料也多。技术的进步会带来这样一个现象：让更多低水平的人可以参与，但也会限制他们能力提升的曲线。

最后聊聊自动化测试覆盖率和成果向上汇报的问题。

覆盖率本身只是一个衡量和评估的参考数据，并不能对自动化测试真正的效果和价值给出明确的结论。但出于很多因素的考量，很多同学犯了一个错，即给领导画了一个很大的饼，结果真正做起来才发现难度和耗费的资源超过预期，最后只能用覆盖率之类的指标。

比如星球里一位同学的案例：最初给领导规划的很好，结果为了赶进度，复杂的接口象征性校验一下，为了 KPI 好看。最后看起来覆盖率高了，但遇到核心功能改动后需要大范围的回归测试，接口自动化根本靠不住，还得手动回归。

真的不太建议在自动化测试实践中，太过依赖覆盖率作为 KPI 或者汇报核心，否则大家都是在单纯堆用例或者脚本。

即使出于度量和评估的因素，在制定度量指标时，建议遵循和考量如下几点：

1. 切忌面向指标/面向 KPI 做度量；

2. 考虑到冗余成本，指标不宜过多；

3. 制定指标是为了提升质量，而非做数据；

4. 根据做自动化测试的目的来制定度量指标；

5. 度量指标对比应该以是否解决了痛点为依据；

6. 度量指标是辅助评估依据，并不是唯一正确的结果；

7. 制定指标应考虑到哪些指标更实际有效，从解决问题角度出发；

8. 度量指标不要单一的评估，应结合多个维度来综合评估开展质量度量；