我们知道体系化的建立是一个比较困难的过程，但是体系化意味着规范化与流程化，在某种程度上可以提高我们的工作效率。面对软件测试行业存在体系化建设问题，我有些见解与看法，可以提供给大家进行探讨：软件测试体系化——我们共同的责任。如果你看完本文还有更多关于软件测试体系化的见解，欢迎来达内软件测试培训班进行交流。

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

上图中明确表示了我们到底应该如何建立测试体系，但是实际工作中确实很少有公司能够落地。本质上我觉得有2点原因：

1.是因为本身让研发人员自发的做单元测试，就是一件挺难的事情，没有谁会一开始就认为自己的代码就是有问题的，而且我们大多数人所经历的工作，也都没有哪个公司建立起来了这样的研发文化;

2.是因为还是有部分人认为UI最能代表用户，UI所触发的，就是用户触发的，UI一定涉及到了接口，涉及到了底层。

关于第1点，笔者不做太多的解答，毕竟现状如此，而关于第2点，这里面我们反问几个问题，相信应该可以改变一部分人的观点了。

1.以UI为驱动，要多久才能把Service，即我们所谓的接口可以覆盖的东西都覆盖掉;

2.UI成批量实现并结合CICD后，一次回归需要多久的时间;

3.在现在的互联网以快为核心的浪潮下，有多少稳定不变的东西可以让我们的UI自动化有较大的回报。所以当你算完ROI后，你自然知道如何四两拨千斤了。简而言之，即使要四两拨千斤，也需要用对力气。

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

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

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

02、其次，我一定会在接口测试上大作文章。当然，推进时受制于公司现状不同，我们可能面对的局面不一样，受到的困难也不同。有的公司认为质量就是测试的事情，没有文档，没有思路，就像传统的瀑布模型下的职能式的管理，核心的瓶颈点在于团队的管理者，如果这个管理者对于某一个问题束手无策，那么该问题很可能无解了。在这种环境下，如果测试人员想出彩，无法难上加难。相反有些公司本身就注重质量，注重过程中可沉淀的文档，有一定的流程、标准，那此种局面则更加方便我们推进。

这里给大家提供一个思路：

1.接口测试从状态级别做起，做到最基本的覆盖，那么就可以和公司的持续集成挂钩了，一方面能很快的验证接口当前情况，是否因为改动有bug，另外方面也可以很快的对当前环境的可用性做一个评估。

2.状态级别完成后，我们进行参数级别的验证，参数的类型、范围、是否必填、默认值、参数间的关联性等，当然这里就会自然而然的用很多方法生成正向及逆向的用例。

3.当参数级别验证完成后，我们针对返回体做校验，必填项是否都已经返回，字段是否都已经返回了，字段间的关系是什么样的(比如父子关系)，数据类型是否正确。

4.其实做到前3点，整个的接口测试就已经很不错了，然后针对测试用例分级，对应到公司不同级别的CI当中，就已经是比较好的体系了。如果再往下的话，就是对返回值的一个校验。有些读者会认为，这个本身就应该是校验的内容啊，确实是的，但是有些公司环境很多，有些公司环境少，环境多的时候，我们用一套接口脚本，同时运行多个环境，本身就已经对接口脚本提出了很高的要求，数据动态获取，接口间的相互关联，前置后置等等，此时再校验不同环境下的返回值，是很有难度的。当然能做到更好。

到此，接口测试基本完成，接口测试做为自动化测试中最好见成效，也是构建最快的一项，在整个的质量体系中发挥着极大的价值。

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

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

05、最后，当我们将整体工作建立好后，再来做UI，此时的UI，我们就可以投入精力，从用户最常用的，较为稳定的地方推行，UI本质上无法帮助我们发现人工发现不了的问题，做为回归测试，降低人力投入的重要手段，本身就具备高投入的特性。

同时，笔者这里再提醒下大家进行UI时的一些关键点：

1.一定是和测试用例打通，并且优先实现高级别的用例，后期可逐步替代人工冒烟、回归。并且紧密结合公司持续集成。同时，释放的人力可以做更多有价值的测试，比如探索性测试等。

2.一定要在UI自动化的过程有效的断言，断言是达到机器替代人工、自动化是否有效的极其重要的判断标准。一句话，没有断言的UI自动化就是耍流氓，断言比例高的时候，甚至一条用例就会有10条以上的断言，分为页面显示级别的，元素状态级别的(比如有些场景button不能点击或者隐藏，进行特定操作后可点击或显示)，当然还有数据库级别的。

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

恭喜你阅读完了本文，我知道任何一件事物从无到有，都要经历一个比较困难的过程，对于软件测试体系的建设更是，甚至要推翻你之前的测试思路、测试顺序，但希望你敢于突破，任何事物的规范化都意味着进步，软件测试体系化是你我共同的责任。如果你想通过软件测试培训培养自己的体系化，欢迎你来达内软件测试培训机构进行咨询。

免责声明：内容和图片源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。