不断蔓延的软件测试基础结构的危险[1]

　　不断蔓延的软件测试基础结构的危险[1]   软件测试

　　来自于 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实例?

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

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

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