主题五：过度使用技术
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).
其他种类的测试不是这个明显。仔细想一下，对于那些多次运行或者运行次数是手工运行次数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.
如果你能够降低创建自动测试的成本，就可以多做一些。这也是使用GUI捕获／回放工具能够减少创建测试的成本的承诺。这个想法是你只需要执行手工测试，工具会录制下你所做的操作。当你手工检查一个值是否正确时，工具会记着那个正确值。过后你可以回放录制，工具会检查是否所有检查的值是否都与记忆的值相同。
There are two variants of such tools. What I call the first generation tools capture raw mouse movements or keystrokes and take snapshots of the pixels on the screen. The second generation tools (often called "object oriented") reach into the program and manipulate underlying data structures (widgets or controls).
这类工具有两个变种。我称为第一代的工具只是捕获原始的鼠标移动或击键操作，并记下屏幕上象素的瞬象。第二代工具（常称为“面向对象的”）深入程序并操纵底层数据结构（小配件或控件）。
First generation tools produce unmaintainable tests. Whenever the screen layout changes in the slightest way, the tests break. Mouse clicks are delivered to the wrong place, and snapshots fail in irrelevant ways that nevertheless have to be checked. Because screen layout changes are common, the constant manual updating of tests becomes insupportable.
第一代工具产生的是不可维护的测试。不论什么时候，只要屏幕布局有了非常微小的变化，测试就要中断。鼠标的点击传送到不正确的位置，瞬象以一种不相关的方式失败，必须予以检查。因为屏幕布局变化是常见情况，所以经常手动更新测试也变得无法忍受。
Second generation tools are applicable only to tests where the underlying data structures are useful. For example, they rarely apply to a photograph editing tool, where you need to look at an actual image - at the actual bitmap. They also tend not to work with custom controls. Heavy users of capture/replay tools seem to spend an inordinate amount of time trying to get the tool to deal with the special features of their program - which raises the cost of test automation.
第二代工具只有在底层数据结构有用时才是可行的。例如，它们很少能用于照片编辑工具，因为你需要查看实际的图象，即实际的位图。它们也不大能够与定制的控件一起使用。大量用户的捕获／回放工具似乎都要花费大量时间来使得工具能够处理他们程序的特殊功能——这增加了自动测试的成本。
Second generation tools do not guarantee maintainability either. Suppose a radio button is changed to a pulldown list. All of the tests that use the old controls will now be broken.
第二代工具也不能保证可维护性。假设一个单选按钮改变为下拉列表。所有使用老控件的测试都将中断。
GUI interface changes are of course common, especially between releases. Consider carefully whether an automated test that must be recaptured after GUI changes is worth having. Keep in mind that it can be hard to figure out what a captured test is attempting to accomplish unless it is separately documented.
GUI界面当然是常常会改变的，特别是在不同的发行版之间。仔细考虑一下一个在GUI变化之后必须重新捕获的自动化测试工具是否值得拥有。记住，除非另外使用文档记录下来，否则想要了解一个录制的测试能够完成什么工作是一件困难的事。
As a rule of thumb, it's dangerous to assume that an automated test will pay for itself this release, so your test must be able to survive a reasonable level of GUI change. I believe that capture/replay tests, of either generation, are rarely robust enough.
一个基本原则是，认为自动化测试的投资在这个发行版就能收回的想法是危险的，所以在一个合理的GUI变化范围之内测试必须能够继续使用。我相信不论是第一代还是第二代捕获／回放测试，都不够健壮。
