这里的争论比较复杂，所以我先给出一个大纲。
1. The code under test has structure。如一个有用的近似值，我们能把code under test分为功能代码和支持代码。
2.测试人员编写那些有业务特色的脚本代码，其它support code对测试人员来说是不可见的。
3. 对业务代码的变动会对测试的行为产生影响。因此，因为它导致测试的死亡的可能性要比导致测试显示出一个Bug的可能性要大得多。
4.测试的价值主要体现在当support code发生变化后发现Bug的能力。
5. 我们不知道support code的任何事情！我们怎样去知道将来测试会不会把它当作是Bug被捕获？当找到一些Bug的时候我们怎样推测整个的测试过程是正确的？
----一般情况下如果某个地方做了变动那么那里就会出现Bug。如果那里在过去做了变化那么将来这里会有更多的变更。
----我们很难知道测试是否正常的工作，但是可以说明有一个功能没有正常的进行工作。这样的测试不会自动的执行。
6.测试下的代码同其它的产品互相的影响，这些对support code的影响比较多。我们希望由于support code导致的Bug我们可以及时发现。
----我们再来认识一个低价值测试的特征。高价值的测试不可能是一个feature-driven的测试；而通常会是一个task-driven。
次要的考虑
当我在思考做自动化测试的时候我需要在头脑中留意这样一些事情：
l 人们（用户）可以会发现自动化测试没有发现的bug。我们用来过滤掉界面上不相关的变化的工具和测试库可能同样的也会过滤掉一些古怪的bug。我曾亲眼看到一个测试员和偶然的发现当他移动鼠标的时候鼠标会不停的闪动而且这个现象不会经常的出现，对这个现象进行了深入的研究后我们发现了一个严重的bug。我听说过这样的一组测试，测试在屏幕上以X，Y为坐标显示一个图形，而这个图形测试人员在界面上无法看到，可是测试工具却可以发现它，并给出了正常的报告。
l 但是，如果测试人员非常的注意那些古怪的bug，那么会非常的辛苦而且还不会得到准确的检测结果。如果潜藏一个精确度为0.0000001的bug，人是难以发现它的，而工具就不会。注意Nyman指出工具可能分析出来人们无法见到的东西。测试工具不会紧紧局限到屏幕上可见的那一部分内容，他可以发现表明下数据结构上的问题。
l 事实上，人们不可能保证反复的以手工的方式重复输入相同数据来完成同样测试的过程丝毫不差，相反的都会有些细小的差别。例如，人们的操作犯了错误、后退、重新输入，这样有时偶然会发现在错误操作处理和support code交互之间的bug。
l 需要在不同外部配置下进行的测试尽可能多的使用自动化测试。如果需要在其它的操作系统、驱动或者第三方的函数库等情况下运行程序，理论上等同于使用不同的support code来运行程序。如果你知道将来会有这些变化，自动化测试将有很高的价值。但是，编写一个对外部配置敏感的测试其实是一个骗局。因为这样很可能使这组测试没有多少对bug的判断力而只是可以在不同的环境下运行。
l 如果在第一次运行测试的时候找到了一个bug，你清楚你应该在对bug进行修改后需要重新的对它进行测试。但是可能仅仅对这一个bug做自动化测试是不充足的。可以对这部分代码做一个标记，说明将来会对这部分做更改，这样还可以提醒你对这部分进行更多的自动化测试，如果bug出现在support code里，尤其应该这样。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/