自动化黑盒测试、GUI级回归测试工具在行业中被广泛应用。根据现在流行的说法，即使是只有很少的编程经验的人都能使用这些工具快速创建各种测试套件。按照这种说法，这些工具易于使用，并且连测试套件的维护也不成问题。因此，一位开发部经理很自然地用这些工具之一去替代一些（或很多）麻烦的测试人员，这样既省心又省钱，还能快速发布软件。

　　以上说法被工具提供商和不懂测试的经理到处散布，甚至还包括那些应该对测试有更多了解的测试人员和测试经理们。

　　事实上，一些公司成功地使用了这些工具，而另一些公司则没能有效地利用它们。

　　十三位经验丰富的软件测试工程师讨论了可维护性黑盒回归测试套件的开发过程中的成功及失败模式。讨论的焦点是实际经验。首先，我们承认很多实验室已开发出解决自动化问题的实用方法。因此，我们的目的就是把这些实际经验汇集到一起，在相对较短的时间内获得较大进展。

　　大家只为同一个目标组织到一起。但成员们有他们自己的观点，并不一定代表整个团体的观点。

　　本文综合了本次讨论的一些重点议题以及我的一些测试经验。

　　问题

　　自动化回归测试有很多缺陷，我在这里只列举了一些。James Bach(LAWST成员之一)在他的文章“Test Automation Snake Oil”中列举了其它的很多种。

　　基本规范的问题

　　以下是基于GUI的自动化回归测试的基本规范：

　　a. 设计一个测试用例，然后运行。

　　b. 如果程序不能通过测试，就撰写一份错误报告。在bug被清除后再重新开始。

　　c. 如果程序通过了测试，就自动运行。然后重新运行测试(通过脚本或者借助截取工具)。在测试末尾对屏幕输出进行截图。然后保存测试用例及输出结果。

　　d. 接下来，运行测试用例并把它的输出与已保存的输出作比较。如果匹配，则表明程序通过了测试。

　　第一个问题：这种做法开销很大。通常，对自动化测试进行创建、验证、简化文档所花费的时间是创建并手工运行测试的3到10倍，甚至更多。虽然很多测试值得被自动化、但对于那些只运行一两次的测试，这样做并不划算。

　　有人建议测试人员对他们所有的测试用例都进行自动化。我很不赞成这种观点。因为很多黑盒测试被创建并运行仅仅一次，那么，要自动化这些一次性的测试，就会不得不在每一个测试上花费大量的时间和金钱。而同时，将不能运行大量测试。所以，为什么非要让每一个测试变得低覆盖率、高成本呢?

　　第二个问题：这种做法带来了额外开销的风险。我们都知道找到并修复bug的成本随时间而升高。当一个产品离它的计划发布时间更近时，就会有更多的人参与工作，比如，内部?测试用户以及制作用户手册和营销材料的人。因此，越晚找到并修复重大的bug，这些人被浪费的时间就越多。如果把先前大部分的测试时间都用在写测试脚本上，那么你将更晚发现bug，到时候付出的代价也会更大。

　　第三个问题：这些测试并不强大。因为只有那些通过测试的程序才能进行自动化测试，而这样又会发现许多新的bug。我所知的估计值在6%至30%之间。而如果你在创建测试用例时就计算你所找出的bug,这个数值会变得更大。

　　第四个问题：实际上，许多测试团队只能对那些易于运行的测试进行自动化。测试初期，它们易于设计，而且程序也不能运行更复杂的测试用例。但到后来，这些测试变得失效，甚至还不如熟练的手工测试人员所设计的已经日益粗糙的测试有用。