ISTQB认证测试工程师学习笔记（6）——测试工具

测试工具的考虑

测试工具可以用于支持一种或多种测试活动。这些工具一般包括：
1）直接用于测试的工具，比如测试执行工具，测试数据准备工具等；
2）用于协助管理需求、测试用例、测试规程、自动化测试脚本、测试结果、测试数据和缺陷等的工具，以及用于报告和监督测试进度的工具，比如禅道等缺陷管理和配置管理工具
3）用于分析和评估的工具，比如静态分析工具
4）任何对测试有帮助的工具（比如电子表格）

测试工具分类

依据具体情况具体分析，测试工具可以有以下目的：
1）对于可自动重复执行的任务，或是手动执行需要消耗大量人工或时间的任务（例如测试执行时的遍历操作等），可以使用测试工具改进测试效率；
2）在整个测试活动中，通过支持手动测试活动来实现提高测试效率；
3）通过更多的测试一致性和更高缺陷重现性，实现改进测试质量；
4）自动化无法通过手动执行的测试（比如大规模性能压力测试）；
5）增加测试的可靠性。

有些工具只能支持或主要支持一种活动；有些工具可以支持多种活动，在这种情况下将它们分类到联系最紧密的那一类活动中。同一家供应商的测试工具，尤其是那些为了协同工作而设计的测试工具，可能会被集成到一个套件中。
某些类型的测试工具本身是植入式的，这意味着测试的实际结果可能会受到影响。比如，由于使用性能测试工具执行了额外的指令，可能导致实际的响应时间的不同；或者使用覆盖工具可能得到了不正确的代码覆盖率。使用植入式工具导致的结果也称为探测影响（探针效应）。

支持测试和测试件管理的工具
管理工具适用于整个软件开发生存周期中的所有测试活动。
支持测试和测试件管理的工具举例如下：
 测试管理工具和应用生存周期管理工具（ALM）  需求管理工具（例如：与测试对象的可追溯性）
 缺陷管理工具
 配置管理工具
 持续集成工具（D）

支持静态测试的工具
静态测试工具与第 3 章描述的活动与收益相关。工具举例如下：

静态分析工具(D)
支持测试设计和实施的工具
测试设计工具旨在帮助测试设计和实施时生成可用的工作产品，包括测试用例、测试规程和测试数据。
工具举例如下：
 基于模型的测试工具
 测试数据准备工具
有时候，支持测试设计和实施的工具，也会支持测试执行和日志记录，或直接输出到其它支持测试执行和日志记录的工具。

支持测试执行和日志记录的工具
许多工具可以支持和提高测试执行和日志记录活动。工具举例如下：
 测试执行工具（例如：执行回归测试）
 覆盖工具（例如：需求覆盖、代码覆盖(D)）
 测试用具(D)

支持性能测量和动态分析的工具
性能测量和动态分析工具对于支持性能和负载测试活动是必不可少的，因为这些活动无法有效地通过手工方式来完成。
工具举例如下：
 性能测试工具
 动态分析工具(D)

支持专业测试要求的工具
除了支持一般测试过程的工具外，还有许多用于支持对非功能特性的专业测试工具。

测试自动化的收益和风险

仅仅购买工具并不能保证测试自动化的成功。要让引入组织的新工具能获得真正持续的成效还需要大量投入。测试中使用工具具有潜在的收益和机会，但是同样存在风险。这对测试执行工具（通常用作测试自动化）来说尤其正确。

使用工具支持测试执行的潜在收益包括：
 减少重复性的手工工作来节省时间（比如，执行回归测试、环境设置/拆除、重新输入相同
测试数据，和代码规则检查）
 更好的一致性和可重复性（比如，测试数据按照一致的方式产生，用工具按照相同的顺序和频率执行测试，以及始终从需求出发进行测试）
 更客观的评估（比如，静态测量、覆盖）
 更容易得到测试的相关信息（比如，关于测试进展、缺陷发生率和性能的统计和图表）

使用工具支持测试的潜在风险：
 对工具抱有不切实际的期望（包括功能性和易用性）
 低估首次引入工具所需的时间、成本和工作量（包括培训和额外的专业知识）
 低估从工具中获得较大和持续收益所需付出的时间和工作量（包括测试过程所需的变更和使用工具方法的持续改进）
 低估对工具生成的测试工作产品进行维护所需的工作量
 对工具过分依赖（替代测试设计或执行，或者对一些更适合手工测试的方面却使用自动测试工具）
 忽视对测试工作产品的版本控制
 忽视多个重要工具之间的关联和互操作性问题，例如：需求管理工具、配置管理工具、缺陷管理工具，和其他从不同供应商获得的工具
 工具供应商破产、停止维护工具或将工具卖给其他供应商的风险
 供应商对工具的支持、升级和缺陷修复支持不力
 开源工具项目中止的风险
 工具可能不再支持新平台或新技术的风险
 工具所有权可能不清晰而带来的风险（例如：指导、升级等）

测试执行和测试管理工具的特殊考虑

为了顺利和成功实施，在选择测试执行以及测试管理工具和将它们集成到组织内时，应考虑到许多方面。

测试执行工具
测试执行工具使用自动化的测试脚本执行测试对象。为了获得可观收益，经常需要为这类工具投入很多工作量。
1）捕获测试方法：通过记录（捕获）测试工程师的手动操作而生成的测试脚本，看起来似乎很吸引人，但是这种方法不适合大量的测试脚本。捕获的脚本只是一种线性表达，脚本内包含特定数据和操作。当发生意外事件时，这类脚本可能会很不稳定，并且需要随着系统用户界面的不断发展而需要不断进行维护。
2）数据驱动测试方法：这种测试方法是将测试输入和期望结果与脚本分离，通常可以存放在一个电子表格中，这样可以使用更通用测试脚本读取输入数据，从而用不同的数据执行相同的测试脚本。
3）关键字驱动测试方法：在这种测试方法中，通用脚本处理描述系统要执行操作的关键字（也称为行为字），然后调用这些关键字脚本来处理相关联的测试数据。

上面这些测试方法都需要有脚本语言方面的专业技术人员（测试工程师、开发人员或测试自动化专家）。当使用数据驱动或关键字驱动的测试方法时，不熟悉脚本语言的测试工程师也可以为这些预定义脚本创建测试数据和/或关键字。无论使用什么脚本技术，都需要比较每次测试的预期结果和实际结果，可以是动态的（测试执行时）或者先存储，然后在后期（测试执行结束后）进行比较。

测试管理工具
由于不同的原因，测试管理工具通常需要与其他工具或电子表格程序有接口，例如：
 以便生成符合组织所需格式的有用信息
 为了维护需求管理工具中针对需求的一致可追溯性
 为了链接到配置管理工具中测试对象版本信息
当使用集成工具时（例如：应用生存周期管理），由于包含组织中其他团队使用的测试管理模块以及其他模块（例如：项目进度和预算信息），需要特别认真的考虑。

工具的有效使用

工具选择的主要原则

为组织选择工具所需要考虑的关键点有：
 评估自己组织的成熟度和优缺点
 识别引入工具能改进测试过程的机会
 了解测试对象所使用的技术，以便选择与此技术相适合的工具
 了解组织内已使用的构建和持续集成工具，以便确保工具的兼容与集成
 根据明确的需求和客观的准则对工具进行评估
 考虑工具是否提供免费试用期（以及多长时间）
 评估供应商（包括培训、提供的支持及其他商业方面考量），或非商业性工具（例如：开源）的支持
 针对工具使用的指导和培训，识别内部需求
 评估培训需求时，需要考虑工作中将直接使用工具的人员的测试（以及测试自动化）技能
 考虑各种许可证模式的优缺点（例如：商业或开源）
 根据实际的情况估算成本-收益比（如果需要的话）
作为最后一步，应进行可行性研究（概念验证），以确定该工具是否在所测试的软件和当前基础设施内有效运行，或在必要时确定为有效使用该工具而需要对该基础设施进行的修改。

组织引入工具的试点项目

完成工具选择和成功进行可行性研究（概念验证）后，将选择的工具引入组织通常从试点项目开始，试点项目有以下目的：
 深入了解工具有关的知识，了解工具的优缺点
 评估工具与现有过程以及实践的配合程度，确定哪些方面需要作修改
 定义一套标准的方法来使用、管理、储存和维护工具及测试工作产品（比如，定义文件和测试的命名规则，选择编码标准，创建库和定义模块化测试套件）
 评估在付出合理的成本后能否得到预期的收益
 理解工具应该收集和报告的度量，并对工具进行配置，以保证度量的获取和报告

工具的成功因素

在组织内成功地评估、实施、部署和持续支持工具的因素包括：
 逐步在组织的其余部分推广工具
 调整并改进过程来配合工具的使用
 为工具使用者提供培训、辅导和指导
 定义工具使用指南（例如：自动化的内部标准）
 实施一种在实际使用中收集工具使用信息的方法
 监督工具的使用和收益
 为测试团队使用工具提供支持
 在所有团队内收集经验和教训
同样重要的是保证工具在技术上和组织上集成到软件开发生存周期中，同时包括独立负责操作的组织和/或第三方供应商。