zaIIlbelich关于测试自动化说过这些话：
已有相当多的测试专家令人信服地重复实施着软件测试过程自动化的工作。参加软件测试的大部分人都认为测 试过程的自动化不仅是我们期望的，而且实际上也是当前 市场必须的要求。[3]
开发鱼盐业趟塾焦壅坚一个费钱而且费时的项目。这个框架的创建和实现必须在AL盯交付Qc(Quality C0nt耐，质量控制)之前完成，因此得在该项目的生命周期的早期阶段构建并测试。然而，一旦使用该框架，你可能会发现它不适合你的组织所有的软件测试需要。了解何时使用这样一个框架是测试自动化重要的部分。我们已经与自动化测试团体的其他成员在在线讨论中热烈讨论过这个问题。我们讨论的部分内容是给定开发该框架所花费的工作量，邀据驱动测试的价值何在。该讨论的部分内容发布在：1999年5月17至21日SOA用户组网站上。尽管很多人参加了讨论，这里只摘录Elfriede Dustin、cd Nagle和Dan M0sky的谈话。完整的在线讨论请见附录A。
E1抽ede：
我同意Mark的观点，数据驱动测试会有普及的一天，虽然现在还未到时日。我在使用数据驱动测试时使用的是“测试数据”(请看㈣t。testc。．∞m，那里有一个例子描述了我们如何使用Robot工具对两千年数据进行测试)，但是我们很少在数据驱动测试中使用“控制数据”。原因在于实施起来很麻烦，并且只有当测试能在后续版本中重用多次时这些努力 算值得。
Ed Kit在srAR做完讲座之后我曾经咨询过他，他也认同找的观点，即这种方法至少要重用17次后才能使回报与付出相抵。(没错，这是他给出的数据。) 较早时候，我在先前工作中的一位合作者刚好接受了这种 数据驱动测试的训练。此人花了3周的时间实施数据驱动方 法。有很多漂亮的表格，里面有各种命令／控制以及要读取的 数据。但是最后大家归结出如果使用简单的记录以及回放和脚 本的修改，将会更有效率，因为这种测试无法重复使用。在此案例中这种尝试属于浪费时间。你将不得不依赖于你自己的判 断，并请记住在测试自动化中使用复杂的数据驱动框架有时是 得不偿失的。
Cad：
我对你的各种观点都比较同意，但是我认为如果不是有意进行重用，那么再多的自动化方法也是不合算的。实际上，即 使是经过第17次重用才划算的说法听起来也太好了。根据每 晚进行的构建验证，应该是17个工作日(或更少)并全在同 一个版本中!
Dan：7
我恐怕不能同意你(E“nede)的观点。数据驱动的确需， 要你所说的前期投入，但是在软件刨建这个级别的回归测试中f它的回报是很大的。我自己经历过并且见过。我们曾经必须为一个财务软件测试100多个交易画面(每一个都是一个窗口)。I 我们开发了超过7000个的数据驱动测试，其中每一个大约要 花费3～5天进行编制和调试，但是这些测试在每一次软件新 版本创建之间重复运行只要1～2个小时。我们通常每周都会 收到一个新的版本，而我们每周都能够重复使用那100多个测 试脚本和7000多个测试记录，并且我们可以按时完成工作。
从这些讨论中可见，关于自动化测试的价值，特别是数据驱动方法价值存在不同的意见。主要问题是：何时实现自动化测试框架是有意义的?对于较小的测试项目，这种工作就不值得了。即使对于较大的测试项目如果测试不在回归测试套件中重用，测试自动化也似乎不明智。另一个解决这个问题的方法是看要被自动化的测试类型。对于单元和集成测试，自动化是必不可少的。为什么?因为如果没有自动化，用于测试的构建版本质量就会很差。结果是本应在开发中发现的缺陷，留给系统测试者了。在当前的Web开发领域，Java是可选的语言，且使用面向对象方法。开发者使用测试工具比如JLhit把测试用例作为类嵌入，这些类可与其余代码一起保存，并且在构建过程中集成前被用僵用来测试Java对象。这样做可以清除许多当前留给系统测试的错误类型。此外．自动的集成级冒烟测试应该在每个构建版本进人系统测试前准备和执行。第5章更深人地讨论了这些问题。
HaIlcock认为： 测试自动化是一项投资。最初的投资可能很多，但投资的回报 很丰厚。自动化测试运行超过15次以后，测试就是免费的了。[1]他将自动与手工测试的比较看作是基本自g威本一收摘分析。他引用了Kalr时的假设，构建、验证和存档自动化测试要花手工测试3～10倍的时间[2]。Hartcock在他的测试自动化的可能回报的例子中用15倍作为最坏的情况，对可能的回报做了保守估计。
为了计算投资回报(鲢tumon lnvestment，RoI)，Han∞ck说一定要确定“次数”；也就是说，测试集需要执行多少次——要将平台数、操作系统数，以及与软件相容的外语数目相乘，也要与测试要运行的构建数／版本数相乘[1]。
如果你用Hancock的ROI方法，单元和集成测试的自动化比系统测试的自动化更值得，因为系统测试比其他两种测试类型重用的机会少。如果系统级测试没有在一个重用程度很高的自动化回归套件中实现，系统测试自动化就不会有太高的ROI。而单元和集成测试的ROI就高得多。很少有公司完全意识到自动化测试的价值。他们想拥有，也知道他们需要，但最后他们不能让上层管理者信服其成本收益。
文章来源于领测软件测试网 https://www.ltesting.net/
