你真的需要自动化测试吗？

前几天在技术交流群，有同学抛了一个关于自动化测试的思维导图，问大家有什么好的建议。

思维导图如下：

看完之后我问了几点问题：

• 团队目前的痛点是什么；
• 有哪些可能的解决方案；
• 自动化是不是最好的方案；
• 实施自动化，团队内部是否做过调研评估；

很多同学做自动化测试时，常见的问题是我要怎么做，用什么框架，脚本和数据分离，陷入熟悉依赖路径，但缺乏思考。

这篇文章，我想谈谈在自动化测试落地之前，关于是否需要做自动化以及什么时候做自动化的一些思考和个人看法。

要不要做自动化测试？

其实自动化这个概念很早前就有了，最初主要应用于工业生产领域，指通过指令或软件控制机械工具完成一些重复度较高的工作。后来随着计算机技术的发展和互联网行业的蓬勃趋势，开始应用于软件开发和测试领域。

无论是我们比较熟悉的各种自动化测试如UI自动化、接口自动化甚至单元自动化测试或者是CICD，其本质都是通过借助工具帮我们完成日常工作中重复度较高，手动又比较费时的工作。

自动化测试的优势在于将重复度较高又比较费时的工作交给软件工具，解放人力资源去做其他更有创造性的工作，提升投入和产出的比率，用更少的成本投入创造更大的价值。

那么工作中要不要做自动化测试呢？答案是肯定的。

但是新的问题来了，自动化测试=适用于任何阶段任何团队的吗？并不一定。

什么时候做自动化测试？

我们都知道，软件测试（质量保障）其实追求的是2个目标：质量和效率。

本质来说，自动化测试是一种辅助的提效手段，而不是解决问题的目的，且并不是唯一的提效手段。

工作中什么时候开展自动化测试，如何开展，做什么类型的自动化测试，是否有足够的资源投入，都是需要经过慎密的调研评估，而非为了自动化而自动化，这样无异于舍本逐末。

我们日常的测试工作都是在软件工程的方法论指导下，遵循一定的流程规范来开展的。软件工程的方法论，其实本质来说就是三个词：成本+收益+风险。即尽可能用较低的成本投入获得更高的收益，且承担的风险可控。

三者不可兼得，需要做一定的平衡和牺牲，以达到最终的质量和效率目的。

因此在评估是否要开展自动化测试之前，需要尽可能基于上述几点因素来考虑。

举个例子：

某创业型公司，当前处于产品初创和快速迭代期，追求的是快速推出MVP产品推向市场，业务不稳定，人力资源紧张，技术基础设施很差，那这个时候是不适合做开展自动化测试的。

前面提到了， 自动化测试适用于重复度较高的工作，且不是一蹴而就即插即用就能解决问题的。需要相对稳定的业务需求迭代、比较成熟稳定的研发团队和一定的技术基础设施建设，以及较为规范的流程才能更好的落地，达到提效的目的。

那么如果要落地自动化测试并达到提效的目的，需要考虑哪些因素呢？

落地自动化测试前要思考的

以我个人的实践经验来讲，落地自动化测试之前，需要思考下面一些因素：

• 当前面临的痛点是什么？
• 痛点背后的原因有哪些？
• 有什么可以解决问题的方案？
• 自动化是不是最好的解决方案？
• 当前的情况是否适合开展自动化测试？
• 开展自动化测试前要调研评估哪些因素？
  • 选定试点范围；
  • 自动化工具调研；
  • 团队成员技术栈匹配度；
  • 要投入多少人力时间资源；
  • 预期的投入产出比是多少；

就像群里一位同学说的一段话：“我昨天和业务部门开会，有部门领导提出来说全链路压测平台和商用的差距还很大，需要好好建设。我说，你们都基本没有全链路压测需求，我投入大量精力去做，但没人用啊”。

企业的本质是追求更大化的价值，其实并不关心用什么技术手段。自动化是一种辅助提效手段之一，并不是做事的目的。

不要为了自动化而自动化，看到钉子就想找锤子砸下去，相比于做什么，更需要考虑的是做这件事的原因和带来的价值。

这篇文章，我阐述的是一种思考问题的方式，而非具体的实践路径。

下篇文章，我会聊聊自动化测试在具体的工作中如何落地，敬请期待。