1. 对从自动化中获益的时机重新设定管理期望值

　　当GUI级回归自动化测试在软件的发行版N中被开发后，我们都认为在发行版N+1的测试和开发中会有很多收益。我想我们会惊奇地发现所有人都赞成该结论，因为我们总是听说(并没有实际经历)对自动化测试的投入会有快速的回报。

　　以下例子体现了发行版N中的一些收益：

　　o 对一套用于测试目的的测试(也叫“烟雾测试”)进行自动化可以获得很大的收益。在开发第N版时，你或许会运行它们50次或100次。即使开发每一个测试是手动执行测试时间的10倍，且在可维护性方面的成本也会是10倍，但仍然对每个测试用例节省了相当于30至80倍的手动执行时间。

　　o 你能通过自动化配置和兼容性测试节省时间，减少人为错误，并获得对已完成工作的良好跟踪。在这样的情况下，你会对很多设备或在很多环境下运行相同的测试。如果你要测试兼容30个打印机的程序，那么你可以在不到一周的时间里收回自动化该测试的成本。

　　o 回归自动化有助于性能基准跨越不同的操作系统以及同一程序的不同开发版本。

　　虽然可以利用自动化近期回报的优点，但是在进行目的是短期收效的自动化时，需要注意对每个额外测试用例或测试用例组进行成本验证。

　　如果要寻找更长期的收效，跨越软件的不同发行版，那么你就应该为第N版认真地考虑设置如下目标：

　　在一些特殊的领域(如烟雾测试和兼容性测试)，为版本N提供有效的回归测试。

　　为N+1版中范围更广、更有效的自动化测试做一些支持工作。

　　2. 承认测试自动化开发是软件开发的一部分

　　不能在缺乏明晰且实际的计划的情况下，开发在下个发行版中继续有效并适用的测试套件。

　　不能在缺乏明晰且实际的计划的情况下，开发可扩展的测试套件(所产生的代码量可能比正在测试的应用程序更多)。

　　不能在缺乏明晰且实际的计划的情况下，开发很多没有足够可维护性开销来证明在项目生命周期中的存在性的测试套件。

　　软件自动化测试与软件开发人员进行的其它所有自动化工作类似。但有一个例外，那就是测试人员要编写自动化代码。

　　o 就算程序语言很怪异，它也是一种编码。

　　o 在专门用于测试的某个应用程序中，每个测试用例都是一种特性。

　　o 从自动化测试应用程序的观点来看，应用程序(你正在测试的那个)的每个方面都是数据。

　　在研究众多其它软件开发项目后，我们认为软件开发人员(在这种情况下，也就是测试人员)必须做到：

　　o 理解需求;

　　o 采用一个能使我们能有效开发、集成以及维护特性和数据的架构;

　　o 采用并遵守标准。(我不是指如ISO 9000 或者CMM这样的大型标准。我的意思是务必使在同一个项目中的两个程序员使用相同的命名规则、相同的模块文档结构、相同的错误处理方法等。在任何一个程序员团队中，遵守相同规则本身就是一种标准)

　　o 遵守纪律。

　　在所有人中，测试人员必须认识到，遵循一个规范方法而不是为了图快而不保证质量地去设计与实现，这对于软件开发很重要。否则，我们就只能面临失败，与我们已测试的众多应用程序的失败结局一样。