How not to automate怎么实现自动化
Whatever you do, do not simply distribute a testing tool among your testers and expect them to automate the test process. Just as you would never automate accounting by giving a program compiler to the accounting department, neither should you attempt to automate testing by just turning a testing tool over to the test group.
无论你做什么，不要简单的发布一个测试工具就指望你的测试人员实现自动测试过程。。就像你永远不会通过程序编译器给会计部自动化会计，你也不应该尝试通过只是把一个测试工具在测试组进行自动化测试。
It is important to realize that test automation tools are really just specialized programming languages, and developing an automated test library is a development project requiring commensurate skills.
有必要明确测试自动化工具仅仅只是一种专业的编程语言，和开发自动化的测试库是需要相称的开发技能。
Automation is more than capture/replay
自动化不仅仅是捕获/回放
If you acquired a test tool with the idea that all you have to do is record and playback the tests, you are due for disappointment.Although it is the most commonly recognized technique,capture/replay is not the most successful approach. As discussed in a later chapter, Selecting an Automation Approach, capture and replay does not result in a test library that is robust, maintainable or transferable as changes occur.
如果你想做的就是记录和回放测试获得的测试工具，你恐怕会失望.尽管它是最普遍认可的技术，单捕获/回放不是最成功的方法。作为在后面的章节中讨论，选择一个自动化的方式，捕获和重放不会增强测试库发生健壮性、易维护性和易转变。
Don’t write a program to test a program!
不要写一个程序来测试程序！
The other extreme from capture/replay is pure programming. But if you automate your tests by trying to write scripts that anticipate the behavior of the underlying program and provide for each potential response, you will essentially end up developing a mirror version of the application under test! Where will it end? Who tests the tests? Although appealing to some, this strategy is doomed - no one has the time or resources to develop two complete systems.
从捕获/回放另一个极端是纯粹的编程。但是，如果你试图通过编写预计底层程序的行为，并为每一个潜在的响应脚本自动化您的测试，你会基本上结束了测试开发应用程序的镜像版本！它会在哪里结束？谁测试测试？虽然吸引了一些，这种策略注定 - 没有人有时间或资源来开发两个完整的系统。
Ironically, developing an automated test library that provides comprehensive coverage would require more code than exists in the application itself! This is because tests must account for positive,negative, and otherwise invalid cases for each feature or function.
讽刺的是，开发一种自动化测试库，提供了全面覆盖，需要更多的代码比存在于应用程序本身！这是因为测试必须考虑为正，负，并以其他方式无效的情况下为每个特征或功能。
Automation is more than test execution
自动化是超过测试执行
So if it isn’t capture/replay and it isn’t pure programming, what is it?Think of it this way. You are going to build an application that automates your testing, which is actually more than just running the tests. You need a complete process and environment for creating and documenting tests, managing and maintaining them, executing them and reporting the results, as well as managing the test environment. Just developing scores of individual tests does not comprise a strategic test automation system.
所以，如果它不捕获/回放，它不是纯粹的编程，是什么呢？它认为这种方式。你要建立一个自动化您的测试，这实际上是不是仅仅运行测试的更多的应用程序。你需要创建和记录测试，管理和维护他们，他们执行并报告结果，以及管理测试环境一个完整的流程和环境。只是单项测试的分数发展不包括战略自动化测试系统。
Duplication of effort
重复的工作
The problem is, if you just hand an automation tool out to individual testers and command that they automate their tests, each one of them will address all of these issues - in their own unique and personal way, of course. This leads to tremendous duplication of effort and can cause conflict when the tests are combined, as they must be.
问题是，如果你只是将自动化工具单独分派测试人员自动化测试任务，他们每个人都将以自己独特的个人化的方式解决。这必然导致工作巨大的重复和可能导致冲突的测试组合。
Need for a framework
需要建立一个框架
Instead, approach the automation of testing just as you would the automation of any application - with an overall framework, and an orderly division of the responsibilities. This framework should make the test environment efficient to develop, manage and maintain. How to develop a framework and select the best automation approach are the focus of this handbook.
相反，方法测试自动化就与整体框架的任何应用程序的自动化，并有序的分工职责。该框架应使测试环境的有效开发，管理和维护。如何制定一个框架和选择最佳的自动化的方法是本手册的重点。
Remember, test tools aren’t magic - but, properly implemented, they can work wonders!
请记住，测试工具是不是魔术 - 但，正确实施，他们可以创造奇迹！