6.1 测试工具的考虑

测试工具可以用来支持一个或多个测试活动。这些工具包括：
• 直接用于测试的工具，如测试执行工具和测试数据准备工具
• 有助于管理需求、测试用例、测试规程、自动化测试脚本、测试结果、测试数据和缺陷的工具，以及用于报告和监视测试执行情况的工具
• 用于调查和评价的工具
• 任何有助于测试的工具（这个意义上电子表格也是测试工具）
6.1.1 测试工具分类
测试工具可以根据上下文有以下一个或多个目的：
• 将重复的任务或者手动测试需要大量资源的任务进行自动化以提高测试活动的效率(例如：测试执行、回归测试)
• 在整个测试过程中支持手工测试活动，以提高测试活动的效率(见第1.4节)
• 通过更加一致的测试和更高的缺陷重现级别来提高测试活动的质量
• 自动化无法手工执行的活动(例如：大规模性能测试)
• 提高测试的可靠性（例如：通过自动进行大规模数据比较或模拟的行为）
可以根据目的、价格定价、许可证发放模式(例如商业来源或开放来源)和所使用的技术等若干标准对工具进行分类。在本大纲中，工具根据其支持的测试活动进行分类。
有些工具明确只支持或主要支持一项活动；另一些工具可能支持多项活动，但被归类为与其联系最密切的活动。单一供应商提供的工具，特别是那些被设计成可以一起工作的工具，可以作为一个集成套件提供。
某些类型的测试工具可能具有干预性，这意味着它们可能影响测试的实际结果。例如：应用程序的实际响应时间可能因性能测试工具执行的额外指令而不同，或者由于使用覆盖工具而导致代码覆盖的数量可能被扭曲。使用干预性工具的后果称为探针效应。
一些工具提供的支持通常更适合开发人员（例如：在组件和集成测试期间使用的工具）。这些工具在以下各节中以"(D)"进行标识。
测试和测试件管理的工具支持
管理工具可适用于整个软件开发生命周期中的任何测试活动。支持测试和测试件管理的工具的例子包括：
• 测试管理工具和应用生命周期管理工具（ALM）
• 需求管理工具（例如：测试对象的可追溯性）
• 缺陷管理工具
• 配置管理工具
• 持续集成工具(D)
静态测试的工具支持
静态测试工具与第3章中描述的活动和收益相关联。这类工具的例子包括：
• 支持评审的工具
• 静态分析工具(D)
测试设计与实现的工具支持
测试设计工具有助于在测试设计和实现中创建可维护的工作产品，包括测试用例、测试规程和测试数据。这类工具的例子包括：
• 测试设计工具
• 基于模型的测试工具
• 测试数据准备工具
• 验收测试驱动开发（ATDD）和行为驱动开发（BDD）工具
• 测试驱动开发工具(TDD)（D）
在某些情况下，支持测试设计和实现的工具也可能支持测试执行和日志记录，或者将其输出直接提供给支持测试执行和日志记录的其他工具。
测试执行与记录的工具支持
有许多工具可以支持和增强测试执行和日志记录活动。这些工具的例子包括：
• 测试执行工具（例如：运行回归测试）
• 覆盖工具(如需求覆盖、代码覆盖(D))
• 测试用具(D)
• 单元测试框架工具(D)
性能测量和动态分析的工具支持
性能测量和动态分析工具对于支持性能和负载测试活动是必不可少的，因为这些活动不能有效地通过手工完成。这些工具的例子包括：
• 性能测试工具
• 监视工具
• 动态分析工具(D)
特殊测试需要的工具支持
除了支持一般测试过程的工具外，还有许多其他工具支持更具体的测试事件。其中包括侧重于以下方面的工具：
• 数据质量评估
• 数据转换和迁移
• 易用性测试
• 辅助性测试
• 本地化测试
• 安全性测试
• 可移植性测试（例如：在多个支持的平台上测试软件）
6.1.2 测试自动化的收益与风险
仅仅获得工具并不能保证成功。每个组织引入新工具都需要投入工作量以实现真正和持久的收益。测试中使用工具有潜在的收益和机会，但也存在风险。这对于测试执行工具（通常称为测试自动化）尤其如此。
使用工具支持测试执行的潜在收益包括：
• 减少重复的手工工作（例如：运行回归测试、环境安装/拆除任务、重新输入相同的测试数据和检查编程规范），从而节省时间
• 更好的一致性和可重复性(例如：以一致的方式创建测试数据，通过工具以相同频率相同顺序执行测试，使用一致的方式从需求中获得测试)
• 更客观的评估(例如：静态测量、覆盖率)
• 更容易获得有关测试的信息（例如：关于测试进度、缺陷率和性能的统计数字和图表）
使用工具支持测试的潜在风险包括：
• 对工具不切实际的期望(包括功能性和易用性)
• 低估初次引入工具的时间、成本和工作量(包括培训和外部专业知识)
• 低估从该工具获得重大和持续收益所需的时间和工作量(包括需要的测试过程的改变和该工具使用方式的不断改进)
• 低估维护该工具生成的测试资产所需的工作量
• 过分依赖工具（被看作测试设计或执行的替代，或在使用人工测试更好的情况下切使用自动测试）
• 忽视测试资产的版本控制
• 忽视关键工具之间的关系和互操作性问题，例如需求管理工具、配置管理工具、缺陷管理工具和来自多个供应商的工具
• 工具供应商可能倒闭、工具退役或将工具卖给其他供应商
• 供应商不能及时提供对支持、升级和缺陷修复的响应
• 开源项目暂停
• 工具不支持新平台或新技术
• 该工具可能没有明确的责任人(例如：指导、更新等)
6.1.3 测试执行与测试管理工具的特殊考虑
为了顺利和成功地实现，在选择和集成测试执行和测试管理工具到组织中时，有许多事情需要考虑。
测试执行工具
测试执行工具使用自动化测试脚本执行测试对象。这类工具往往需要付出巨大的工作量，才能取得显著的收益。
通过记录手动测试人员的动作来捕获测试似乎很有吸引力，但是这种方法无法应用到大量测试脚本的情况。捕获的脚本是作为每个脚本一部分的带有特定数据和动作的线性表示。当不可预料的事件发生时，这种类型的脚本是不稳定的。最新一代的工具利用了"智能"图像捕捉技术，增强了这类工具的效用，尽管生成的脚本仍然需要随着系统用户界面的发展不断进行维护。
数据驱动的测试方法将测试输入和预期结果分离出来，通常放入电子表格中，并使用更通用的测试脚本，通过读取输入数据并使用不同的数据执行相同的测试脚本。不熟悉脚本语言的测试人员可以为这些预先定义的脚本创建新的测试数据。
在关键字驱动的测试方法中，通用脚本处理描述要采取的动作的关键字（也称为动作词），然后调用关键字脚本处理相关的测试数据。测试人员（即使他们不熟悉脚本语言）可以使用关键字和相关数据定义测试，这些关键字和相关数据可以根据正在测试的应用程序进行裁剪。数据驱动和关键字驱动的测试方法的进一步细节和例子，可以参考ISTQB-TAE高级测试自动化工程师大纲，Fewster1999和Buwalda2001。
上述方法需要有人具备脚本语言的专门知识（测试人员、开发人员或测试自动化方面的专家）。无论使用何种脚本技术，每个测试的预期结果都需要与测试的实际结果进行比较，或者是动态的（在测试运行时），或者是存储供以后（执行后）比较。
基于模型的测试（MBT）工具能够以模型的形式捕获功能规格说明，例如活动图。此任务通常由系统设计人员执行。MBT工具解释模型以创建测试用例规格说明，然后保存在测试管理工具中和/或通过测试执行工具执行（见ISTQB-MBT基础级别基于模型的测试大纲）。
测试管理工具
测试管理工具经常由于各种原因需要与其他工具或电子表格相互交互，包括：
• 以适合本组织要求的格式提供有用的信息
• 对需求管理工具中的需求保持一致的可追溯性
• 在配置管理工具中与测试对象版本信息链接
这一点在使用综合工具（如应用生命周期管理）时尤其重要，该工具包括测试管理模块（可能还有缺陷管理系统），以及其他模块（如项目时间进度和预算信息），它们会在同一个组织内的不同团体中使用。