6. 考虑使用其他类型的自动化

　　LAWST会议的重点在GUI级回归测试工具，所以本文的重点也是这个内容。在LAWST会议召开前夕，我们每人都介绍了我们在测试自动化方面的经验。其中的一些人报告了大量的成功案例，但大多数案例都涉及到那些编写测试应用程序的程序员的协作。这些成功案例中用到的工具各式各样，说明不同的测试工具能带来不同的收益。

　　对于基于GUI的回归自动化测试，有很多带有欺骗性的、不切实际的想法。它们制造出测试能覆盖所有地方的假象，并且引起严重的员工跳槽，并且还使你最有技术的员工专注于设计和维护相对较少bug的测试用例。

　　这些工具确实很有用，但是它们需要大量投资、审慎规划、培训员工以及十分小心地使用。

　　附录　LAWST会议上得到的若干结论

　　在讨论会议每天日程的后三分之一，我们把在讨论中得到的一些论述抄写到写字版上并进行投票。我们并非想获得一致意见。这样做的目的，是想看看每条论述与这些经验丰富的测试工程师的经验符合的程度。在有些情况下，我们中的一些人并没有投票，可能是因为我们缺乏对要投票的论述的具体经验，也可能是因为我们认为该论述不够合理。（这里我已经省略了大多数论述。）

　　如果你正试图把自动化的成本和风险告诉给你的一位经理，那么以下这些投票结果或许是你们讨论的有用数据。

　　一般原则

　　1. 这些论述并非终极真理。在规划自动化时，由于投入了这么多的努力，你必须时刻记住哪个问题是你试图要解决的，以及在何种环境下解决它。（一致同意）

　　2. GUI级自动化测试是软件开发中的一项重大工作。它需要架构、标准和纪律。适用于软件设计和实现的一般原则同样适用于自动化设计和实现。（一致同意）

　　3. 为了效率和可维护性，我们需要首先开发一个不随特性改变的自动化结构。我们应该开发像特性一样稳定的基于GUI的自动化。（一致同意）

　　4. 我们中的一些人认为一个公司的自动化工作可以采用演化模式来进行。

　　第一代（7票赞成，1票反对）：在缺乏以前的自动化经验时，大多数自动化工作将经历以下三个过程：

　　a. 截取/回放失败。我们截取的是比特还是窗口部件都无关紧要（面向对象的截取/重放）

　　b. 使用个人编程的测试用例失败。（个人编码的测试用例是按他自己的标准编写的，没有遵循一般标准以及构建共享库）

　　c. 开发维护在正在进行的基础之上的函数库。这个库可以包括脚本测试用例或数据驱动测试。

　　第二代（10票赞成，1票反对）：一般自动化的主动失败源于以下几点：

　　a. 把截取/回放作为创建测试用例的原则性方法。

　　b. 使用个人编写脚本测试用例 （个人编码的测试用例是按他自己的标准编写的，没有遵循一般标准以及构建共享库）

　　c. 使用设计不好的框架。这是一个普遍问题。