一千个人心目中，有一千种DevOps。在我看来，DevOps最核心的特点，应该是持续化。在CI/CD时代，提倡持续集成和持续交付；而在DevOps时代，软件生命周期的每个阶段都被持续化，因此有了持续计划，持续开发，持续集成，持续测试，持续部署，持续交付和持续监控。
持续的对立面是非持续，是一次性，是"瀑布"。有了持续化，生产者才能够将软件产品更早交付给消费者，从而更快获得消费者的反馈，并反过来指导产品的迭代升级。这是一个生产者与消费者双赢的模式。
持续化是一场软件研发革命。然而，要实现持续化并不容易。不管在CI/CD时代还是在DevOps时代，许多人都将持续集成看作"发动机"，看作驱动软件研发体系运转的关键。
在落地持续集成的过程中，一个经常被忽略的重点是持续集成和持续测试之间的关系。注意到，在DevOps中，在单个迭代周期内，集成和测试并不是独立和串行的，而是耦合和交织的。它们是"你中有我，我中有你"的关系。
为什么这么说呢？
所谓集成，就是将开发者提交的代码改动与代码主干进行合并，并将合并后的代码进行编包和组包的过程。集成的输入是源代码，输出是可用的软件产品。
因此，从快速交付角度来看，持续集成是核心，但是从又快又好交付角度来看，持续集成加上持续测试才是核心。
根据我的切身经历，相比持续集成，持续测试是一件挑战性更大的工作。在持续集成中，开发者在提交代码改动时，依据持续测试的反馈结果，来判断代码改动是否有问题。持续测试的最大挑战在于，随着时间的推移，反馈周期会不断增长，从而降低研发效率，成为项目瓶颈。
关于持续测试的反馈周期，我们有这样一个公式：
测试反馈周期 ∝ 测试用例数 * 代码提交频率 / 测试资源数
这个公式表明，测试反馈时间与测试用例数成正比，与代码提交频率成正比，与测试资源数成反比。在我所经历的一个中等规模软件项目中，随着时间的推移，测试用例数，代码提交频率和测试资源数的变化趋势如下。
图1: 测试用例数变化趋势图
从图1可以看到，在项目的整个周期内，测试用例的数量持续增长，从最初的1个用例增长到600多个。用例数量增长，意味着用例的总执行时间也同步增长。
图2: 代码提交数变化趋势图
从图2可以看到，在项目的大部分时期内，每日代码提交次数，从0次逐步增长到40多次。在项目末期，随着软件进入维护模式，每日代码提交次数才有所下降。
图3: 测试机器数趋势图
从图3可以看到，测试机器经过数次扩容之后，达到一个稳定的最大值。在云计算背景下，计算设备成本降低，扩展也容易，但是资源毕竟是有限的，测试机器数量不可能无限增长。
由于测试用例数量和代码提交数量都在增长，然而测试资源有限，根据上述公式可知，测试反馈周期是不断变大的。从开发者角度来看，就是等待时间越来越长，提交代码越来越难。
持续测试，成为DevOps中的一个重大瓶颈。
如何打破这一瓶颈，缩短持续测试反馈周期，提高持续测试效率呢？从技术角度来说，主流的方法有四种，分别是批量测试，并行测试，选择性测试和优先级测试。下面这张表格，就介绍了这四种技术的工作原理和特点。
如果说传统软件研发模式下的常见瓶颈是测试，那么敏捷和DevOps软件研发模式下的常见瓶颈就是持续测试。我们对持续测试的认知，还难言充分。如何让持续测试变得更好，是一个值得研究的重要课题。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理
