2.9　在经过一段很艰难的时光后才得到的经验教训
在过去的三四年里，我们遇到了无数的困难：
软件测试变得非常成熟，有时反而会使我们忽略一些最简单的测试。比如，我们往往测试了复杂的SQL查询语句，却忽略了对在用户组之外创建新用户这类简单操作的测试。事实上，这种语句是不允许出现的，因为可能会由于在用户组的权限设置中没有考虑到这种情况而导致重大的错误。
我们过于关注大规模的自动化测试中的变化，导致有些非功能性测试有时并未得到足够的重视。比如，用户可能会获得只有专业人员才能看懂的错误提示消息，软件产品中经常缺少帮助功能，这些都是软件设计和测试中存在的问题。
使用随机生成的输入数据来进行测试时，有时虽然发现了严重的缺陷，但是因为测试人员能力有限，不能再重新生成导致故障的数据，所以并不能对调试过程产生任何帮助。经常讨论上述这种测试，一般是从经济的角度：它们通常需要额外的资源来辅助进行分析，并且在大多数情况下，并不能通过它们找到产生bug的原因，因此，也不可能通过它们找到产生软件缺陷的根本原因。
对自动化投入的评估主要看ROI的效果。如果不在比较的过程中引入其他因素，很有可能得出错误的故障报告。比如，我们要仔细地对结果进行比较，考虑到地域因素，有时要先进行转换再进行比较等。例如，当你在比较一台位于挪威境内的PC上的日期和一台位于美国境内的PC上的日期的时候，不同的时间格式（挪威为“日/月”而美国境内为“月/日”）导致时间显示的结果也会不同。
有时候通过软件来模拟物理故障并不是很容易，并且要模拟这些故障在多台电脑上几乎同时发生也是很困难的。此外，通过软件来模拟的断电和断网情形与实际发生的断电和断网也可能并不一样。
有时候可能会发生结果误报问题，因为测试时，即便遇到一个或多个失效也可能报告正确的结果。对于那些长期使用都未出现过故障的测试用例，往往更容易忽略对其正确性的检查。但随着时间的流逝，这些测试可能会不断积累许多错误，因此在报告中要不定期地对其正确性进行检查。
如果一些优先级比较低的次要bug没有立即修复，那么它们可能会掩盖一些主要bug，而这些主要bug由于引入的时间太长，往往更难对其进行分析。
必须要插入和修改等待时间来保证在测试继续运行之前，前面的强制性过程已经完成了。用更新的硬件取代现有硬件通常意味着要对这一过程再一次进行同步。
【真知灼见】
预测可能会发生改变的事物，并使它们在必要的时候更容易改变（例如，保存同步时间的核心列表）。
在测试套件的某些部分中，期望结果模板用来与实际结果进行比较。由于这类模板需要大量的维护工作，因此我们试图将这些基于模板的测试改为基于断言的测试。
引入新的平台有时会产生一些问题，并需要大量的资源来解决这些问题。同时，对操作系统的监控力度也要加大。
对于基于Windows的测试，要关闭自动更新，并将更新放在等待队列中，在测试可以中断的那个时段之前，再运行这些更新。
我们要清楚正在运行测试的网络中所发生的一切。比如，每隔一个月午夜时候出现一些无法解释的故障，最后发现，故障是由前雇员的一台电脑上的夜间执行工作所导致的：这台电脑没有关闭，而是仍然非常活跃地向本地网络发送查询请求的垃圾邮件。
【小窍门】
回头看有些错误是非常显而易见的，但你如果没有想到，它们可能就会困扰你。
建议定期做探索性测试，你将会对所发现的问题感到非常惊奇，同时，有时候你还可以将这些经验用于新的自动化测试中。