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