问题
There are many pitfalls in automated regression testing. I list a few here. James Bach (one of the LAWST participants) lists plenty of others, in his paper "Test Automation Snake Oil." [3]
自动化回归测试有很多缺陷，我在这里只列举了一些。James Bach(LAWST成员之一)在他的文章“Test Automation Snake Oil”中列举了其它的很多种。
Problems with the basic paradigm:
基本规范的问题
Here is the basic paradigm for GUI-based automated regression testing: [4]
以下是基于GUI的自动化回归测试的基本规范：
a. Design a test case, then run it.
设计一个测试用例，然后运行。
b. If the program fails the test, write a bug report. Start over after the bug is fixed.
如果程序不能通过测试，就撰写一份错误报告。在bug被清除后再重新开始。
c. If the program passes the test, automate it. Run the test again (either from a script or with the aid of a capture utility). Capture the screen output at the end of the test. Save the test case and the output.
如果程序通过了测试，就自动运行。然后重新运行测试(通过脚本或者借助截取工具)。在测试末尾对屏幕输出进行截图。然后保存测试用例及输出结果。
d. Next time, run the test case and compare its output to the saved output. If the outputs match, the program passes the test.
接下来，运行测试用例并把它的输出与已保存的输出作比较。如果匹配，则表明程序通过了测试。
First problem: this is not cheap. It usually takes between 3 and 10 times as long (and can take much longer) to create, verify, and minimally document [5] the automated test as it takes to create and run the test once by hand. Many tests will be worth automating, but for all the tests that you run only once or twice, this approach is inefficient.
第一个问题：这种做法开销很大。通常，对自动化测试进行创建、验证、简化文档所花费的时间是创建并手工运行测试的3到10倍，甚至更多。虽然很多测试值得被自动化、但对于那些只运行一两次的测试，这样做并不划算。
Some people recommend that testers automate 100% of their test cases. I strongly disagree with this. I create and run many black box tests only once. To automate these one-shot tests, I would have to spend substantially more time and money per test. In the same period of time, I wouldn’t be able to run as many tests. Why should I seek lower coverage at a higher cost per test?
文章来源于领测软件测试网 https://www.ltesting.net/
