如何在开发阶段保证软件工程质量 (程序员要做些什么)

前言

大家常说：“代码和人，有一个能跑就行”，但这并不意味着我们可以放弃职业道德。与土木工程一样，软件工程也需要一些可度量的指标来衡量产品的交付质量。一个高质量的软件绝对不能只靠测试人员来保证，更不能相信程序员自己立下的“军令状”。

本文将从程序员的角度，讲述开发阶段如何保证软件质量：

硬性代码度量指标(静态代码分析，漏洞扫描)
自动化测试（Unit Test, Integration Test, Specification Test, E2E Test）
交付文档(程序说明文档，SOUP文档，Safety文档)
持续集成测试环境

硬性指标

静态代码分析

相信很多同学都被屎山代码折磨过，使用静态代码分析可以将长篇累牍的垃圾代码扼杀在摇篮里。

以Sonarqube为例，它支持几十种编程语言，其中包含数百种C#代码规则，对不满足管理员要求的代码将给出警告，因此经常在Pipeline CI 阶段充当代码质量网关，它可以自动检查pr中的不良代码，添加comments，并生成质量报告。

使用严格的代码审阅工具可以“强迫”开发者写出易于维护的规范代码，例如：

要求每个函数不得超过40行，圈复杂度不超过10，结构深度不超过3；
代码必须通过单元测试，并且行覆盖率或条件覆盖率必须达到80%；
代码与注释的比例不得超过10:1；
不能使用魔法数字，比如 if(a == 3), 它会要求你将3定义为一个有意义常量等；
警告相同的字符串或者相似的代码片段在程序中出现多次；
它还会手把手教你写代码，例如： IDisposable接口的最佳实现。
Sonarqube | C# static code analysis

漏洞扫描

2021年Java开源日志组件Log4j爆出“核弹级”安全漏洞，该日志组件在全球范围内广泛使用，一时引起轩然大波。

你有没有想过自己项目当中引用了多少种类库呢？这些类库本身又依赖了哪些类库？你如何保证这些类库是安全的？并不是每一个风险漏洞都会上热搜，构建高质量软件必须引入漏洞扫描机制。

同样的，我们需要在Pipeline CI阶段集成漏洞扫描工具，在pr阶段发现程序，程序依赖项，以及依赖项的依赖项，容器镜像等，其中的高/中/低不同安全等级的漏洞，开发者可以依照建议进行修复，软件交付的重要指标就是不存在漏洞库里已知的安全漏洞。

自动化测试

自动化测试同样可以作为Pipeline CI的一部分，无法通过测试验证的代码，不应该允许Merge；无法通过E2E 测试的软件版本，也不应允许发布。

每一个合格的项目都应该具备Unit Test，根据需要添加Integration Test，Specification Test更接近黑盒测试，而E2E Test则是利用页面自动化测试手段，完全模仿用户行为的一种测试方法。

.NET中常用的测试框架有xUnit，MSTest, NSubstitute，Shouldly，Specflow等。.NET 测试框架 xUnit，MSTest, Specflow 使用经验汇总_郭麻花的博客-CSDN博客

Unit Test

单元测试是纯函数测试，它只关心测试模块的输入和输出是否满足要求。单元测试必须保证单一性，纯洁性，不能使用真实的网络请求，不能使用真实的数据库连接，也不可以读取系统当前时间等等。

初识单元测试的同学可能体会不到它的价值，通常会有以下问题：

拿着Mock出来的数据库或者网络请求测试有什么意义呢？
一个加法函数，输入两个1，结果肯定等于2呀，为什么还要写单元测试？
一个几百行的业务函数，调用了N次网络接口，查询了N次数据库，单元测试怎么写？
单元测试比代码还多，以后改了需求还要维护单元测试，岂不是要累死？
...

这里不多做解释。单元测试是软件质量的基础保证，99%的项目都无法避免非纯函数，这是事实，但这绝不是抵触单元测试的理由。你会发现责任不清晰，逻辑混乱，又臭又长的代码很难进行单元测试，强制要求项目达到80%的单元测试覆盖率可以倒逼开发者重构不良代码。

单元测试可以保证业务逻辑和算法的正确性，还可以提高代码质量，增加日后重构代码时的信心。

Integration Test

开发人员习惯将项目分为不同的模块，这样的代码结构易于管理和维护。Integration Test指的是同一项目中不同模块之间的统一测试。集成测试也应该避免使用真实的数据环境，除非你的项目大部分内容都是与外部集成，并且要保证每次的测试环境都是干净的。

集成测试按照设计方案可以分为全量测试，增量测试，三明治测试。

全量测试指的是将系统作为一个整体进行测试，这种方案需要更全面的测试用例，需要投入更多的人力物力，所以往往在开发阶段后期进行，而且它更关注整体因此不能测试到所有细节。

开发阶段更常用的是增量测试。增量测试一般可分为自顶向下和自底向上两种方式，可以按照系统的开发进度，逐渐集成新的测试模块。或者按照项目的代码逻辑，从最底层或最顶层代码开始测试，然后逐层增加测试模块，最终完成系统整体测试。

分层混合测试又称为三明治测试，三明治测试按照侧重点又可分为高层测试，底层测试和集成测试。高层测试关注用户接口，底层测试接近单元测试关注实现细节，集成测试则是两者结合测试。

Specification Test

Specification Test接近于黑盒测试，一般通过设计具有实际意义的Scenario来进行测试。在Specification Test当中可以使用Mock的外部数据，也可以使用真实的数据库或者其它基础设施。但是一定要控制好测试边界，将关注点放在当前代码项目上，尽量减少对外部系统的依赖，并且最好使用容器化技术，保证每次Specification Test都是在干净的测试环境下进行。