为什么我们做不好自动化测试?

1. 自动化测试落地状况

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

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

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

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

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

2. 测试工程师

2.1 编码能力是稀缺技能

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

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

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

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

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

2.2 找不到切入点

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

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

2.2.1 框架选型

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

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

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

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

2.2.2 分层选型

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

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

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

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

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

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

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

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

2.4 用例代码Bug比项目Bug还多

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

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

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

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

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

we