Intervening Code不是唯一可以变化的代码，code under test同样可以变化。特别的是，它可以改变使其完全不同的去做某件事。
例如，假设几年前某个人写了一个关于点话号码的校验测试，为了检查那些不符合要求的电话号码，就像1-888-343-3533。在当时，没有888这样的电话号码，但是现在却存在这样的号码。这样就导致了测试拒绝888号码给出提示，尽管现在这个号码是合法的，但是测试脚本会按照先前的规则进行测试从而拒绝它。解决这件事情可能很简单也可能很复杂。如果你了解问题所在那么这件事是一件很容易的事情：只需要将“888”改为“889”。但是可能很困难对测试做足够的解释去了解测试电话号码整个的方法。或者你没有意识到“888”再现在来说是一个合法的号码，所以你会认为测试理所应当的测出这条Bug。测试在你使用一些假的“Bug”来骚扰开发人员之前是不会固定不变的。
所以，在决定是否要进行自动化测试之前你同样需要问自己这样的几个问题：
code under test 行为的稳定行如何？
注意强调的“稳定性”——只要他们保持外部可试行为相同代码的代码就OK！
不同类型的产品，不同类型的code under test有不同的稳定性。电话号码实际上还是相当稳定的。再如一个银行帐目管理系统可以说是一个相当稳定的系统，如果每次存100元需要收取30元的手续费那么记录到帐的就是130元，这种关系是稳定的（除非银行改变了收费的标准）。而用户的界界面是相当的不稳定的一个因素。
增加行为往往是无害的。例如，可能有这样一个检查，测试从一个帐户撤回 $100 由于 $30 生产错误导致操作失败但是帐户余款方面的没有改变。但是，现在测试被重写，增加了一个新的特性：顾客可以根据需要确定是否需要“自动透支保护”功能，它允许用户提取多余他帐户内存在的钱数。这种变化不会破坏现有的测试，只要默认的帐户测试保持原来的行为。（当然，新的测试必须依*新的行为来运行。）
我们的立足点在哪里呢？
现在我们知道了自动化测试应该跳远的障碍：必须保证自动化测试的价值要大于采用手工测试的价值。我们需要估计一个测试的生命周期，它可以有机会创造出价值的时间段。现在，我们需要询问一下它可以创造出价值的实际可能性。我们可以期待它能发现什么样的Bug？
文章来源于领测软件测试网 https://www.ltesting.net/