1. 软件测试基础

1.1.什么是测试

1.1.1. 典型的测试目标

• 通过评估工作产品以防止缺陷，例如需求、用户故事、设计和代码
• 建立对被测对象质量级别的信心
• 发现缺陷和失效，从而降低软件质量不足的风险

根据被测组件或系统的环境、测试级别和软件开发生存周期模型的不同，测试目标会有所变化。

不同包括：

 在组件测试时，尽可能多的发现失效，以便尽早识别和修复潜在的缺陷可能是其一个目标。

而另一个目标可能是增加组件测试时的代码覆盖率。

 在验收测试时，确认系统能够按照预期工作并且满足用户需求可能是其一个目标。而另一

个测试目标可能是为利益相关方提供关于在给定时间发布系统的风险信息。

1.1.2. 测试与调试

测试和调试是两个不同的概念。执行测试可以发现由于软件缺陷引起的失效。而调试是发现、

分析和修复这些缺陷的开发活动。随后的确认测试检查修复活动是否解决了缺陷。有的时候，测试

员负责开始及最终的确认测试，而开发人员则负责调试、相关组件和组件的集成测试（持续集成）。

然而，在敏捷开发和其他的一些软件开发生存周期中，测试员也可能会参与调试和组件测试。

1.2.为什么需要测试？

1.2.1. 测试对成功的贡献

• 让测试员参与需求评审或用户故事细化，可以发现这些工作产品中的缺陷。识别和修复需 求缺陷可以减少被开发（功能）特征的不正确或不可测试的风险。
• 在系统设计过程中，让测试员与系统设计人员密切合作，可以提高各方对设计和如何测试
• 的理解。理解的增加可以降低基本设计缺陷的风险，并使测试能够尽早介入。
• 在开发代码过程中，让测试员与开发人员密切合作，可以提高各方对代码以及如何测试的
• 理解。理解的增加可以降低代码和测试中出现缺陷的风险。
• 让测试员在发布之前对软件进行验证和确认，可能发现之前遗漏的失效，并帮助修复导致

失效的缺陷(即调试)。这样就增加了软件满足利益相关方需求的可能性。

1.2.2. 质量保证和测试

除其他活动外，质量管理还包括质量保证和质量控制。质量保证的关注点在于遵循正确的过程，

为产品能够达到合适的质量级别提供信心。当过程正确开展时，这些过程所创造的工作产品通常具

有更高的质量，这也有助于缺陷的预防。另外，使用根本原因分析方法来发现缺陷并消除引起缺陷

的原因，以及适当应用回顾性会议的结论来改进过程，对于有效的质量保证都也很重要。

质量控制涉及各种支持达到适当质量级别的活动，包括测试活动。测试活动是整个软件开发或

维护过程的一部分。因为质量保证涉及到整个过程的正确执行，质量保证会支持正确的测试活动。

测试在以各种方式帮助实现质量的提高

1.2.3. 错误、缺陷和失效

所有人都会犯错误(mistake)，这样就会导致在软件代码或者其他相关工作产品中引入缺陷

(fault 或 bug)。在一个工作产品中引入的缺陷就可能会导致其他相关工作产品都引入缺陷。例如，

需求引发的错误就可能导致需求缺陷，需求缺陷就会导致编程错误，这样代码中就存在缺陷。

如果执行了存在缺陷的代码，就可能导致失效，但不一定在所有情况下都是这样。例如，有些

缺陷需要非常特殊的输入或先决条件才能触发失效，这种失效可能很少发生，也可能永远不会发生。

发生错误的原因有很多种，例如：

 时间压力

 人本身容易犯错

 缺乏经验或技能不足的项目参与者

 项目参与者之间沟通有误，包括需求和设计之间的沟通误解。

 代码、设计、架构的复杂度，待解决的潜在问题，和/或使用的技术

 对系统内和系统间接口的误解，特别是当系统内和系统间的交互数量比较多的时候

 新的不熟悉的技术

除了代码中的缺陷导致的失效之外，环境条件也可能导致失效。例如：辐射、电磁场和污染等

都有可能引起固件中的失效，或者由于硬件环境的改变而影响软件的执行。

但并非所有意外的测试结果都属于失效。由于测试执行方式的错误，或者由于测试数据、测试

环境或其他测试件中的缺陷，又或者由于其他的原因，可能会出现假阳性结果（误报）。相反的情况 也有可能发生，即相似的错误或缺陷会导致假阴性结果（缺陷的漏报）。假阴性结果指的是没有发现测试应该要发现的缺陷；假阳性结果记录为缺陷，但实际上并不是缺陷。

1.2.4. 缺陷、根本原因和影响

缺陷的根本原因是导致缺陷产生的最早的行为或条件。

1.3.七项测试的基本原则

原则 1 测试说明缺陷的存在，而不能说明缺陷不存在

测试可以证明存在缺陷，但不能证明不存在缺陷。测试降低了软件中存在未发现缺陷的可能性，

但即使没有发现缺陷，测试也无法证明其对象的正确性。

原则 2 穷尽测试是不可能的

进行穷尽测试（输入和前提条件的所有组合）是不可行的，除非是小型的案例。应利用风险分

析、测试技术和优先级确定测试工作量，而不是试图进行穷尽测试。

原则 3 测试的尽早介入可以节省时间和成本

为了尽早发现缺陷，应该在软件开发生存周期中尽早启动静态和动态测试活动。测试的尽早介

入有时被称为测试的左移。在软件开发生存周期的早期进行测试有助于减少或消除代价高昂的变更

原则 4 缺陷的群集效应

通常在少数模块中包含了大部分在发布前测试中发现的缺陷，或者是造成大部分运行失效的原

因。预测的缺陷集群和在测试或操作中实际观察到的缺陷集群，应该作为风险分析的重要输入，并

用来集中测试工作量。

原则 5 杀虫剂悖论

如果多次重复同样的测试，最终这些测试将不再能够发现任何新的缺陷。为了发现新的缺陷，

可能需要更改现有的测试用例和测试数据，并且可能需要编写新的测试。（测试不再能有效发现缺陷，

就像杀虫剂在一段时间后对杀死昆虫不再有效一样）。但是在某些情况下，杀虫剂悖论也有好处，例

如在自动化回归测试中，发现的回归缺陷数量相对较少。

原则 6 测试活动依赖于测试周境

测试在不同周境下是不同的。比如，安全关键工业控制软件的测试不同于电子商务移动应用。

另一个例子，在敏捷项目中进行的测试不同于在顺序软件开发生存周期项目中进行的测试

原则 7 不存在缺陷的谬论

有些组织期望测试员能够运行所有可能的测试并发现所有可能的缺陷，但是原则 2 和原则 1 分

别告诉了我们这是不可能的。另外，期望仅仅发现并修复大量缺陷就能确保系统的成功，这是一个

谬论（即错误的信念）。例如，穷尽测试所有指定的需求并修复发现的所有缺陷，仍然可能会生产出一个难以使用，或无法满足用户需求和期望，或与其他竞争产品相比更差的系统。

1.4.测试过程

1.4.1. 周境中的测试过程

1.4.2. 测试活动和测试任务

测试计划

测试计划包括的活动有定义测试目标以及在周境因素限制下达到测试目标的方法(例如，指定适

合的测试技术和适当的测试任务，并制定满足截止期限的测试进度表)。根据测试监督与控制活动的反馈，可以重新审议测试计划。测试计划会在第 5.2 节中进一步讲述。

测试监督与控制

测试监督包括使用测试计划中定义的测试监督度量，对实际进度与计划的进展进行持续的比较。

测试控制包括采取必要的措施来满足测试计划的目标(目标可能会随时间的变化有所更新)。测试监

督与控制是通过评估出口准则来支持的，出口准则在一些软件开发生存周期模型中被称为“完成的

定义”（参见 ISTQB-CTFL-AT）。例如，作为给定测试级别的一部分，对测试执行的出口准则评估可能包括:

 根据指定的覆盖准则检查测试结果和日志。

 根据测试结果和日志评估组件或系统的质量级别。

 确定是否需要做更多的测试(例如，如果原本旨在达某个级别的产品风险覆盖率的测试失

败了，则需要编写和执行额外的测试)

在测试进度报告中向利益相关方通报测试进度，包括偏离计划的情况和帮助决定结束测试的信

息。测试监督与控制将在第 5.3 节中进一步讲述

测试分析

在测试分析过程中，分析测试依据以识别可测试特征和定义相关的测试条件。换句话说，测试

分析根据可测量的覆盖标准来确定“测试什么”。

测试分析主要包括以下活动:

• 分析所考虑测试级别的测试依据，例如：

 需求规格说明，如业务需求、功能需求、系统需求、用户故事、史诗、用例或类似

的工作产品，其中指定了所需的功能和非功能的组件或系统行为

设计和实现信息，如系统或软件架构图或文档、设计规格说明、调用流图、模型图

(例如 UML 或实体关系图 ERD)、接口规格说明或类似的工作产品，其中指定了组件

或系统的结构

 组件或系统本身的实现，包括代码、数据库元数据和查询以及接口

 风险分析报告，其考虑了组件或系统的功能、非功能及结构问题

• 评估测试依据和测试项，以识别各种类型的缺陷，例如:

 歧义

 遗漏

 不一致

 不准确

 矛盾

测试设计

在测试设计时，将测试条件细化成概要测试用例、概要测试用例集和其他测试件。因此，测试

分析回答了“测试什么？”的问题，而测试设计是回答了“如何测试？”的问题。

测试设计包括以下的主要活动:

 设计测试用例和测试用例集，并确定其优先级

 识别所需的测试数据以支持测试条件和测试用例

 设计测试环境并识别所需的基础设施和工具

 撷取测试依据、测试条件和测试用例之间的双向追溯性(参见第 1.4.4 节

测试实施

在测试实施期间，创建和/或完成测试执行所需的测试件，包括将测试用例排序为测试规程。所

以，测试设计回答了“如何测试”的问题，而测试实施则回答了“我们现在是否已经有了运行测试

所需的一切条件?”

测试实施包括以下主要活动:

 开发并确定测试规程的优先级，如有可能，并创建自动化测试脚本

 根据测试规程和(如果有的话)自动测试脚本来创建测试套件。

 在测试执行进度表中，以促进有效测试执行的方式安排测试套件(参见第 5.2.4 节)

 构建测试环境(包括可能的，测试工具、服务虚拟化、模拟器和其他基础设施项目)，并验

证一切所需都已正确设置

在探索性测试和其他基于经验的测试类型中，测试设计和实施可能作为测试执行的一部分得到

执行和记录。探索性测试可以基于测试章程(作为测试分析工作产品的一部分)，在探索性测试时直

接进行设计和实施(参见第 4.4.2 节)。

测试执行

在测试执行期间，测试套件按照测试执行进度表运行。

测试执行包括以下主要活动:

 记录测试项或测试对象、测试工具及测试件的 ID 和版本

 手工或者使用测试执行工具执行测试

 将实际结果与预期结果进行比较

 分析异常现象以确定它们可能发生的原因(例如，出现失效可能是由于代码中的缺陷，但也

可能出现假阳性结果（误报）(参见第 1.2.3 节))

 根据实际观察到的失效报告缺陷(参见第 5.6 节)

 记录测试执行的结果(例如通过、失败、阻塞)

 作为对异常现象采取行动的结果，或作为计划要测试的一部分(例如，执行修正后的测试、

确认测试和/或回归测试)，重复测试活动

 确认并更新测试依据、测试条件、测试用例、测试规程和测试结果之间的双向可追溯性

测试结束

测试结束活动从已完成的测试活动中收集数据，以强化经验、测试件，以及任何其他相关信息。

测试结束活动出现在项目里程碑点，例如：当软件系统发布时、当测试项目完成（或取消）时、当敏捷项目的迭代完成时、当测试级别完成时，或当维护版本完成时。

测试结束包括以下主要活动：

 检查是否所有的缺陷报告已关闭，为测试执行结束时仍未解决的缺陷，是否已创建需求变

更或产品待办事项

 创建测试总结报告，并将信息传达给利益相关方

 最后确定并归档测试环境、测试数据、测试基础设施及其他相关测试件，以便以后重复使

用

 将测试件移交给维护部门、其他项目团队和/或其他可以从使用测试件中获益的利益相关

方

 从已完成的测试活动中，分析所获得的经验教训来确定以后迭代、版本和项目所需的变更

 使用收集到的信息来改进测试过程的成熟度

1.4.3. 测试依据和测试工作产品之间的可追溯性

如第 1.4.3 节描述的，测试工作产品以及这些工作产品的名称差别很大。无论差异如何，为了

实施有效的测试监督与控制，如上所述，在测试依据的每个元素和与该元素相关联的各种测试工作

产品之间建立和维护整个测试过程的可追溯性是很重要的。除了评估测试的覆盖率外，良好的可追

溯性支持：

• 分析变更的影响
• 测试的可审计
• 符合 IT 管理标准
• 提高测试进度报告和测试总结报告的易理解性，包括测试依据中元素的状态。（例如通过测

        试的需求、未通过测试的需求以及有待完成测试的需求）

• 将测试的技术方面与利益相关方关联起来，使利益相关方能够理解
• 根据业务目标，提供评估产品质量、过程能力和项目进展的相关信息

若本文有帮助到阅读本文的同学，欢迎点赞、关注、收藏，互相学习交流。