《 自动化测试最佳实践：来自全球的经典自动化测试案例解析》一一 1.10　持续改进

1.10　持续改进
2011年是我们自动化测试之旅的第8年，总是要面临新的挑战。正如本章所述，我们的GUI测试套件已经增长到需要2个多小时来运行。这个时间太长了，所以我们将它划分为两个测试套件，并在两个从属机器上并行运行。这需要进行大量的工作，因为有些测试依赖于其他测试，过去没有好好实施而是采取了折中的方法，现在要为此付出代价。我们有超过5400（这个数字还在增长）个JUnit，并且重构的FitNesse测试套件在30分钟内完成。
我们知道在单元级别中的测试覆盖率，但是并不知道在功能性或GUI级别的测试覆盖率。我们目前采用一个的工具进行实验，可以测量出FitNesse测试的代码覆盖率。
相比于8年前，我们现在对自动化测试设计有了更深入的了解，并且我们的测试需要大规模的重构。无论何时，当加入一个测试用例或者对其进行修改的时候，我们都尝试去改善测试，但是只在工程冲刺阶段才进行大规模重构。我们通过一些开源工具进行观测，并不断尝试我们认为可以降低测试维护费用或者提供更快反馈的新工具。
在GUI测试中我们也是这么做的。几年前，当我们发现Canoo WebTest并不能很好地支持JavaScript的时候，就在所有回归测试中开始使用Watir编写新的功能点。约一年之后，Canoo WebTest升级到比那时的Watir可以更好地处理JavaScript和Ajax，而Watir更难与构建过程整合，所以在保留现有的Watir回归测试脚本的基础上，我们又切换回WebTest。
我们也进行了调查，准备使用Slim来替代Fit进行我们的FitNesse测试。同样，我们可能不会立刻把所有FitNesse测试转为Slim，但我们同时发现维护多种工具也没有很大问题。
这些年来，我们的员工相当稳定。一位新程序员和一位测试人员来了又走，但是团队的核心成员一直保留着。我认为这是因为优秀的人才乐意留在他们可以尽最大努力工作的地方，那就是我们团队。比如，我们允许他们做类似自动化回归测试的事情。我们有一些有趣的转变，一位测试人员决定成为一位程序员，所以他参加了一些Java课程的培训，另一位程序员跟他一起合作，他的学习速度非常快。同时，他仍然保留了自己在测试方面的兴趣，尤其在性能测试方面。另一位程序员一直都无法采用TDD方法，尽管经过了大量的指导和培训，因为他的代码始终没有达到标准，最终只好让他离开。我们从不会去刻意填补空缺职位，但我们的团队效率却在提高。每一个团队都需要恰当的人选，而且那些人需要时间来学习、实验和提高。