How Many Bugs Should Be Captured In CI

07 Dec 2014   Category: Testing

一个Continuous Integration系统发现多少bugs才合适？

我知道脱离context，这个问题没意义。产品、测试方式/工具、编程语言、测试范围/粒度等都不尽相同，每人答案肯定不一样。But seriously, have you ever thought about it? How many bugs should be captured in YOUR CI system?

自打Continuous Integration这个概念出现后，自动化测试（注意，自动化测试不等于CI。）变得前所未有的重要起来。团队在测试过程中会花费大量时间搭建CI框架/环境以及想方设法将测试用例加入CI，以期通过自动触发跑用例的方式找到新代码提交是否break了之前已验证过的功能。有过CI经历的团队，想必知道这个过程中，搭建和维护整个CI环境/用例的effort还是挺大的。

那么当别人问起我们在CI里发现了多少bugs，如果说出来的数字很少，甚或一个星期也发现不了一个bug时，他一定会质疑这样的投入产出比是否值得。

有意思的是，如果数字大得惊人的话，他同样会质疑，不过质疑的是软件质量–真的这么差？

因此，这个问题就变得特别微妙，太多太少看起来都不好。要么测试没做好，要么开发不行，总之就是在打自己R&D团队的脸。

这里涉及到另一个长期有争议的话题：用发现bug的数量来衡量一个人或一个系统，是否合适？ 个人意见是，如果只拿它当作唯一或者最重要的指标，肯定不合适。我们应该基于全方位了解的前提下，去评估一个人或一个系统，而不是简单笼统的评价他/她/它的好坏。

不必说不同的产品或feature间的差异，就算是同一个产品和feature，随着时间的推移，情况都不一样。一个产品周期里，前期测试发现的问题一定是最多的。同理，break CI的机会也是最大的，CI上发现的问题数肯定很多。而当feature开发进入尾声，CI上发现问题的频率和可能性都会降到极低，因为这时代码的改动都非常少了。用简单的数量比较，没有太多意义。

因此，我更倾向于认为，持续集成(Continuous Integration)虽好，更应该持续优化(Continuous Improvement)。

当你发现CI上bugs数量过少时，应先看项目开发进度。如已进入尾声，少点也无妨。若处于项目开初，看看是否由于CI框架还不够完善。如果产品各features都已火热的启动，每天commit数量巨大，而CI上bugs数仍少得可怜，需检查CI上case的设计和选取是否合适，以及自动化的check points是否合理等(这需要case by case的分析)。

当CI上bugs数量惊人时，也不必惊慌。先检查valid的bugs数量，搞不好是CI环境的不稳定引入了大量非软件问题。如果valid CI bugs数量持续增多，一定要和开发人员以及当前测试环节之前的测试人员（比如系统测试就要找前面的UT/MT等）沟通，提高自测和前期测试的质量。

而我们的CI也一定不是一成不变的。一个产品的成长过程，就如同人的成长一样，每个时期的问题都是不一样的。因此我们需要对不同的时期设定不一样的CI规则。比如每个case的CI频率，有per commit/day/week等。每种频率，有对人员和设备需求的考虑。这里有个误区，我们倾向于越简单的case越频繁，越难跑的case频率越低。而忽略了一点，应该是越容易出问题的case越频繁，而不是用case的难以程度去区分。一般而言，项目早期，我们应选择最基础的用例去验证启动等过程是否正常；基于不同的feature开发进度，选择代码改动最频繁的feature相关case，去做最频繁的验证；项目尾声，大部分代码改动是对bug的修正，因此更应该验证改动对legacy basic functionalities的影响。

同样，CI上的cases和check points等，也不应是一成不变的。这里就涉及到CI框架/工具是否足够灵活，今天暂且不提。