我曾经看见过许多不同的困扰测试自动化工作量的问题。我在许多软件公司工作过，有大的，有小的，也曾经和许多其他公司的人聊过天。这篇文章介绍了避免这些问题的方法。但是首先我们需要了解它们。让我用一个故事来解释。

很久以前，我们有一个需要测试自动化的项目。小组里的每一个人都一致认为自动化是需要的。这个项目的经理叫做Anita Delegate。她审查了一些可用的测试工具，选择了其中一个并且购买了几个拷贝。她指派了Jerry加班做自动化测试用例的工作。Jerry其实还有很多其他的工作，但是在这其中，他试用了新的工具。在产品上使用工具的时候，碰到了一些困难。配置那个工具非常复杂和困难。他不得不给客户支持热线打了几个电话。他甚至觉得需要有个专家来设置好它并指出其中的问题。在打过多个电话后，对方最后终于派了一个专家。专家到达之后，指出了问题并将工具配置地可以正常工作了。非常好！但是很多个月过去了，他们仍然没有开始自动化，因为Jerry拒绝以后在那个项目工作，他害怕那不只是一次失败。

Anita重新为项目指派了一位新招的负责测试软件的短期职员，Kevin。Kevin刚获得计算机科学的文凭并且希望利用这份工作作为他寻求更有挑战性且更有价值的工作的一个台阶。Anita送他参加了工具培训以便他不会象Jerry一样一碰到挫折时就放弃。Kevin非常兴奋。测试是重复性的且烦人的工作因此他很开心做自动化测试。在发布一个重要的版本之后，他被批准全职做自动化测试。他渴望有个机会证实他能够编写复杂的代码。他编写了一个测试库并且设计了一些可以支持多搁测试用例的聪明的技巧。这花了比计划更长的时间，但是脚本可以开始工作了。他在新的版本上使用测试包并且发现了错误。然后Kevin得到了一个成为开发人员的机会就调走了，留下了他的自动化测试。

Ahmed不好采被指派运行Kevin的测试包。他发现那些少的可怜的文档根本没有什么帮助。Ahmed花了一段时间才终于搞清楚如何运行脚本。他得到了很多失败，但是也不确信自己运行的对不对。错误信息也没有什么帮助。他又深入地研究测试包，后来发现有一些测试看上去永远不会结束，有些还需要特殊的设置。他更新了设置文档并重新努力地查找问题。他发现一些失败正是由于回归中的错误引起的。每个人都很开心测试包发现了这些问题。他认为测试包中有些地方需要更改以更加的可靠，但是时间不多了。已经计划好了产品的下一个版本有一些重大的变更。Ahmed马上认识到产品的变更会破坏自动化测试。大多数的测试脚本会失败。关于这个问题Ahmed自己研究过并得到了其他人的一些帮助。他们意识到需要做些大的工作以保证测试脚本可以在新的产品界面上运行。最后他们这样做了。测试通过后，产品也发布了。但是客户马上开始打电话因为软件不可以工作。他们开始意识到在返工一些测试脚本的过程中忽略了错误信息。实际上测试已经失败了，但却因为一个程序错误掩盖了这些错误。产品是个失败。

这是我的一则小故事。可能你对故事中的一些情节感到熟悉。但是我希望你永远不要看到相同的结局。这篇文章提出了一些关于如何避免相同命运的一些方法。

问题

这则故事中说明了折磨测试自动化项目的7个问题。

消磨时间的测试自动化。人们被允许在他们自己的时间里做测试自动化或是在测试计划允许的时间里做为一个后备（back burner）的项目。这个可以让他们充分利用时间并且把精力放在需要的地方。

缺乏明确的目标。做自动化测试有许多好的原因。它可以节约时间，使测试更容易并且提高测试的覆盖率。它也可以帮助保持测试人员的动力。但是在同一个时间并不可以做所有的事情。不同的团体可能有不同的希望。这些都需要确定下来，甚至应该同样包括失望。

缺乏经验。尝试测试自己极限的初级开发人员经常会绊倒测试自动化项目。结果常常是很难继续下去。

人员周转率高。测试自动化是需要时间学习的。但是如果周转率太高，你将失去那些经验。

绝望的反映。在测试开始之前问题就潜伏在软件中很长时间了。但是测试带来了光明。测试本身是非常困难的。在测试之后再测试并且重新测试修复的软件，人们就可能变得疲倦。什么时候才可以结束测试呢？当计划指出软件现在应该完毕时，这种绝望变得特别得敏感。只要它不是为了所有的测试！在这种情况下，测试自动化可能是一个备选的答案，但是可能也不是最好的。它可能更多是是一个愿望，而不是一个现实的方案。

不情愿思考测试。许多人发现自动化一个产品比测试产品更有意思。一些自动化的项目给他们为什么不愿意涉入测试提供了方便的借口。测试工作量不能带来多少成果。

以技术为中心。如何自动化软件是一个技术相关的有趣的问题。但是这却导致没有关注结果是否满足了测试的需要。

遵循软件开发原则

你可能熟悉用于给软件开发组织分级的成熟度模型（CMM）中的5个台阶。软件工程学院（SEI）的能力成熟度模型是一个著名的例子。Jerry Weinberg有他自己的组织模型，他增加了一个叫做pattern zero的格外的等级。一个pattern zero的组织忘记了正在开发软件的事实；在用户和开发人员之间没有任何区别。在哪里都可以找到自动化测试。因此，测试自动化有专用的资源并且把它作为一项开发活动，提升到了第一级别。这是解决测试自动化问题的核心所在。我们需要象我们做其他的软件开发项目一样做测试自动化项目。和其他的软件开发项目一样，我们需要有专门负责开发测试自动化的开发人员。和其他的软件开发项目一样，测试自动化自动化开发人员在那方面可能不是专家的一个任务。因此，应该咨询内行的测试人员并提供需求。和其他的软件开发项目一样，如果我们在开始编码之前先设计我们的方法，测试自动化就可能获益。和其他的软件开发项目一样，需要记录并保护测试自动化代码。因此我们需要使用源代码管理工具。和其他的软件开发项目一样，测试自动化也有错误。因此我们需要计划记录并测试它们。和其他的软件开发项目一样，用户需要知道如何使用它。因此我们需要用户文档。

我不会在这里告诉你如何开发软件。我假设你们已经知道一些关于怎样将合理并有效的方法用于开发软件的软件组织中的一员。我只是力促你们同样遵循软件开发的原则作为自己测试自动化的原则。这篇文章由那些我们所有用在软件开发项目的标准步骤组成，并且在专为测试自动化考虑和挑战的地方做了特别的说明。

1． 改进测试流程

2． 定义需求

3． 证实想法

4． 拥护产品的可测试性

5． 设计可持续性

6． 计划部署

7． 面对成功的挑战

步骤一、改进测试流程

如果你负责改进一项业务的效率，你首先应该确信流程已经被很好地定义了。在投资时间和金钱在自动化正在使用计算机的系统之前，你也应该了解是否有简单且廉价的方法使事情变得更容易。当然，同样要把握测试自动化。实际上，我喜欢认为“测试自动化”这个术语只是流水线化测试的流程，将事情更快地向前推进且很少有延期的现象。在机器上运行自动化测试脚本只是一个备选方案。

例如，许多团队通过自动化他们的回归测试开始自动化测试。它常常需要运行多次测试，以检查并确保以前可以运行的功能没有因为新的更改而被破坏。它经常要运行并且相当乏味的。如何更好地文档化你的回归测试呢？常见的方法是利用需要检查的功能列表。这是一个非常好的开始。关于测试目标的提示应该适合于那些了解产品并需要理解采用的测试方法的人。

但是在你开始自动化之前，你需要改进这些文档以使测试更加清楚。指出测试需要使用的名字，数据或者提供编辑它们的指南。假如测试人员有基本的产品知识可能是安全的。当然这肯定需要其他地方有相关的文档。但是你还是需要明确测试设计的细节。你需要说明期望的结果。这个常常没有说明，建议测试人员应该知道。很多的测试人员没有意识到他们正在遗漏什么或是因为不好意思而没有问的问题。由于现在任何一个对产品有基本认识的人就可以执行测试，这种详细的文档马上就可以给你的团队带来收益。在你开始做更彻底地自动化之前，这些是必须先完成的。你的测试设计将会是自动化测试的首要需求陈述，因此必须十分清楚也重要。它有可能因为清楚地指出需要执行测试的每一个步骤而走向极端。假设让那些了解如何操作软件的人员执行测试是比较可靠的。但是不要假设他们也理解你的关于如何测试的观点。

我曾经做过自动化测试一个软件模块的工作。这个模块有一些比较难自动化的功能。当我意识到我不可能在短时间内完成它时，我断定我需要一份详细的回归测试设计。我浏览了这个模块所有的已关闭的错误，并且为每一个错误都写了一个如何发现错误的描述。我的计划是它将会给我提供一份详细的关于可以帮我决定模块的哪些部分最需要自动化支持的自动化需求清单。当然，我从未有编写自动化的机会。但是当我们需要运行这个模块的完整的回归测试时，我们可以把测试说明书给那些了解产品但是没有测试经验的人。利用这份详细的测试说明，他们能够进行独立地测试。他们可以在没什么监督的情况下发现错误。在某种程度上，这就是非常好地自动化。实际上，在这个项目里，我们最好使用书面的测试用例，而不是使用我们拥有的其他产品模块的自动化测试脚本。我们知道自动化测试脚本需要太多的培训以致于其他人不仅仅是拿起脚本就开始运行。如果自动化测试可以更好地设计，这将不是一个问题，但是我们发现创建设计良好的测试文档比起创建同样设计良好的测试自动化更容易些。

另一个改进测试效率的简单方法是获得更多的计算机。许多的测试人员很容易让几台机器保持繁忙。这是显而易见的事情，但是我之所以提出这一点是因为我曾经看到过一些被误导的自动化试图将所有的测试在一台机器上完成。测试自动化可能是处理设备短缺的一种昂贵且冒险的方法。比较好的是，集中拿出一个你所需设备的证据。

最后一个关于改进测试流程的建议是改进产品以便更容易测试。有许多可以帮助用户和测试人员的改进办法。稍后我会讨论自动化所需的可测试性。这里我只想建议识别可以帮助手工测试的产品改进方法。

有一些产品很难安装，测试人员发现花费了大量的时间在安装和重新安装上。与其自动化这个安装过程，不如改进安装程序。客户也可以从中受益。另外一个方法就是考虑开发一个成形的自动化安装程序以使其可以和产品一起交付。实际上有许多可用的商业工具可以自定义设计安装程序。

另一个产品改进是利用工具扫描安装或运行日志中的错误。虚拟扫描一页页的日志来寻找错误信息这样会更快。所以让我们自动化它吧，好吗？如果你知道错误信息是什么样的话，编写一个扫描工具是非常容易的。但是如果你不确定，这将把你自己推向灾难。还记得那个关于遗漏错误的测试包吗？客户也不想通过扫描日志来查找错误。为产品增加一个错误扫描器很可能会产生一个更可靠的扫描器，或者要求修改错误日志系统以确保捕捉了所有的错误。这是一个测试可以依赖的工具。

性能是另一个产品需要改进且可以帮助测试的方面。这很明显。如果产品的反映迟钝耽误了你的测试，找出反应慢的功能，估量它，并且将它作为一个阻碍测试的错误提交。

这些是在不建立一个测试自动化系统的时候你可以为改进测试效率做的事情。改进测试流程可能可以节约一些时间给测试自动化，使你的自动化项目更加平滑。

步骤二、定义需求

在我们的故事里，我们可以看到和发起人相比自动化人员有不同的目标。为了避免这种情况，我们需要确信大家在测试自动化的需求上达成了一致。我们已经有描述哪些地方需要测试的测试需求。它要详细地描述我们的测试设计，而且要有描述自动化目标的自动化需求。很多人认为测试自动化就是目标，不需要再描述他们希望得到的是什么。以下是几个人们为什么选择自动化测试的原因：

• 加速测试以加快发布版本

• 测试可以执行地更加频繁

• 通过减少人力以减少测试的成本

• 提高测试覆盖率

• 确保一致性

• 提高测试的可靠性

• 允许没有什么技术的人员测试

• 定义测试流程并减少对了解产品的少数人的依赖

• 使测试更有意思

• 发展程序技能

开发管理层，测试管理层，测试人员和自动化测试的人员的目标经常是不同的。除非他们达成了一些协议，否则很难获得成功。

当然，以上有一些测试目标比其他的目标更容易达到。测试自动化实际上经常提高了测试人员所需的技能水平，因为他们必须要能够充分地理解已自动化的测试以便他们能够重现发现的问题。自动化不能帮助你从你的职员中抽取测试知识。无论如何，先清楚人们认为成功是什么。

手工测试人员在运行测试时，做了很多没有意识的事情。他们计划然后得到所需的资源。他们设置然后执行测试。他们注意是否有任何不正常的事情发生。他们对照测试结果。他们记录结果并重新设置系统以准备下一次测试。他们分析错误并调查古怪的行为。他们寻找失败的模式并想办法执行更多的测试以帮助定义缺陷。然后记录缺陷报告以使其得到修复，总结报告以让其他人知道他们已经测试了哪些地方。

不要硬逼自己自动化测试的每一部分。寻找你将来可能得到最大回报的地方。部分的自动化都是可行的。你可能发现最好的是自动化执行过程加上手工验证结果。或者你会选择自动化验证过程加上手工执行测试。我曾经听一些人说除非自动化测试完成了所有的事情，否则不是真正的自动化。那是胡说。如果你只是单纯地寻求挑战，那么你会尝试做所有的事。但是如果你是寻找成功，那么就集中精力在你可以快速获得能够让你再三使用的自动化测试上。

为你的测试自动化项目定义需求将促使多样的权衡变得更清晰。它也有助于合理地设置不同团体的期望。通过定义你的目标，你已经迈出了通往测试自动化成功的下一步。

步骤三、证实想法

在我们的故事里，我们看到自动化人员不是十分确切地明确他们的方向在哪里就进入了自动化项目。但是期间也得到了一些为项目提供的支持。

你可能没有意识到这一点，但是你必须证明你的测试自动化项目的可行性。它总是花了比人们想象更长的时间。为了得到承诺，我们需要得到来自组织里的各方面人员的支持。

许多年前，我在一个测试自动化项目里工作，我们有各式各样的好想法。我们设计了一个复杂的测试系统，接着努力的开发许多的组件。我们定时地做一些说明自己想法和进展情况的报告。我们甚至演示自己正在工作的部分。但是我们没有演示真正的测试。最终这个项目被取消了。从此我再也没有犯同样的错误。

你需要尽快地确认你的工具和方法。你的项目可能做自动化测试吗？这常常是很困难的。你需要尽快地找到答案。你需要查明你的工具和方法是否适合你的产品和职员。你需要的是一个想法的证据－一个快速的，有意义的可以证明你走在正确的道路上的测试包。可以证明想法的测试包是评估一个测试工具的最好方法。

对于很多人来说，测试自动化意味着GUI测试自动化。这和我所想的不一样。我做过GUI和非GUI的自动化，对听说大多数计划中所关心的问题是互相共享的，我感到吃惊。但是GUI测试工具是非常昂贵且很讲究的。很难说它们将会碰到什么样的困难。因此，选择正确的GUI测试工具是一个非常重要的决定。Elisabeth Hendrickson提供了一份非常好的选择工具的指南。我建议你将证实想法作为你评估的重要部分。这要求至少一个月的工具使用协议。你甚至可以先采购一份拷贝，评估之后再购买更多的拷贝。在你付出这一大笔钱之前，你应该可以找出工具的问题。你可以从供应商那得到些帮助，这样即使你发现不得不切换使用其他的工具时你也不会感到被欺骗了。

以下是一些证实想法的备选项：

回归测试。每一个版本你都要测试吗？这种测试是自动化的最佳候选项

配置测试。你的软件要支持多少个不同的平台？你要测试所有的平台吗？一些自动化可能有些帮助。

设置测试床（Test bed）。相同的设置过程可能在许多不同的测试中使用。在自动化测试之前，先自动化设置步骤。

非GUI测试。自动化命令行和API测试比自动化GUI测试容易的多。

不管你的方法如何，定义一个可证明的目标然后集中证明它。这可以使你在成功的道路上迈的更远。

步骤四、拥护产品的可测试性

一个产品可能有三个不同的接口，分别是命令行接口（CLIs），应用程序编程接口（APIs）和图形用户界面（GUIs）。有些可能三个都有，但多数只有一个或两个。它们是你测试可用的接口。本质上，APIs和CLIs比自动化GUI容易地多。查明你的产品是否有这两者之一。有时它可能被隐藏了或者只给内部用户使用。如果不是的话，支持产品的可测试性要求你鼓励开发人员将CLI或API放到你的产品中。

但是首先，让我说说一些关于GUI测试自动化的事情。GUI测试自动化比人们常认识到的更困难，有几个原因。第一个原因是GUI测试自动化要求编写一些手工脚本。大多数的GUI自动化工有个叫“录制和回放”的功能，或叫“捕捉/回放”。这个想法是非常好的。你手工执行测试的同时，测试工具在后台工作并记录你的操作。然后生成你可以运行以重新执行测试的脚本。这是非常好的想法但很少工作。大多数作者认为尽管产生的代码可以重用，还是有各式各样的问题会阻止录制器有效地用于全面地测试生成。因此，你首先需要手工创建你的GUI测试。

第二个造成GUI测试自动化难点的原因关系到工具工作在产品上的技术挑战。这需要相当多专业的技术使GUI测试工具可以工作在最新的用户接口技术上。这个难点也是为什么GUI测试工具如此昂贵的一个主要原因。不标准的或自定制的控件会增加其他的难度。一般可以找到解决办法，但是通常需要修改产品的源代码或从工具供应商获得更新。测试工具中的错误可能需要分析和补丁或者绕行的办法。测试工具可能要求相当多的定制以使其更有效地工作在你产品接口的自定制的控件上。这种工作的困难度让大家吃惊。你可能也会重设计测试以避开那些有困难的控件。

第三个使GUI测试自动化的原因涉及到要跟上GUI的设计变更。众人皆知GUI在整个开发得过程中是经常要修改的和重新设计。GUI的第一个版本一般是比较糟的。但是要保持自动化脚本在GUI一直在更改的过程中都可以运行必须经常要运行它。你可以花大量的时间修改你的测试脚本以使其可以运行在变更中的界面。然而，你不想站在争论有帮助的改进方法的对立面。我曾经处在那种情况下，那是非常不舒服的。在最初的设计被重新做过之后可编程接口的变动率会便少。

以上是不依赖GUI测试自动化作为测试你产品功能的基础原因。GUI仍然需要测试，当然，你可以选择自动化这些测试。但是你应该有其他的可以依赖测试核心产品功能的测试，它们在GUI重新被设计时不会被破坏的。这些测试需要通过一个不同的接口的工作：命令行或API。我曾经看过人们选择GUI测试自动化是因为他们不想修改产品。但是最终他们认识到为了使GUI测试自动化可以工作，必须修改产品。自动化是很可能要求产品修改成你所需的模样。因此要求一个可编程的接口是可靠的。

为了使测试一个API更加容易，你可以需要绑定一个编译器，好比TCL或Perl或甚至使Python。它们使互动测试变得可能并且可以加快自动化测试的开发速度。工作在API上可以使你为单独的产品组件成为自动化单元测试。

一个很可能隐藏的可编程接口的例子是InstallShield，一种非常流行的开发安装程序的工具。InstallShield有命令行选项可以激活安静安装（Silent Install）。这样允许从你提前创建的回应文件中读取安装选项。利用这种方法比自动化InstallShield的GUI本身更容易和可靠。

另一个关于你可能如何避开GUI自动化的例子是关于基于web的软件。GUI工具可以通过浏览器操作web的界面。但是直接测试web浏览器用来和Web服务器通信的HTTP协议会更容易些。Perl是也是唯一一个能够直接连接到TCP/IP端口的语言工具，可以做它的自动化。使用先进的接口技术的应用程序，例如客户端的Java或ActiveX不能采用这种方法。但是如果这种方法是适用的话，你可能会发现这种自动化比通过GUI工作更便宜且更容易。

我曾经被雇来为一个产品的GUI编写自动化的测试。这个产品有一个已经被自动化测试了的命令行的接口。在经过一些调查之后，我认识到要发现GUI的错误不是困难的，但是客户没有给予和他们高兴使用CLI一样多的关心。我也认识到我们没有为最新的功能做自动化（不管是通过GUI还是CLI）。我决定不作GUI测试自动化而是扩张CLI的测试包以覆盖最新的功能。回头想想，我有时认为我选择不做GUI测试自动化项目是我最大的成功之一，因为那可能会浪费所有的时间和工作量。他们已经为GUI自动化做好准备了，他们购买了工具和所有的东西。但是我知道他们也将面临各种各样的困难和障碍，然而可能只会收获非常有限的回报。

无论你是需要GUI，CLI或是API自动化的支持，如果你早一些提出问题，你将更成功的得到为产品设计可测试性的功能，尽管产品可能还在设计中。启发开发人员认识到可测试性也是产品的一个需求。

步骤5