2.6 管理自动化测试
我们的测试过程在持续改进，并且我们为测试设计了一个可记录的生命周期，如图2-2所示。
测试被开发出来之后，会进行评审，如果审查通过，这个测试就会被包含到候选队列中（一个测试集合用来尝试是否应该包含到整个自动化套件中）。如果一个候选测试在一行中有4天都失败了，那么它会被提取出来重新进行开发。在测试本身没有任何失效一周之后，这个测试会设置为“有效”状态，并可以包含到每晚的或者每周的测试套件中。
图2-2 测试的生命周期
如果产品的功能改变了但是其测试没有更新，测试可以“挂起”。根据挂起的原因，测试将来可能会成为“有效”状态或者候选测试状态（故障的原因被修复之后）。
不同测试套件的内容会进行周期性分析。度量指标用来衡量运行这些特定测试的收益。根据这一过程的结果，一个测试可以从一个测试套件移到另一个测试套件（依据测试的运行频率），或者在某些情况下转移到“退出”状态。如果某一个测试可能不会再用到了，团队就会考虑删除它。
我们制定了很多度量标准，都使管理层非常满意，而且非常关注我们，并提高了团队的优先级。毫无疑问，相比于之前，他们对产品审批过程的信任有了大幅提升。
2.7 测试套件和类型
最后，我们用这个工具批准开发人员代码检入：在允许提交新的或者修改后的代码之前，他们必须在三个不同平台上运行一个最小的验收测试套件（Minimum Acceptance Test Suite, MATS）来测试其代码。通过实验，我们选择这些平台来发现特定的或者罕见的故障。这一步骤有利于在变更被引入源代码之前，减少回归测试和失效的数量。这些测试的运行时间被控制在最短时间内，所以这些测试是有用的，在时间上并没有成为影响进一步开发的障碍。
【真知灼见】
提供及时的反馈，并且将日常开支减少到最小，为开发人员提供最好的支持。
该工具用作夜间的回归测试，这样开发人员白天一上班就能获得关于他们代码变更的反馈信息。这个测试套件包括大部分运行时间稍短的回归测试，并运行在有限选择的平台上：一般是在3 ~ 5个平台，并且运行时间为将近12小时。
我们通常还在3个不同的平台上进行每周测试，每一个测试套件运行4 ~ 5天。
这些回归测试具有很高的优先级，并获得了管理层的大力支持。这里出现的故障必须尽快修复。
除了这些回归测试外，其他测试是在候选批次中运行的。这些测试，是对新版本中新功能或者已变更功能的典型测试，具有更低的优先级，因为它们往往是由负责的开发人员和测试开发人员进行监控的。候选批次也包括夜间和每周运行的批次。项目团队可以根据需要定义更适合自己团队需求的测试套件。
这些测试在我们的内部测试工具上运行，性能测试与它们并行运行，并且与基准线进行对比。由于它们对测试和结果的特殊需求，它们都有自己的框架。这些测试通常仅在一个平台上运行。 发布测试一般包含以上描述的所有类型的测试，但是在至多22个不同的平台上运行。如图2-3所示。
此外，发布测试还包括在测试工具上运行的其他非功能性测试，比如：
长时间测试：不同的场景下运行时间至少为10天的测试。
扩展性测试：通过增加硬件来减轻负荷的测试，一般采用24台服务器和12台客户机来运行测试。
图2-3 发布测试的内容
2.8 现状
该工具已经用于不同的数据库产品的测试当中，而且现在是一个开源工具，请参阅http: //kenai.com/projects/jet。
2.9 在经过一段很艰难的时光后才得到的经验教训
在过去的三四年里，我们遇到了无数的困难：
软件测试变得非常成熟，有时反而会使我们忽略一些最简单的测试。比如，我们往往测试了复杂的SQL查询语句，却忽略了对在用户组之外创建新用户这类简单操作的测试。事实上，这种语句是不允许出现的，因为可能会由于在用户组的权限设置中没有考虑到这种情况而导致重大的错误。
我们过于关注大规模的自动化测试中的变化，导致有些非功能性测试有时并未得到足够的重视。比如，用户可能会获得只有专业人员才能看懂的错误提示消息，软件产品中经常缺少帮助功能，这些都是软件设计和测试中存在的问题。
使用随机生成的输入数据来进行测试时，有时虽然发现了严重的缺陷，但是因为测试人员能力有限，不能再重新生成导致故障的数据，所以并不能对调试过程产生任何帮助。经常讨论上述这种测试，一般是从经济的角度：它们通常需要额外的资源来辅助进行分析，并且在大多数情况下，并不能通过它们找到产生bug的原因，因此，也不可能通过它们找到产生软件缺陷的根本原因。
对自动化投入的评估主要看ROI的效果。如果不在比较的过程中引入其他因素，很有可能得出错误的故障报告。比如，我们要仔细地对结果进行比较，考虑到地域因素，有时要先进行转换再进行比较等。例如，当你在比较一台位于挪威境内的PC上的日期和一台位于美国境内的PC上的日期的时候，不同的时间格式（挪威为“日/月”而美国境内为“月/日”）导致时间显示的结果也会不同。
有时候通过软件来模拟物理故障并不是很容易，并且要模拟这些故障在多台电脑上几乎同时发生也是很困难的。此外，通过软件来模拟的断电和断网情形与实际发生的断电和断网也可能并不一样。
有时候可能会发生结果误报问题，因为测试时，即便遇到一个或多个失效也可能报告正确的结果。对于那些长期使用都未出现过故障的测试用例，往往更容易忽略对其正确性的检查。但随着时间的流逝，这些测试可能会不断积累许多错误，因此在报告中要不定期地对其正确性进行检查。 如果一些优先级比较低的次要bug没有立即修复，那么它们可能会掩盖一些主要bug，而这些主要bug由于引入的时间太长，往往更难对其进行分析。
必须要插入和修改等待时间来保证在测试继续运行之前，前面的强制性过程已经完成了。用更新的硬件取代现有硬件通常意味着要对这一过程再一次进行同步。
【真知灼见】
预测可能会发生改变的事物，并使它们在必要的时候更容易改变（例如，保存同步时间的核心列表）。
在测试套件的某些部分中，期望结果模板用来与实际结果进行比较。由于这类模板需要大量的维护工作，因此我们试图将这些基于模板的测试改为基于断言的测试。
引入新的平台有时会产生一些问题，并需要大量的资源来解决这些问题。同时，对操作系统的监控力度也要加大。
对于基于Windows的测试，要关闭自动更新，并将更新放在等待队列中，在测试可以中断的那个时段之前，再运行这些更新。
我们要清楚正在运行测试的网络中所发生的一切。比如，每隔一个月午夜时候出现一些无法解释的故障，最后发现，故障是由前雇员的一台电脑上的夜间执行工作所导致的：这台电脑没有关闭，而是仍然非常活跃地向本地网络发送查询请求的垃圾邮件。
【小窍门】
回头看有些错误是非常显而易见的，但你如果没有想到，它们可能就会困扰你。
建议定期做探索性测试，你将会对所发现的问题感到非常惊奇，同时，有时候你还可以将这些经验用于新的自动化测试中。
2.10 如何使用自动化测试书中的建议
在开发自动化测试过程中，我们运用了《Software Test Automation》一书中许多有用的知识点：
在进行自动化测试工具开发之前，首先对工具进行需求分析并列出需求清单，我们对需求清单中的每一个需求进行讨论和评审，结果表明这是整个开发取得成功的坚实基础。在评审过程中，参与人员中有代表不同需求的关键人物：经理、IT运营商、发布工程师、测试经理、开发人员和测试人员。
测试自动化只是从以下几个方面来对测试进行自动化：测试的准备、执行、核对、清空、存档、生成报告和度量。而测试执行之前的过程，例如，测试用例的设计等，是没有进行自动化的。
我们得到了管理层的大力支持来实施这项自动化工作，并且他们有着切实的期望。
【真知灼见】
管理层的支持是至关重要的，但是他们的期望必须要符合实际。
如果没有来自不同领域的杰出专家，我们就不可能取得成功。整个实现过程和解决方案都很复杂并具有挑战性。
幸运的是，在大部分产品中都没有要求进行GUI测试，这使整个自动化过程不会显得很冗长。
数据库中的GUI测试属于可用性测试，识别这种测试类型使我们取得了很多重大的改进，并使可用性测试延期。到今天为止，可用性测试还没有完成，但是因为考虑到这点我们受益匪浅！
测试工具的大部分开发是集中在GUI部分的开发。然而，在后面，GUI几乎不会用到，因为所有的自动化都是通过命令行界面进行的。我们前期之所以会集中精力进行GUI的开发，可能是因为我们大脑中还存在进行手动测试的定势思维。 【小窍门】
工具中良好的用户界面可能在自动化项目的前期最有用。
经过本次自动化项目的实践，测试人员也学会了别的技术并在他们感兴趣的领域变得更加专业。有些测试人员更精通测试开发，有些则在测试的执行和生成报告方面更精通。
只有心中牢记不断取得进步这一目标，才能让我们大步前进。通过小组讨论来分析现有问题以及如何对其进行自动化，最终就会找到解决方案。
让所有的测试人员参加国际软件测试认证委员会（International Software Testiing Qualifications Board， ISTQB）的基础认证课程，这样有助于术语的统一使用和理解，从而有助于增进测试人员间的交流。
有时候项目中人员数量突然减少从某种程度上也可以促进自动化过程——使用更少人力资源的需求变得更为突出。
能详细地向整个项目中的其他成员介绍每一步是怎么实施的，很有用，因为相比于将它们整合到产品之后再进行测试，显然单个部分的测试更容易执行。
【真知灼见】
在走向成功时，步子要快，但也要稳。
通过自动化进行的测试是整个项目的核心过程，无论什么时候出现了故障，它们都会尽力地报告给整个部门的每个人。这可能会对开发产生负面影响，因为看到这些失效之后，开发人员在修改代码时会格外小心，虽然这种格外留心有助于提高产品质量，但他们可能要为此花费过多的精力和时间。对于软件产品来说，对于“怎样的质量才算足够好”是没有明确定义的，这可能会导致在开发中投入过多的精力。这仅仅只是我个人毫无根据的假设，并没有事实能证明这一观点，但是开发人员太关注质量这在软件行业里是不寻常的！
2.11 总结
刚开始的时候数据库产品和测试的质量都很差，但是在自动化测试开始之前都得到了显著提高。
接着开始了自动化测试工具的开发过程。首先，成立一个包含信息传递人员、专家和利益相关者的团队，进行需求定义。然后，用最专业的人员完成了开发，自动化测试也逐步实施，在这一过程中，每个参与人员都起到了非常重要的作用：工具开发人员、促变者、管理层、工具管理人员以及整个实施团队。
早期我们达到了开发这个工具的第一目标，然后随着时间的推移，完成了越来越多的目标。我们的效率至少提高了2400倍，并为公司开发了一款非常好的工具。在实施小的修复或者增强功能的时候，需要的维护工作量非常少，这也为我们的成功帮了不少忙。我们的硬件资源都达到了最合理的使用：大部分机器除了短暂的休息以外，都是24小时/天，7天/周地工作。
对我们来说，这就是最终的自动化测试。
2.12 致谢
首先，要感谢Yngve Svendsen和 J?rgen Austvik在我写这篇案例研究时提供了非常有用的建议和反馈信息。此外，还要感谢所有为这个项目的成功而努力的人们，尤其是William Franklin，感谢他对我们自动化测试的大力支持和鼓励。同时，也要感谢本书的两位作者，感谢他们给了我公布这个案例研究故事的机会。
（未完待续...）
相关链接：
自动化测试最佳实践 连载一
自动化测试最佳实践 连载二
自动化测试最佳实践 连载三
自动化测试最佳实践 连载四
自动化测试最佳实践 连载五