测试会延续它的价值吗？
这里的争论比较复杂，所以我先给出一个大纲。
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。
次要的考虑
当我在思考做自动化测试的时候我需要在头脑中留意这样一些事情：
● 人们(用户)可以会发现自动化测试没有发现的bug。我们用来过滤掉界面上不相关的变化的工具和测试库可能同样的也会过滤掉一些古怪的bug。我曾亲眼看到一个测试员和偶然的发现当他移动鼠标的时候鼠标会不停的闪动而且这个现象不会经常的出现，对这个现象进行了深入的研究后我们发现了一个严重的bug。我听说过这样的一组测试，测试在屏幕上以X，Y为坐标显示一个图形，而这个图形测试人员在界面上无法看到，可是测试工具却可以发现它，并给出了正常的报告。
● 但是，如果测试人员非常的注意那些古怪的bug，那么会非常的辛苦而且还不会得到准确的检测结果。如果潜藏一个精确度为0.0000001的bug，人是难以发现它的，而工具就不会。注意Nyman指出工具可能分析出来人们无法见到的东西。测试工具不会紧紧局限到屏幕上可见的那一部分内容，他可以发现表明下数据结构上的问题。
● 事实上，人们不可能保证反复的以手工的方式重复输入相同数据来完成同样测试的过程丝毫不差，相反的都会有些细小的差别。例如，人们的操作犯了错误、后退、重新输入，这样有时偶然会发现在错误操作处理和support code交互之间的bug。
● 需要在不同外部配置下进行的测试尽可能多的使用自动化测试。如果需要在其它的操作系统、驱动或者第三方的函数库等情况下运行程序，理论上等同于使用不同的support code来运行程序。如果你知道将来会有这些变化，自动化测试将有很高的价值。但是，编写一个对外部配置敏感的测试其实是一个骗局。因为这样很可能使这组测试没有多少对bug的判断力而只是可以在不同的环境下运行。
● 如果在第一次运行测试的时候找到了一个bug，你清楚你应该在对bug进行修改后需要重新的对它进行测试。但是可能仅仅对这一个bug做自动化测试是不充足的。可以对这部分代码做一个标记，说明将来会对这部分做更改，这样还可以提醒你对这部分进行更多的自动化测试，如果bug出现在support code里，尤其应该这样。
● 如果你的自动化测试设计的支持性非常的出色，开发人员可以很容易的使用它，让他们做一次测试观察结果要比你把bug通过仔细的描述来再现给开发人员要快的多也好的多。这中测试的自动化执行的级别会很高。开发人员通常使用测试工具会很困难，或者没有在他们的机器上安装这些工具，再或者有一个环境对测试造成不可思议的破坏等等。如果真的让开发来运行测试有可能会阻止了他们正常的工作，浪费了当量的时间，而这些的目的只是为了避免书写详细的bug报告。
● 最让人恶心的是在手工测试中找到了bug，但是没有办法再现。可能你做了些什么，可是根本没有记住是怎么做的。自动化测试很少会出现这样的情况(尽管有时候你没有注意到它们依*了已经变化了的环境)。产品中的跟踪和日志可以给我们很大的帮助，这些对开发人员是非常有用的。如果这些东西不存在，自动化测试的工具可以用来创造类似日志的文档记录键盘和鼠标的操作信息。这种日志的使用价值以来它的可读性是怎么样的，在程序内部产生的日志文档是非常好的。根据我所见到的，大部分的测试人员可以在用来做记录的便签儿上得到很多东西。
● 一组自动化测试每天都可以对整个的项目进行一次探测。一个手工测试的努力可能保持长久的时间来对所有的功能进行重复的测试。但是在做过不正确的修改之后自动化测试会很迅速的发现它。如果原先正常工作的部分现在被破坏了，首先的一个问题是“最后修改的代码是哪一部分？”调试一天内所做的修改是一件很没有必要的事情，那么使用自动化测试来查看修改的情况是一件很高兴的事情。
注意，真正有威胁性的调试是在处理于子系统之间的关系。如果产品很大，内容很繁琐很难进行调试，这样自动化测试会有很高的价值。对任务驱动的测试更是如此(尽管他的生命周期不是很长)。
● 在程序开发者做了一个修改后，测试人员要进行检查。可以包含原有测试的主要框架，再根据具体情况做相应变化。有时候交流很贫乏，测试人员不可能及时的被告知已经修改的地方。我们运气好，往往这样做的结果是自动化测试不会正常的继续进行，导致测试者开始注意修改的地方。自动化测试组越少，发生这种可能的机会越小。(我发现自动化测试是一个拐弯抹角的花费昂*的一个基本交流的替代品。)
● 因为施行自动化测试需要时间，所以你不可能像手工测试那样在出现bug的第一间告知开发人员。如果你的最终测试报告在两个星期后发布，而这段时间开发人员又在原先的基础上做了新的功能，这样就是一个问题。
● 我们要尽力避免只是因为实现自动化测试比较容易而不是考虑发现bug的能力来组织测试。你可能会发现你自己设计的测试太过简单，而已清醒的知道因为过于简单你的测试会在产品发生变化的时候被破坏。这样简单的测试也很少会发现support code下的bug。
● 假设产品改变了它的部分功能，导致自动化测试给出不真实错误报告。我们可以通过更改我们的测试来屏蔽掉这些虚假的报告，但同时我们的做法可能降低测试发现bug的能力。这样测试功能在无形之中是衰退了的。
● 一个好的自动化测试的测试类可以按照一定的顺序执行，并且可以每日改变之间的次序。这可能是从一套特征测试创造任务驱动测试的一个廉价的方法。这是Edward L. Peters当看完这篇文章的草稿后提醒我注意的地方。Noel Nyman指出，自动化测试在利用偶然性(测试过程的顺序和输入的数据)的方面比人要好。
● 在准备开始测试之前需要做好自动化测试的准备。那样的话，写测试脚本的时间就不会占用测试时间，就不需要在手工测试和它之间困难的选择。当这种产品准备测试时，你仍然应该考虑实际上使那些脚本工作的费用。
● 一次自动化的试验可能不会有任何发现直到下一版本出现之前。.手动测试将会发现一个版本中存在的任何bug。 在当前版本发现bug要比在下一个才发现版本bug有价值的多。(如果当前版本没有成功那么就不会有下一个版本。)
相关阅读：
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
