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