在大多数时候，你不可能有机会直接运用the code under test。例如：你不可能直接得到确认电话号码的那部分代码，因为它通常会是一个用户的一部分属性，就需要通过用户接口来测试，将与其关联的那部分代码组织起来，使这部分转变到内部程序的数据，并会按照常规将这部分数据表现出来。当然，你也不能直接对表现出来的数据进行检测，因为转变会通过其他的代码来将其转变成在用户界面可见的最后的数据（就像非法的数据会转换成错误信息）。我称这些代码为intervening code——介于测试本身和code under test之间的代码。
Changes to the intervening code（对介入其间的代码进行变化）
介入其间的代码是导致测试死亡的主要因素。而且用户图形界面接口较上文提到的那个接口和一些硬件驱动接口相比更是这个样子。例如：假设用户接口要求你输入电话号码，但是现在变化为要求提供一个电话按键区的视觉表现。这时你要使用鼠标敲击号码模拟使用真实的电话。（这是个非常愚蠢的主意，但是这怪异的事情已经发生了。）尽管接口传给了code under test一个正确的值，但是用户界面的变化很可能破坏一次自动化测试，是因为很可能使用者再没有地方输入电话号码了。
就像另外的一个例子，一个输入的错误用户界面会用其它的方法来告诉用户。它可能会刷新主窗体使其显示红色同时发出特殊的声音来代替弹出的提示信息来告知你不能完成这次操作。但是，如果你的测试是通过测试是不是弹出提示信息来判定的，那么将视这种正常的运行为一个bug。很显然这个测试就没有效果了。
"Off the shelf "测试自动化工具能做避免测试死亡的有限制的工作。例如：大多数的GUI自动化测试工具都可以忽视文本框大小、位置和颜色的改变。从而把握像上面两段所提到的那些大的改变，但是需要事先定制。这需要在你的工程中有一些人去创建test libraries。这样就要求你，一个测试人员，在编写好测试的特殊术语，尽可能多的忽略用户接口的细节。例如，你的自动化测试可能包含这样一行定制的信息：try 217-555-1212 try是test library程序，它的作用是将电话号码翻译成接口可以知道的术语。如果用户界面接受在输入框中输入字符，try会在其中输入电话号码。如果需要通过显示在屏幕上的特定图形区域键入电话号码时，try也会做到。
test library 可以有效地将那些不相关信息过滤掉。这样我们就可以详细的准确的测试那些与功能相关的数据。在输入上，增加这些附加信息是intervening code所必须的。在输出上，它们将intervening code中的信息全部压缩到一个很重要的模块中，其中的信息实际上可以当作是Code Under Test的一个延伸。这种过滤可以用左图来描述：
多数用户界面的变化不会需要对测试做更改，而只需要对test library做相应的修改。应为test Code要比library Code多的多，所以只修改library Code的代价会很低。
但是，尽管我们有更好的补偿性的代码也不可能将测试从所有的变化中隔离出来。它仅仅是尽可能的去预期所有的事情。所以其中有很多可能性，将来很可能出现一些问题破坏你的测试。你必须问自己这样一个问题：
在变化中Intervening Code会把测试保护到什么程度?
你需要估计intervening Code的改变对测试造成影响的可能性。要保证用户界面永远的不会改变是一件不可能的事情，这就使你需要不停的改变自动化测试的脚本以保证测试可以自动的执行。（我不会相信界面冻结后永远不会变化，除非manager答应如果以后每做一个新的修改将会给我100美元）
如果变化是可能的，你一定会被询问对你的test Library保护你的测试不受其影响正常执行有多大的信心。如果说test Library不能保护测试，那么起码它可以很容易的做出改动以适应变化。如果花费一个半小时的时间可以拯救300个测试，那么所做的一切是值得的。但是，小心：很多人往往低估了维护test Library的困难，特别是在变化后需要手工的对测试test Library进行反复的修改。不应该马上就放弃，抛弃所有的测试类和test Library，从头开始，因为很可能只需要简单的修改就可以完成需要的测试。
如果你没有test Library——如果你正在使用自动化GUI测试工具来捕获和重放模式——你不要期待会有任何保护。一次对界面的修改会让你的大部分的测试“死亡”。往往不会有足够的时间来允许我们完成对发生变化的测试进行修改，我们不得不在少的花费和短的生命生存期之间做出选择。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/