持续集成易,持续测试难

发表于:2020-2-12 14:36  作者:肖哥shelwin   来源:测试不将就

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 软件测试

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

      本文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理

【福利】填问卷送精选测试礼包+接口测试课程!为测试行业做点事!

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2020, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道