从瀑布开发走向敏捷开发模式下的自动化测试（3）
之前讨论到似乎自动化的程度挺高的，从自动装包（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
