为什么我们的自动化测试做不起来？

摘要：如果让两个相互不认识的、来自于不同公司的测试工程师自由讨论，我猜他俩寒暄的第一个问题会是：你们公司的自动化是怎么做的？

自动化测试落地状况

如果让两个相互不认识的、来自于不同公司的测试工程师自由讨论，我猜他俩寒暄的第一个问题会是：你们公司的自动化是怎么做的？如果你去问一个来自于大厂的质量部门的测试架构师：你家的测试平台有什么功能？你能听各种天花乱坠的功能、自动化能力，让你叹为观止。而同时让你去问该厂的某个业务测试工程师：你们的自动化测试做的怎么样？对方很有可能会告诉你：啥？自动化？哪有什么自动化！

很有意思的现象，是吧？今天我不谈怎么写代码了，来聊个在绝大多数公司都存在的、而且很可能不愿意被外人知晓的问题：为什么我们公司/产品/项目的自动化测试做不起来？

自动化测试做不起来，本质上就是自动化测试体系难以落地，那怎么才叫落地呢，以我的经验来看，需要同时具备以下四点：

有统一的测试框架、平台
有基本的CI、CD流程，具备自动、定时触发执行的能力
自动化测试用例覆盖度高，能切实有效地帮助测试人员回归，明显地提高测试效率
测试、开发人员认同自动化测试执行的结果

难吗？感觉要求其实并不高，但你跟同行去聊聊的话，你会发现要完成这四点是件不容易的的事情。下面我尝试从测试人员、研发体系（公司）维度来剖析下，来讲讲为什么难，为什么自动化测试体系落地这么困难。

测试工程师

编码能力是稀缺技能

中国软件测试起步比较晚，测试工程师这个职业很有可能是伴随着“软件外包”兴起的（请勿考古）。早期的测试工程师清一色地做着功能（手工）测试，不需要有编码能力，甚至觉得不用会编码是理所应当的。（2019年我校招时发现还有这样的论调）

之后逐渐出现了能用QTP或者Rational Robot做自动化的人，这些人几乎站在了那时测试职业食物链的顶端，睥睨群雄。我还记得，十几年前读大学那会，我在一家软件公司实习的时候，当时的主管向我介绍QTP，一脸的崇拜的样子。那时能应用QTP主要依赖它强大的录制、回放能力，大部分人自动化测试依然不需要会写代码，能简单修改简单生成的vbs即可。

测试人员逐渐接受编码技能，应该是从web2.0概念盛行后，大量的项目需要使用开源的selenium、watir进行自动化测试，自动化测试的需求越来越旺盛，一些有好奇心的测试人员开始学习编码做自动化测试，也有部分开发人员选择转行做专职的自动化测试。

不过十年过去了，时至今日，编码能力依然是普通测试工程师的稀缺技能：目前软件测试从业人员中，还是有非常大比例的纯功能测试，虽然他们大部分都想学一门编程语言，但是大多就是停留在想学的程度，所付出的努力并没有带来实质的改变。

现如今的自动化测试技术栈，不管是接口、web、移动端，绝大多数都是基于开源项目来构建，不再有QTP那样的录制回放能力，没有编码能力自然无法实施自动化测试。

找不到切入点

当测试工程师掌握编码能力后下场写自动化测试了，会面临下一个问题：我该怎么从头开始做自动化？

困惑于不知道选什么样的测试框架、工具，困惑于不知道从接口、Web、移动端哪一层入手。简言之，找不到切入点。

框架选型

先提一个很不好的现象：很多测试人员学习编码是从学习测试框架切入的，比如selenium、appium，他们所具备的编码能力只局限于这些框架API；而不是先学习编程语言、再学习测试类库这样的路径。

所以这样来，测试人员大多只能从自己熟悉的框架着手，而不能全盘考虑各类框架优劣势：

做web自动化，只能想到Selenium
做移动端，大概率会选appium
做接口，postman、jmeter

所以这样来，其实也不存在框架选型的困扰：技能点就点了一下，没得选。

分层选型

然后是测试分层，其实测试分层是个比较大的话题，单元、集成、接口、UI都可以切入。大部分测试文章都推崇金字塔分层模型，一张经典的图：

在你具备足够的能力下，我当然建议你把自动化测试下沉到底层去，实现更高的ROI。

不过我觉得金字塔分层模型过于理想化，单元测试的难度也不小，在微服务架构下，我更推崇的是橄榄球分层模型，即尽可能接口测试先行：

重视框架、平台开发，不重用例覆盖率

再来说一个怪像：如果你留意下一些测试社区，里面有非常多讨论开发测试框架、平台的帖子，也会有很多分享自造轮子的帖子，但如果你想找一些自动化用例设计的帖子，却发现非常的少。

我面试过很多写过测试平台的候选人，这样的面试里我很喜欢问：你的平台上有多少用例？测试覆盖率怎么样？这个时候大部分人就卡壳了，有些支支吾吾说不上来，有些能说上来，只是自动化用例的数量比较少，几十、一两百，整体的测试覆盖率非常低。

似乎大多数测试开发工程师的心态是：我能写代码我厉害，测试框架、平台信手拈来，至于填充用例这种体力活跟我没关系。

殊不知，自动化测试体系的核心资产绝对是测试用例，而不是那些烂代码堆砌出来的测试框架、平台。

用例代码Bug比项目Bug还多

这又是一个让测试工程师很尴尬的事情，因为代码功底问题，有时候一个简单的用例几行代码里能出一堆Bug，结果测试结果完全没有可信度。

不要不信，我抛一个简单的问题：如果一个分页查询接口，它的响应报文中total字段表示匹配记录总数，data字段值是一个数组，返回当前页匹配记录条数，你会怎么校验total的值的正确性？

对于这种情况，也没什么太多可说的，不断去强化你的代码能力，而且心态上有改变：不要觉得自己是会写代码的测试，觉得比功能测试强；当你在写代码了，应该像开发一样要求自己，要求自己的代码。

不仅去学测试框架，更要去学数据结构、设计模式、数据库、中间件…

另外，在开发测试用例时，严格遵守FIRST原则：

FIRST

自动化测试用例缺少有效维护

在完成自动化测试用例的早期积累后，你也把用例执行整合进一些CI系统中了，开始进入收获季节了，享受自动化测试带来的测试效率提升的红利了。

在这个时候千万不要觉得自动化测试落地成功了，这个时候很像在魔兽世界里把一个职业练到60级，你不是走到了终点，而是终于跨进了真实世界的大门了。

产品、功能每个版本都发生着变化，自动化用例的期望值也随之变化，如果不能及时、有效跟进这些变化，无效用例就像滚雪球越滚越大，让你无法维护。

研发体系

优先级不够，没有建设的迫切性

如果把质量范畴的各类工作用四象限法来划分的话，自动化体系建设这样的事情大概率会落到『重要不紧急』象限中。

这个判定的逻辑很简单：我们当然认可自动化带来的各种价值，但是目前的手工测试也能很好的发现问题，交付的质量、效率也堪堪可行。而且，如果你真的要全面推行自动化体系落地，短期成本还会明显增加：

需要招聘有编程能力的测试开发工程师
普通测试工程师学会了自动化测试能力，有了更高的薪酬期望
越懂代码、自动化，测试范围越大（多层累加），不一定会缩短测试周期

另外尴尬的一点，自动化体系建设的成果很难量化、包装出来：写了多少测试用例、降低了多少人力成本、测试周期缩短多少、业务场景的覆盖率有多少？

挖掘分析上面的指标，你甚至会发现在某些时间段，自动化建设还带来了负作用，这就落了个吃力不讨好。

所以这一堆大大小的原因加起来，结果就导致了这个事情叫好不叫座，没多少领导愿意主动承担起这个事情来。

建设路线图不清晰

能在公司层面推动自动化建设的不多，真正落地自动化体系的不多，愿意出来分享成功经验的不多…这么几个不多累加起来，就导致了我们在建设初期很难去借鉴别人。

作业抄不到，自动化体系负责人又往往是开发背景，工程能力强，但是测试的积累不够，不一定能想清楚整个项目要怎么推动、推进路径是什么；而在执行层，执行者有可能是测试背景有不错代码能力的工程师，按理说能补足上面提到的缺陷，但是毕竟不在一个维度，看得到局部，但缺少一些全局视角。

长线建设中干扰因素多，建设决心不够

上面也提到了自动化是需要持续迭代的，这是一个长线建设，贯穿在整个产品的生命周期中。所以在研发过程中碰到的各种干扰因素在自动化建设中同样会遇到。

测试人员不够、项目周期被压缩、需求频繁改动、老板让做的等各种司空见惯的意外，迫使你不得不放下手中的自动化测试工作，改成手工测试加速发版上线。

在版本高速迭代的并且具有敏捷开发能力的互联网公司里，这些流程不合理、资源不足的现象都是合理的，你得承认、接受，并做出妥协，但不要质疑自动化、不要放弃持续建设。

测试架构组缺乏对业务测试组的穿透能力

最后提一个很痛的问题：组织架构。

很多公司尤其是大厂，缺少公司层面的质量部门。为了快速应对业务的变化，更喜欢采用垂直向的组织架构形式，把各个职能角色放进来，而整个业务条线负责人大多又是产品、开发背景，测试在垂直条线里存在感、话语权都有限。

这样的组织架构下，业务测试组缺少来自公司层面、自上而下的测试规范、行为约束。有些公司建立了一些横向的测试架构组尝试解决，甚至碰瓷中台，推测试中台或者组织中台这样的概念，想要缓解这样的尴尬。

我目前直接负责整个公司的质量体系，我的主管也充分授权，但即便这样的情况下，我依然觉得这些横向的测试架构组的产出不容易穿透到业务测试组中：双方考核目标差异、业务条线压力等都行成了厚实的壁垒，阻挡着自动化体系的落地。

写在最后

吐槽了这么多问题，文章可以改名成自动化测试：从入门到放弃了，开个玩笑：）

综上，真正要落地自动化测试，要考虑到人员能力、成本、项目周期、组织架构等因素，这是件昂贵的事情。也正因为昂贵，我们应该踏踏实实迈好每一步，不要把事情浮于表面。研发效率的提升、测试成本的降低、CI/CD的闭环这些指标才能验证自动化测试体系的成果。