l 最让人恶心的是在手工测试中找到了bug，但是没有办法再现。可能你做了些什么，可是根本没有记住是怎么做的。自动化测试很少会出现这样的情况（尽管有时候你没有注意到它们依*了已经变化了的环境）。产品中的跟踪和日志可以给我们很大的帮助，这些对开发人员是非常有用的。如果这些东西不存在，自动化测试的工具可以用来创造类似日志的文档记录键盘和鼠标的操作信息。这种日志的使用价值以来它的可读性是怎么样的，在程序内部产生的日志文档是非常好的。根据我所见到的，大部分的测试人员可以在用来做记录的便签儿上得到很多东西。
l 一组自动化测试每天都可以对整个的项目进行一次探测。一个手工测试的努力可能保持长久的时间来对所有的功能进行重复的测试。但是在做过不正确的修改之后自动化测试会很迅速的发现它。如果原先正常工作的部分现在被破坏了，首先的一个问题是“最后修改的代码是哪一部分？”调试一天内所做的修改是一件很没有必要的事情，那么使用自动化测试来查看修改的情况是一件很高兴的事情。
注意，真正有威胁性的调试是在处理于子系统之间的关系。如果产品很大，内容很繁琐很难进行调试，这样自动化测试会有很高的价值。对任务驱动的测试更是如此（尽管他的生命周期不是很长）。
l 在程序开发者做了一个修改后，测试人员要进行检查。可以包含原有测试的主要框架，再根据具体情况做相应变化。有时候交流很贫乏，测试人员不可能及时的被告知已经修改的地方。我们运气好，往往这样做的结果是自动化测试不会正常的继续进行，导致测试者开始注意修改的地方。自动化测试组越少，发生这种可能的机会越小。（我发现自动化测试是一个拐弯抹角的花费昂*的一个基本交流的替代品。）
l 因为施行自动化测试需要时间，所以你不可能像手工测试那样在出现bug的第一间告知开发人员。如果你的最终测试报告在两个星期后发布，而这段时间开发人员又在原先的基础上做了新的功能，这样就是一个问题。
l 我们要尽力避免只是因为实现自动化测试比较容易而不是考虑发现bug的能力来组织测试。你可能会发现你自己设计的测试太过简单，而已清醒的知道因为过于简单你的测试会在产品发生变化的时候被破坏。这样简单的测试也很少会发现support code下的bug。
l 假设产品改变了它的部分功能，导致自动化测试给出不真实错误报告。我们可以通过更改我们的测试来屏蔽掉这些虚假的报告，但同时我们的做法可能降低测试发现bug的能力。这样测试功能在无形之中是衰退了的。
l 一个好的自动化测试的测试类可以按照一定的顺序执行，并且可以每日改变之间的次序。这可能是从一套特征测试创造任务驱动测试的一个廉价的方法。这是Edward L. Peters当看完这篇文章的草稿后提醒我注意的地方。Noel Nyman指出，自动化测试在利用偶然性（测试过程的顺序和输入的数据）的方面比人要好。
l 在准备开始测试之前需要做好自动化测试的准备。那样的话，写测试脚本的时间就不会占用测试时间，就不需要在手工测试和它之间困难的选择。当这种产品准备测试时，你仍然应该考虑实际上使那些脚本工作的费用。
l 一次自动化的试验可能不会有任何发现直到下一版本出现之前。.手动测试将会发现一个版本中存在的任何bug。 在当前版本发现bug要比在下一个才发现版本bug有价值的多。（如果当前版本没有成功那么就不会有下一个版本。）
相关信息请点击:http://bbs.51testing.com/thread-534-1-1.html
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
