个人认为，基本原则里的第一条很有指导性，自动化测试得带有目的，并且和所处的环境关系很大。这里说的环境可能包括公司结构，项目结构， 被测对象，人员以及技术。另外，本章还提到了进化（evolution），既然是进化就是一个不断死去的过程。我觉得做自动化测试开发时，应该注意的不是我们能做什么，而是我们不能做什么。
General principles
基本原则
1. These statements are not ultimate truths. In automation planning, as in so many other endeavors, you must keep in mind what problem are you trying to solve, and what context are you trying to solve it in. (Consensus)
这些论述并非终极真理。在规划自动化时，由于投入了这么多的努力，你必须时刻记住哪个问题是你试图要解决的，以及在何种环境下解决它。（一致同意）
2. GUI test automation is a significant software development effort that requires architecture, standards, and discipline. The general principles that apply to software design and implementation apply to automation design and implementation. (Consensus)
GUI级自动化测试是软件开发中的一项重大工作。它需要架构、标准和纪律。适用于软件设计和实现的一般原则同样适用于自动化设计和实现。（一致同意）
3. For efficiency and maintainability, we need first to develop an automation structure that is invariant across feature changes; we should develop GUI-based automation content only as features stabilize. (Consensus)
为了效率和可维护性，我们需要首先开发一个不随特性改变的自动化结构。只有在功能稳定的情况下，我们才应该开发基于GUI的自动化。（一致同意）
4. Several of us had a sense of patterns of evolution of a company’s automation efforts over time:
我们中的一些人认为一个公司的自动化工作可以采用演化模式来进行。
First generalization (7 yes, 1 no): In the absence of previous automation experience, most automation efforts evolve through:
第一代(7票赞成，1票反对)：在缺乏以前的自动化经验时，大多数自动化工作将经历以下三个过程：
a. Failure in capture /playback. It doesn’t matter whether we’re capturing bits or widgets (object oriented capture/replay);
截取/回放失败。我们截取的是比特还是窗口部件都无关紧要（面向对象的截取/重放）
b. Failure in using individually programmed test cases. (Individuals code test cases on their own, without following common standards and without building shared libraries.)
使用个人编程的测试用例失败。（个人编码的测试用例是按他自己的标准编写的，没有遵循一般标准以及构建共享库）
c. Development of libraries that are maintained on an ongoing basis. The libraries might contain scripted test cases or data-driven tests.
开发维护在正在进行的基础之上的函数库。这个库可以包括脚本测试用例或数据驱动测试。
Second generalization (10 yes, 1 no): Common automation initiatives failures are due to:
第二代（10票赞成，1票反对）：一般自动化的主动失败源于以下几点：
a. Using capture/playback as the principle means of creating test cases;
把截取/回放作为创建测试用例的原则性方法。
b. Using individually scripted tested cases (i.e. test cases that individuals code on their own, without following common standards and without building shared libraries);
使用个人编写脚本测试用例（个人编码的测试用例是按他自己的标准编写的，没有遵循一般标准以及构建共享库）
c. Using poorly designed frameworks. This is a common problem.
使用设计不好的框架。这是一个普遍问题。
5. Straight replay of test cases yields a low percentage of defects. (Consensus)
测试用例的直接重放会带来低缺陷（一致同意）
Once the program passes a test, it is unlikely to fail that test again in the future. This led to several statements (none cleanly voted on) that automated testing can be dangerous because it can gives us a falsely warm and fuzzy feeling that the program is not broken. Even if the program isn’t broken today in the ways that it wasn’t broken yesterday, there are probably many ways in which the program is broken. But you won’t find them if you keep looking where the bugs aren’t.
一旦一个程序通过了测试，那么以后就不太可能不通过该测试了。这种说法导出了一些论述（没有一个被明确赞成），即自动化测试有危险，因为它给我们一种很舒服的错觉，认为程序没有问题。即使程序今天没有出现昨天出现的问题，但是依然还有很多情况可以使程序出问题。而如果你总是在没有bug的地方寻找，你就永远找不到它们。
