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

如果你看这个标题感兴趣，证明你至少应该是一个测试老鸟，或者在公司中成为核心骨干的 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