之前讨论到似乎自动化的程度挺高的，从自动装包（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

相关链接：

从瀑布开发走向敏捷开发模式下的自动化测试（1）

从瀑布开发走向敏捷开发模式下的自动化测试（2）

Tags：郑州java培训怎么样,.NET开发培训,电脑办公软件培训,河南.NET培训,.NET培训好不好,办公软件培训