互联网企业创业 如何让自动化测试跑起来?

一、自动化测试落地状况

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

如果你去问一个来自于大厂的质量部门的测试架构师:你家的测试平台有什么功能?你能听各种天花乱坠的功能、自动化能力,让你叹为观止。

而同时让你去问该厂的某个业务测试工程师:你们的自动化测试做的怎么样?对方很有可能会告诉你:啥?自动化?哪有什么自动化!

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

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

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

难吗?感觉要求其实并不高,但你跟同行去聊聊的话,你会发现要完成这四点是件不容易的的事情。

下面我尝试从测试人员、研发体系(公司)维度来剖析下,来讲讲为什么难,为什么自动化测试体系落地这么困难。

二、测试工程师

2.1 编码能力是稀缺技能

中国软件测试起步比较晚,测试工程师这个职业很有可能是伴随着“软件外包”兴起的(请勿考古)。

早期的测试工程师清一色地做着功能(手工)测试,不需要有编码能力,甚至觉得不用会编码是理所应当的。(2019年我校招时发现还有这样的论调)

之后逐渐出现了能用QTP或者Rational Robot做自动化的人,这些人几乎站在了那时测试职业食物链的顶端,睥睨群雄。

我还记得,十几年前读大学那会,我在一家软件公司实习的时候,当时的主管向我介绍QTP,一脸的崇拜的样子。

那时能应用QTP主要依赖它强大的录制、回放能力,大部分人自动化测试依然不需要会写代码,能简单修改简单生成的vbs即可。

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

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

现如今的自动化测试技术栈,不管是接口、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原则:

互联网企业创业 如何让自动化测试跑起来?

严格遵守FIRST原则

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

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

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

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

发表评论,文明发言,遵守法律法规一律通过

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: