【IT168 技术文章】

    来自于 Rational Edge：包含良好自动化测试实践的基础结构可以是一个幸事，也可以是一个祸根。这篇文章描述了这样一种场景，它避免了测试小组随着时间的推移，产生出不断蔓延的测试基础结构。

    这是我在项目中的第一天，我把每周一次的关于自动化测试的讨论作为文章的开始。我发现即使精通多种操作系统，数据库，程序语言，并且阅读过很多产品特性的资料，但我依然很难明白所讨论的内容。而且似乎参加会议的每个人都在谈论着某种程序语言，而这种语言对我来说却是陌生的。人们不断地谈到"enabler routines"和API方法，而这些API方法在我所读过的API文档中从未见到过。

    我花了些工夫才意识到，人们在探讨测试框架中的惯例和方法，而不是测试中的产品。在过去的几年里，测试框架已包括了许多的惯例，这些惯例封装了实际产品的API方法。

    现今这种方法的确有很多优点。它减少了冗余测试代码，能够强制使用标准的机制执行任务，并且可以跟踪API方法的返回值。随着它不断的发展，这种特殊的框架结构已经变的如此广泛以至于它自身已变成一种程序语言。创建整套完整用户文档和处理定期框架更新版本的小组成员推荐这种方法。

    但是还是有不足之处的。由于测试框架是如此的广泛，而且许多自动化的测试都基于这个框架，使得维护框架结构和测试变的十分昂贵。为了保持与测试产品的新版本的同步，框架不断被更新，这不仅使得任务变的越来越大，而且使得像我这样的新成员不得不花费更多时间学习测试框架。

    当我第一次参加会议时，我震惊于人们对于测试框架学习的花费。他们能够用同样的方法讨论各种"enabler routines"的程序，就像我讨论JDBC的使用或者在Java中使用一个数组或矢量的优缺点一样。

    诚实地讲，会议有点胁迫的感觉。这有点像身处在外国，而你却不会讲他们的语言一样。但是我最担心的是：对我来说似乎提供自动化测试程序框架的过程，能够使工作变得容易并且有效率，但是我们增加了如此复杂的抽象层，使得人们更少的接触到所测试的产品。或许我有点夸大其词了，但这确确实实是我的感受。

    Infrastructure-itis

    我突然记起几年前的相似经历。当时我正创建软件质量评价小组来检测Internet防火墙。我们需要一种方法来检测某些命令行工具，并且决定在Expect中写测试脚本。开始的两天进行的很顺利，直到Al（不是他的真名）称他"改进"了Expect。并把他的创造叫做"RunExpect"。你可以想象，它是一串在Expect中写的封装好的函数。我感谢他，但是我谢绝成为第二个，最终也是最后一个加入RunExpect用户社区的人。我选择使用Expect并且创建我们所需要的并且可随时使用的惯例。

    因此，这里发生了什么？这是经常出现在软件质量保证团队中的情况：infrastructure-itis。

    什么是infrastructure-itis？这是一个适应坏状况的很好的主意。这个好主意用来创建（或调整）软件工具使得测试更加自动化且更有效率。坏状况就是这些工件的维护变得过于沉重。

    如何开发一个infrastructure-itis实例？

    它可以从一个小范围开始。我们可以向他们说，你们正在测试一个数据库应用程序。你的自动化测试将需要通过一些注册或者使用者身份验证的形式访问数据库。你可以在每一个测试程序中通过复制代码来为注册用户编号，或者你可以使它成为一个单一的，可调用的例行程序。这是一个好方法。这个例行程序为你的测试程序提供了访问数据库的路径，但它同时使测试程序设计员无法处理注册程序的准确语义。相反，他们处理可调用例行程序提供的抽象注册界面。最终，你将创建越来越多的可调用的例行程序来支持测试。

    问题是，这些例行程序的创建可以成为它之中和它本身的一个结束，在极端情况下，实际也可以分散你对手边实际工作的注意力——指的是自动化测试的创建和执行。但它是恶性的循环。你创建一个有用的例行程序，然后再一个，接着又一个，很快所有你所做的工作就是创建，重分解和改进测试的基础结构。它能使人成瘾。做软件工作的众多乐趣之一就是你可以随意设计，创建，然后再设计，再创建。它把软件的自然特性当作一种媒介。如果你用钢或花岗岩来工作，重新设计或增加一些东西是很贵的。然而，在软件工作中，你可以通过按压键盘来完成工作。（是的，有很多键，但改变软件仍然要比建一座吊桥容易。）

    避免恶性循环

    你将如何避免影响？警示符号是什么？技巧在于，在你陷入恶性循环之前控制住你自己。在你实际已经离开很远的时候很难意识到你离开太远了。一个很老的Buggs Bunny卡通片说明了这一点。Buggs感到沮丧是因为对于兔子的慷慨比更具破坏性的动物少得多。他决定要通过跨越南北美洲来迂回前进破坏出一条路以便表示慷慨。他的慷慨是1百万美元。后来他发现他正被整个陆军和海军搜寻。正当炮弹在他周围降落，他悔恨，"可能我离开得有一些远了。"

    你可以避免这种命运。这里是三种你需要注意的情况：

    人们把他们的精力倾注在基础结构，而不是测试上面

    正如我们早先所讨论的，做软件工作的乐趣之一就是如果你的想象力无限，你将可以创建出任何复杂的系统。成为软件测试工程师的人们，当他们通常是以破坏东西来拿薪水的时候，对这个警报器的声音是没有免疫力的，并且经常将他们的创造精力倾注在建立复杂的测试基础结构上。（有几分像想当导演的演员。）这将自动成为一个问题吗？不，但当工程师们对于基础结构的情感因素，使他们对它的真实效用和限制失去判断力时，它可能会成为一个问题。

    测试工程师们可能将他们的基础结构，看作所有问题的理想解决方法，但是在某些情况下，它甚至根本就不是一个解决方法。（记住一句古老的说法"当你所拥有的全部就是一把锤子时，任何东西看起来都像一个钉子"）。更糟糕的是，他们对于基础结构的巨大投入以及不断地追加，会阻止他们看到他们的基础结构该到停止使用或至少需要重新架构的时候了。他们可能没有记住，他们的基础结构曾经也是新的，并且取代了其它一些工具。

    讽刺的是这个竟然发生在软件测试工程师的身上，因为软件测试的基本原则之一就是测试团队必须独立于软件开发组织，为的是使测试团队保持客观性。一个简单的事实是：你很难客观和严格地对待自己的工作。