测试工程师们可能将他们的基础结构，看作所有问题的理想解决方法，但是在某些情况下，它甚至根本就不是一个解决方法。（记住一句古老的说法"当你所拥有的全部就是一把锤子时，任何东西看起来都像一个钉子"）。更糟糕的是，他们对于基础结构的巨大投入以及不断地追加，会阻止他们看到他们的基础结构该到停止使用或至少需要重新架构的时候了。他们可能没有记住，他们的基础结构曾经也是新的，并且取代了其它一些工具。
讽刺的是这个竟然发生在软件测试工程师的身上，因为软件测试的基本原则之一就是测试团队必须独立于软件开发组织，为的是使测试团队保持客观性。一个简单的事实是：你很难客观和严格地对待自己的工作。
基础结构的维护费用在不断增长
你是否留意过城市和乡镇是怎样建设新公园的，但只是几年之后，它们便因为失修变得破烂了？城市看起来总是找到一条筹集资金的路来建公园，并且有时以需要正面新闻的人的名字来命名，但他们通常没有资金来维护它们。
维护：那是软件开发的成本，包括软件测试基础结构开发，这一点每个人都忘了去记住。是什么使一个软件测试基础结构的维护成本的增长超出控制？通常的情况是一个软件程序开始时很小，并且被设计成服务于一个特殊的需要。接着它变成了它自己的一个牺牲品，并被扩展来执行更多的任务。然而，它的基础体系结构并没有被修改，以便来处理这种增长。随着时间的过去，越来越多的用户可见的特性被增加，并且每一个新变化都会导致出现问题；当缺乏一个基础结构时，这些问题可能十分严重，它允许使一个程序变成一个单一的巨大的实体，而不是一个由组件支持的核心。结果，越来越多的人需要修改软件，并测试它，以便保证每一个修改不会使程序变得不稳定。
投入在基础结构的时间和精力是无关紧要的；它总是缺乏一个你执行当前任务所需要的功能或特性。为什么会出现这种情况呢？可能是因为基础结构尝试成为所有人的一切基础，并且它的维护人员总是尝试扩展它的原始基础结构来符合新的测试要求。
简单代码和智能数据的开源社区模型通常被认为是设计和创建一个程序的一个非常有效的方法。一个经常扩展的，单片的程序与这个模型正好相反，它可能是维护人员的一个梦魇。
使用测试基础结构，高维护成本的一个征兆是建立一支"工具团队"来维护基础结构。这个工具团队是独立于软件测试团队的，而软件测试团队是工具的实际使用者。我已经在多元化公司见到了这个模型，但我一直没有看见它们很好地工作。测试团队和工具团队不可避免地要在工具的成本和时间消耗上产生分歧。为什么？就是因为创建工具的人不用工具完成他们的工作。我认为一个模型在所有，或至少是许多创建和维护测试工具的软件测试工程师那儿，会工作得更好。这个模型可以追随开源社区模型，在开源社区模型中工具使用者（或是"消费者"）可以直接对工具的创建和维护作出贡献。
基础结构变得如此繁重以至于人们都避免使用它
这有一个说法——列宁所说——在陷入困境时，人们"用他们的脚投票" 。换句话说，当情况变得艰苦，大多数人就会去别的地方。当软件使用的工具没有用或使用起来很麻烦时，他们就会寻找其它的工具或创建他们自己的工具。当一个测试基础结构扩展变得如此复杂，以至于它成为使用的一个负担时，人们可能就会创建基础结构的一个更简单的版本，或者干脆不去使用它。否则他们可能人为地限制他们对基础结构的使用。几年前我看见过这种人为限制使用的一个实例。问题中的基础结构是一个测试结果跟踪系统。系统开始时就是一个带有GUI前端界面的简单数据库，但经过多年的使用，它发展成为一个非常复杂的，很难使用的系统。系统是高度劳动密集的：需要大量的手工干预以使得 1）按照一种可以使用的形式使信息进入系统和 2）从系统中生成进度报告。结果，一些工程师就直接拒绝使用它，一些整体团队构建了其它的报告系统，而另外一些工程师则人为地限制测试用例的数量。以便他们能（勉强地）运行系统记录。
结论
首先也是最重要的是：要记住，作为软件测试工程师，你创建的工具是通往一个终点的路。并且那个终点使你可以更好地发现不易察觉的小错误。你做的所有工作就是：要在消费者发现这些小错误之前去发现它们。
第二，要记住维护的成本。你增加到基础结构的每一行代码都是你需要维护的另一行代码。同时，因为你测试的产品将不可避免地要不断变化，你需要具有修改和扩展你的工具的能力。你的基础结构设计必须支持你正在进行的改变。
第三，使工具创建者/维护者和工具使用者保持成为一个整体。最理想的情况是，至少一些使用者需要积极参与工具的设计和维护，同样，一些工具的设计者和创建者实际上也是工具的使用者。这种"异花授粉"的方式将减少定义工具或整个基础结构而造成的混乱。
文章来源于领测软件测试网 https://www.ltesting.net/
