作者：Cem Kaner
翻译：piaocl
自动化黑盒测试，GUI级别衰退测试工具在当今很流行，根据这些神话，你的编程经验即使不是很丰富，也可以建立很强大的测试套件。这些工具（按照说明）很容易上手。维护测试套件不是问题。因此，神话继续上演，用这些测试工具之一替换掉那些讨厌的软件测试工程师,开发管理者可以节省大量的金钱和负担，使软件很快正常运行。
测试软件的卖主，不懂测试的主管极力推广这样的神话，甚至那些测试经理，测试工程师也这么认为。认为使用测试工具多么好。
一些公司已经开始享受成功给他们带来的好处，但是另外一些公司由于没有有效的使用测试工具，失败了。
二月，十三个富有经验的软件测试工程师在LAWST聚会两天，讨论成功的模式和测试套件用于衰退测试阶段的黑盒测试脚本的可维护性失败的教训。我们讨论的重点集中在实际经验，以哪些已经在实际中部分有效的解决自动化问题的方案开始。我们的目标是在有限的经验下，在短时间内总结出一套有效的的过程。为了提高的效率，我们在富有经验的-- Brian Lawrence（会议的主持人） 带领下展开讨论。
其他参加者: Chris Agruss (Autodesk), Tom Arnold (ST Labs), James Bach (ST Labs), Jim Brooks (Adobe Systems, Inc.), Doug Hoffman (Software Quality Methods), Cem Kaner (kaner.com), Brian Lawrence (Coyote Valley Software Consulting), Tom Lindemuth (Adobe Systems, Inc.), Brian Marick (Testing Foundations), Noel Nyman (Microsoft), Bret Pettichord (Unison), Drew Pritsker (Pritsker Consulting), 和 Melora Svoboda (Electric Communities). 所以的与会者只有一个目的， 表达了个人的观点，不受公司的观点的束缚。
下边列出其他与会者的测试经验：
问题是什么？
自动化衰退测试中有很多缺陷。我只列出了一小部分。James Bach（与会者之一）在"Test Automation Snake Oil“中列举出其他很多问题。
通过范例举例：
这是个在衰退测试中基于GUI的自动化范例
设计测试用例，然后运行他
如果这个脚本运行失败，你将写个bug报告，赋予缺陷状态为fixed，然后从新开始。如果这个自动化脚本运行成功，并功能正确。在此运行测试脚本（或者来自于某个脚本，或者来自于某类捕获工具）。在测试后抓取屏幕文件输出，保存测试用例和这个输出文件。下次对比输出文件和这个保存的输出文件，如果一样，那么脚本运行成功，测试通过。
第一个问题：这样做不划算。创建，验证，编写自动化测试脚本和手工创建执行测试一样要花费3到10次甚至更多（直到成功为止）。很多测试人员愿意自动化，但是对于测试人员来说，只运行一次脚本，那么这种效率就很低下了。
很多测试人员建议百分之百自动化测试用例。我强烈不同意这样的要求。我创建的很多黑盒测试用例只执行一次。要把每一个测试用例自动化，我要花费很多时间和金钱。利用这些时间我可以执行很多测试测试用例。为什么要低覆盖高成本的测试呢？
第二个问题:这个方法有附加的风险存在.我们知道发现，修正缺陷的成本会随着时间的增长而增长。随着产品越来越接近出货日期人们做的工作就愈多, 作为试用版用户要编写手册和买卖原料. 越后来发现修正重大缺陷越多的人的时间将被浪费。如果你在测试时间前花费大量时间写测试脚本, 你知道最后才发现缺陷, 这是非常昂贵的。
第三个问题: 这些测试不够强大. 执行了自动化测试的这些测试已经通过。但是通过这种方法你新的缺陷能发现多少？据我听说的评估大概在百分之六道三十之间。这个数字在你创建测试用例发现缺陷的时候是呈增长的趋势,这仅仅是手工测试,和自动化测试没有关系。
第四个问题: 实践,很多测试组织仅仅是简单的运行脚本。测试前期, 简单的设计和程序不可能运行更多复杂的测试用例。稍后, 虽然, 这些测试很简单, 尤其与有经验的测试人员相比这就是无用的测试方法。
