脚本命令是执行适当的鼠标点击和按键的子程序。如果API设计得好，大多数GUI变化仅需要对函数（例如withdraw）实现变化，而不是所有使用它们的测试。请注意设计精良的API和其他好API一样难写。也就是说，因为它们不容易写，你也不要指望第一次就得到正确结果。
In a variant of this approach, the tests are data-driven. The tester provides a table describing key values. Some tool reads the table and converts it to the appropriate mouse clicks. The table is even less vulnerable to GUI changes because the sequence of operations has been abstracted away. It\'s also likely to be more understandable, especially to domain experts who are not programmers. See [Pettichord96] for an example of data-driven automated testing.
这个方法的一个变种，是数据驱动的测试。测试员提供一个表来描述键值。某些工具读取表并将它转换为特定的鼠标点击。这个表即使在GUI变化时也不易受到损害，因为操作序列已经被抽象出来了。它也有可能是更易于理解，尤其是对于非程序员的领域专家。查看[Pettichord96]可以获得数据驱动自动化测试的示例。[Page]
Note that these more abstract tests (whether scripted or data-driven) do not necessarily test the user interface thoroughly. If the Withdraw dialog can be reached via several routes (toolbar, menu item, hotkey), you don\'t know whether each route has been tried. You need a separate (most likely manual) effort to ensure that all the GUI components are connected correctly.
注意这些抽象测试（不论是脚本化的还是数据驱动的）不一定会完全测试用户界面。如果“取款”对话框能够通过几个途径（工具条、菜单项）达到，你无法知道是否尝试了每个路线。你需要一个单独的（很可能是手工的）的工作来确保所有的GUI部件都正确地连接。
Whatever approach you take, don\'t fall into the trap of expecting regression tests to find a high proportion of new bugs. Regression tests discover that new or changed code breaks what used to work. While that happens more often than any of us would like, most bugs are in the product\'s new or intentionally changed behavior. Those bugs have to be caught by new tests.
不论你采用的是什么方法，不要陷入期望回归测试发现高比例的新 bug 的陷阱。回归测试是发现以前起作用、但新代码或更改后的代码不起作用的现象。虽然它比我们希望的发生的次数更多，但许多 bug 是产品的新的或故意更改的行为。那些 bug 必须通过新测试来捕捉。
Code coverage
代码覆盖率
GUI capture/replay testing is appealing because it\'s a quick fix for a difficult problem. Another class of tool has the same kind of attraction.
GUI捕获／回放测试因为可以快速修复困难问题而具有吸引力。另一类工具也同样具有吸引力。
The difficult problem is that it\'s so hard to know if you\'re doing a good job testing. You only really find out once the product has shipped. Understandably, this makes managers uncomfortable. Sometimes you find them embracing code coverage with the devotion that only simple numbers can inspire. Testers sometimes also become enamored of coverage, though their romance tends to be less fervent and ends sooner.
困难的问题是很难知道你是否圆满地完成了测试工作。可能只有当产品已交付后才能真正知道。可以理解的是，这使得经理们不舒服。有时候你会发现他们热心采用代码覆盖率，认为只有那些简单的数字可以鼓舞士气。候测试员也变得倾心于覆盖率，虽然他们的兴趣没有那么高，而且结束得也快。
What is code coverage? It is any of a number of measures of how thoroughly code is exercised. One common measure counts how many statements have been executed by any test. The appeal of such coverage is twofold:
什么是代码覆盖率？它是代码是否全面执行的数字衡量。一个常见的衡量是计算所有测试共执行了多少条语句。对这种覆盖率的呼吁有两方面：[Page]
1. If you\'ve never exercised a line of code, you surely can\'t have found any of its bugs. So you should design tests to exercise every line of code.
如果你从未执行过某一行代码，你当然不能找出它的任何 bug 。所以应当设计一个可以执行每一行代码的测试。
2. Test suites are often too big, so you should throw out any test that doesn\'t add value. A test that adds no new coverage adds no value.
测试套件常常很大，所以应该抛弃任何不能增值的测试。一个不增加新覆盖率的测试不能增加任何价值。
Only the first sentences in (1) and (2) are true. I\'ll illustrate with this picture, where the irregular splotches indicate bugs:
句子(1)和(2)中，只有第一句是正确的。我将用下面的图说明，其中的不规则黑点指示的是 bug ：
If you write only the tests needed to satisfy coverage, you\'ll find bugs. You\'re guaranteed to find the code that always fails, no matter how it\'s executed. But most bugs depend on how a line of code is executed. For example, code with an off-by-one error fails only when you exercise a boundary. Code with a divide-by-zero error fails only if you divide by zero. Coverage-adequate tests will find some of these bugs, by sheer dumb luck, but not enough of them. To find enough bugs, you have to write additional tests that \"redundantly\" execute the code.
文章来源于领测软件测试网 https://www.ltesting.net/
