如果你能够降低创建自动测试的成本，就可以多做一些。这也是使用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).[Page]
这类工具有两个变种。我称为第一代的工具只是捕获原始的鼠标移动或击键操作，并记下屏幕上象素的瞬象。第二代工具（常称为“面向对象的”）深入程序并操纵底层数据结构（小配件或控件）。
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.[Page]
一个基本原则是，认为自动化测试的投资在这个发行版就能收回的想法是危险的，所以在一个合理的GUI变化范围之内测试必须能够继续使用。我相信不论是第一代还是第二代捕获／回放测试，都不够健壮。
An alternative approach to capture/replay is scripting tests. (Most GUI capture/replay tools also allow scripting.) Some member of the testing team writes a \"test API\" (application programmer interface) that lets other members of the team express their tests in less GUI-dependent terms. Whereas a captured test might look like this:
捕获／回放的一个替代方法是脚本化测试。（大多数GUI捕获／回放工具都允许编写脚本。）测试小组的某些成员编写一个“测试API（应用编程接口）”，允许小组的其他成员以较少依赖GUI的方式表达他们的测试。一个捕获的测试类似于这样：
· text $main.accountField \"12\"
click $main.OK
menu $operations
menu $withdraw
click $withdrawDialog.all
...
文本 $main.accountField \"12\"
点击 $main.OK
菜单 $operations
菜单 $withdraw
点击 $withdrawDialog.all
a script might look like this:
而一个脚本类似于：
· select-account 12
withdraw all
...
select-account 12
withdraw all
The script commands are subroutines that perform the appropriate mouse clicks and key presses. If the API is well-designed, most GUI changes will require changes only to the implementation of functions like withdraw, not to all the tests that use them. Please note that well-designed test APIs are as hard to write as any other good API. That is, they\'re hard, and you shouldn\'t expect to get it right the first time.
文章来源于领测软件测试网 https://www.ltesting.net/
