聊聊测试在持续集成中的地位

lsekfe

做持续集成(CI)工作以来，我越来越感受强烈的一点是CI不是孤立存在的。CI与软件开发存在密切联系，这是众人皆知的。然而，CI与软件测试存在的密切关系，提及者却不多。
　　"皮之不存，毛将焉附"。如果没有软件开发，CI将完全没有存在意义；如果没有软件测试，CI将黯然失色许多。这篇文章，就来聊聊软件测试在CI中的角色。
　　CI存在的最基础的需求，是把来自各个开发者的代码，或者来自各个开发团队的软件模块，以某种方式编译，组装在一起，成为一个完整的软件包或者产品，交付给下游的测试部门或者用户。
　　基于这个需求，CI的一部分任务可以简单解释为: 获取开发者提交的代码，将代码编译成一个个的模块，然后将多个模块组装成一个完整的包。这个过程中，还涉及到编译环境管理，软件版本管理，分支管理，模块之间的接口管理等技术问题。
　　虽然这部分内容很重要，但是如果仅仅只有这部分内容，CI无疑不会有它在现代敏捷开发和DevOps中如此重要的地位。CI的重要性，还体现在它拥有另一部分不容忽视的内容，那就是软件测试。
　　测试为什么会成为CI的重要内容？这实际上是来自软件质量方面的要求。根本原因在于，CI要交付的不是任意的一个包，而要是一个好包。毕竟，交付一个不工作的包，意义何在?
　　那么，什么样的包才是好包？口说无凭，需要证据。证据来自测试结果。一般认为，通过软件测试检验的包，才是一个相对较好的包。
　　具体来说，光有编译和基本的版本检查还不够，我们还需要利用各种各样的基于软件需求或者代码实现所设计的测试用例来保障软件包的质量。
　　并且，这里的测试往往不是单一的，而是覆盖CI编组包全过程的。例如，构建好一个模块之后，最好在针对这个模块的测试通过后，我们才继续组包；组装好一个包之后，最好在针对这个包的测试通过后，我们才发布给下游。
　　这里隐含着软件测试的分级原理。对于有一定规模的软件项目来说，CI中的测试往往是多级别的。例如，针对单个模块，有单元测试UT，模块测试MT；针对相互联系的多个模块，有集成测试IT；针对一个完整的包，有冒烟Smoke测试，UI测试，端到端E2E测试等。
　　当然，并不是所有的测试都一定能够成为CI的一部分。在加入CI之前，测试至少要满足若干准入条件，包括完全自动化，环境易于扩展，执行速度快，外部依赖可控，自身稳定性高等特点。这是一个重要的话题，我们另文讨论。
　　多级别的软件测试，极大地丰富了CI的内涵。有了这些测试的协助，CI将不仅仅是一个编组包的流水线，更成为一个7 x 24 小时运转，永不懈怠，严格守护软件质量的“门神”。
　　从这个角度来说，包不包含软件测试，或者说包含的软件测试充分不充分，是衡量CI有效性的一个重要指标。不包含软件测试，或者软件测试虽然存在但是很不充分的CI，在我看来是功能残缺，地位有限的。
　　当然，万事皆有两面性。软件测试加入CI，既能丰富CI的内涵，也给CI带来了巨大挑战。这种挑战不仅在于CI需要实现许多用于软件测试的任务和脚本，还在于更多方面。
　　为了应对软件测试海量执行次数的需求，CI需要准备和维护足够多的测试资源。
　　为了提升测试执行效率，CI需要研究和引入并行测试，选择性测试，动态优先级测试等有难度的技术。
　　为了应对回归测试中广泛存在的测试不稳定性或test flakiness(原谅我迄今为止没有找到很好的中文翻译)，CI需要对大量测试数据进行持续监控和统计分析，并做好偶现问题跟踪解决工作。
　　一言以蔽之，测试进入CI，意味着CI需要投入更多资源，并且日常的大部分工作将围绕软件测试和质量保障展开。
　　如何衡量针对CI的这份投入是否值得？需要具体情况具体分析。一般来说，如果加入CI的测试的有效性比较好，能够发现软件问题，那么可以认为投入产出比还不错。毕竟在CI阶段，软件问题的解决成本还比较低。如果这些问题遗漏到下游，造成的损失和解决的成本不在一个数量级。
　　啰啰嗦嗦说了这些，其实就是想说明CI与软件测试存在紧密关系。抛开测试策略来单纯讨论CI策略，往往会失去重心。 通过与多个级别的测试结合在一起，CI才能如虎添翼，更好完成在软件开发全过程中保障软件质量的重任。