我先是自己来调试原来一直跑不起来的case，发现之所以前面的case失败了，会影响后面的case，其实是由于case之间的独立性不好引起的。
为了能解决这个问题，我还和team一起设计了一个复杂的环境恢复的keyword，里面判断了不同情况下，如果有板子没有起来，应该怎么恢复的问题。
用了这个方法，case执行的稳定性逐渐提高了。大概过了1-2个月左右，case执行的通过率从原来的在40-50%徘徊，而且也不能发现比较有意义的问题，提高到了90%以上，而且失败的那些case，虽然不能说都是由于软件bug引起的，但至少可以说也是软件的相关问题引起的。后来这批case经过测试人员的持续优化，帮助相关领域的测试人员发现了很多软件的问题。当然，这也是由于这个领域本身就是问题多发造成的。
之后开始从一个team跳出来，关注整个部门的自动化测试的情况。因为我们采取的是迭代开发的模式，所以管理层希望每个迭代周期，甚至每个daily build，软件始终处于一种比较良好的质量，这样，在这个基础上面开发后续新的功能才会更有信心。当时让管理层比较头痛的一个问题就是，一个新版本发布了以后，这个版本的自动化测试通过率始终上不去。而且，问题大部分也不是由于软件问题引起的。所以虽然team还是坚持在跑自动化测试，但是慢慢地开始有一种声音，就是自动化测试并不如我们原来想得那么有用。不但不能有效地发现问题，还浪费了 team的effort。
首先我做的一个事情就是希望让让这些情况更加visible，希望每个问题都能找到是哪个team负责的。然后希望Scrum Master可以更多来帮助处理这些team的impediment。
为此，我整理了原来的统计问题的表格，按照不同的硬件配置，不同的team分别有各自的excel sheet，而且又能够自动汇总到一个统一的地方来。
Team如果发现case有问题的话，不能不闻不问，需要在一个分析工具，我们叫Case Analyzer上面针对每个case做分析。如果发现有问题属于软件问题，但是又不在正常的Bug工具里面的话，或者根本fail的case都没有分析的话，我就会找team问里面的原因。
另外，还向我们的工具开发部门提了很多需求。他们当时有个工具，叫做reporting server，可以每天统计测试的结果。但是因为一开始主要是针对较高层的Program Manager开发的，部门用来follow 问题并不方便。后来他们也做了一些改进，比如说可以有各个部门独立的View，有team level的view，帮助相关人等看到假如某个版本的回归测试通过率上不去，是被那个team的问题block住了。另外，还有一些辅助工具，比如如何更方便地配置每天应该跑什么包，在什么时候跑测试。以及Bug的辅助管理工具，帮助我们看到自动化case的失败都是由于哪些原因引起的。
这样做了一段时间，慢慢的问题变得清楚了，team也在改进他们的case，慢慢地稳定性也有了改进。一般来说的话，一个新的版本发布出来的话，如果没有什么软件问题的话，3天左右就能到95%以上的通过率。这个通过率，基本上也可以达到项目对于软件版本处于一个比较健康状态的评定要求了。
似乎我们部门的自动化测试已经处于一种比较理想状态，当新的版本发布的时候，测试人员只要点几个鼠标，就可以完成装包，然后可以自动跑测试，结果自动上传，可以及时让管理人员知道我们当前的软件版本还存在哪些问题。测试人员同时也会对fail的case存在的问题进行分析。同时我们可以看到自动化测试发现问题的列表，这也有力地击碎了自动化测试不能帮助我们发现软件问题的谣言。
似乎一切都已经比较完美了，我们到底还有什么问题呢？
可是，真地是这样吗？
相关链接：
