Test automation is based on a simple economic proposition:
测试自动化基于一个简单的经济观点：
· If a manual test costs $X to run the first time, it will cost just about $X to run each time thereafter, whereas:
· 如果第一次手工测试的成本是$X，则其后每次测试的成本大致都是$X，然而：
· If an automated test costs $Y to create, it will cost almost nothing to run from then on.
· 如果创建自动化测试的成本是$Y，则其后的运行成本几乎为零。
$Y is bigger than $X. I\'ve heard estimates ranging from 3 to 30 times as big, with the most commonly cited number seeming to be 10. Suppose 10 is correct for your application and your automation tools. Then you should automate any test that will be run more than 10 times.
$Y比$X大。我了解到的估计范围是从3至30倍，而常常被引用的数值似乎是10。假设10对于应用程序和自动化工具是正确的。这样应当将运行10次以上的测试都进行自动化。
A classic mistake is to ignore these economics, attempting to automate all tests, even those that won\'t be run often enough to justify it. What tests clearly justify automation?
一个典型错误是忽略这些经济上的考虑，试图自动化所有的测试，甚至包括那些不常运行的测试以至不能证明自动化是必要的。哪些测试能明显地证明自动化是必要的？
· Stress or load tests may be impossible to implement manually. Would you have a tester execute and check a function 1000 times? Are you going to sit 100 people down at 100 terminals?
· 压力或负载测试可能无法手工实现。你会让测试员执行并检查一个函数1000次吗？你会找100个人坐在100个终端前面吗？
· Nightly builds are becoming increasingly common. (See [McConnell96] or [Cusumano95] for descriptions of the procedure.) If you build the product nightly, you must have an automated \"smoke test suite\". Smoke tests are those that are run after every build to check for grievous errors.
· 夜间构建变得越来越普遍了。（参见[McConnell96]或[Cusumano95]可以了解这个过程的描述）。如果在夜间构建产品，就必须有一个自动化的“冒烟测试套件”。 冒烟测试指的是那些在每次构建之后都去检查严重错误的测试。
· Configuration tests may be run on dozens of configurations.
· 配置测试可能要在数十种配置上运行。
The other kinds of tests are less clear-cut. Think hard about whether you\'d rather have automated tests that are run often or ten times as many manual tests, each run once. Beware of irrational, emotional reasons for automating, such as testers who find programming automated tests more fun, a perception that automated tests will lead to higher status (everything else is \"monkey testing\"), or a fear of not rerunning a test that would have found a bug (thus leading you to automate it, leaving you without enough time to write a test that would have found a different bug).[Page]
其他种类的测试不是这个明显。仔细想一下，对于那些多次运行或者运行次数是手工运行次数10倍的自动化测试，你是否只运行一次。要当心实现自动化的不理性的、感情的原因，例如测试员发现程序自动化测试更有趣，认为自动化测试将带来更高的地位（其他测试都是“猴子测试”），或者是害怕不能重新运行一个会发现 bug 的测试（这导致你将它自动化，使你没有足够的时间编写一个会发现其他 bug 的测试）。
You will likely end up in a compromise position, where you have:
你可能在最后有一个折中的方式，你将有：
1. a set of automated tests that are run often.
一套经常运行的自动化测试。
2. a well-documented set of manual tests. Subsets of these can be rerun as necessary. For example, when a critical area of the system has been extensively changed, you might rerun its manual tests. You might run different samples of this suite after each major build.
一套文档齐备的手工测试。这些测试的子集合可以在需要的时候重新运行。例如，当一个系统的关键领域被大规模地改变时，可能会重新运行手工测试。在每一次主要构建之后，都可能会运行这个套件的不同样例。
3. a set of undocumented tests that were run once (including exploratory \"bug bash\" tests).
一套没有文档的、只运行一次的测试（包括探索性的“bug 大清除”测试）。
Beware of expecting to rerun all manual tests. You will become bogged down rerunning tests with low bug-finding value, leaving yourself no time to create new tests. You will waste time documenting tests that don\'t need to be documented.
注意不要期望重新运行所有的手工测试。重新运行这些很少能找到 bug 的测试会使你停滞不前，使你自己没有时间创建新的测试。你会把时间浪费在为不需要文档的测试编写文档上。
You could automate more tests if you could lower the cost of creating them. That\'s the promise of using GUI capture/replay tools to reduce test creation cost. The notion is that you simply execute a manual test, and the tool records what you do. When you manually check the correctness of a value, the tool remembers that correct value. You can then later play back the recording, and the tool will check whether all checked values are the same as the remembered values.
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/