软件测试之迈向测试自动化成功的七个步骤

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

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

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

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

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

问题

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

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

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

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

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

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

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

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

原文转自：http://www.ltesting.net