四层质量基线提升模型(上)

作者：王洪亮

下篇请看：四层质量基线提升模型(下）

前言

目前我国外包服务发展已经达到了成熟的阶段，外包的人员可以达到降低软件开发成本的目的，但也导致存在人员流动的大的风险问题，整体人员流动率大概在15%左右。

在人员流动较大、人员技术的参差不齐的情况下，我们会发现对项目整体的开发会产生质量问题。在代码质量上、整体规范上留下大量的问题上较为突出。这些问题在迭代周期快、交付的需求压力大的情况下，会隐藏非常多的技术债，导致后期在不断迭代开发的过程中，还需要进一步的维护先前的代码，这样不仅导致成本增高，交付压力更大。

目前这种问题导致大部分甲方企业都感到困扰，优普丰敏捷学院提出了四层拉⾼质量基线的方法来解决外包开发质量及人员流动问题。

一、建立代码质量⻔禁与DevOps环境搭建

1-1.什么是代码质量门禁

代码质量门禁可以称为是一项保证代码质量的举措，要求开发人员提交的代码前需要满足内置于CI（持续集成流水线）的质量代码标准，自动化地防止提交不合格的代码，或者将不合格的代码提交到流水线里。我们可以通过质量⻔禁举措，可以提升代码质量，达到质量内建的效果，从⽽减少由于质量问题⽽造成的反复，例如一些超市的手推车是推不出超市的，通过一些措施可以防止人为失误。这个机制叫做PokaYoke（防呆）。

1-2.搭建代码质量⻔禁与DevOps环境解决的问题

目前，通过DevOps环境搭建与质量⻔禁，可以将重复劳动⾃动化，减少⼈⼯失误和提⾼⼯作效率，并且结合合适的分⽀策略可以减少开发⼈员的合并代码的时间消耗，为及时发布提供必要的守护和保证。

搭建DevOps环境搭建与质量⻔禁我们会发现核心问题，想要提降低人工失误和提高工作效率，需要在两个点上下功夫：1.stop the line（当生产线发生问题的时候要停止生产线，达到符合的生产标准，而不是继续制造更多的问题）。2.Pokayoke（通过工具来防止人们犯低级错误，而不是通过管理手段和流程）。

1-3.实际应用方案

通过技术⼿段，在持续集成流⽔线(CI)上集成⾃动化的代码校验机制，来防⽌低级错误的产⽣。下面介绍优普丰敏捷学院在实际辅导客户转型时几种常见的搭建方案。

• Githook+Checkstyle检查后端代码

GitLab基于Githook做checkstyle的代码检测时，支持Git命令下的Githook（钩子）执行一系列脚本。因此我们在Commit（提交）之前需要做代码校验，但发生本次提交代码不符合规范情况，则会中断提交。

• Githook+ESLint校验前端代码

用一套统一的规范来要求开发人员，可以有效的避免在提交和拉取代码时造成的代码错乱或冲突问题，使用Githook提交代码时可以满足该场景，同时可以调用eslint来做校验和信息规范，达到统一前端代码风格。

• Githook检查代码提交信息格式

GitHook可以推动提交信息格式规范化，还可以同时根据仓库的状态来改变整体的项目环境、监控和优化开发工作流。这样就会在提交信息的场景中减少填写“提交”“更新”等没有意义的内容。

例如正确的是规定格式应该为：

-解决bug 271

-完成feature：登录

这样通过githook检查信息格式可以确保提交信息的质量和可追溯性。

• Githook检查必须有单元测试

在Githook里填配置出各种预处理的脚本，可以使代码在检查中进行单元测试。如果出现的代码没有通过代码检查或者测试用例覆盖率等问题，会直接被拒绝。每次代码提交新的代码前都需要在Githook去进行单元测试并进行结果检查，满足所有流程跑通后，才可以进行提交。

• Gitlab-CI 集成SonarQube

SonarQube是管理代码质量一个开放平台，可以快速的定位代码中潜在的或者明显的错误，Gitlab-CI集成SonarQube可以更好完成代码检测，实现代码质量检查。

利⽤SonarQube扫描的结果和给出的建议，指导开发⼈员具体的修改代码的技巧，对代码的问题进⾏有效修复，逐渐降低遗留代码的质量问题。与此同时，通过SonarQube的扫描，阻⽌新的问题引⼊， 进⽽逐渐的让产品达到更⾼的质量。

二、自动化测试导入

自动化测试作为持续集成、持续交付的敏捷核心实践之一，有着不可动摇的地位。

2-1.什么是自动化测试

以程序测试程序，用脚本的运行代替手工测试。自动化的测试涵盖了：功能（黑盒）自动化测试、功能（白盒）自动化测试、性能测试、压力测试、GUI（Graphical User Interface）图形界面测试、安全性测试等。自动化测试可运行更多、更繁琐的测试，且快速高效。并且可执行一些手工测试执行相当困难或者做不到的测试，如大量的用户并发。同时可以更好的利用资源，具有一致性和可重复性的特点。自动化测试脚本完全可复用；提升了软件的可信度、并支持多环境下测试等。

但目前存在一种观点，认为开发写自动化测试会花费很多时间，甚至写了自动化测试，但是没有assert断言，变成虚假的测试，提供虚假的测试覆盖率，这样的测试是没有意义的。我们建议从API层开始导入自动化测试用例就可以覆盖到service和repository层。并且我们要知道在http请求中就是request/response，其实是有共同的规律的。通过简化的框架代码可以快速实现真实测试，达到高覆盖的效果。我们不是不能自动化测试，知识是方案不对，但如果想达到降低测试门槛，减少了成本的目的，也就自然而然的实施了。

2-2.自动化测试导入解决的问题

⾃动化测试是确保质量的重要⼿段。缺少⾃动化测试的代码是⽆法建⽴质量信⼼的。目前很多团队都会因为⾃动化测试需要投⼊的⼈⼯望⽽却步。但采⽤专业的快速⾃动化测试导⼊⽅案可以在少量⼈⼯投⼊的情况下并达到⾼覆盖率、保证质量。

该⽅案已经在多客⼾处采⽤，质量保障⽅⾯可以提升基线。

2-3.实际应用方案

• 核⼼代码的基础上可以通过restful接口驱动实现⾃动化测试⽅案

要避免⼈⼯投⼊过⼤⽽造成不去实施⾃动化测试的情况，因此需要测试通过核⼼代码，实现真正的测试，避免没有assert断言的假测试。

• 通过契约测试解决系统间集成问题

契约测试分两种类型，一种是消费者驱动，一种是提供者驱动。其中最常用的，是消费者驱动的契约测试（Consumer-Driven Contract Test，简称 CDC）。核心思想是从消费者业务实现的角度出发，由消费者端定义需要的数据格式以及交互细节，生成一份契约文件。然后生产者根据契约文件来实现自己的逻辑，并在持续集成环境中持续验证该实现结果是否正确。对于基于Restful API的微服务来说，它的契约就是指 API 的请求和响应的规则。结合上述所描述的⾃动化测试框架，辅以矩阵式测试⽤例编写的⽅式，以100%条件覆盖的⽅式导⼊测试⽤例。并结合CI的环境，每天早上测试接⼝提供⽅的接⼝质量，确保接⼝没有发⽣变化，就算产生了变化也可以达到实时感知。