前几天在群里有人聊起明年的规划时，提到了要引入自动化测试，顺着这个话题聊了很多。之前我也写过类似的文章（接口测试平台演进思考、你写的接口脚本合理么），但大多数都是从工具本身提供的能力或者个人研发的角度来看自动化测试。很少从团队的角度来看待这个问题。所以整理了一下思路，本文将从 4 个方面来展开。

01 自动化测试的目标是什么

从个人的角度来讲，通过引入自动化测试工具，可以有效的时间，提高测试效率（真的么？）。同时可以体现自己的代码力，提升自己的价值和议价能力（嗯，好像是这样的）。那么，从团队的角度来说，当我们决定引入自动化测试时，我们的期望是什么？个人感觉至少有以下 4 点期待：
1、突破现有瓶颈，提升测试效能，同时降低人力成本（注意不能把降低人力成本放在核心位置，否则容易适得其反）；
2、降低人为错误率，规避因为人的疲劳和惯性思维以及投机取巧导致的错误；
3、提升执行效率，以及应对高强度连轴转任务，搞定长时间的系统稳定性测试和高并发场景的压力测试；
4、增加软件的信任程度，解释下这点，个人认为，自动化测试是用来保障产品的质量下线的，当我们执行完正确自动化脚本后，我们可以信任当前的交付物是基本可靠的；

02 引入自动化的成本问题

从个人的角度来讲，开展自动化测试，投入的基本上就是时间成本（不管在公司倒腾还是回家研究，付出的都是时间成本），但转换到团队的角度，事情就会变得比较复杂了。我们需要综合考量一些影响因数。主要有以下三个方面：

2.1 时间
项目的持续时间短：当有一些项目紧急程度非常高，从立项到结束只有一个月的时间，而这一个月的时间可能相当长的时间都是用来看需求文档，改需求文档，编写测试用例等，真正留给测试的时间是不多的。所以这个时候如果强行要做自动化测试，维护成本将会非常高，ROI 也低。
项目存在的时间短：别是一些外包类项目或者政治任务的项目（这类项目其实并不少见）。并不会长期存在，或者没有长期测试的必要，那么也不需要考虑引入自动化测试，想要自动化测试的 ROI 高，一定是那些可以被重复执行和测试的内容。

2.2 成本
团队成员的能力成本：如果要引入自动化测试，那测试人员的能力要求也会相对高一些，例如他要懂协议，需要了解协议的传输过程及原理，还要有一定的编码能力。这类人员的成本也会相对高些。
研发团队的配合成本：想要更好的自动化，前提得是有标准化的东西。由于测试不是研发过程的源头。所以我们能够改变的东西很少，只能去尝试、推动开发人员做一些改变。例如想要更好的做接口测试，你至少要有规范化的、时效性强的接口文档吧（不管是第三 API 文档还是 Swagger 文档）。很多团队都没有这些文档，或者都是一些过期的接口文档。仅仅依赖测试人员通过抓包来了解接口，在我看来，这种情况下开展接口自动化，纯粹是浪费时间，效率低不说，维护成本还高。
时间投入的成本：不管是开发脚本还是维护脚本，都是需要时间投入。虽然从长远上来看，自动化的效率肯定是会提高的。但是针对某个迭代来说，是需要从原来的功能测试时间中抽出一部分时间来编写脚本和维护脚本的。那么是否可以保证这些时间的投入并算入工时，而不是靠团队成员利用业余时间来投入呢？（接触过不少团队，接口测试脚本编写是靠爱发电的）

2.3 效率问题
在引入自动化测试工具的时候，工具并没有告诉你要自动化什么东西，哪些东西值得做自动化。盲目地追求自动化覆盖率并不是什么正确的事。个人认为，我们可以从两个方向上做尝试：
基于风险的自动化测试：我们应该最先测试最有失败风险的功能点，如果发生所述失败，这些功能也会带来最大的负面后果。例如：会影响核心流程的使用、在测试环节中 BUG 相对集中的功能点、影响服务级别协议（SLA）的功能点以及可以造成经济损失的功能点。
基于 ROI 的自动化测试：我们知道，基于 BUG 的修复成本，越底层的自动化测试越能产生高价值。理论上来说，我们应该优先引入单元测试，来保障第一道代码质量。但现实是怎么样的，大家都清楚。所以我们会建议优先引入接口/集成自动化测试，尽早的发现问题。至于 UI 自动化，如果没有规范化的前端约束，不管是基于 JS 的还是基于 XPath 的，成本都非常高（基于图像识别的 UI 自动化，严重依赖识别算法，而且代码的可阅读性太低）。
当我们能够很好地平衡这几者的关系后，引入自动化测试才有可能产生真正的价值，并长期落地，否则很容易变成面子工程，半路夭折。

03 常见的自动化测试误区

在第 1 点中，我们聊了引入自动化测试的目标和期待。但往往团队对于自动化测试有过高的期待，觉得引入自动化测试就可以解决所有问题。所以在这里需要澄清一些关于自动化测试的误区。

3.1 为了做自动化测试而做自动化测试
事先没有做好规划，管理好引入自动化测试的目标和期待值，只是人云亦云。盲目幻想，认为自动化测试能够省钱，想着搞起来自动化，省掉多少多少人力成本；自动化测试如果做得成功的话，是可以节省成本和提高产品质量，但是，把节省人力成本当做核心目标，这样的对于项目来说是致命的；我们应该认识到自动化测试是存在它本身的局限性的。

3.2 自动化测试为什么发现不了 BUG
发现更多的新缺陷应该是手工测试的主要目的，不能期望自动化测试去发现更多新缺陷。事实上，自动化测试主要用于发现原来的缺陷。用于回归测试，而大量的新业务测试更多地还是依赖手工测试。自动化测试不直接找 bug，而是通过解放有经验的测试工程师的生产力，让其从重复的回归测试中解放出来，从事新的测试方法和测试手段的研究。通过自动化测试解放出测试人员的时间和精力来间接地找到更多、更深层次的新 bug，将产品质量再提高一个档次。如果没有建立一个正确的软件测试自动化的观念，认为测试自动化可以完全代替手工测试，或者认为测试自动化可以发现大量新缺陷，或者不愿在初期投入比较大的开支等，则自动化测试一定会让我们大失所望。

3.3 自动化测试工具是 “万能” 的
很多人一听到自动化测试，就认为自动化测试工具可以完成一切测试工作，从测试计划到测试执行再到测试结果分析，都不需要任何人工干预。显然，这是一种理想状态，现实中还没有哪个测试工具有这个能力，并且将来也不会有。在现实中有关的测试设计、测试案例，以及一些关键的测试任务还是需要人工参与的，即自动化测试是对手工测试的辅助和补充，它永远也不可能完全取代手工测试（未来的 AI 探索测试或许会做到，但至少目前来看，还缺乏实际的落地场景）。

3.4 能录制回放的自动化工具是最好的
在早期的自动化测试工具中，都会有录制回放的功能。这个功能有多鸡肋，实际用过的同学都应该清楚，说多了都是泪。但领导往往没能意识到这点，感觉录制后直接回放，不是很简单的么？录制回放在工具中消失过一段时间，大家都很少提及。现在又火起来了，为什么呢？因为现在的录制回放和而来的已经不是一回事了。早期的录制回放指提是录制某个用户的行为动作，然后通过协议回放出来。而现在大家在说的录制回放，更多的是基于流量的录制回放，录制的是大量用户的实现请求，然后在测试环境中回放。完全不是一个级别的事。后者需要依赖大量的基础能力，诸如基于中间件的流量录制、数据清洗改造、修证数据后再回放到测试环境等等。

04 不同阶段的自动化测试形态

只有当我们正确认认识到自动化测试能给我们带来的预期收益和目标后，结合团队的具体情况，逐步的引入自动化测试，给予一定的时间，慢慢沉淀和发展，才有可能真正实现自动化测试的价值。在不同的阶段，自动化的形态和预期也不一样。
图片

4.1 基于 PostMan 之类的简单接口调用
在团队前期，应当致力于一些基础规范的制定，比如让开发提交时效性高的接口文档，或者通过类似 Swagger 的插件来自动生成文档。我们经常说开发讨厌两件事：讨厌自己写文档，讨厌别人不写文档。现在有很多工具可以自动生成 API 文档。

4.2 引入测试框架
当有了一定的基础之后，我们可以通过框架来解析接口文档，生成最基础的测试用例。然后基于这些接口或者用例来补充和完善测试场景。当下流行的测试框架也很多，如 HttpRunner，Pytest，Junit 等等。如果团队成员的代码能力更强些，开发的配合度更高些，也可以尝试一些左移的框架，如基于 SpringBoot@Test 的注解，基于 SOA 的单元测试（可以听听云大在 2021MTSC 上的演讲），或者基于注解的接口测试（胡小天在 2021MTSC 上的演讲）

4.3 发展成平台化
当团队实践自动化测试有一定的规模之后，再考虑做成平台化，推广到更多的团队当中去。这个大型的公司中都会有相关的工具。各类大会上的分享也有很多。可以适当关注下。（可以参考我之前的文章：接口测试平台演进思考）

4.4 产品化
现在这类的 DevOps 平台厂商也很多，都会带有一定的自动化测试工具，产口良莠不齐，自己需要做好甄别。
4.5 机器学习、AI 探索
这类自动化测试在最前沿的一线互联网公司正在逐步的落地，大势所趋。但个人对此还是比较谨慎。原因在于，对于一般的企业，很难有大量的数据来训练这些模型（这个大量不是一般的大）。第二，如果我们引入训练好的模型，如果要落地，则需要与它的数据结构相匹配，否则又得重新训练，团队面临的改造成本非常大。

总结：
只有当我们正确认认识到自动化测试能给我们带来的预期收益和目标后，结合团队的具体情况，避免对自动化测试有过高的预期，避开一些常见的误区，逐步的引入自动化测试，给予一定的时间，慢慢沉淀和发展，才有可能真正实现自动化测试的价值。

[原文连接]（https://mp.weixin.qq.com/s/qwp9jt2djKBAvTyju7NrTg）