2.4 开发内部测试工具
该内部测试工具的基本功能是由3 ~ 4位开发人员在6 ~ 9个月的时间内开发出来的，是用Java语言编写的。第一个版本开发之后，一个人专门负责对其进行维护和进一步的开发，显然维护和进一步开发的工作量是逐步减少的。
图2-1是测试的Java引擎（Java Engine for Testing, JET）架构的一个概览。每个大的矩形都是一台运行某些软件的计算机。
我们在图2-1中的运行机（runner）处开始运行一组测试集合。它使用JETBatch来开始运行测试并收集运行结果。客户端（client）运行与JETBatch进行交互的Jet代理程序（JET Agent，JAG），即使用JAG来启动JET运行单个测试。这些JET读入一个XML文档，该文档会给JET提供测试运行的内容，并与服务器的JAG进行交互来启动我们需要测试的软件。整套系统还包括一个测试装置，通过使用不同的机器操作不同的任务，避免了架构本身的资源消耗对被测任务的影响。
因为我们确实投入了大量的时间和精力来设计自动化测试，所以几乎实现了所有的目标（只有性能测试是由我们的另一款内部开发工具完成的，这不在本案例研究的讨论范畴）。几乎所有的测试都是通过我们的工具自动运行的，其中只有几个测试，我们认为自动化的价值并不是很大，是由手动完成的。最后，我们有了一款可以在很多不同领域使用的、功能非常强大的工具。
图2-1 测试工具的架构（出自 http://kenai.com/projects/jet）
2.4.1 配置
测试配置：我们的测试是定义在一个数据库中的，并且可以单选、成组选择或者根据特定序列来进行选择。工具在每次测试之前都会进行一次初始化，避免前面的测试结果影响到后续的测试，工具在每次测试之后也会将测试环境清理干净。工具还自动将测试件进行收集和归档。
【小窍门】
把实施预处理和后续处理作为启动一个测试套件的一部分。
测试时应用程序的配置：可以对产品版本进行选择，包括调试版本和来自开发人员“沙箱”（sandbox）的本地版本。
服务器和客户端平台的配置：我们使平台的定义和在运行测试的平台组的定义变得简单。根据测试装置在一个平台组（例如，Windows Vista，64位，JDK 6）里面是否可用而将其划分成不同的测试装置。我们可以用一到两个平台为服务器设置一个单独的配置，通常也可以用一个平台为客户端设置一个单独的配置。对于客户端和服务器来说，都可以选择不同的操作系统。
一个标准的测试需要4台机器：一台测试机器，一台客户机，两台包含被测数据库的服务器。
2.4.2 资源优化
通过添加更多的机器到测试装置池中，我们可以并行地运行测试。另外，测试具有排队机制：一个测试装置上的测试完成之后，候选队列里面的下一个测试就开始运行。
2.4.3 测试报告
这个内部工具创建了网站来记录测试报告，所有的结果在一个数据库中也进行了详细存档，这有利于我们建立详细的度量，比如下面的度量：
1）在哪些平台上会有一些什么样的bug及其出现的频率（可以帮助指定bug的优先级）。
2）每个平台上的一般信息统计。
3）测试中bug的检出率。
4）测试的冗余。
一个测试完成之后，会自动发送一个包含测试结果的汇总邮件，同时生成一个XML文件，它包含了用以导入到其他数据库或者报表生成器的所有必要信息。
该工具也使得从开源测试覆盖工具（EMMA）中导入信息变得更容易，而且让我们能观察到测试的质量——至少从表面上看是这样的。
2.4.4 故障分析
在测试失效分析达到60% ~ 80%正确率之后，才能对失效进行自动识别。比如，通过定义描述故障的模式和标记来进行识别，在大多数情况下，我们定义一些模式或者签名对故障进行描述，这些模式或者签名通常与测试产生的错误信息、测试名称和产生这条实效信息的测试语句直接相关。一个bug可能有多个标记，如果要对新的故障或者已知故障的新症状进一步进行人工分析，就需要新的标记信息。
用这个新工具实施的某产品的首次发布测试中，要求不论何种原因，无论是产品原因或者是测试原因，至少75%的测试运行的时候不会出现故障。最后，要求至少96%的测试运行的时候不会出现故障。
