如果一些优先级比较低的次要bug没有立即修复，那么它们可能会掩盖一些主要bug，而这些主要bug由于引入的时间太长，往往更难对其进行分析。

　　必须要插入和修改等待时间来保证在测试继续运行之前，前面的强制性过程已经完成了。用更新的硬件取代现有硬件通常意味着要对这一过程再一次进行同步。

　　【真知灼见】

　　预测可能会发生改变的事物，并使它们在必要的时候更容易改变（例如，保存同步时间的核心列表）。

　　在测试套件的某些部分中，期望结果模板用来与实际结果进行比较。由于这类模板需要大量的维护工作，因此我们试图将这些基于模板的测试改为基于断言的测试。

　　引入新的平台有时会产生一些问题，并需要大量的资源来解决这些问题。同时，对操作系统的监控力度也要加大。

　　对于基于Windows的测试，要关闭自动更新，并将更新放在等待队列中，在测试可以中断的那个时段之前，再运行这些更新。

　　我们要清楚正在运行测试的网络中所发生的一切。比如，每隔一个月午夜时候出现一些无法解释的故障，最后发现，故障是由前雇员的一台电脑上的夜间执行工作所导致的：这台电脑没有关闭，而是仍然非常活跃地向本地网络发送查询请求的垃圾邮件。

　　【小窍门】

　　回头看有些错误是非常显而易见的，但你如果没有想到，它们可能就会困扰你。

　　建议定期做探索性测试，你将会对所发现的问题感到非常惊奇，同时，有时候你还可以将这些经验用于新的自动化测试中。

　　2.10　如何使用自动化测试书中的建议

　　在开发自动化测试过程中，我们运用了《Software Test Automation》一书中许多有用的知识点：

　　在进行自动化测试工具开发之前，首先对工具进行需求分析并列出需求清单，我们对需求清单中的每一个需求进行讨论和评审，结果表明这是整个开发取得成功的坚实基础。在评审过程中，参与人员中有代表不同需求的关键人物：经理、IT运营商、发布工程师、测试经理、开发人员和测试人员。

　　测试自动化只是从以下几个方面来对测试进行自动化：测试的准备、执行、核对、清空、存档、生成报告和度量。而测试执行之前的过程，例如，测试用例的设计等，是没有进行自动化的。

　　我们得到了管理层的大力支持来实施这项自动化工作，并且他们有着切实的期望。

　　【真知灼见】

　　管理层的支持是至关重要的，但是他们的期望必须要符合实际。

　　如果没有来自不同领域的杰出专家，我们就不可能取得成功。整个实现过程和解决方案都很复杂并具有挑战性。

　　幸运的是，在大部分产品中都没有要求进行GUI测试，这使整个自动化过程不会显得很冗长。

　　数据库中的GUI测试属于可用性测试，识别这种测试类型使我们取得了很多重大的改进，并使可用性测试延期。到今天为止，可用性测试还没有完成，但是因为考虑到这点我们受益匪浅！

　　测试工具的大部分开发是集中在GUI部分的开发。然而，在后面，GUI几乎不会用到，因为所有的自动化都是通过命令行界面进行的。我们前期之所以会集中精力进行GUI的开发，可能是因为我们大脑中还存在进行手动测试的定势思维。