《 自动化测试最佳实践：来自全球的经典自动化测试案例解析》一一1.9 团队成功...

1.9　团队成功
我们的团队在一年的时间内，从没有自动化测试发展到将所有的回归测试进行自动化。我们的自动化金字塔还不完全是理想的形状，但是我们有了好的测试框架和在每个级别（见图1-2）实现测试的驱动程序。尽管这样，我们却没有满足现状，而是继续寻找在各个级别有效地进行自动化回归测试的方法。当我们可以控制功能测试的自动化之后，我们将着手性能测试的自动化。我们有处理不完的挑战！
最好的是，我们有时间对每个用户故事或功能集合进行充分的探索性测试，这样的话，在产品中就很少会有问题浮出水面。同时自动化测试也可以帮助我们进行探索性测试。我们希望创建：使用Ruby的具有高灵活性的脚本，Watir（Ruby中的Web应用测试）测试驱动，以及测试/单元框架。它们接收运行参数，允许我们在几秒或者几分钟内建立复杂的测试数据和情景，而不再需要花费时间搭建繁琐的手动测试平台。通过脚本可以直接对需要进行测试的部分进行测试，这样我们就可以拥有更多的时间来深入探索软件。
【真知灼见】
使用自动化测试来支持创新型手动测试。
我们的目标是使所有回归测试实现自动化，但是这一目标有几点需要说明。要达到一个合理的ROI，自动化测试在设计时必须要考虑到长期可维护性。因此要求程序员拥有好的设计技巧，可以帮助设计各个级别的自动化测试。我们不断对测试进行重构以使维护费用较低。同时，在选择将哪些测试保留在自动化回归测试套件中时，团队要有准确的判断力，需要“正好”（good enough）覆盖。测试太多意味着反馈周期太长和维护费用过高。同时，我们还有少量的遗留代码没有被自动化测试覆盖，当我们进行可能对遗留代码造成影响的大范围的代码重构时，我们要留一些时间进行手动回归测试。

图1-2　自动测试金字塔使用的工具
我们成功的关键是采用“完整团队”（whole-team）的方法,团队里的每个人都致力于将所有回归测试实现自动化，我们有很多的技术和观点来帮助解决自动化中遇到的问题。自动化测试金字塔的每一层都包含不同的工具，而且大家可以关注不同层。开发人员像写代码那样编写单元测试用例，测试人员更多的是进行GUI测试的自动化，在FitNesse中，双方在中间层合作。然而，在每一个用户故事完成之前，团队中的每个人都负责每个用户故事的所有测试活动。
自动化测试给我们一个快速的反馈周期。如果在几小时内任何一个现有的功能点遭到破坏，在工程冲刺时，我们应该腾出时间来做出改变，使加入更多测试用例后的反馈周期仍然很快。我们知道是代码的哪些改变引起的这个问题，并立刻进行修复。我们可以在经常发布新业务价值的同时，达到公司的要求，开发出最高质量的产品。