【最全】ISTQB- FL大纲（含重点）

软件系统是生活中不可或缺的一部分，包括从商业应用（比如银行系统）到消费产品（比如汽车）的各个领域。然而，很多人都有过这样的经历：软件并没有按照预期进行工作。不能正常工作的软件会导致许多问题，包括资金、时间和商业声誉的损失，甚至是伤害或死亡。软件测试是评估软件质量和降低软件运行中出现失效风险的一种方法。

对测试的常见误解是，它只包含了运行测试，即执行软件和检查结果。如第 1.4 节所述，软件测试是一个包含了许多不同活动的过程；测试执行(包括检查结果)只是这些活动之一。测试过程还包括诸如测试计划、测试分析、测试设计、测试实施、报告测试进度和结果，以及评估测试对象的质量等活动。

有些测试确实涉及到被测组件或系统的执行，这种测试称为动态测试。不涉及运行被测组件或系统的测试，称为静态测试。所以，测试还包括评审工作产品，例如需求、用户故事和源代码。

另一个关于测试的常见误解是，它完全关注于需求、用户故事或其他规格说明的验证。虽然测试确实涉及检查系统是否满足指定的需求，但它也包含确认，即检查系统在其运行的环境中是否满足用户和其他利益相关方的需求。

测试活动在不同的生存周期中的组织和实施是不同的(参见第 2.1 节)

1.1.1. 典型的测试目标

对于给定的任何项目，其测试目标可以包括：

通过评估工作产品以防止缺陷，例如需求、用户故事、设计和代码
验证是否实现了所有指定的需求
检查测试对象是否完成，并确认是否按照用户和其他利益相关方期望那样工作
建立对被测对象质量级别的信心
发现缺陷和失效，从而降低软件质量不足的风险
为利益相关方提供足够的信息以允许他们做出明智的决策，特别是关于测试对象的质量级别
遵守合同、法律或法规要求或标准，和/或验证测试对象是否符合这些要求或标准

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

在组件测试时，尽可能多的发现失效，以便尽早识别和修复潜在的缺陷可能是其一个目标。而另一个目标可能是增加组件测试时的代码覆盖率。
在验收测试时，确认系统能够按照预期工作并且满足用户需求可能是其一个目标。而另一个测试目标可能是为利益相关方提供关于在给定时间发布系统的风险信息。

1.1.2. 测试与调试

测试和调试是两个不同的概念。执行测试可以发现由于软件缺陷引起的失效。而调试是发现、分析和修复这些缺陷的开发活动。随后的确认测试检查修复活动是否解决了缺陷。有的时候，测试员负责开始及最终的确认测试，而开发人员则负责调试、相关组件和组件的集成测试（持续集成）。然而，在敏捷开发和其他的一些软件开发生存周期中，测试员也可能会参与调试和组件测试。

1.2.为什么需要测试？

对组件和系统及其相关文档进行严格的测试，有助于降低软件运行过程中出现失效的风险。当发现缺陷并随后加以修复时，这有助于提高组件或系统的质量。此外，还可能需要进行软件测试，以满足合同或法律法规或行业具体标准的要求。

1.2.1. 测试对成功的贡献

纵观计算机的历史，软件和系统的交付使用是很常见的，但是由于缺陷的存在，随后就会导致软件和系统的失效，或者没有满足利益相关方的需求。然而，使用适当的测试技术可以减少这种有问题交付的频率，只要这些技术是在适当的测试技能水平、适当的测试级别和软件开发生存周期的适当点上得到应用。例如:

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

除了这些例子之外，达到已定义测试目标(参见第 1.1.1 节)有助于整个软件开发和维护的成功。

1.2.2. 质量保证和测试

人们经常使用“质量保证”(或 QA)来代指测试，虽然它们是有关联的，但是质量保证和测试是不一样的。可以用更大的概念把它们联系在一起，质量管理。质量管理包括所有指导和控制组织质量的活动。

除其他活动外，质量管理还包括质量保证和质量控制。质量保证的关注点在于遵循正确的过程，为产品能够达到合适的质量级别提供信心。当过程正确开展时，这些过程所创造的工作产品通常具有更高的质量，这也有助于缺陷的预防。另外，使用根本原因分析方法来发现缺陷并消除引起缺陷的原因，以及适当应用回顾性会议的结论来改进过程，对于有效的质量保证都也很重要。

质量控制涉及各种支持达到适当质量级别的活动，包括测试活动。测试活动是整个软件开发或维护过程的一部分。因为质量保证涉及到整个过程的正确执行，质量保证会支持正确的测试活动。如第 1.1.1 节和 1.2.1 节所述，测试在以各种方式帮助实现质量的提高。

1.2.3. 错误、缺陷和失效

所有人都会犯错误(mistake)，这样就会导致在软件代码或者其他相关工作产品中引入缺陷 (fault 或 bug)。在一个工作产品中引入的缺陷就可能会导致其他相关工作产品都引入缺陷。例如，需求引发的错误就可能导致需求缺陷，需求缺陷就会导致编程错误，这样代码中就存在缺陷。

如果执行了存在缺陷的代码，就可能导致失效，但不一定在所有情况下都是这样。例如，有些缺陷需要非常特殊的输入或先决条件才能触发失效，这种失效可能很少发生，也可能永远不会发生。

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

时间压力
人本身容易犯错
缺乏经验或技能不足的项目参与者
项目参与者之间沟通有误，包括需求和设计之间的沟通误解
代码、设计、架构的复杂度，待解决的潜在问题，和/或使用的技术
对系统内和系统间接口的误解，特别是当系统内和系统间的交互数量比较多的时候
新的不熟悉的技术

除了代码中的缺陷导致的失效之外，环境条件也可能导致失效。例如：辐射、电磁场和污染等都有可能引起固件中的失效，或者由于硬件环境的改变而影响软件的执行。

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

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

缺陷的根本原因是导致缺陷产生的最早的行为或条件。可以分析缺陷并找出其根本原因，以减少类似的缺陷以后再发生。通过将关注点放在最重要的根本原因，根本原因的分析可以促进过程的改进，从而防止将来引入大量的缺陷。

例如，假设由于一行不正确的代码，支付了错误的利息，导致了客户投诉。由于产品负责人对如何计算利息有误解，所以为模糊的用户故事编写了有缺陷的代码。如果在利息计算中存在很大比例的缺陷，并且引发这些缺陷的根本原因来源于类似的误解，那么需要为产品负责人进行利息计算相关主题的培训，以便在未来减少这类缺陷。

在这个例子中，客户投诉的是缺陷导致的影响。支付错误的利息属于失效。代码中的错误计算属于缺陷，它是由模糊的用户故事中的原始缺陷造成的。原始缺陷产生的根本原因是产品负责人知识的缺乏，导致产品负责人在编写用户故事时犯了错误。在 ISTQB-CTEL-TM 和 ISTQB-CTEL-ITP 大纲中讨论了根本原因分析过程。

1.3.七项测试的基本原则

过去 50 年来，人们提出了一些测试原则，并为所有测试提供了通用的指南。

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

测试可以证明存在缺陷，但不能证明不存在缺陷。测试降低了软件中存在未发现缺陷的可能性，但即使没有发现缺陷，测试也无法证明其对象的正确性。

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

进行穷尽测试（输入和前提条件的所有组合）是不可行的，除非是小型的案例。应利用风险分析、测试技术和优先级确定测试工作量，而不是试图进行穷尽测试。

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

为了尽早发现缺陷，应该在软件开发生存周期中尽早启动静态和动态测试活动。测试的尽早介入有时被称为测试的左移。在软件开发生存周期的早期进行测试有助于减少或消除代价高昂的变更（参见第 3.1 节）。

原则 4 缺陷的群集效应

通常在少数模块中包含了大部分在发布前测试中发现的缺陷，或者是造成大部分运行失效的原因。预测的缺陷集群和在测试或操作中实际观察到的缺陷集群，应该作为风险分析的重要输入，并用来集中测试工作量（如原则 2 所述）。

原则 5 杀虫剂悖论

如果多次重复同样的测试，最终这些测试将不再能够发现任何新的缺陷。为了发现新的缺陷，可能需要更改现有的测试用例和测试数据，并且可能需要编写新的测试。（测试不再能有效发现缺陷，就像杀虫剂在一段时间后对杀死昆虫不再有效一样）。但是在某些情况下，杀虫剂悖论也有好处，例如在自动化回归测试中，发现的回归缺陷数量相对较少。

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

测试在不同周境下是不同的。比如，安全关键工业控制软件的测试不同于电子商务移动应用。另一个例子，在敏捷项目中进行的测试不同于在顺序软件开发生存周期项目中进行的测试（见第 2.1 节）。

原则 7 不存在缺陷的谬论

有些组织期望测试员能够运行所有可能的测试并发现所有可能的缺陷，但是原则 2 和原则 1 分别告诉了我们这是不可能的。另外，期望仅仅发现并修复大量缺陷就能确保系统的成功，这是一个谬论（即错误的信念）。例如，穷尽测试所有指定的需求并修复发现的所有缺陷，仍然可能会生产出一个难以使用，或无法满足用户需求和期望，或与其他竞争产品相比更差的系统。

更多测试原则的实例及其他测试原则，请参见 Myers 2011, Kaner 2002，Weinberg 2008，和 Beizer 1990。

1.4.测试过程

尽管没有统一的软件测试过程，但是有一些常见的测试活动，如果没有这些测试活动就不太可能实现既定的目标。这些测试活动就组成了一个测试过程。在任何给定的情况下，适当的、特定的软件测试过程取决于很多因素。

测试过程中涉及哪些测试活动，如何实施这些测试活动，以及何时开始这些测试活动，都可以在组织的测试策略中进行讨论。

1.4.1. 周境中的测试过程

影响组织测试过程的周境因素包括，但不仅限于以下：

使用的软件开发生存周期模型及项目所使用方法
考虑的测试级别和测试类型
产品风险和项目风险
业务领域
运行限制，包括但不仅限于：预算和资源、时间、复杂度、合同和法规要求
组织方针和实践
所需的内部和外部标准

后面章节就以下几点描述了组织中测试过程的通用方面：

测试活动和测试任务
测试工作产品
测试依据和测试工作产品之间的可追溯性

如果测试依据（对于正在考虑的任何测试级别或类型）具有可度量的覆盖标准，那是非常有用的。覆盖标准可以有效地作为关键绩效指标(KPIs)，推动显示软件测试目标实现的活动(参见第 1.1.1 节) 例如，对于移动应用程序，测试依据可能包括需求列表和支持的移动设备列表。

每个需求都是测试依据的一个元素。覆盖标准可能要求测试依据的每个元素至少有一个测试用例。执行测试时，这些测试的结果将告诉利益相关方是否实现了指定的需求，以及是否在受支持的设备上观察到了失效。

有关于测试过程的更多信息参见 ISO 标准(ISO/IEC/IEEE 29119-2)。

1.4.2. 测试活动和测试任务

测试过程主要由以下主要的活动组所组成：

测试计划
测试监督与控制
测试分析
测试设计
测试实施
测试执行
测试结束

每个活动组都是由多个活动构成，具体内容将在下面的小节中加以说明。每个组成的活动都可能由多个单独的任务组成，这些任务可能因项目或版本发布而不同。

此外，虽然这些主要活动组中的许多活动在逻辑上看起来是有顺序的，但它们通常是迭代实现的。例如，敏捷开发涉及到软件设计、构建和测试的小迭代，这些迭代都是在持续计划的支持下连续进行的。所以，在这种软件开发的方法中，测试活动也是在迭代的、持续的基础上进行。即使在顺序软件开发中，主要活动的阶梯式逻辑顺序也会涉及重叠、组合、并发或省略，所以必须根据系统和项目的周境因素裁剪这些主要活动。

测试计划

测试计划包括的活动有定义测试目标以及在周境因素限制下达到测试目标的方法(例如，指定适合的测试技术和适当的测试任务，并制定满足截止期限的测试进度表)。根据测试监督与控制活动的反馈，可以重新审议测试计划。测试计划会在第 5.2 节中进一步讲述。

测试监督与控制

测试监督包括使用测试计划中定义的测试监督度量，对实际进度与计划的进展进行持续的比较。测试控制包括采取必要的措施来满足测试计划的目标(目标可能会随时间的变化有所更新)。测试监督与控制是通过评估出口准则来支持的，出口准则在一些软件开发生存周期模型中被称为“完成的定义”（参见 ISTQB-CTFL-AT）。例如，作为给定测试级别的一部分，对测试执行的出口准则评估可能包括:

根据指定的覆盖准则检查测试结果和日志。
根据测试结果和日志评估组件或系统的质量级别。
确定是否需要做更多的测试(例如，如果原本旨在达某个级别的产品风险覆盖率的测试败了，则需要编写和执行额外的测试)

在测试进度报告中向利益相关方通报测试进度，包括偏离计划的情况和帮助决定结束测试的信息。测试监督与控制将在第 5.3 节中进一步讲述。

测试分析

在测试分析过程中，分析测试依据以识别可测试特征和定义相关的测试条件。换句话说，测试分析根据可测量的覆盖标准来确定“测试什么”。

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

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

需求规格说明，如业务需求、功能需求、系统需求、用户故事、史诗、用例或类似的工作产品，其中指定了所需的功能和非功能的组件或系统行为
设计和实现信息，如系统或软件架构图或文档、设计规格说明、调用流图、模型图 (例如 UML 或实体关系图 ERD)、接口规格说明或类似的工作产品，其中指定了组件或系统的结构
组件或系统本身的实现，包括代码、数据库元数据和查询以及接口
风险分析报告，其考虑了组件或系统的功能、非功能及结构问题

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

歧义
遗漏
不一致
不准确
矛盾
多余的表述

识别被测特征和特征集
根据对测试依据的分析，并考虑到功能、非功能和结构特征、其他业务和技术因素以及风险级别，界定每个特征的测试条件并确定其优先次序
在测试依据的每个元素与相关测试条件之间获取双向可追溯性(参见第1.4.3节和第1.4.4 节)

在测试分析过程中，使用黑盒测试技术、白盒测试技术、基于经验的测试技术(参见第 4 章)，可以减少遗漏重要测试条件的可能性，并且能更精确和准确的定义测试条件。

在某些情况下，测试分析得到的测试条件，这些条件将作为测试章程中的测试目标。在某些基于经验的测试中，测试章程是典型的工作产品(参见第 4.4.2 节)。当这些测试目标可以追溯到测试依据时，就可以测量基于经验的测试中实现的覆盖率。

在测试分析过程中识别缺陷是一个重要的潜在收益，特别是在没有使用其他评审过程和/或测试过程与评审过程之间间隔很短的情况下。这样的测试分析活动不仅要验证需求是否一致、是否表达正确以及是否完整，还需验证需求是否正确满足客户、用户和其他利益相关方的需求。例如，行为驱动开发(BDD)和验收测试驱动开发(ATDD)等技术，它们都需要在编码之前，从用户故事和验收标准中生成测试条件和测试用例，这些技术同样要在用户故事和验收标准中验证、确认和发现缺陷(参见 ISTQB-CTFL-AT)。

测试设计

在测试设计时，将测试条件细化成概要测试用例、概要测试用例集和其他测试件。因此，测试分析回答了“测试什么？”的问题，而测试设计是回答了“如何测试？”的问题。

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

设计测试用例和测试用例集，并确定其优先级
识别所需的测试数据以支持测试条件和测试用例
设计测试环境并识别所需的基础设施和工具
撷取测试依据、测试条件和测试用例之间的双向追溯性(参见第 1.4.4 节)

在测试设计过程中，将测试条件细化为测试用例和测试用例集，常常会涉及到使用测试技术(参见第 4 章)。

与测试分析一样，测试设计也可能在测试依据中识别出相似类型的缺陷。与测试分析一样，测试设计过程中识别出缺陷也是其重要的潜在效益。

测试实施

在测试实施期间，创建和/或完成测试执行所需的测试件，包括将测试用例排序为测试规程。所以，测试设计回答了“如何测试”的问题，而测试实施则回答了“我们现在是否已经有了运行测试所需的一切条件?”

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

开发并确定测试规程的优先级，如有可能，并创建自动化测试脚本
根据测试规程和(如果有的话)自动测试脚本来创建测试套件。
在测试执行进度表中，以促进有效测试执行的方式安排测试套件(参见第 5.2.4 节)
构建测试环境(包括可能的，测试工具、服务虚拟化、模拟器和其他基础设施项目)，并验证一切所需都已正确设置
准备测试数据并确保在测试环境中正确地加载
确认并更新测试依据、测试条件、测试用例、测试规程和测试套件之间的双向可追溯性(参见第 1.4.4 节)

测试设计和测试实施任务通常是结合在一起的。

在探索性测试和其他基于经验的测试类型中，测试设计和实施可能作为测试执行的一部分得到执行和记录。探索性测试可以基于测试章程(作为测试分析工作产品的一部分)，在探索性测试时直接进行设计和实施(参见第 4.4.2 节)。

测试执行

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

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

记录测试项或测试对象、测试工具及测试件的 ID 和版本
手工或者使用测试执行工具执行测试
将实际结果与预期结果进行比较
分析异常现象以确定它们可能发生的原因(例如，出现失效可能是由于代码中的缺陷，但也可能出现假阳性结果（误报）(参见第 1.2.3 节))
根据实际观察到的失效报告缺陷(参见第 5.6 节)
记录测试执行的结果(例如通过、失败、阻塞)
作为对异常现象采取行动的结果，或作为计划要测试的一部分(例如，执行修正后的测试、确认测试和/或回归测试)，重复测试活动
确认并更新测试依据、测试条件、测试用例、测试规程和测试结果之间的双向可追溯性

测试结束

测试结束活动从已完成的测试活动中收集数据，以强化经验、测试件，以及任何其他相关信息。测试结束活动出现在项目里程碑点，例如：当软件系统发布时、当测试项目完成（或取消）时、当敏捷项目的迭代完成时、当测试级别完成时，或当维护版本完成时。

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

检查是否所有的缺陷报告已关闭，为测试执行结束时仍未解决的缺陷，是否已创建需求变更或产品待办事项
创建测试总结报告，并将信息传达给利益相关方
最后确定并归档测试环境、测试数据、测试基础设施及其他相关测试件，以便以后重复使用
将测试件移交给维护部门、其他项目团队和/或其他可以从使用测试件中获益的利益相关方
从已完成的测试活动中，分析所获得的经验教训来确定以后迭代、版本和项目所需的变更
使用收集到的信息来改进测试过程的成熟度

1.4.3. 测试工作产品

测试工作产品作为测试过程中的一部分被创建。正如不同的组织在实施测试过程的方式时存在明显差异一样，在测试过程中创建的工作产品的类型也存在明显差异，这些工作产品的组织和管理方式，以及这些工作产品的名称也都存在明显差异。本大纲遵循上述测试过程以及本大纲和 ISTQB® 术语表中描述的工作产品。ISO 标准(ISO/IEC/IEEE 29119-3)也可以作为测试工作产品的指南。

本节所描述的很多测试工作产品都是可以使用测试管理工具和缺陷管理工具来获取和管理的 (参见第 6 章)。

测试计划工作产品

测试计划的工作产品通常包括一个或多个测试计划。测试计划包括关于测试依据与其他测试工作产品之间可追溯性的相关信息(参见下面内容及第 1.4.4 节)，以及测试监督与控制期间使用的出口标准(或“完成的定义”)。测试计划描述参见第 5.2 节。

测试监督与控制工作产品

测试监督与控制的工作产品通常包括各种类型的测试报告，包括测试进度报告(持续和/或定期生成的)和测试总结报告(在各种已结束里程碑上生成的)。所有的测试报告都应该提供在截止日期前与测试受众相关的细节，包括一旦获得测试执行结果后的总结。

测试监督与控制的工作产品还应该解决项目管理所关心的问题，例如任务完成度、资源的分配和使用，以及工作量。

测试监督与控制，及在这些活动中创建的工作产品，将会在本课程大纲第 5.3 节做进一步解释。

测试分析工作产品

测试分析工作产品包括已定义的和按优先级排序的测试条件，理想情况下每一个测试条件都可以双向追溯到它所覆盖的测试依据的特定元素。对于探索性测试，测试分析可能涉及到创建测试章程。测试分析还可能发现和报告在测试依据上的缺陷。

测试设计工作产品

测试设计生成测试用例和测试用例集，以覆盖测试分析中定义的测试条件。通常设计概要测试用例是一种很好的做法，概要测试用例里没有具体的输入数据和预期结果的值。这样的概要测试用例可以在使用不同具体数据的多个测试周期中重复使用，同时仍能够充分记录测试用例的范围。理想情况下，每个测试用例都可以双向追溯到其覆盖的测试条件。

测试设计的工作产品包括：

设计和/或识别必要的测试数据
设计测试环境
识别基础设施和工具

记录的这些结果的范围差别会很大。

测试实施工作产品

测试实施工作产品包括:

测试规程以及这些测试规程的顺序
测试套件
测试执行进度表

理想情况下，一旦测试实施活动完成，就可以基于测试用例和测试条件，通过测试规程和测试依据的特定元素之间的双向可追溯性，来证明测试计划中确定的覆盖率准则是否实现。

在某些情况下，测试实施涉及使用工具创建工作产品，例如服务虚拟化和自动化测试脚本。

测试实施还可能需要创建和验证测试数据和测试环境。数据和/或环境验证结果的文档完整性可能会有很大差异。测试数据为测试用例的输入和预期结果指定具体的值。这些具体的值，以及使用具体值的明确指示，将概要测试用例转换为可执行的详细测试用例。当在测试对象的不同版本上执行时，相同的概要测试用例可能使用不同的测试数据。使用测试结果参照物来识别与具体的测试数据相关的明确的预期结果。

在探索性测试中，可以在测试执行的过程中创建某些测试设计和测试实施的工作产品，尽管探索性测试文档化的范围(以及它们对测试依据中的特定元素的可追溯性)可能会差异很大。

测试分析中定义的测试条件可以在测试实施中进一步细化。

测试执行工作产品

测试执行工作产品包括:

记录各单个测试用例或测试规程状态的文档(例如准备运行、通过、失败、阻塞、故意跳过等)
缺陷报告(参见第 5.6 节)
测试过程中包含测试项、测试对象、测试工具及测试件的文档

理想情况下，一旦完成了测试执行，可以通过与测试规程相关的双向可追溯性来确定和报告测试依据中每个元素的状态。例如，我们可以说哪些需求通过了所有计划的测试，哪些需求的测试失败了，和/或有与该需求相关的缺陷，以及哪些需求的测试已经计划好了但在等待运行。这样就可以验证是否满足了覆盖标准，以及确认利益相关方是否可以理解这些测试结果报告。

测试结束工作产品

测试结束的工作产品包括测试总结报告、改进后续项目或迭代的行动项、变更请求或产品待办事项，以及最终的测试件。

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

如第 1.4.3 节描述的，测试工作产品以及这些工作产品的名称差别很大。无论差异如何，为了实施有效的测试监督与控制，如上所述，在测试依据的每个元素和与该元素相关联的各种测试工作产品之间建立和维护整个测试过程的可追溯性是很重要的。除了评估测试的覆盖率外，良好的可追溯性支持：

分析变更的影响
测试的可审计
符合 IT 管理标准
提高测试进度报告和测试总结报告的易理解性，包括测试依据中元素的状态。（例如通过测试的需求、未通过测试的需求以及有待完成测试的需求）
将测试的技术方面与利益相关方关联起来，使利益相关方能够理解
根据业务目标，提供评估产品质量、过程能力和项目进展的相关信息

某些测试管理工具提供了与本节中描述的部分或全部测试工作产品相匹配的测试工作产品模型。有些组织建立了自己的管理系统来管理工作产品，并提供他们所需的可追溯性信息。

1.5.测试心理学

软件开发，包括软件测试，都涉及到人的参与。因此，人的心理对软件测试有着重要的影响。

1.5.1. 心理学和测试

不论是在静态测试时识别缺陷，例如需求评审或用户故事细化，又或者是在动态测试执行时识别失效，都可能会被看作是对产品及其作者的批评。人类心理学中有个叫做“确认偏见”的原理，会让人难以接受与目前所持有的信仰相悖的信息。例如，由于开发人员希望他们的代码是正确的，但是他们存在确认偏见，这使得他们很难接受代码是错误的。除了确认偏见之外，其他的认知偏见都可能使得人们难以理解或接受测试产生的信息。而且，指责坏消息的传递者是人类的共同特征，而测试产生的信息往往包含了坏消息。

虽然测试对项目进展和产品质量有很大的贡献(参见第 1.1 节和第 1.2 节)，但是由于这些心理因素，还是会有人认为测试是一种破坏性的活动。为了减少这些观念所带来的影响，应该以建设性的方式去沟通关于缺陷和失效的相关信息。这样就可以缓解测试员和分析人员、产品负责人、设计人员和开发人员之间的紧张关系。这同时适用于静态测试和动态测试。

测试员和测试经理需要有良好的沟通技巧，才能够有效地沟通缺陷、失效、测试结果、测试进度和风险，并与同事建立积极的关系。良好沟通方式的例子包括：

从合作而不是争斗的方式开始项目。提醒项目的每位成员，大家的共同目标是追求更高质量的系统。
强调测试的好处。例如，对于作者而言，缺陷信息可以帮助他们改进他们的工作产品和他们的技能。对于组织而言，测试过程中发现并修复缺陷可以节省时间和金钱，并降低产品质量的总体风险。
以中性的、以事实为中心的方式去沟通测试结果和其他发现，而不要去指责引入该缺陷项的人员。编写客观且实际的缺陷报告和评审发现的问题。
尽量理解其他成员的感受，以及他们为什么对信息反应消极的原因。
确认其他成员已经理解了你的描述，反之亦然。

前面讨论了典型的测试目标(参见第 1.1 节)。清楚地定义正确的测试目标具有重要的心理暗示作用。大多数人倾向于将他们的计划和行动与团队、管理人员和其他利益相关方设定的目标保持一致。同样重要的是，测试员要以最低限度的个人偏见去坚持这些目标。

1.5.2. 测试和开发的思维方式

开发人员和测试员通常有不同的想法。开发的主要目标是设计并构建一个产品。如前文所述，测试的目标包括验证和确认产品，在发布之前发现缺陷等。因为这些不同的目标，就需要不同的思维方式。将这些不同的思维方式结合在一起，有助于提高产品的质量。

思维方式反映了个人的假设以及作出决策和解决问题的首选方法。测试员的思维方式应该包括好奇心、职业的悲观主义、批判性的眼光、对细节的关注，以及良好和积极的沟通和人际关系的动机。随着测试员经验越来越丰富，测试员的思维方式也在不断成长和成熟。

开发人员的思维方式中可能会包含一些测试员思维方式中的元素，但成功的开发人员通常对设计和研究解决方案更感兴趣，而不是去考虑这些解决方案中可能存在的问题。此外，确认偏见使他们很难会意识到自己犯下的错误。

有了正确的思维方式，开发人员就可以自己测试自己的代码。不同的软件开发生存周期模型，通常有不同的组织测试员和测试活动的方式。由独立的测试员进行的一些测试活动可以提高缺陷检测的有效性，这对大型、复杂或安全关键系统尤其重要。因为测试员与作者有不同的认知偏见，所以独立的测试员带来的视角不同于工作产品的作者（例如，业务分析师、产品负责人、设计师和开发员）

2. 软件开发生存周期中的测试

2.1.软件开发生存周期模型

软件开发生存周期模型描述了软件开发项目中每个阶段要开展的活动类型，以及这些活动是如何在逻辑上和时间上相互关联的。有许多不同的软件开发生存周期模型，每个模型都要求使用不同的测试方法。

2.1.1. 软件开发和软件测试

为了能够进行适当的测试活动，熟悉常见的软件开发生存周期模型是测试员的重要职责。

在任何软件开发生存周期模型中，良好的测试都有以下几个特点：

每个开发活动会有对应的测试活动
每个测试级别会有对应的特定的测试目标
相应的开发活动期间，对特定的测试级别进行测试分析和设计
测试员参与讨论，以明确和改善需求和设计，并在初稿完成时立即参与工作产品（例如需求、设计、用户故事等）的评审工作

无论选择哪种软件开发生存周期模型，测试活动都应在生存周期的早期阶段开始，以符合测试的尽早介入原则。

常见的软件开发生存周期模型，本大纲分类如下：

顺序开发模型
迭代和增量开发模型

顺序开发模型将软件开发过程描述为线性的、顺序的活动流。它是指开发过程中的任何阶段都应该在完成前一阶段的基础上进行。从理论上讲，阶段之间没有重叠，但在实践中，都会受益于来自下一阶段的早期反馈。

在瀑布模型中，开发活动（例如需求分析、设计、编码、测试）是一个接一个完成的。在该模型中，只有在完成所有其他开发活动之后，才会进行测试活动。与瀑布模型不同，V-模型将测试过程集成到了整个开发过程中，满足了尽早测试的原则。此外， V-模型还包括与每个相应开发阶段相对应的测试级别，这进一步支持了尽早测试（关于测试级别的讨论请参见第 2.2 节）。在该模型中，与每个测试级别相关联的测试执行是按顺序方式进行的，但在某些情况下会发生重叠。

顺序开发模型交付的软件包含了完整的特征集，但通常需要几个月或几年的时间才能交付给利益相关方和用户。

增量开发包括建立需求、设计、构建和测试一个系统的各个部分，这意味着软件的特征在不断增加。这些特征增量的大小各不相同，有些方法的增量很大，而有些方法的增量很小。特征增量的大小可以小到是对用户界面或新的查询选项的修改。

迭代开发发生在多个特征在一系列周期中一起被指定、设计、构建和测试的时候。迭代可能涉及早期迭代中发生功能变更，以及更改项目范围。每次迭代都会交付工作软件，这是整个特征集不断增长的子集，直到交付最终软件或停止开发。

示例包括：

统一软件开发过程（RationalUnifiedProcess）：每次迭代往往相对较长（例如，两到三个月），并且特征增量相对较大，例如两组或三组相关特征。
迭代增量框架（Scrum）: 每次迭代往往相对较短（例如，几个小时、几天或几周），并且特征增量相对较小，例如一些增强特征和/或两个或三个新特征。
看板（Kanban）：用或不用固定长度进行迭代，可以在完成时交付单个增强或特征，也可以将特征组合在一起，即刻发布。
螺旋式（Spiral）：包括创造实验增量，其中一些可能会被大量返工，甚至在后续的开发工作中被放弃。

在开发过程中，使用这些方法开发的组件或系统通常会涉及到测试级别的重叠和迭代。理想情况下，在每个特征交付之前，需在多个测试级别上进行测试。在某些情况下，团队使用持续交付和持续部署，这两者都涉及到将多个测试级别自动化，并作为其交付管道的一部分。许多使用这些方法的开发工作还包括自组织团队的概念，它改变测试工作的组织方式以及测试员和开发人员之间的关系。

这些方法形成了一个不断增长的系统，这个系统可以基于功能特征、基于迭代或者以更传统的主版本发布方式，交付给最终用户。无论软件增量是否发布给最终用户，随着系统的发展，回归测试变得越来越重要。

与顺序模型相比，迭代和增量模型可以在几周甚至几天内交付可用的软件，但只能在几个月甚至几年的时间内交付完整的需求产品集。有关敏捷开发周境中软件测试的更多信息，请参见 ISTQB-CTFL-AT，Black 2017，Crispin 2008 和 Gregory 2015。

2.1.2. 周境中的软件开发生存周期模型

软件开发生存周期模型必须根据项目周境和产品特性来选择和调整。应该根据项目目标、正在开发产品的类型、业务优先级（例如上市时机）以及已识别的产品和项目风险，选择和调整合适的软件开发生存周期模型。例如，小型内部管理系统的开发和测试，应该与安全关键系统（如，汽车刹车控制系统）的开发和测试不同。另一个例子是，在某些情况下，组织和企业文化问题可能会阻碍团队成员之间的交流，从而阻碍迭代开发。

根据项目周境，可能需要合并或重组测试级别和/或测试活动。例如，为了将商业现货（COTS）软件产品集成到更大的系统中，采购者可以在系统集成测试级别（例如，集成到基础设施和其他系统中）和在验收测试级别（功能和非功能，以及用户验收测试和运行验收测试）上进行互操作性测试。关于测试级别的讨论，参见第 2.2 节；关于测试类型的讨论，参见第 2.3 节。

此外，软件开发生存周期模型本身可能会组合起来。例如，V-模型可用于后端系统及其集成的开发和测试，而敏捷开发模型可用于开发和测试前端用户界面（UI）和功能。可以在项目的早期使用原型，在试验阶段完成后，就采用增量开发模型。

物联网（IoT）系统由许多不同的对象组成，例如设备、产品和服务，通常会给每个对象应用单独的软件开发生存周期模型，这对物联网系统版本的开发提出了特殊的挑战。此外，在这些对象的软件开发生存周期中更加强调它们被投入使用后的后期阶段（例如，运行、更新和退役阶段）。软件开发模型必须适应项目和产品特性的原因可以是：