之前讨论到似乎自动化的程度挺高的,从自动装包(Automatic deployment),自动执行(Automatic Execution),自动上传结果(Automatic Uploading),自动生成结果报告(Automatic Reporting),自动化测试的各个阶段都已经实现了。

  套用一句话,看起来挺美的。可是,真的是这样吗?

  毛主席教育我们要从群众中来,到群众中去。我们还是应该听听,一线测试人员以及team的反应,他们说:

  自动化测试还是不能帮助我们发现太多的问题,与此同时,我们投入地还是太多。

  测试人员普遍不愿意持续地来维护CRT,感觉持续地做这个事情,学习的地方不多。

  自动化测试的误报概率还是太高,很多时候case失败了,并不是真正的软件问题,甚至连什么问题都不清楚。

  ...

  看起来,事情远远没有我们想象的那么完美。

  从我的角度看,看到了以下几点:

  我们的自动化测试离incremental build/incremental testing还是有很大的距离。我们虽然提供了所谓的daily build,但是daily build并没有得到很好的测试。关键是在代码check in之前,以及代码check in之后,以及在正式的编包之前,我们的测试做得并不是很充分。在代码check in之后,只会做UT,然后是几百个软件模块在一起集成测试,这个测试的跨度还是太大了,所以不符合CI的精神,即每个很小的软件变化(delta)都能被测试到。因为软件版本在你check in之前还是好的,现在check in之后不好了,那很大的可能这个问题是由于你的这次check in引起的,哪怕你的这次check in是没问题的,只是引发了以前的一个隐藏的问题,那你也应该负责把问题查清楚,并且解决掉问题。所以我们如果对软件进行持续的集成测试,如果我们集成的频率足够地频繁,甚至代码的每次check in都可以把所有的case跑一遍,我们出现的问题应该很容易定位。

  但是现状和理想还是相距挺远的。关键问题是我们的case跑的时间还是太长了。比如说,当时部门里面大约总共有1500个自动化测试用例,差不多分配到10个team,然后每个team自己跑自己的case,差不多每个team要跑一个晚上了。而且我们的case执行都是独占式的,即一个case跑得时候,别的case是不能在同一台机器上面跑的。我曾经做过一个统计,所有的测试用例跑完,差不多要50个小时,这个离我们的理想显然是太遥远了。

  一个新的版本发布出来以后,的确很快能达到95%的通过率,但是似乎也很难再提高了,而且依靠这种外部的监督来达到这种状态,可能也不是一种很理想的状态。Team讨论起CRT的问题来,总是觉得很难,但是总又觉得解决问题无从下手。

  所以我们在想,如果有一个Golden Testbed,它可以持续不断的执行测试用例,然后一有问题通知相关的有问题的team,然后team只需要解决问题,并不需要把时间花在这些重复的环境准备上。如果我们排除了环境问题,那么只要我们的case足够地健壮,那么理论上来,发现的问题应该都是team应该花精力解决的问题了吧。

  这样看起来,当前的焦点集中在测试的执行时间上,具体到每个case的测试时间,如果不到team里面去,可能连case都看不懂,也很难解决实际的问题。于是,我又来到了team里面。

  一开始我和他们一起来执行测试用例,然后过了一段时间后,对他们的测试用例也逐渐熟悉起来了,于是可以开始来思考如何优化测试用例本身了。

  具体的技术细节这里不多论述了,可以说的是,经过一段时间的case refactory以后,原来5个team分开来执行,各自要执行4-5个小时的case,现在在一起只需要一个晚上可以执行完了。

  这个时候,我们的想法也大胆成型了,即把比较成熟的几个team的case,放在一个golden testbed上来统一执行,然后team不需要花时间来装包,维护环境。需要做的是当他们的测试用例fail的时候,他们需要来分析以及解决问题。也是说,假如他们的测试用例质量很高的话,他们所负责的软件模块也很稳定的话,Team基本上不需要花太多的effort在这个上面了。这样的话,也可以从另一个角度来激励team不断地改进Case的质量,从而可以尽可能地少花不必要的effort。

  这个想法也得到了我们PO(Product Owner)的赞同,为了能够把这个事情做好,PO还专门成立了一个Task force来做这个事情。重点放在以下几个方面:

  每个软件模块check in之后,在Unit Test之后,会自动部署到目标设备上新的一个daily build上,执行Smoke Test,大约执行时间一分多钟,包括前面的部署时间的话,总的时间控制在8分钟以内。只有功能测试也通过的话,才会编到终的package里面。

  每天的中午或者下午,会把所有有变化的软件模块放在一起,执行Light Weight RT,即把feature核心的一些测试用例抽出来。

  等到晚上的时候,当前Pate里面应该是新的daily build+通过smoke test的各个软件模块,基本上,这个组合代表了我们软件当前新的一种状态。然后利用晚上的时间,对其进行充分的回归测试。

  基本上这是我们敏捷开发的自动化话回归测试的现状,现在还不确定这个模式会不会引入新的一些问题,如果碰到新的问题的话,我们可以再分析解决。

  等到晚上,我们可以在跑Regression Test