4.3　运用综合手段保证质量和安全

我们前面讲过，源代码改动发生后的软件交付过程，主要包括三类事情：一是各种类型的检查、测试和反馈，以保证质量和安全；二是改动的合并汇聚；三是软件形态的转换，即将源代码编译构建为安装包，经过部署，转换为软件系统运行起来。若论所需的时间和精力，其中第一类事情是最大头。接下来就围绕着第一类事情来讲“运用综合手段保证质量和安全”这个策略。

4.3.1　各种各样的测试

为方便起见，我们把代码改动发生后进行的各种类型的检查、测试和反馈，统称为“测试”。各种各样的测试，用来发现软件中的缺陷，以及稳定性、可靠性、安全性等方面的问题，也用来发现软件与产品设计不相符的情况，并探测用户是不是喜欢。下面我们来看看这个广义的测试具体包括哪些测试方法。

首先，它包括我们平常说的测试，也就是程序运行起来的测试，比如单元测试、集成测试、系统测试等。同时它也包括无须程序运行，直接对源代码或安装包进行的静态检查，比如代码扫描、代码评审等。

其次，它既包括人工测试，比如人工的UI测试，也包括自动化测试，比如自动化接口测试。并且，测试不仅可以发生在测试环境下，也可以在生产环境中做测试，比如生产环境的全链路压测、混沌工程、灰度发布、A/B测试等。

最后，虽然构建、部署活动不是以测试为主要目的的，但是从测试的角度来看，它们仍然属于某种测试：测试程序能不能构建，测试程序能不能部署。此外，生产环境部署过程本身，可以采用灰度发布、蓝绿部署等方式来降低风险。严格地讲，这也属于测试。

这么多种测试手段，我们该怎么选用呢？核心思路是，根据实际情况，综合运用多种手段：一是在合适的时机做合适的测试，不能一味地强调测试左移或测试右移；二是并非所有的事情都应该分派给测试人员或者开发人员；三是自动化测试并不能完全取代人工测试。接下来我们进行详细分析。

4.3.2　左移+右移

我们先来看在合适的时机做合适的测试。

有些测试很“便宜”，可以早早地做、反复做、经常做，所发现的问题可以很快得到修复。但这样仍然会有不少漏网之鱼。那些“贵”一些的测试，则可以进一步找出问题，当然，发现问题的代价和修复问题的代价都要大一些。还有些测试，必须搭一个测试环境来做，不仅太“贵”了，而且效果可能也不好，所以干脆到线上去做。

一会儿说测试左移，也就是尽量写完代码就测试；一会儿又说测试右移，跑到线上去做。其实它们并不矛盾，这正是体现了不同的测试手段都有相应的使用时机、场合和策略。

4.3.3　测试人员+开发人员

测试该由谁来做呢？对源代码本身的检查当然由开发人员来做，也就是代码评审甚至结对编程。那把软件运行起来之后做的测试呢？一般来说，越是专业能力的测试，就越是倾向于由测试人员来编写和执行，比如探索性测试、安全方面的测试等。而越是与编程实现相关，对系统结构中某个组件甚至某个函数和类进行的测试，就越是倾向于由开发人员来编写和执行，比如单元测试、对单个接口的自动化测试等。

4.3.4　人工测试+自动化测试

自动化测试并不能完全取代人工测试。一般认为单元测试、接口测试是可以完全自动化执行的。而自动化的代码扫描尽管可以发现不少问题，但不能完全取代人工的代码评审。人工的探索性测试也没法自动化完成。一般来说，需要反复执行的、检查判断有明确标准和规则的测试适合自动化完成，然而并非所有的测试都是如此。

自动化测试要根据实际情况，逐步将自动化的比重和测试覆盖率提高到一个合理的范围内，还要按不同的测试类型，比如单元测试、对单个接口的自动化测试、接近端到端的自动化接口测试、自动化UI测试等分别考查，确定自动化的比重和测试覆盖率多大，确定对于特定场景来说是否合理。

4.3.5　综合运用

这么多种测试手段，不是必须要全部用上。流程设计得简单点儿还是复杂点儿，每个活动要做得多么深入、全面，也需要根据系统/产品/模块的具体情况来定。总体来说，越是对质量要求高的产品和服务、越是复杂的紧密耦合的系统，就越是需要步骤多一些的流程，流程中的每一件事情就越是需要严防死守，深入、全面地做。反之，就可以简单点儿做，抓重点做。

应该为不同的测试手段各分配多少力气，这个话题通常被称为测试分层策略。测试分层策略有理想主义的金字塔模型、更务实的橄榄球模型等。而在整个开发、集成发布流程中，何时该做哪种测试、以什么频率测试、如何进行质量卡点，则是集成发布策略的一部分。