当用户界面语言改变时(比如从英文变成法文)，为了正确反映并测试你的程序而修正脚本又变得有多困难?
We need strategies that we can count on to deal with these issues.
Here are two strategies that don’t work:
我们需要处理这些议题的可靠策略。下面是两种无法解决问题的策略：
Creating test cases using a capture tool: The most common way to create test cases is to use the capture feature of your automated test tool. This is absurd.
用截取工具创建测试用例：创建测试用例最普通的方法就是使用自动化测试工具的截取功能。但这种方法很不合逻辑。
In your first course on programming, you probably learned not to write programs like this:
在程序的第一段，你很可能不会像下面这样编写代码：
SET A = 2
SET B = 3
PRINT A+B
Embedding constants in code is obviously foolish. But that’s what we do with capture utilities. We create a test script by capturing an exact sequence of exact keystrokes, mouse movements, or commands. These are constants, just like 2 and 3. The slightest change to the program’s user interface and the script is invalid. The maintenance costs associated with captured test cases are unacceptable.
在代码中嵌入常量显然是愚蠢的。然而，这就是我们用截取工具得到的结果。我们通过截取一段敲键、移动鼠标或者命令行序列来创建一个测试脚本。这本身就是常量，就好象2和3。于是，程序用户界面的最微小的改变也会导致脚本无效。因此，与截取测试用例有关的可维护性开销是不能被接受的。
Capture utilities can help you script tests by showing you how the test tool interprets a manual test case. They are not useless. But they are dangerous if you try to do too much with them.
截取工具通过展示测试工具如何翻译一个手工测试用例来帮助你编写测试代码。它们并非没有用。但是，如果你试图用它们做太多的事情，那会变得很危险。
Programming test cases on an ad hoc basis: Test groups often try to create automated test cases in their spare time. The overall plan seems to be, "Create as many tests as possible." There is no unifying plan or theme. Each test case is designed and coded independently, and the scripts often repeat exact sequences of commands. This approach is just as fragile as the capture/replay.
基于特定基础编写测试用例：测试团队通常在他们的闲暇时间尝试创建自动化测试用例。其总体规划看起来就像“创建尽可能多的测试”。而这并没有统一规划或主题。每个测试用例都是独立设计并编写的，且脚本通常重复同样的命令行序列。这种方法与截取/重放方法一样脆弱。
文章来源于领测软件测试网 https://www.ltesting.net/
