立志做国内自动化/AI测试领域最好的原创公众号。欢迎微信关注公号"测试不将就"(ID: awesometest),更多原创文章在路上。我们的口号是:“插上自动化/AI的翅膀,软件测试也能高大上”,同时会发布关于Python开发, 持续集成等精彩文章。
作者:肖哥,资深码农/技术写作者,欢迎添加作者微信(slxiaozju)交流。
PART 1: 背景
持续集成(Continuous Integration, CI)存在的意义,是发现代码改动(Gerrit ticket/Gitlab MR/Github PR, etc.)所包含的软件问题(Bug),并阻止这些有问题的代码改动合入代码主干(Master)。
CI由一系列任务(例如,Jenkins Job)组成。一般来说,只有所有任务都成功了,代码改动才能通过验证。任何一个任务的失败,都会导致代码改动无法提交。
然而,这样的CI规则基于的是一个潜在的假设,那就是:如果CI任务失败,那么失败一定是由触发这次任务的代码改动造成的。
显然,这种假设是过于理想化的,在实践中经常并不成立。因为CI是一个系统,被测软件(测试对象)只是CI的组成部分,而不是CI的全部。CI的失败,完全可能是由被测对象之外的因素导致的。
我们通常用“稳定性”(Stability)来衡量CI在判断代码改动是否有问题时的表现。对于一个稳定性足够高的CI来说,当代码改动没有问题时,它能够稳定地成功;而当代码改动有问题时,它又能够稳定地失败。这是目标。
虽然CI的稳定性受多方面因素制约。但是对于CI工程师来说,提高CI自身(即被测软件之外的部分)的质量(Quality),是一件自主可控的,能够促进CI整体更稳定的事情。
然而