我们应该如何推进测试体系建设 —— 技术推进篇

如果你看这个标题感兴趣,证明你至少应该是一个测试老鸟,或者在公司中成为核心骨干的 Tester 了,甚至更多数应该为测试的管理者,负责一个公司的测试体系建设,很高兴看到这么多仍然在测试行业奋斗中的同行们,还是要提前说一句,观点代表个人,不喜勿喷

写这篇文章的初衷,是因为看到目前太多的公司在测试上投入很大精力,很多测试同行在自己公司中十分努力的推行测试体系,但收效甚微。同时,笔者经常和入行不久的测试沟通、交流,甚至和入行很久的测试高手交流时,也难免会有很多人表达出对自动化尤其是 UI 自动化的向往、崇尚。所以也略微的分享一些自己的心得吧

首先我们看 2 张图,第一张图相信绝大多数的测试人员都看到过,但是做的时候很少有公司按此落地。

上图中明确表示了我们到底应该如何建立测试体系,但是实际工作中确实很少有公司落地了。本质上我觉得有 2 点原因,1 是因为本身让研发自发的做单元测试,就是一件挺难的事情,谁也不会一开始就认为自己的代码就是有问题的,而且我们大多数人所经历的工作,也都没有哪个公司建立起来了这样的研发文化;2 是因为还是有部分人认为 UI 最能代表用户,UI 所触发的,就是用户触发的,UI 一定涉及到了接口,涉及到了底层。

关于第 1 点,笔者不做太多的解答,毕竟现状如此,而关于第 2 点,这里面我们反问几个问题,相信应该可以改变一部分人的观点了。1,以 UI 为驱动,要多久才能把 Service,即我们所谓的接口可以覆盖的东西都覆盖掉;2,UI 成批量实现并结合 CICD 后,一次回归需要多久的时间;3,在现在的互联网以快为核心的浪潮下,有多少稳定不变的东西可以让我们的 UI 自动化有较大的回报。所以当你算完 ROI 后,你自然知道如何四两拨千斤了。简而言之,即使要四两拨千斤,也需要用对力气。

图一我们就说这么多,接着我们看图二。

图中,列出了 5 点笔者认为测试体系中应该做的事情,并且每一项前面的数字,就代表了应该推进的顺序。

首选,不管怎么说,黑盒测试或者称为业务测试,目前仍然为大多数公司无法替代的,虽然在国外已经有很多公司没有手工测试了,真正将自动化测试迈向测试自动化,但在国内多数公司,仍然为质量的主要保证手段。现状如此,但还是有很多公司未把黑盒测试做好。做了很多年测试管理,面试了许多人,居然发现很多公司都不在乎黑盒测试的方法、用例设计的质量,把测试质量寄托于个人的能力,甚至于人的状态、心情。这无异于是将质量交给上帝,运气好,客户没发现问题,然而现在的用户、客户越来越聪明,对于产品整体的要求也越来越高,没有哪个公司是可以不在乎质量真正长久做大的,所以,如果还是有测试的管理者,认为黑盒测试就是点点点的话,确实该好好反思了。

其次,我一定会在接口测试上大作文章。当然,推进时受制于公司现状不同,我们可能面对的局面不一样,受到的困难也不同。有的公司认为质量就是测试的事情,没有文档,没有思路,就像传统的瀑布模型下的职能式的管理,核心的瓶颈点在于团队的管理者,如果这个管理者对于某一个问题束手无策,那么该问题很可能无解了。在这种环境下,如果测试人员想出彩,无法难上加难。相反有些公司本身就注重质量,注重过程中可沉淀的文档,有一定的流程、标准,那此种局面则更加方便我们推进。
这里给大家提供一个思路:
1,接口测试从状态级别做起,做到最基本的覆盖,那么就可以和公司的持续集成挂钩了,一方面能很快的验证接口当前情况,是否因为改动有 bug,另外方面也可以很快的对当前环境的可用性做一个评估。
2,状态级别完成后,我们进行参数级别的验证,参数的类型、范围、是否必填、默认值、参数间的关联性等,当然这里就会自然而然的用很多方法生成正向及逆向的用例。
3,当参数级别验证完成后,我们针对返回体做校验,必填项是否都已经返回,字段是否都已经返回了,字段间的关系是什么样的(比如父子关系),数据类型是否正确。
4,其实做到前 3 点,整个的接口测试就已经很不错了,然后针对测试用例分级,对应到公司不同级别的 CI 当中,就已经是比较好的体系了。如果再往下的话,就是对返回值的一个校验。有些读者会认为,这个本身就应该是校验的内容啊,确实是的,但是有些公司环境很多,有些公司环境少,环境多的时候,我们用一套接口脚本,同时运行多个环境,本身就已经对接口脚本提出了很高的要求,数据动态获取,接口间的相互关联,前置后置等等,此时再校验不同环境下的返回值,是很有难度的。当然能做到更好
到此,接口测试基本完成,接口测试做为自动化测试中最好见成效,也是构建最快的一项,在整个的质量体系中发挥着极大的价值。

然后,我们反过头来推进静态代码扫描。有些研发人员会说,这不是开发的工作么?我认为,和质量相关的,其实都可以归属到质量体系中来。静态代码扫描做为一项较低成本并且可持续运行的工具,较好的替代了人工 Code Review 时的不确定性及高昂的成本,且不谈有很多公司就没有 Code Review 的习惯。所以,静态代码扫描做到好了,是能发挥很大的价值的,技能规范研发人员的代码风格,也能发现渐层的问题,比如空指针、基本代码逻辑的检查等,长期把静态代码扫描做下去,对于研发质量一定是有很好的帮助的。

之后,我们推行单元测试,为什么这么重要的内容一开始不推,且图一中明显提到了单元测试应该是最花费时间投入的,成本最低,收效最大。原因正如我们前文所述,如果没有较好的检查机制,你很难说单元测试覆盖到了什么样的水平,并且单元测试是否真的有效的覆盖了。这里就依赖很多工具的使用,比如 Jacoco 对于单测的度量,同时更依赖于我们是否可以把他推行到研发的日常工作中。

最后,当我们将整体工作建立好后,再来做 UI,此时的 UI,我们就可以投入精力,从用户最常用的,较为稳定的地方推行,UI 本质上无法帮助我们发现人工发现不了的问题,做为回归测试,降低人力投入的重要手段,本身就具备高投入的特性。同时,笔者这里再提醒下大家进行 UI 时的一些关键点。1,一定是和测试用例打通,并且优先实现高级别的用例,后期可逐步替代人工冒烟、回归。并且紧密结合公司持续集成。同时,释放的人力可以做更多有价值的测试,比如探索性测试等。2,一定要在 UI 自动化的过程有效的断言,断言是达到机器替代人工、自动化是否有效的极其重要的判断标准。一句话,没有断言的 UI 自动化就是耍流氓,断言比例高的时候,甚至一条用例就会有 10 条以上的断言,分为页面显示级别的,元素状态级别的(比如有些场景 button 不能点击或者隐藏,进行特定操作后可点击或显示),当然还有数据库级别的。

说了这么多,还是希望后续的测试同行们在推行测试的时候,可以更好的做出成绩。很多公司情况不一样,推行的方式也不同,甚至顺序也不同,这里只是笔者的个人观点,当然如果对大家有帮助则更好。第一篇,我们以技术推进的角度来看如何推进测试体系建设的,后面我们再一起讨论下以质量管理的角度来看如何推进整体进展。

原文链接:https://mp.weixin.qq.com/s/8LsKtbx3DYITVnf2D8I72w


↙↙↙阅读原文可查看相关链接,并与作者交流