目录
软件系统是生活中不可或缺的一部分，包括从商业应用（比如银行系统）到消费产品（比如汽 车）的各个领域。然而，很多人都有过这样的经历：软件并没有按照预期进行工作。不能正常工作 的软件会导致许多问题，包括资金、时间和商业声誉的损失，甚至是伤害或死亡。软件测试是评估 软件质量和降低软件运行中出现失效风险的一种方法。
对测试的常见误解是，它只包含了运行测试，即执行软件和检查结果。如第 1.4 节所述，软件测试是一个包含了许多不同活动的过程；测试执行(包括检查结果)只是这些活动之一。测试过程还包括诸如测试计划、测试分析、测试设计、测试实施、报告测试进度和结果，以及评估测试对象的质量等活动。
有些测试确实涉及到被测组件或系统的执行，这种测试称为动态测试。不涉及运行被测组件或系统的测试，称为静态测试。所以，测试还包括评审工作产品，例如需求、用户故事和源代码。
另一个关于测试的常见误解是，它完全关注于需求、用户故事或其他规格说明的验证。虽然测试确实涉及检查系统是否满足指定的需求，但它也包含确认，即检查系统在其运行的环境中是否满足用户和其他利益相关方的需求。
测试活动在不同的生存周期中的组织和实施是不同的(参见第 2.1 节)
对于给定的任何项目，其测试目标可以包括：
根据被测组件或系统的环境、测试级别和软件开发生存周期模型的不同，测试目标会有所变化。 不同包括：
测试和调试是两个不同的概念。执行测试可以发现由于软件缺陷引起的失效。而调试是发现、 分析和修复这些缺陷的开发活动。随后的确认测试检查修复活动是否解决了缺陷。有的时候，测试员负责开始及最终的确认测试，而开发人员则负责调试、相关组件和组件的集成测试（持续集成）。 然而，在敏捷开发和其他的一些软件开发生存周期中，测试员也可能会参与调试和组件测试。
对组件和系统及其相关文档进行严格的测试，有助于降低软件运行过程中出现失效的风险。当发现缺陷并随后加以修复时，这有助于提高组件或系统的质量。此外，还可能需要进行软件测试， 以满足合同或法律法规或行业具体标准的要求。
纵观计算机的历史，软件和系统的交付使用是很常见的，但是由于缺陷的存在，随后就会导致软件和系统的失效，或者没有满足利益相关方的需求。然而，使用适当的测试技术可以减少这种有问题交付的频率，只要这些技术是在适当的测试技能水平、适当的测试级别和软件开发生存周期的适当点上得到应用。例如:
除了这些例子之外，达到已定义测试目标(参见第 1.1.1 节)有助于整个软件开发和维护的成功。
人们经常使用“质量保证”(或 QA)来代指测试，虽然它们是有关联的，但是质量保证和测试是不一样的。可以用更大的概念把它们联系在一起，质量管理。质量管理包括所有指导和控制组织质量的活动。
除其他活动外，质量管理还包括质量保证和质量控制。质量保证的关注点在于遵循正确的过程， 为产品能够达到合适的质量级别提供信心。当过程正确开展时，这些过程所创造的工作产品通常具有更高的质量，这也有助于缺陷的预防。另外，使用根本原因分析方法来发现缺陷并消除引起缺陷的原因，以及适当应用回顾性会议的结论来改进过程，对于有效的质量保证都也很重要。
质量控制涉及各种支持达到适当质量级别的活动，包括测试活动。测试活动是整个软件开发或维护过程的一部分。因为质量保证涉及到整个过程的正确执行，质量保证会支持正确的测试活动。 如第 1.1.1 节和 1.2.1 节所述，测试在以各种方式帮助实现质量的提高。
所有人都会犯错误(mistake)，这样就会导致在软件代码或者其他相关工作产品中引入缺陷 (fault 或 bug)。在一个工作产品中引入的缺陷就可能会导致其他相关工作产品都引入缺陷。例如， 需求引发的错误就可能导致需求缺陷，需求缺陷就会导致编程错误，这样代码中就存在缺陷。
如果执行了存在缺陷的代码，就可能导致失效，但不一定在所有情况下都是这样。例如，有些缺陷需要非常特殊的输入或先决条件才能触发失效，这种失效可能很少发生，也可能永远不会发生。
发生错误的原因有很多种，例如：
除了代码中的缺陷导致的失效之外，环境条件也可能导致失效。例如：辐射、电磁场和污染等都有可能引起固件中的失效，或者由于硬件环境的改变而影响软件的执行。
但并非所有意外的测试结果都属于失效。由于测试执行方式的错误，或者由于测试数据、测试环境或其他测试件中的缺陷，又或者由于其他的原因，可能会出现假阳性结果（误报）。相反的情况也有可能发生，即相似的错误或缺陷会导致假阴性结果（缺陷的漏报）。假阴性结果指的是没有发现测试应该要发现的缺陷；假阳性结果记录为缺陷，但实际上并不是缺陷。
缺陷的根本原因是导致缺陷产生的最早的行为或条件。可以分析缺陷并找出其根本原因，以减少类似的缺陷以后再发生。通过将关注点放在最重要的根本原因，根本原因的分析可以促进过程的改进，从而防止将来引入大量的缺陷。
例如，假设由于一行不正确的代码，支付了错误的利息，导致了客户投诉。由于产品负责人对如何计算利息有误解，所以为模糊的用户故事编写了有缺陷的代码。如果在利息计算中存在很大比例的缺陷，并且引发这些缺陷的根本原因来源于类似的误解，那么需要为产品负责人进行利息计算相关主题的培训，以便在未来减少这类缺陷。
在这个例子中，客户投诉的是缺陷导致的影响。支付错误的利息属于失效。代码中的错误计算属于缺陷，它是由模糊的用户故事中的原始缺陷造成的。原始缺陷产生的根本原因是产品负责人知识的缺乏，导致产品负责人在编写用户故事时犯了错误。在 ISTQB-CTEL-TM 和 ISTQB-CTEL-ITP 大纲中讨论了根本原因分析过程。
过去 50 年来，人们提出了一些测试原则，并为所有测试提供了通用的指南。
原则 1 测试说明缺陷的存在，而不能说明缺陷不存在
测试可以证明存在缺陷，但不能证明不存在缺陷。测试降低了软件中存在未发现缺陷的可能性， 但即使没有发现缺陷，测试也无法证明其对象的正确性。
原则 2 穷尽测试是不可能的
进行穷尽测试（输入和前提条件的所有组合）是不可行的，除非是小型的案例。应利用风险分 析、测试技术和优先级确定测试工作量，而不是试图进行穷尽测试。
原则 3 测试的尽早介入可以节省时间和成本
为了尽早发现缺陷，应该在软件开发生存周期中尽早启动静态和动态测试活动。测试的尽早介入有时被称为测试的左移。在软件开发生存周期的早期进行测试有助于减少或消除代价高昂的变更 （参见第 3.1 节）。
原则 4 缺陷的群集效应
通常在少数模块中包含了大部分在发布前测试中发现的缺陷，或者是造成大部分运行失效的原 因。预测的缺陷集群和在测试或操作中实际观察到的缺陷集群，应该作为风险分析的重要输入，并 用来集中测试工作量（如原则 2 所述）。
原则 5 杀虫剂悖论
如果多次重复同样的测试，最终这些测试将不再能够发现任何新的缺陷。为了发现新的缺陷， 可能需要更改现有的测试用例和测试数据，并且可能需要编写新的测试。（测试不再能有效发现缺陷， 就像杀虫剂在一段时间后对杀死昆虫不再有效一样）。但是在某些情况下，杀虫剂悖论也有好处，例如在自动化回归测试中，发现的回归缺陷数量相对较少。
原则 6 测试活动依赖于测试周境
测试在不同周境下是不同的。比如，安全关键工业控制软件的测试不同于电子商务移动应用。 另一个例子，在敏捷项目中进行的测试不同于在顺序软件开发生存周期项目中进行的测试（见第 2.1 节）。
原则 7 不存在缺陷的谬论
有些组织期望测试员能够运行所有可能的测试并发现所有可能的缺陷，但是原则 2 和原则 1 分别告诉了我们这是不可能的。另外，期望仅仅发现并修复大量缺陷就能确保系统的成功，这是一个 谬论（即错误的信念）。例如，穷尽测试所有指定的需求并修复发现的所有缺陷，仍然可能会生产出 一个难以使用，或无法满足用户需求和期望，或与其他竞争产品相比更差的系统。
更多测试原则的实例及其他测试原则，请参见 Myers 2011, Kaner 2002，Weinberg 2008，和 Beizer 1990。
尽管没有统一的软件测试过程，但是有一些常见的测试活动，如果没有这些测试活动就不太可能实现既定的目标。这些测试活动就组成了一个测试过程。在任何给定的情况下，适当的、特定的软件测试过程取决于很多因素。
测试过程中涉及哪些测试活动，如何实施这些测试活动，以及何时开始这些测试活动，都可以在组织的测试策略中进行讨论。
影响组织测试过程的周境因素包括，但不仅限于以下：
后面章节就以下几点描述了组织中测试过程的通用方面：
如果测试依据（对于正在考虑的任何测试级别或类型）具有可度量的覆盖标准，那是非常有用 的。覆盖标准可以有效地作为关键绩效指标(KPIs)，推动显示软件测试目标实现的活动(参见第 1.1.1 节) 例如，对于移动应用程序，测试依据可能包括需求列表和支持的移动设备列表。
每个需求都是测试依据的一个元素。覆盖标准可能要求测试依据的每个元素至少有一个测试用例。执行测试时， 这些测试的结果将告诉利益相关方是否实现了指定的需求，以及是否在受支持的设备上观察到了失 效。
有关于测试过程的更多信息参见 ISO 标准(ISO/IEC/IEEE 29119-2)。
测试过程主要由以下主要的活动组所组成：
每个活动组都是由多个活动构成，具体内容将在下面的小节中加以说明。每个组成的活动都可能由多个单独的任务组成，这些任务可能因项目或版本发布而不同。
此外，虽然这些主要活动组中的许多活动在逻辑上看起来是有顺序的，但它们通常是迭代实现的。例如，敏捷开发涉及到软件设计、构建和测试的小迭代，这些迭代都是在持续计划的支持下连续进行的。所以，在这种软件开发的方法中，测试活动也是在迭代的、持续的基础上进行。即使在顺序软件开发中，主要活动的阶梯式逻辑顺序也会涉及重叠、组合、并发或省略，所以必须根据系统和项目的周境因素裁剪这些主要活动。
测试计划
测试计划包括的活动有定义测试目标以及在周境因素限制下达到测试目标的方法(例如，指定适合的测试技术和适当的测试任务，并制定满足截止期限的测试进度表)。根据测试监督与控制活动的 反馈，可以重新审议测试计划。测试计划会在第 5.2 节中进一步讲述。
测试监督与控制
测试监督包括使用测试计划中定义的测试监督度量，对实际进度与计划的进展进行持续的比较。 测试控制包括采取必要的措施来满足测试计划的目标(目标可能会随时间的变化有所更新)。测试监 督与控制是通过评估出口准则来支持的，出口准则在一些软件开发生存周期模型中被称为“完成的 定义”（参见 ISTQB-CTFL-AT）。例如，作为给定测试级别的一部分，对测试执行的出口准则评估可能包括:
在测试进度报告中向利益相关方通报测试进度，包括偏离计划的情况和帮助决定结束测试的信 息。测试监督与控制将在第 5.3 节中进一步讲述。
测试分析
在测试分析过程中，分析测试依据以识别可测试特征和定义相关的测试条件。换句话说，测试分析根据可测量的覆盖标准来确定“测试什么”。
测试分析主要包括以下活动:
在测试分析过程中，使用黑盒测试技术、白盒测试技术、基于经验的测试技术(参见第 4 章)， 可以减少遗漏重要测试条件的可能性，并且能更精确和准确的定义测试条件。
在某些情况下，测试分析得到的测试条件，这些条件将作为测试章程中的测试目标。在某些基 于经验的测试中，测试章程是典型的工作产品(参见第 4.4.2 节)。当这些测试目标可以追溯到测试依据时，就可以测量基于经验的测试中实现的覆盖率。
在测试分析过程中识别缺陷是一个重要的潜在收益，特别是在没有使用其他评审过程和/或测试过程与评审过程之间间隔很短的情况下。这样的测试分析活动不仅要验证需求是否一致、是否表达正确以及是否完整，还需验证需求是否正确满足客户、用户和其他利益相关方的需求。例如，行为 驱动开发(BDD)和验收测试驱动开发(ATDD)等技术，它们都需要在编码之前，从用户故事和验收标准中生成测试条件和测试用例，这些技术同样要在用户故事和验收标准中验证、确认和发现缺陷(参见 ISTQB-CTFL-AT)。
测试设计
在测试设计时，将测试条件细化成概要测试用例、概要测试用例集和其他测试件。因此，测试分析回答了“测试什么？”的问题，而测试设计是回答了“如何测试？”的问题。
测试设计包括以下的主要活动:
在测试设计过程中，将测试条件细化为测试用例和测试用例集，常常会涉及到使用测试技术(参见第 4 章)。
与测试分析一样，测试设计也可能在测试依据中识别出相似类型的缺陷。与测试分析一样，测试设计过程中识别出缺陷也是其重要的潜在效益。
测试实施
在测试实施期间，创建和/或完成测试执行所需的测试件，包括将测试用例排序为测试规程。所 以，测试设计回答了“如何测试”的问题，而测试实施则回答了“我们现在是否已经有了运行测试所需的一切条件?”
测试实施包括以下主要活动:
测试设计和测试实施任务通常是结合在一起的。
在探索性测试和其他基于经验的测试类型中，测试设计和实施可能作为测试执行的一部分得到执行和记录。探索性测试可以基于测试章程(作为测试分析工作产品的一部分)，在探索性测试时直接进行设计和实施(参见第 4.4.2 节)。
测试执行
在测试执行期间，测试套件按照测试执行进度表运行。
测试执行包括以下主要活动:
测试结束
测试结束活动从已完成的测试活动中收集数据，以强化经验、测试件，以及任何其他相关信息。 测试结束活动出现在项目里程碑点，例如：当软件系统发布时、当测试项目完成（或取消）时、当 敏捷项目的迭代完成时、当测试级别完成时，或当维护版本完成时。
测试结束包括以下主要活动：
测试工作产品作为测试过程中的一部分被创建。正如不同的组织在实施测试过程的方式时存在明显差异一样，在测试过程中创建的工作产品的类型也存在明显差异，这些工作产品的组织和管理方式，以及这些工作产品的名称也都存在明显差异。本大纲遵循上述测试过程以及本大纲和 ISTQB® 术语表中描述的工作产品。ISO 标准(ISO/IEC/IEEE 29119-3)也可以作为测试工作产品的指南。
本节所描述的很多测试工作产品都是可以使用测试管理工具和缺陷管理工具来获取和管理的 (参见第 6 章)。
测试计划工作产品
测试计划的工作产品通常包括一个或多个测试计划。测试计划包括关于测试依据与其他测试工作产品之间可追溯性的相关信息(参见下面内容及第 1.4.4 节)，以及测试监督与控制期间使用的出口标准(或“完成的定义”)。测试计划描述参见第 5.2 节。
测试监督与控制工作产品
测试监督与控制的工作产品通常包括各种类型的测试报告，包括测试进度报告(持续和/或定期生成的)和测试总结报告(在各种已结束里程碑上生成的)。所有的测试报告都应该提供在截止日期前与测试受众相关的细节，包括一旦获得测试执行结果后的总结。
测试监督与控制的工作产品还应该解决项目管理所关心的问题，例如任务完成度、资源的分配和使用，以及工作量。
测试监督与控制，及在这些活动中创建的工作产品，将会在本课程大纲第 5.3 节做进一步解释。
测试分析工作产品
测试分析工作产品包括已定义的和按优先级排序的测试条件，理想情况下每一个测试条件都可以双向追溯到它所覆盖的测试依据的特定元素。对于探索性测试，测试分析可能涉及到创建测试章 程。测试分析还可能发现和报告在测试依据上的缺陷。
测试设计工作产品
测试设计生成测试用例和测试用例集，以覆盖测试分析中定义的测试条件。通常设计概要测试用例是一种很好的做法，概要测试用例里没有具体的输入数据和预期结果的值。这样的概要测试用例可以在使用不同具体数据的多个测试周期中重复使用，同时仍能够充分记录测试用例的范围。理想情况下，每个测试用例都可以双向追溯到其覆盖的测试条件。
测试设计的工作产品包括：
记录的这些结果的范围差别会很大。
测试实施工作产品
测试实施工作产品包括:
理想情况下，一旦测试实施活动完成，就可以基于测试用例和测试条件，通过测试规程和测试依据的特定元素之间的双向可追溯性，来证明测试计划中确定的覆盖率准则是否实现。
在某些情况下，测试实施涉及使用工具创建工作产品，例如服务虚拟化和自动化测试脚本。
测试实施还可能需要创建和验证测试数据和测试环境。数据和/或环境验证结果的文档完整性可能会有很大差异。 测试数据为测试用例的输入和预期结果指定具体的值。这些具体的值，以及使用具体值的明确 指示，将概要测试用例转换为可执行的详细测试用例。当在测试对象的不同版本上执行时，相同的概要测试用例可能使用不同的测试数据。使用测试结果参照物来识别与具体的测试数据相关的明确的预期结果。
在探索性测试中，可以在测试执行的过程中创建某些测试设计和测试实施的工作产品，尽管探索性测试文档化的范围(以及它们对测试依据中的特定元素的可追溯性)可能会差异很大。
测试分析中定义的测试条件可以在测试实施中进一步细化。
测试执行工作产品
测试执行工作产品包括:
理想情况下，一旦完成了测试执行，可以通过与测试规程相关的双向可追溯性来确定和报告测试依据中每个元素的状态。例如，我们可以说哪些需求通过了所有计划的测试，哪些需求的测试失败了，和/或有与该需求相关的缺陷，以及哪些需求的测试已经计划好了但在等待运行。这样就可以 验证是否满足了覆盖标准，以及确认利益相关方是否可以理解这些测试结果报告。
测试结束工作产品
测试结束的工作产品包括测试总结报告、改进后续项目或迭代的行动项、变更请求或产品待办事项，以及最终的测试件。
如第 1.4.3 节描述的，测试工作产品以及这些工作产品的名称差别很大。无论差异如何，为了实施有效的测试监督与控制，如上所述，在测试依据的每个元素和与该元素相关联的各种测试工作产品之间建立和维护整个测试过程的可追溯性是很重要的。除了评估测试的覆盖率外，良好的可追溯性支持：
某些测试管理工具提供了与本节中描述的部分或全部测试工作产品相匹配的测试工作产品模型。 有些组织建立了自己的管理系统来管理工作产品，并提供他们所需的可追溯性信息。
软件开发，包括软件测试，都涉及到人的参与。因此，人的心理对软件测试有着重要的影响。
不论是在静态测试时识别缺陷，例如需求评审或用户故事细化，又或者是在动态测试执行时识别失效，都可能会被看作是对产品及其作者的批评。人类心理学中有个叫做“确认偏见”的原理， 会让人难以接受与目前所持有的信仰相悖的信息。例如，由于开发人员希望他们的代码是正确的， 但是他们存在确认偏见，这使得他们很难接受代码是错误的。除了确认偏见之外，其他的认知偏见都可能使得人们难以理解或接受测试产生的信息。而且，指责坏消息的传递者是人类的共同特征， 而测试产生的信息往往包含了坏消息。
虽然测试对项目进展和产品质量有很大的贡献(参见第 1.1 节和第 1.2 节)，但是由于这些心理因素，还是会有人认为测试是一种破坏性的活动。为了减少这些观念所带来的影响，应该以建设性 的方式去沟通关于缺陷和失效的相关信息。这样就可以缓解测试员和分析人员、产品负责人、设计 人员和开发人员之间的紧张关系。这同时适用于静态测试和动态测试。
测试员和测试经理需要有良好的沟通技巧，才能够有效地沟通缺陷、失效、测试结果、测试进度和风险，并与同事建立积极的关系。良好沟通方式的例子包括：
前面讨论了典型的测试目标(参见第 1.1 节)。清楚地定义正确的测试目标具有重要的心理暗示作用。大多数人倾向于将他们的计划和行动与团队、管理人员和其他利益相关方设定的目标保持一 致。同样重要的是，测试员要以最低限度的个人偏见去坚持这些目标。
开发人员和测试员通常有不同的想法。开发的主要目标是设计并构建一个产品。如前文所述， 测试的目标包括验证和确认产品，在发布之前发现缺陷等。因为这些不同的目标，就需要不同的思维方式。将这些不同的思维方式结合在一起，有助于提高产品的质量。
思维方式反映了个人的假设以及作出决策和解决问题的首选方法。测试员的思维方式应该包括好奇心、职业的悲观主义、批判性的眼光、对细节的关注，以及良好和积极的沟通和人际关系的动 机。随着测试员经验越来越丰富，测试员的思维方式也在不断成长和成熟。
开发人员的思维方式中可能会包含一些测试员思维方式中的元素，但成功的开发人员通常对设计和研究解决方案更感兴趣，而不是去考虑这些解决方案中可能存在的问题。此外，确认偏见使他们很难会意识到自己犯下的错误。
有了正确的思维方式，开发人员就可以自己测试自己的代码。不同的软件开发生存周期模型， 通常有不同的组织测试员和测试活动的方式。由独立的测试员进行的一些测试活动可以提高缺陷检 测的有效性，这对大型、复杂或安全关键系统尤其重要。因为测试员与作者有不同的认知偏见，所 以独立的测试员带来的视角不同于工作产品的作者（例如，业务分析师、产品负责人、设计师和开 发员）
软件开发生存周期模型描述了软件开发项目中每个阶段要开展的活动类型，以及这些活动是如何在逻辑上和时间上相互关联的。有许多不同的软件开发生存周期模型，每个模型都要求使用不同的测试方法。
为了能够进行适当的测试活动，熟悉常见的软件开发生存周期模型是测试员的重要职责。
在任何软件开发生存周期模型中，良好的测试都有以下几个特点：
无论选择哪种软件开发生存周期模型，测试活动都应在生存周期的早期阶段开始，以符合测试的尽早介入原则。
常见的软件开发生存周期模型，本大纲分类如下：
顺序开发模型将软件开发过程描述为线性的、顺序的活动流。它是指开发过程中的任何阶段都应该在完成前一阶段的基础上进行。从理论上讲，阶段之间没有重叠，但在实践中，都会受益于来自下一阶段的早期反馈。
在瀑布模型中，开发活动（例如需求分析、设计、编码、测试）是一个接一个完成的。在该模型中，只有在完成所有其他开发活动之后，才会进行测试活动。 与瀑布模型不同，V-模型将测试过程集成到了整个开发过程中，满足了尽早测试的原则。此外， V-模型还包括与每个相应开发阶段相对应的测试级别，这进一步支持了尽早测试（关于测试级别的讨论请参见第 2.2 节）。在该模型中，与每个测试级别相关联的测试执行是按顺序方式进行的，但在某些情况下会发生重叠。
顺序开发模型交付的软件包含了完整的特征集，但通常需要几个月或几年的时间才能交付给利益相关方和用户。
增量开发包括建立需求、设计、构建和测试一个系统的各个部分，这意味着软件的特征在不断增加。这些特征增量的大小各不相同，有些方法的增量很大，而有些方法的增量很小。特征增量的 大小可以小到是对用户界面或新的查询选项的修改。
迭代开发发生在多个特征在一系列周期中一起被指定、设计、构建和测试的时候。迭代可能涉及早期迭代中发生功能变更，以及更改项目范围。每次迭代都会交付工作软件，这是整个特征集不断增长的子集，直到交付最终软件或停止开发。
示例包括：
在开发过程中，使用这些方法开发的组件或系统通常会涉及到测试级别的重叠和迭代。理想情况下，在每个特征交付之前，需在多个测试级别上进行测试。在某些情况下，团队使用持续交付和 持续部署，这两者都涉及到将多个测试级别自动化，并作为其交付管道的一部分。许多使用这些方 法的开发工作还包括自组织团队的概念，它改变测试工作的组织方式以及测试员和开发人员之间的 关系。
这些方法形成了一个不断增长的系统，这个系统可以基于功能特征、基于迭代或者以更传统的主版本发布方式，交付给最终用户。无论软件增量是否发布给最终用户，随着系统的发展，回归测试变得越来越重要。
与顺序模型相比，迭代和增量模型可以在几周甚至几天内交付可用的软件，但只能在几个月甚至几年的时间内交付完整的需求产品集。 有关敏捷开发周境中软件测试的更多信息，请参见 ISTQB-CTFL-AT，Black 2017，Crispin 2008 和 Gregory 2015。
软件开发生存周期模型必须根据项目周境和产品特性来选择和调整。应该根据项目目标、正在开发产品的类型、业务优先级（例如上市时机）以及已识别的产品和项目风险，选择和调整合适的软件开发生存周期模型。例如，小型内部管理系统的开发和测试，应该与安全关键系统（如，汽车刹车控制系统）的开发和测试不同。另一个例子是，在某些情况下，组织和企业文化问题可能会阻碍团队成员之间的交流，从而阻碍迭代开发。
根据项目周境，可能需要合并或重组测试级别和/或测试活动。例如，为了将商业现货（COTS） 软件产品集成到更大的系统中，采购者可以在系统集成测试级别（例如，集成到基础设施和其他系 统中）和在验收测试级别（功能和非功能，以及用户验收测试和运行验收测试）上进行互操作性测试。关于测试级别的讨论，参见第 2.2 节；关于测试类型的讨论，参见第 2.3 节。
此外，软件开发生存周期模型本身可能会组合起来。例如，V-模型可用于后端系统及其集成的开发和测试，而敏捷开发模型可用于开发和测试前端用户界面（UI）和功能。可以在项目的早期使用原型，在试验阶段完成后，就采用增量开发模型。
物联网（IoT）系统由许多不同的对象组成，例如设备、产品和服务，通常会给每个对象应用单独的软件开发生存周期模型，这对物联网系统版本的开发提出了特殊的挑战。此外，在这些对象的 软件开发生存周期中更加强调它们被投入使用后的后期阶段（例如，运行、更新和退役阶段）。 软件开发模型必须适应项目和产品特性的原因可以是：
测试级别是一组可以共同组织和管理的测试活动。每个测试级别都是测试过程的一个实例，在特定的开发级别上由第 1.4 节中描述的活动组成，从单元或组件到完整的系统，又或是其他适用的综合系统。测试级别与软件开发生存周期内的其他活动相关。本课程大纲中使用的测试级别有：
测试级别具有以下属性：
每个测试级别都需要合适的测试环境。例如，在验收测试中，类似生产的测试环境是非常理想 的，而在组件测试中，开发人员通常使用他们自己的开发环境。
组件测试的目标
组件测试（也称为单元或模块测试）关注在可单独测试的组件。组件测试的目标包括：
在某些情况下，特别是在增量和迭代开发模型中（如敏捷），代码持续发生着变化，组件的自动 化回归测试，在对于变更没有破坏现有组件方面所建立的信心起着关键的作用。
组件测试通常独立于系统其它部分的测试，具体取决于软件开发生存周期模型和该系统，这可能需要模拟对象、服务虚拟化、用具、桩和驱动。组件测试可以包括功能（例如，计算的正确性）、 非功能特性（例如，查找内存泄漏）和结构特性（例如，判定测试）。
测试依据
组件测试中可用作测试依据的典型工作产品包括：
测试对象
组件测试的典型测试对象包括：
典型的缺陷和失效
组件测试发现的典型缺陷和失效包括：
组件测试通常没有进行正式的缺陷管理，缺陷通常在发现后立即修复。但是，当开发人员报告缺陷时，这为根本原因分析和过程改进提供了重要信息。
特定的方法和职责
组件测试通常由编写代码的开发人员开展，组件测试是需要访问到被测软件的代码。开发人员可以将组件开发与发现和修复缺陷交替进行。开发人员经常在编写组件代码后编写并执行测试。但是，尤其在敏捷开发中，编写自动化组件测试用例可能先于编写应用程序代码。 例如，考虑测试驱动开发（TDD）。测试驱动开发是高度迭代的，基于开发自动化测试用例、 构建和集成小段代码，然后执行组件测试、纠正所有问题并重构代码的循环。该过程将持续到完全构建好组件且通过了所有组件测试。测试驱动开发是测试优先方法的一个例子。虽然测试驱动开发起源于极限编程（XP），但它已经扩展到其他形式的敏捷以及顺序生存周期（参见 ISTQB-CTFL-AT）。
集成测试的目标
集成测试侧重于组件或系统之间的交互。集成测试的目标包括：
与组件测试一样，在某些情况下，自动化集成的回归测试可以增强信心，因为即使产品有变更也不会破坏已有的接口、组件或系统。
本大纲中描述了两种不同级别的集成测试，可以对不同大小的测试对象进行测试，如下所示：
测试依据
集成测试中可用作测试依据的典型工作产品包括：
测试对象
集成测试的典型测试对象包括：
典型的缺陷和失效
组件集成测试中典型缺陷和失效包括：
系统集成测试中典型缺陷和失效包括：
特定的方法和职责
组件集成测试和系统集成测试应该集中在集成本身。例如，如果将模块 A 与模块 B 集成，则应侧重于模块之间的通信，而不是单个模块的功能，因为在组件测试期间应该已经覆盖了单个模块的 功能。如果将系统 X 与系统 Y 集成，测试应该 侧重于系统之间的通信，而不是单个系统的功能，因为在系统测试中应该已经覆盖了单个系统的功能。功能测试、非功能测试和结构测试类型都适用于组件集成测试和系统集成测试。
组件集成测试通常由开发人员负责。系统集成测试通常由测试员负责。理想情况下，开展系统集成测试的测试员应该理解系统架构，并且能够影响到集成计划。
如果在组件或系统构建之前就已经计划了集成测试和集成策略，则组件或系统可以按照最有效测试所需的顺序构建。系统集成策略可以基于系统架构（例如，自上而下和自下而上）、功能任务、 事务处理序列或系统或组件的一些其他方面。为了简化缺陷隔离并尽早发现缺陷，集成通常应该是 增量式的（即每次增加少量的组件或系统）而不是“大爆炸”式的（即一次性集成所有的组件或系 统）。对最复杂的接口进行风险分析有助于针对性的进行集成测试。
集成的范围越大，将缺陷定位到指定的组件或系统就越困难，这可能会增加风险并增加了排错的时间。在持续集成中，软件中的每个组件逐步集成（即功能集成）成为了普遍做法，这就是持续集成的一个原因。这种持续集成通常包括自动回归测试，且在理想情况下是在多个测试级别进行的。
系统测试的目标
系统测试侧重于整个系统或产品的行为和能力，通常会考虑系统可开展的端到端任务和开展这些任务时所展现的非功能行为。系统测试的目标包括：
对于某些系统，验证数据质量也可能是一个系统测试的目标。在某些情况下，也会与组件测试和集成测试一样，自动化系统回归测试可以增强信心，即便在代码变更时，也不会破坏现有的特性或端到端的功能。系统测试通常会提供信息给利益相关方用来决策系统是否发布。系统测试也可能是为了满足法律或法规要求或符合标准。
理想情况下，测试环境应与最终目标或生产环境相对应。
测试依据
系统测试中，可以作为测试依据的典型工作产品包括：
测试对象
系统测试的典型测试对象包括：
典型的缺陷和失效
系统测试的典型缺陷和失效包括：
特定的方法和职责
系统测试应侧重整个系统的端到端行为，包括功能和非功能。系统测试应针对被测系统的各个方面使用最合适的技术（参见第 4 章）。例如，可以创建决策表来验证功能行为是否满足业务规则的 要求。
系统测试通常由高度依赖规范说明的独立测试员进行测试。规格说明中的缺陷（例如，缺少用 户故事、业务需求表述错误等）会导致对预期系统行为缺乏理解或产生分歧。这些情况会导致假阳性结果（误报）和假阴性结果（漏报），误报会导致浪费时间，漏报导致缺陷检测有效性的降低。测试员早期参与用户故事细化或静态测试活动，例如评审，有助于减少此类问题的发生。
验收测试的目标与系统测试类似，验收测试通常侧重于整个系统或产品的行为和功能。验收测试的目标包括：
验收测试可以提供信息，用以评估系统是否可以部署并交付给客户（最终用户）使用。虽然在验收测试期间可能会发现缺陷，但发现缺陷通常不是其目标。在验收测试过程中发现大量的缺陷， 在某些情况下可能会被认为是一个重要的项目风险。验收测试也可能是为了满足法律或法规要求或 标准。
验收测试的常见形式包括：
用户验收测试（UAT）
系统的用户验收测试通常侧重于验证系统是否适合在真实用户的环境或模拟运行环境中运行。 其主要目标是建立信心，让用户能够以最低的难度、成本和风险使用这个系统去满足他们的要求、 满足需求和开展业务流程。
运行验收测试（OAT）
操作或系统管理人员对系统的验收测试，通常是在（模拟的）生产环境中进行的。测试侧重于
运行方面，可能包括：
运行验收测试的主要目标是建立信心，操作员或系统管理员能确保用户在运行环境中正常操作系统，即使在异常或困难的条件下也要确保系统可以正常工作。
合同和法规验收测试
合同验收测试是根据合同中生产定制软件的验收标准开展的。验收标准应在双方合同达成一致时确定，通常由用户或独立的测试员进行合同验收测试。
法规验收测试根据必须遵守的法规开展，例如政府、法律或安全法规。通常由用户或独立的测试员进行法规验收测试，有时监管机构也会参与见证或审计。
合同和法规验收测试的主要目标是建立信心，证明合同或法规要求已得到满足。
Alpha 和 beta 测试
Alpha 和 beta 测试通常被商业现货（COTS）软件的开发人员所采用，他们希望在软件产品投放 市场之前从潜在或现有用户、客户和/或操作人员中获得反馈。Alpha 测试是在开发组织所在场地进 行的测试，由潜在或现有客户、和/或操作人员或独立测试团队执行。Beta 测试是由潜在或现有的 客户、和/或操作人员在他们本地执行。在完成 alpha 测试后，可以执行 Beta 测试，或之前没有执 行过任何 alpha 测试的情况下执行 Beta 测试。
alpha 和 beta 测试的一个目标是在为潜在或现有客户和/或操作人员之间建立信心，即他们可以在正常的日常条件下，在操作环境中以最低的难度、成本和风险使用该系统实现目标。另外一个目标是发现与将要使用该系统的条件和环境有关的缺陷，尤其是在开发团队难以复制这些条件和环境的时候。
测试依据
验收测试中，可以作为测试依据的典型工作产品包括：
此外，在运行验收测试中，作为衍生测试用例的测试依据，可以使用以下一个或多个工作产品：
典型的测试对象
验收测试的典型测试对象包括：
典型的缺陷和失效
验收测试的典型缺陷包括：
特定的方法和职责
验收测试通常是由客户、业务用户、产品负责人或系统操作员负责，也可能涉及其他利益相关 方。
验收测试通常作为顺序开发生存周期中的最后一个测试级别，但也可能在其他时间发生，例如：
在迭代开发中，项目团队可以在每次迭代期间和迭代结束时进行各种形式的验收测试，例如根据其验收标准验证新功能，以及确认新功能是否满足用户需求。此外，可能在每次迭代的最后，可能在每次迭代完成后或在一系列迭代之后，开展 alpha 测试和 beta测试。也可能在每次迭代的最后， 或者每次迭代完成或一系列迭代之后执行用户验收测试、运行验收测试、法规验收测试和合同验收 测试。
测试类型是一组基于特定测试目标的测试活动，旨在测试软件系统或系统的一部分特定特性。 这些目标可能包括:
系统的功能测试包括评估系统应该开展功能的测试。功能需求通常在工作产品中描述，例如业务需求规格说明、史诗、用户故事、用例或功能规格说明，或者它们可能没有文档记录。功能指的是系统应该做“什么”。
尽管每个测试级别的关注点不一样（参见第 2.2 节），但所有测试级别都应该执行功能测试（例 如，组件测试以组件规格说明为基础）。
功能测试考虑软件的行为，因此可以通过使用黑盒技术获取组件或系统功能的测试条件和测试用例(参见第 4.2 节)。
功能测试的完整性可以通过功能覆盖来衡量。功能覆盖率是指测试执行某些功能的程度，并以所覆盖元素类型的百分比形式来表示。例如，使用测试和功能需求之间的可追溯性，可以计算出通过测试的需求的百分比，潜在地识别出覆盖的缺口。
功能测试设计和执行可能涉及特殊技能或知识，如软件解决的特定业务问题(例如，石油和天然气行业的地质建模软件)的知识。
系统的非功能测试是用来评估系统和软件的特性，例如易用性、性能效率或安全性。有关软件产品质量特性的分类，参见 ISO 标准（ISO / IEC 25010）。非功能测试是测试系统在运行过程中“表 现如何”。
与常见的误解相反，非功能测试可以并应该在所有的测试级别上开展，并且应尽早开展。对于项目的成功而言，在项目后期才发现非功能性缺陷是非常危险的。
可以使用黑盒技术（参见 4.2 节）生成非功能测试的测试条件和测试用例。例如，边界值分析可用于定义性能测试的压力条件。
非功能测试的完整性可以通过非功能覆盖来衡量。非功能覆盖是指通过测试执行某种类型的非功能元素所达到的程度，并且以所覆盖的元素类型的百分比形式来表示。例如，根据移动应用程序的测试和支持的设备之间的可跟踪性，可以计算出通过兼容性测试的设备所占百分比，发现潜在的覆盖缺口。
设计和执行非功能测试可能会涉及特殊技能或知识，例如设计或技术的固有弱点（例如，与特定编程语言相关的安全漏洞）或特定用户基础（例如，医疗设施管理系统的用户角色）的知识。
有关非功能质量特性测试的更多详细信息， 参见 ISTQB-CTAL-TA、 ISTQB-CTAL-TTA、 ISTQB-CTAL-SEC 和其他ISTQB®相关模块内容。
白盒测试基于系统内部结构或实现来生成测试。内部结构可能包括系统内的代码、架构、工作流和/或数据流(参见第 4.3 节)。
白盒测试的完整性可以通过结构覆盖来测量。结构覆盖是指某种类型的结构元素在测试中被使用的程度，并以所覆盖的元素类型的百分比形式来表示。
在组件测试级别，代码覆盖率基于已测试的组件代码的百分比。可以根据代码的不同方面（覆盖项）来度量，例如组件中测试的可执行语句的百分比，或者测试的判定结果的百分比。这些类型的覆盖统称为代码覆盖。在组件集成测试级别，白盒测试可能基于系统的架构，例如组件之间的接口，结构覆盖率可以根据测试所执行的接口的百分比来度量。
设计和执行白盒测试可能会涉及特殊技能或知识，例如构建代码的方式、数据的存储方式（例如，评估可能的数据库查询）以及如何使用覆盖工具并正确解释其结果。
当系统变更时，无论是修复缺陷，还是新增或修改功能，都应进行测试，以确认变更已修复缺陷或已正确实现功能，并且没有造成任何不可预见的不良后果。
确认测试：修复缺陷后，应该在软件的最新版本上，重新执行之前因该缺陷而导致失败的测试用例。为了覆盖修复缺陷所需的变化，也可以使用新的测试来测试软件。至少必须在新的软件版本上重新执行这些由缺陷引起失效的步骤。确认测试的目的是确认是否已成功修复原来的缺陷。
回归测试：部分代码所做的变更，无论是修复代码，还是其他类型的更改，都可能会意外地影响到除更改代码外的其他部分代码的行为，不管是在同一组件内，还是在同一系统的其他组件中，甚至在其他系统中。变更也可能包括环境的变化，例如操作系统或数据库管理系统的新版本。这种意外的副作用被称为回归。回归测试包括运行测试来检测这些意外的副作用。
确认测试和回归测试可以应用在所有的测试级别。
特别是在迭代和增量开发生存周期（例如，敏捷）中，新增特征、更改现有特征以及重构代码都会导致频繁更改代码，这也需要与变更相关的测试。随着系统不断发展，确认和回归测试非常重 要。这尤其和物联网系统特别相关，在物联网中，会频繁更新或替换个别对象（例如，设备）。
由于要多次运行回归测试套件，并且回归测试套件通常变化缓慢，因此回归测试是自动化的有力候选者。应该在项目的早期就开始测试自动化（参见第 6 章）。
可以在任何测试级别开展上述提到的任何测试类型。下面以银行应用程序为例，介绍功能测试、 非功能测试、白盒测试以及与变更相关的测试在所有测试级别中的应用，从功能测试开始：
以下是非功能测试的示例：
以下是白盒测试的示例：
最后，以下是与变更相关的测试示例：
虽然本节提供了每个级别的每种测试类型的示例，但对于所有软件而言，并不需要在每个级别上都运行每种测试类型。然而，在每个级别运行适用的测试类型很重要，尤其是测试类型出现的最早级别。
一旦部署到生产环境，就需要维护软件和系统。在已交付的软件和系统中，各种各样的变更几乎是不可避免的，比如修复运行使用中发现的缺陷，或添加新功能，或是删除或修改已经交付的功 能。在组件或系统的生存周期中，还需要维护或改进其非功能性质量特性，特别是性能效率、易用 性、可靠性、安全性和可移植性。
系统维护期间做任何变更时，应该执行维护测试，以评估更改的成功程度，并检查系统中未变更部分(通常是系统的大部分)可能出现的副作用(如回归)。
维护可包含计划发布和计划之外发布（热修复）。
根据维护版本的范围，维护版本可能需要在多个测试级别上进行多种测试类型的维护测试。维护测试的范围取决于：
导致软件维护，再到维护测试，其原因很多，包括计划的和计划外的变更。
维护的触发因素分类如下：
对于物联网系统，可以通过将全新或修改过的内容（例如硬件设备和软件服务）引入整个系统来触发维护测试。这类系统的维护测试特别强调在不同级别（例如，网络级别、应用级别） 的集成测试和安全方面，特别是那些与个人数据有关方面。
影响分析评估维护版本所做的变更，来识别预期的结果以及变更带来的预期和可能的副作用，并识别出系统中将受变更影响的区域；影响分析还可以帮助识别变更对现有测试的影响。 可能受变更影响的任何现有测试在更新之后，需要对系统中的副作用和受影响区域进行回归测试。 根据系统其他区域的潜在结果，可以在变更之前进行影响分析来帮助确定是否应进行变更。
如果出现以下情况，影响分析会比较困难：
与动态测试相比，静态测试依赖于软件工作产品的手动检查（即评审），或工具驱动的代码或其 他软件工作产品的评估（即静态分析）。两种类型的静态测试都会评审正在测试的代码或其他软件工 作产品，而无需实际执行所测试的代码或软件工作产品。
静态分析对于安全关键的计算机系统（例如，航空，医疗或核控制软件）很重要，但静态分析在其他环境中也变得重要和常见。例如，静态分析是安全测试的重要部分。静态分析通常也包含在自动软件构建和分布式工具中，例如，在敏捷开发，持续交付和持续部署中。
几乎所有软件工作产品都可使用静态测试（评审和/或静态分析技术）进行检查，例如：
评审可应用于任何工作产品，只要参与者能够阅读和理解这些工作产品。静态分析技术可有效地应用于具有规范结构（典型代表有代码或模型）的任何软件工作产品，可运用适当的静态分析工 具。静态分析技术甚至可借助工具评估以自然语言编写的工作产品，如需求（例如，检查拼写、语法和可读性）。
静态测试技术提供了多种好处。当在软件开发生存周期的早期应用静态测试，就能够在开展动态测试之前尽早地检测缺陷（例如，在需求或设计规格说明评审，待办事项列表的细化工作等）。早 期发现的缺陷通常比软件开发生存周期后期发现的缺陷经济得多，特别是与软件部署和使用后发现 的缺陷相比。使用静态测试技术来发现缺陷然后及时修复这些缺陷几乎总是比使用动态测试在测试 对象中发现缺陷然后修复它们所花费的成本要低得多，特别是在考虑到更新其他软件工作产品以及 开展确认和回归测试的额外成本。
静态测试的其他好处可能包括：
静态测试和动态测试可以具有相同的目标（参见第 1.1.1 节），例如提供对工作产品质量的评估并尽早识别缺陷。静态和动态测试通过发现不同类型的缺陷来相互补充。
静态测试和动态测试的一个主要区别在于静态测试直接发现软件工作产品中的缺陷，而动态测试是在运行软件时识别由缺陷引起的失效。缺陷可以在软件工作产品中存在很长时间而不会导致失效。缺陷所在的路径可能很少被执行或难以到达，因此设计并执行动态测试去发现这样的缺陷并不 容易。静态测试可能付出更少的工作量就能找到缺陷。
另一个区别是静态测试可用于提高软件工作产品的一致性和内部质量，而动态测试通常侧重于外部可见行为。
与动态测试相比，通过静态测试可以更早期更经济地发现和修复一些典型的缺陷，包括：
此外、大多数类型的维护性缺陷只能通过静态测试才能被发现（例如：没有很好的模块化、组件的可重用性较差、难以分析的代码以及很难保证修改代码而不引入新缺陷）。
评审类型是多样化的，从非正式到正式的评审。非正式评审的特点是既无需遵守既定的过程， 也没有正式的文档化输出。正式评审的特点是团队参与、文档化评审结果以及开展评审的文档化过 程。评审过程的正式程度与软件开发生存周期模型、开发过程的成熟度、需评审的软件工作产品的 复杂性、任何法律或法规要求和/或审计跟踪等因素有关。
评审的关注点依赖于已达成一致的评审目标（例如：发现缺陷、增加理解、培训参与者如测试员和团队新成员，或对讨论和决定达成共识等）。
ISO 标准（ISO / IEC 20246）包含对软件工作产品评审过程的更深入描述，包括评审角色和评审技术。
评审过程由以下主要活动构成：
计划
评审启动会
独立评审（即个人准备）
事件交流和分析
修正和报告
典型的正式评审主要有下面几种角色：
作者：
经理（管理者）：
促进者（通常称为主持人）：
评审组长：
评审员：
书记（或记录员）：
在有些评审类型中，一个人可能扮演多个角色，并且每个角色分工也可能因评审类型而异。此外，随着支持评审过程的工具的出现，特别是缺陷、未解决问题和决策记录，通常就不需要记录员。
更多角色的细节可参考 ISO 标准（ISO/IEC 20246）。
虽然评审可用于各种目的，但其主要目的之一是发现缺陷。所有评审类型都可以帮助检测缺陷， 所选的评审类型应基于项目需求、可用资源、产品类型和风险、业务领域和公司文化，以及其他选 择准则。
单一工作产品可能会使用一种以上的评审类型，如果使用了多种类型的评审，则顺序可能会有所不同。例如，可以在技术评审之前进行非正式评审，以确保工作产品已经为技术评审做好了准备。
下面描述的评审类型均可以作为同行评审，也就是说由有资格做同样工作的同事们来完成。
评审中发现的缺陷类型各不相同，尤其取决于评审的工作产品。（参见第 3.1.3 节，了解对不同 工作产品的评审所发现的缺陷示例，以及 Gilb 1993，了解正式审查的有关信息）。
评审可以根据各种属性进行分类。以下列出了四种最常见的评审类型及其相关属性。
非正式评审（例如：伙伴检查、结对、结对评审）
走查
技术评审
审查
在独立评审（即个人准备）活动期间可以应用许多评审技术来发现缺陷。这些技术可用于上述评审类型。这些技术的有效性可能因所使用的评审类型而异。下面列出了各种评审类型的不同独立评审技术的示例。
临时评审
在临时评审中，评审员很少或根本没有得到指导如何执行此任务。评审员经常按顺序阅读工作产品，在遇到问题时识别并记录事件。临时评审是一种常用的技术，几乎不需要准备。此技术高度 依赖于评审员的技能，并可能导致不同评审员报告许多重复的事件。
基于检查表的评审
基于检查表的评审是一种系统性的技术，评审员基于评审开始时（例如，由促进者（主持人）） 分发的检查表来发现事件。评审检查表包含一组基于潜在缺陷的问题，这些问题可能来自经验。检 查表应特定于所评审的工作产品类型，并应定期维护以涵盖以前评审中遗漏的事件类型。基于检查 表的技术的主要优点是对典型缺陷类型的系统的覆盖。应注意不要简单地按照独立评审中的检查表， 而是也要寻找检查表之外的缺陷。
场景和演练的评审
在基于场景的评审中，将为评审员提供有关如何通读工作产品的结构化指南。基于场景的评审支持评审员基于工作产品的预期使用，对工作产品开展“演练”（如果工作产品以适当的格式记录， 例如用例）。与简单的检查表条目相比，这些场景为评审员提供了有关如何识别特定缺陷类型的更好 指导。与基于检查表的评审一样，为避免错过其他缺陷类型（例如，功能遗漏），评审员不应受限于文档化的场景。
基于视角
在基于视角的文档阅读评审中，类似于基于角色的评审，评审员在独立评审中采用不同的利益相关方观点。典型的利益相关方观点包括最终用户、市场人员，设计人员、测试员或操作员。使用不同的利益相关方视角可以更加深入地进行独立评审，同时可以减少评审员之间的重复问题。
此外，基于视角的文档阅读评审还要求评审员尝试使用被评审的工作产品来生成他们所需的衍生产品。例如，如果对需求规格开展基于阅读视角的文档评审，以查看是否包含所有必要信息，这时测试员将会尝试生成草拟的验收测试。此外，在基于视角的文档阅读评审中，希望使用检查表。
经验研究表明，通常情况下基于阅读视角的文档评审是评审需求和技术工作产品最有效的技术。 关键的成功因素是基于风险适当地包括和权衡不同的利益相关方观点。有关基于阅读视角的文档评审的详细信息，参见 Shul 2000；有关不同评审技术的有效性，参见 Sauer 2000。
基于角色的评审
基于角色的评审技术，评审员可以从独立利益相关方角色的角度评估工作产品。典型角色包括特定的最终用户类型（有经验、没有经验、老人、小孩等），以及组织中的特定角色（用户管理员、 系统管理员、性能测试员等）。同样的原则也适用于基于视角的阅读，因为角色是相似的。
为了获得成功的评审，必须考虑适当的评审类型和使用的技术。此外，还有许多其他因素会影响评审结果。
组织层面的评审成功因素包括：
与人相关的评审成功因素包括：
本章节讨论的测试技术，其目的是帮助识别测试条件、测试用例和测试数据。
测试技术的选择基于很多因素，包括：
有些技术更适用于特定的环境和测试级别，而有些则适用于所有的测试级别。在创建测试用例时，测试员通常使用测试技术的组合来实现测试工作的最佳结果。 在测试分析、测试设计和测试实施活动中使用测试技术的范围，可以从很不正式（很少甚至 没有文档）到非常正式。适当的正式程度取决于测试周境，包括测试和开发过程的成熟度、时间 限制、安全或合规要求、相关人员的知识和技能、以及所遵循的软件开发生存周期模型。
本大纲将测试技术分为黑盒、白盒或基于经验的测试技术。
黑盒测试技术（也称为行为的或基于行为/规格说明的技术）基于对适当测试依据的分析（例如：正式需求文档、规格说明、用例、用户故事或业务流程）。这些技术适用功能和非功能测试。黑盒测试技术关注在测试对象的输入和输出，而不考虑其内部结构。
白盒测试技术（也称为结构的或基于结构的技术）基于对架构、详细设计、内部结构或测试对象代码的分析。与黑盒测试技术不同，白盒测试技术关注在测试对象的结构和处理过程。
基于经验的测试技术利用开发人员、测试员和用户的产品经验来设计、实施和执行测试。这类技术通常与黑盒和白盒测试技术相结合。
黑盒测试技术的共同特点包括：
白盒测试技术的共同特点包括：
基于经验的测试技术的共同特征包括：
国际标准（ISO/IEC/IEEE 29119-4）包含测试技术的描述和他们相关的覆盖度量（相关技术的更多信息可参见 Craig 2002 和 Copeland 2004）。
等价类划分将数据划分为不同分区（也称为等价类），使得给定分区内所有成员期望被相同方式处理（参见 Kaner 2013 和 Jorgensen 2014）。等价分区有针对有效值或无效值的。
要使用此技术实现 100％覆盖率，测试用例必须通过使用每个等价类中至少一个值来覆盖所有已识别的等价类（包括无效等价类）。覆盖度量为至少有一个值已经测试过的等价类的数量除以所识别的等价类的总数，通常表示为百分比。等价类划分适用于所有测试级别。
边界值分析是等价类划分的扩展，但仅适用于等价类是有序的、由数字或顺序数据组成。等价类的最小和最大值（或第一和最后的值）是其边界值（参看 Beizer 1990）。
例如，假设一个输入域接受单位整数值作为输入，使用（0-9）数码键限制输入，因此不可能输入非整数。包含的有效区间从 1 到 5（包含 1 和 5）。因此，存在三个等价类：无效（太低）； 有效；无效（太高）。对于有效等价类，边界值是 1 和 5。对于无效（太高）分区，边界值是 6。对于无效（太低）分区，只有一个边界值 0，因为这个分区仅有一个成员。
在上面的例子中，每个边界我们识别出两个边界值。无效（太低）和有效之间的边界给的测试值 0 和 1。有效和无效（太高）之间的边界给的测试值 5 和 6。作为这个技术的变体，每个边界可以识别出三个边界值：到边界之前、正好到边界、刚超过边界的值。在前面例子中，使用三点边界值，低端边界测试值是 0、1 和 2，以及高端边界测试值是 4、5 和 6（参看 Jorgensen 2014）。
在区域的边界上的行为往往比在区域内的行为更容易出现错误。值得注意的是，不仅定义的边界，而且已实现的边界可能会被移动到它们预期位置的上方或下方，或可能会被完全忽略，或还可能会增加不需要的额外边界。边界值分析和测试是通过激发软件显示出与边界值所属区域预期不同的行为，边界值分析和测试将能发现几乎所有这类缺陷。
边界值分析可以应用于所有的测试级别。这个技术通常用来测试需要调用一系列数字的测试需求（包括日期和时间）。对区域的边界值覆盖度量是测试的边界值数量除以识别的边界测试值总数，通常用百分比表示。
判定表是记录系统必须实现的复杂业务规则的一种很好的方法。当建立判定表时，测试员识别系统的条件（通常是输入）和导致的动作（通常是输出）。判定表的行，通常是条件在顶部， 而动作在底部。判定表的每一列对应了一个判定规则，该规则定义了各种条件的一个唯一组合， 其表示与该规则相关的动作的执行。条件值和动作通常表示为布尔值（“真”或“假”）或离散值 （例如：红、绿、蓝），但也可以是数字或数字范围。这些不同类型的条件和动作可能一起出现在同一判定表中。
判定表的常见符号如下：
对条件：
对动作：
完全的判定表有足够多的列（测试用例）来覆盖条件的每个组合。通过删除不影响结果的列， 测试用例的数量可以大大减少。例如通过移除不可能的条件组合。有关如何精简化判定表的进一 步信息，参见 ISTQB-CTAL-TA。
判定表测试的最小覆盖标准通常是对判定表中每个判定规则至少有一个测试用例。这通常涉及覆盖所有条件的组合。覆盖度量是至少被一个测试用例测试过的判定规则的数量，除以判定规则总数，通常以百分比表示。
判定表测试的优点是可以帮助识别所有重要的条件组合，否则其中有些条件组合有可能被忽视。判定表测试也会帮助发现需求中的漏洞。判定表测试可能应用到所有基于条件组合决定软件行为的情况，可以在任何测试级别进行。
根据组件或系统当前条件或先前历史（例如自从系统初始化后发生过的事件），组件或系统可能会产生不同的响应。先前历史可以用状态的概念来总结。状态转换图不但显示可能的软件状态，同时包含了软件如何入口、出口，以及状态之间的转换的。转换是通过事件触发的（例如， 用户输入一个值到输入域内）。事件导致转换。相同的事件从相同状态能导致两个或多个不同转换。状态改变可能导致软件采取动作（例如，输出计算或错误信息）。
状态转换表不但可显示状态之间所有有效转换和潜在的无效转换，而且可表示有效转换的事件和导致的动作。状态转换图通常仅仅显示有效转换，而不包括无效转换。
设计测试可以用来覆盖典型的状态序列、执行所有状态、执行每个转换、执行转换的特定序列，或测试无效的转换。
状态转换测试可以用于基于菜单的应用，其广泛使用在嵌入式软件行业。此技术也适用于有特定状态的业务场景的建模，或测试屏幕上显示的引导或“菜单”。状态的定义是抽象的，即可能表示几行代码或整个业务流程。
覆盖度量通常是识别出已测试状态或已测试转换的数量，除以测试对象已识别出的状态或转换的总数，一般以百分比表示。有关状态转换测试的覆盖准则的进一步信息可参见 ISTQB-CTAL-TA。
测试可以从用例中推导出来，用例是设计软件项交互的一种特殊方式，包含了软件功能的需求。用例关联了参与者（用户、外部硬件或其他组件或系统）和主体（用例所应用的组件或系统）。
每个用例规定了一个主体能与一个或多个参与者合作开展的一些行为（UML 2.5.1 2017）。 一个用例能通过交互和活动以及前置条件、后置条件进行描述，如合适，还可以以自然语言进行描述。参与者和主体之间的交互可能导致主体的状态改变。交互可能以工作流、活动图，或业务流程模型的图示方式表示。
用例包含了其基本行为的可能变化，包括期望行为和错误处理（系统对程序、应用和通讯错误的反应和恢复，例如，导致一个错误信息）。设计测试来执行已定义的行为（基本的、异常的或替代的和错误处理）。覆盖度量是已测试的用例行为数除以用例行为的总数，通常以百分比表 示。
有关用例测试覆盖准则的进一步信息，参见 ISTQB-CTAL-TA 高级测试分析师大纲。
白盒测试是基于测试对象的内部结构。白盒测试技术能用在所有的测试级别，但本节讨论的两个代码相关的技术通常是用于组件测试级别。还有一些更高级的技术，可用于安全关键、任务关键，或高完整性环境以达到彻底的覆盖，但这些不在此处讨论。有关这些技术的进一步信息， 参见 ISTQB-CTAL-TTA。4.3.1. 语句测试和覆盖语句测试执行代码中可执行语句。覆盖度量是被测试执行的语句数，除以测试对象中可执行语句总数，通常以百分比表示。
判定测试执行代码中的判定，以及测试基于判定结果的可执行的代码。为此，测试用例跟随发生在判定点的控制流（例如，针对 IF 语句,一个对真（true）结果和一个对假（false）结果； 针对 CASE 语句，测试用例将要求对所有可能结果，包括缺省（default）结果进行覆盖）。
覆盖度量是被测试执行的判定结果数，除以测试对象中判定结果的总数，通常以百分比表示。
当实现 100％语句覆盖时，它确保代码中的所有可执行语句至少已被测试过一次，但不能确保所有判定逻辑都已被测试过。在本大纲中讨论的两种白盒技术中，语句测试可能提供的覆盖低于判定测试。
当达到 100％的判定覆盖时，它会执行所有判定结果，包括测试取值为真（true）的结果和取值为假（false）的结果，即使没有清晰的假（false）语句（例如，IF 语句的代码中没有 else）。 语句覆盖有助于发现那些未被其他测试执行到的代码中的缺陷。判定覆盖有助于发现那些在其他测试中没有对其所有真值（“真”/“假”）都执行到的代码（例如，判定语句）中的错误。
实现 100％的判定覆盖可保证 100％的语句覆盖（但反之不成立）。
在应用基于经验的测试技术时，测试用例源自测试员的技能和直觉，以及他们在类似应用和技术方面的经验。这些技术有助于识别一些其它系统化技术无法轻易识别的测试用例。根据测试员的方法和经验，这些技术可以达到不同程度的覆盖和有效性。使用这些技术，可能会难以评估和度量覆盖。
以下各节将讨论常用的基于经验的技术。
错误推测法是一种基于测试员的知识来预估错误、缺陷和失效发生的技术，包括：
错误推测技术的一个系统化方法是创建一个可能的错误、缺陷和失效的列表，并设计测试以发现失效以及导致它们出现的缺陷。可以根据经验或缺陷和失效的信息，也可根据软件故障原因的一般知识创建此错误、缺陷和失效列表。
在探索性测试中，在测试执行期间动态地设计、执行、记录、和评估非正式的（非预定义的） 测试。测试结果常用来进一步了解组件或系统，并对可能需要进一步测试的区域生成测试。
探索性测试有时通过基于会话的测试来构造活动。在基于会话的测试中，探索性测试在定义的时间盒内进行，测试员使用包含测试目标的测试章程来指导测试。测试员可能使用测试会话表格来记录随后步骤和发现。
探索性测试在规格说明文档较少或不充分，或测试的时间压力大的情况下是最有帮助的。探索性测试作为对其他更正式的测试技术的补充也是有用的。
探索性测试与应对性（reactive）测试策略高度相关（参见第 5.2.2 节）。探索性测试能与其它黑盒、白盒和基于经验的技术组合使用。
在基于检查表的测试中，测试员设计、实施和执行测试来覆盖检查表中的测试条件。作为分析的一部分，测试员可以创建新的检查表或扩充现有的检查表，但测试员也可能使用没有修改的现有检查表。可以基于检验、对用户重要内容的了解，或对软件失效的原因和方式的理解来构建检查表。
可产生用于支持各种测试类型的检查表，包括功能和非功能测试。在没有详细测试用例的情况下，基于检查表的测试能提供指南和在一定程度上保持一致性。由于它们是概要性的列表，因此在实际测试中往往会出现一些变化和衍生，可能导致更高的覆盖，但又保持了低重复性。
测试任务可以由具有特定测试角色的人员完成，也可以由其他角色的人员（例如，客户）完 成。由于作者和测试员的认知取向不同，一定程度的独立性常常使测试员能更有效地发现缺陷（参见第 1.5 节）。但是，（测试员的）独立性却无法替代（开发人员的）熟悉性，开发人员可以在自己的代码中高效地发现许多缺陷。
测试中的独立程度包括以下几类（独立性从低到高）：
对于大多数类型的项目，通常最好有多个测试级别，其中一些级别由独立的测试员执行。开发人员应参与测试，特别是在较低级别，这样，开发人员能够控制他们自己工作的质量。
实现测试独立性的方式因软件开发生存周期模型而异。例如，在敏捷开发中，测试员可能是开发团队的一部分。在一些使用敏捷方法的组织中，这些测试员也可能被视为更大的独立测试团队的一部分。此外，在这类组织中，产品负责人可以开展验收测试，以在每次迭代结束时确认用户故事。
测试独立性的潜在好处包括：
测试独立性的潜在缺点包括：
许多公司能够认识到测试独立性的好处并避免其缺点。
在本大纲中，涵盖了两个测试角色：测试经理和测试员。这两个角色开展的活动和任务取决于项目和产品背景、人员的技能以及组织。
测试经理的任务是总体负责测试过程和成功管理测试活动。测试管理角色可以是专业的测试经理或项目经理、开发经理或质量保证经理。在较大的项目或组织中，多个测试团队可以向测试经理、 测试教练或测试协调员汇报，而每个团队由测试组长或主要核心测试员领导。
测试经理的典型任务可能包括：
测试经理的角色会因软件开发生存周期的不同而有所差异。例如，在敏捷开发中，上面提到的 一些任务由敏捷团队处理，特别是那些与团队内部日常测试有关的任务，通常由团队内部的测试员 完成。跨越多个团队或整个组织的一些任务、或与人事管理有关的，可以由开发团队以外的测试经 理完成，他们有时被称为测试教练。有关管理测试过程的更多信息，参见 Black 2009。
测试员的典型任务可能包括：
这些角色的人员可以是从事测试分析、测试设计、特定测试类型或测试自动化的人员。根据与产品和项目相关的风险以及所选择的软件开发生存周期模型，不同的人员可以在不同的测试级别上担当测试员的角色。例如，在组件测试级别和组件集成测试级别，测试员的角色通常可以是开发人 员。在验收测试级别，测试员的角色通常可以是业务分析师、领域专家和用户。在系统测试级别和 系统集成测试级别，测试员的角色通常可以是独立的测试团队。在运行验收测试级别，测试员的角 色通常由操作和/或系统管理员来完成。
测试计划描述了开发和维护项目的测试活动。制定计划受组织层的测试方针和测试策略影响， 也受开发生存周期和使用的方法（参见第 2.1 节）、测试范围、目标、风险、约束、重要性、可测试 性和资源可用性的影响。
随着项目和测试计划的进展，测试计划中包含的信息也会越来越多，越来越详细。测试计划是一项持续的活动，贯穿整个产品的生存周期。（请注意，产品的生存周期可能超出项目范围，它还包 括维护阶段。）应使用测试活动的反馈来识别不断变化的风险，以便调整计划。制定和记录规划可以在主测试计划中，也可以在单独的测试级别中，例如系统测试和验收测试，或者甚至可在单独的测 试类型中，例如易用性测试和性能测试。测试计划活动可能包括以下内容，其中一些可能会记录在测试计划中：
测试计划的内容各不相同，可以超出上述主题。测试计划结构的样本以及测试计划的样本可以在 ISO 标准（ISO/IE /IEEE 29119-3）中找到。
测试策略提供测试过程的一般描述，通常是在产品或组织级别上的。常见的测试策略类型包括：
分析型：此类测试策略基于对某些因素（例如，需求或风险）的分析。基于风险的测试是分析型方法的一个示例，这里是根据风险级别设计测试并确定测试的优先级。
基于模型：在这种类型的测试策略中，测试是基于产品的某些需求方面的模型设计的，例如功能、业务流程、内部结构、或非功能特性（例如，可靠性）。此类模型的示例包括业务过程模型、状态模型和可靠性增长模型。
方法论型：此类测试策略依赖于系统地使用一些预定义的测试集或测试条件，例如常见或可能缺陷类型的分类、重要质量特性列表或公司范围内的用于移动应用或网页的外观和感受标准。
符合流程（或符合标准）：此类测试策略是基于外部规则和标准来开展测试，包括分析、设计和实施测试，例如行业特定标准、过程文档、严格标识和使用的测试依据，或由组织制定或针对组织制定的任何过程或标准。
指导型（或咨询）：此类测试策略主要由利益相关方、业务领域专家或技术专家的建议、指导或指示驱动，这些利益相关方、业务领域专家或技术专家可能来自测试团队之外，甚至是在组织之外。
规避回归型：这种类型的测试策略的动机是希望避免现有功能的回归。此测试策略包括重用现有测试件（尤其是测试用例和测试数据）、回归测试的广泛自动化以及标准测试套件。
应对型：在这种类型的测试策略中，测试被动应对被测组件或系统以及测试执行期间发生的事件，而不是预先计划（如前面的策略所示）。测试经过设计和实施，并可能立即执行以响应从先前测试结果中获得的知识。探索性测试是应对型策略中常用的技术。
通常通过组合这些测试策略的类型来创建适当的测试策略。例如，基于风险的测试（分析型策 略）可以与探索性测试（应对型策略）相结合；它们相互补充，并且在一起使用时可以实现更有效 的测试。
虽然测试策略提供了测试过程的一般描述，而测试方法是为特定项目或版本定制的测试策略。 测试方法是选择测试技术、测试级别和测试类型，以及定义入口准则和出口准则（或分别是就绪的 定义和完成的定义）的起点。策略的定制是基于项目的复杂性和目标、正在开发的产品类型和产品 风险分析相关的决策。所选方法取决于项目背景，并可能考虑诸如风险、安全、可用资源和技能、 技术、系统性质（例如，定制与 COTS）、测试目标和法规等因素。
为了有效控制软件和测试的质量，建议使用准则来定义特定测试活动何时开始以及活动何时完 成。入口准则（敏捷开发中常称为就绪的定义）定义了进行特定测试活动的前置条件。如果不满足 入口准则，则活动可能会更难、更耗时、成本更高、风险更大。出口准则（敏捷开发中常称为完成 的定义）定义了为了声明测试级别或一组测试已完成所必须达到的条件。应为每个测试级别和测试 类型定义入口和出口准则，并根据测试目标而有所不同。
典型的入口准则包括：
典型的出口准则包括：
即使没有满足出口准则，但由于预算已耗尽、预定的时间已到、和/或将产品推向市场的压力， 测试活动被缩减是很常见的。如果项目的利益相关方和业务负责人已经评审并接受了无须进一步测 试的情况下上线的风险，那么在这种情况下结束测试是可以接受的。
一旦生成了各种测试用例和测试规程（某些测试规程可能会自动化）并集成到测试套件中，测试套件就可以安排在测试执行进度表中，该进度表定义了它们的运行顺序。测试执行进度表应考虑诸如优先级、依赖性、确认测试、回归测试和执行测试的最有效顺序等因素。
理想情况下，测试用例将基于其优先级次序运行，通常是首先执行具有最高优先级的测试用例。 但是，如果测试用例具有依赖性或者测试的功能具有依赖性，则此方法可能不适用。如果具有较高优先级的测试用例依赖于具有较低优先级的测试用例，则必须首先执行此优先级较低的测试用例。 同样，如果不同测试用例存在依赖关系，则无论其相对优先级如何，都必须对它们进行适当的顺序排序。确认测试和回归测试也必须根据变化后快速反馈的重要程度设置优先级，但这里同样需要考虑它们的依赖性。
在一些情况下，测试的不同顺序是可能的，伴随这些不同顺序会有不同的效率。在这种情况下， 必须在测试执行效率与遵守优先级之间进行权衡。
测试工作量估算包括预估为满足特定项目、发布或迭代的测试目标所需的测试相关工作量。影响测试工作量的因素可能包括产品的特性、开发过程的特性、人员的特性、和测试结果，如下所示。 产品的特点
开发过程的特点
人的特点
有许多估算方法用于确定适当测试所需的工作量。两种最常用的方法是：
例如，在敏捷开发中，燃尽图是基于度量的方法的示例，当获取和确定剩余工作量并报告，然后与团队速度（敏捷项目中生产力的度量）一起使用，以确定团队在下一次迭代中可以完成的工作 量；而计划扑克是基于专家的方法的一个例子，团队成员根据他们的经验估算出交付一个特征的工 作量（ISTQB-CTFL-AT）。
在顺序开发模型的项目中，缺陷移除模型是基于度量方法的示例，其中获得和报告了缺陷的数量和移除它们所需的时间，然后为未来估算类似性质的项目提供了基础；而宽带德尔菲估算技术是基于专家的方法的一个例子，其中专家组根据他们的经验提供估算（ISTQB-CTAL-TM）。
测试监督与控制的目的是收集信息并提供有关测试活动的反馈和可视化。可以手动或自动收集要监督的信息，这些信息可以用来评估测试进度并测量是否满足测试出口准则，或评估敏捷项目中定义的相关测试任务是否完成，例如满足产品风险、需求，或验收准则的覆盖目标。
测试控制描述了根据收集到和（可能）报告的信息和度量所采取的任何指导或纠正措施。其措施可能涵盖任何测试活动，并可能影响软件生存周期中的其他活动。
测试控制措施的示例包括：
当已识别的风险发生时（例如，软件交付延迟），重新确定测试优先级
由于测试环境或其他资源的可用或不可用而更改测试进度表
由于返工，重新评估测试项是否符合入口或出口准则
在测试活动期间和结束时收集度量，用以评估：
常见的测试度量包括：
测试报告的目的是在测试活动（例如，测试级别）期间和结束时，总结和传达测试活动信息。 在测试活动期间准备的测试报告可能被称为测试进度报告，而在测试活动结束时准备的测试报告可 能被称为测试总结报告。
在测试监督和控制期间，测试经理定期为利益相关方发布测试进度报告。除了测试进度报告和测试总结报告的常用内容之外，典型的测试进度报告还可能包括：
当达到出口准则时，测试经理会发布测试总结报告。此报告根据最新的测试进度报告和任何其他相关信息，提供所开展测试的总结。
典型的测试总结报告可能包括：
测试报告的内容将根据项目、组织要求和软件开发生存周期而有所不同。例如，一个有许多利益相关方的复杂项目，或一个受管制的项目可能比一个快速软件更新需要更详细和更严格的报告。 另一个例子，在敏捷开发中，测试进度报告可以包含在任务看板、缺陷摘要和燃尽图中，这可以在 每日站会期间讨论（参见 ISTQB-CTFL-AT）。
除了根据项目周境裁剪定制的测试报告外，还应根据报告的受众裁剪定制测试报告。提交给技术受众或测试团队的测试报告中的信息类型和数量可能与执行总结报告中包含的信息类型和数量是不同的。在第一种情况下，有关缺陷类型和趋势的详细信息可能很重要。在后一种情况下，高级别报告（例如，按优先级的缺陷状态总结、预算、进度表、和通过/未通过/未测试的测试条件）可能更合适。
ISO 标准（ISO/IEC/IEEE 29119-3）涉及两种类型的测试报告，测试进度报告和测试完成报告 （在本大纲中称为测试总结报告），并包含每种类型的结构和示例。
配置管理的目的是在整个项目和产品生存周期期间，建立和维护组件或系统、测试件以及他们之间相互关系的完整性。
为了有效支持测试，配置管理可能涉及确保以下内容：
在测试计划期间，应该识别和实施配置管理过程和基础设施（工具）。
风险涉及未来可能发生负面后果的事件。风险级别取决于事件发生的可能性以及事件的影响程度（伤害）。
产品风险涉及工作产品（例如，规格说明、组件、系统或测试）可能无法满足其用户和/或利益相关方的合法需求的可能性。当产品风险与产品的特定质量特性（例如，功能性、可靠性、性能效 率、易用性、安全性、兼容性、维护性和可移植性）相关联时，产品风险也称为质量风险。
产品风险的例子包括：
项目风险涉及的情况如果发生，可能会对项目实现目标的能力产生负面影响。项目风险的例子包括：
项目事件：
组织事件：
团队事件：
技术事件：
供应商事件：
项目风险可能会影响开发活动和测试活动。在某些情况下，项目经理负责处理所有项目风险， 但测试经理有时也会负责与测试相关的项目风险。
风险用于关注测试期间所需的工作量。它用于决定何时何地开始测试，以及确定需要更多关注的区域。测试用于降低发生不良事件的可能性，或减少不良事件的影响。测试用作风险缓解活动， 提供有关已识别风险的信息，并提供有关剩余（未解决）风险的信息。
基于风险的测试方法提供了降低产品风险水平的机会。它涉及产品风险分析，包括产品风险的识别以及每种风险的可能性和影响的评估。由此产生的产品风险信息用于指导测试计划、测试规格说明、测试用例的准备和执行，以及测试监督和控制。尽早分析产品风险有助于项目的成功。
在基于风险的方法中，产品风险分析的结果可用于：
基于风险的测试利用项目利益相关方的集体知识和洞察力来进行产品风险分析。为确保产品失效的可能性最小化。风险管理活动提供了一种严格的方法：
此外，测试可能识别新风险，帮助确定应该缓解哪些风险，并降低风险的不确定性。
由于测试的目标之一是发现缺陷，因此应记录测试期间发现的缺陷。记录缺陷的方式可能会有所不同，具体取决于所测试的组件或系统的环境、测试级别和软件开发生存周期模型。应对所发现的任何缺陷进行调查，并从发现和分类到其解决进行跟踪（例如，缺陷的修正和缺陷修正后成功进行确认测试，缺陷延迟到后续版本再修改，接受缺陷作为永久产品限制等）。为了管理所有要解决的 缺陷，组织应建立缺陷管理过程，其中包括工作流和分类规则。此过程必须与参与缺陷管理的所有 人员达成一致，包括架构师、设计人员、开发人员、测试员和产品负责人。在某些组织中，缺陷记 录和跟踪可能不一定很正式。
在缺陷管理过程中，某些报告可能会描述假阳性（误报）失效，而不是由于缺陷导致的实际失效。例如，当网络连接中断或超时，测试可能会失败。这类行为不是由测试对象中的缺陷引起的， 但这是异常情况，需要进一步进行调查。测试员应尽量减少假阳性（误报）缺陷的数量。
在编码、静态分析、评审期间，或在动态测试过程中，或软件产品的使用中都可能会报告缺陷。 可能会对代码或工作系统、或任何类型的文档（包括需求、用户故事和验收准则、开发文档、测试文档、用户手册或安装指南）中的事件报告为缺陷。为了获得有效和高效的缺陷管理过程，组织可以为缺陷的属性、分类和工作过程定义标准。
典型的缺陷报告包括以下目标：
动态测试期间提交的缺陷报告通常包括：
当使用缺陷管理工具时，上述有些内容会自动包括和/或管理，例如，在缺陷管理工具的工作流中自动分配标识符、分配和更新缺陷报告状态等。在静态测试期间，特别是评审中发现的缺陷，通 常以不同的方式记录，例如，在评审会议记录中。
可以在 ISO 标准（ISO/IEC/IEEE 29119-3）中找到缺陷报告内容的示例（其将缺陷报告称为事件报告）。
测试工具可以用于支持一种或多种测试活动。这些工具包括：
根据实际情况，测试工具可以有如下一个或多个目的：
工具可以按照多种规则进行分类，例如：目的、价格、许可证模式（例如：商业或开源）和使用的技术等。在本大纲中，是按照测试工具能支持的测试活动来进行分类。
有些工具只能支持或主要支持一种活动；有些工具可以支持多种活动，在这种情况下将它们分类到联系最紧密的那一类活动中。同一家供应商的测试工具，尤其是那些为了协同工作而设计的测试工具，可能会被集成到一个套件中。
某些类型的测试工具本身是植入式的，这意味着测试的实际结果可能会受到影响。0-能导致实际的响应时间的不同；或者使用覆盖工具可能得到了不正确的代码覆盖率。使用植入式工具导致的结果也称为探测影响（探针效应）。
某些测试工具提供的支持可能更适合开发人员（比如在进行组件和集成测试时使用的工具）。在 本节以下的分类中将这些工具用“（D）”来标记。
【支持测试和测试件管理的工具】
管理工具适用于整个软件开发生存周期中的所有测试活动。支持测试和测试件管理的工具举例如下：
这些工具除了提供测试执行、缺陷跟踪和需求管理的接口外，还提供定量分析和测试对象的报 告。它还支持追溯测试对象到需求规格说明并可提供独立的版本控制能力或提供一个外部接口。
需求管理工具储存了需求描述、需求的一些属性（包括优先级），并提供唯一的标识符以及从需 求到相应测试的可追溯性。这些工具也可以帮助识别自相矛盾或遗漏的需求。
这类工具存储并管理事件报告，即缺陷、失效、变更请求或察觉到的问题和异常，并协助管理事件的整个生命周期，为静态分析提供了可能。
严格的来说，配置管理工具并不能算是测试工具，但对测试件和相关软件的存储和版本管理时却 是必要的，尤其是当配置一个以上硬件/软件环境的时候，比如：操作系统版本、编译器、浏览器等等。
【支持静态测试的工具】
静态测试工具与第 3 章描述的活动与收益相关。工具举例如下：
通过静态分析工具能够发现的典型缺陷如下：
【支持测试设计和实施的工具】
测试设计工具旨在帮助测试设计和实施时生成可用的工作产品，包括测试用例、测试规程和测试数据。工具举例如下：
有时候，支持测试设计和实施的工具，也会支持测试执行和日志记录，或直接输出到其它支持测试执行和日志记录的工具。
【支持测试执行和日志记录的工具】
许多工具可以支持和提高测试执行和日志记录活动。工具举例如下：
【支持性能测量和动态分析的工具】
性能测量和动态分析工具对于支持性能和负载测试活动是必不可少的，因为这些活动无法有效地通过手工方式来完成。工具举例如下：
【支持专业测试要求的工具】
除了支持一般测试过程的工具外，还有许多用于支持对非功能特性的专业测试工具。
仅仅购买工具并不能保证测试自动化的成功。要让引入组织的新工具能获得真正持续的成效还需要大量投入。测试中使用工具具有潜在的收益和机会，但是同样存在风险。这对测试执行工具（通 常用作测试自动化）来说尤其正确。
使用工具支持测试执行的潜在收益包括：
使用工具支持测试的潜在风险：
为了顺利和成功实施，在选择测试执行以及测试管理工具和将它们集成到组织内时，应考虑到许多方面。
【测试执行工具】
测试执行工具使用自动化的测试脚本执行测试对象。为了获得可观收益，经常需要为这类工具投入很多工作量。
上面这些测试方法都需要有脚本语言方面的专业技术人员（测试工程师、开发人员或测试自动化专家）。当使用数据驱动或关键字驱动的测试方法时，不熟悉脚本语言的测试工程师也可以为这些预定义脚本创建测试数据和/或关键字。无论使用什么脚本技术，都需要比较每次测试的预期结果和实际结果，可以是动态的（测试执行时）或者先存储，然后在后期（测试执行结束后）进行比较。 在 ISTQB-CTAL-TAE，Fewster 1999 和 Buwalda 2001 中给出了数据驱动和关键字驱动测试方法 的更多细节和示例。 基于模型的测试（MBT）工具能够将功能规格说明以模型的方式呈现出来，比如活动图。该任务通常是通过系统设计人员来开展的。MBT 工具通过解释模型来生成测试用例规格说明，并且存储到测试管理工具和/或通过测试执行工具执行（参见 ISTQB-CTFL-MBT）。
【测试管理工具】
由于不同的原因，测试管理工具通常需要与其他工具或电子表格程序有接口，例如：
当使用集成工具时（例如：应用生存周期管理），由于包含组织中其他团队使用的测试管理模块 以及其他模块（例如：项目进度和预算信息），需要特别认真的考虑。
为组织选择工具所需要考虑的关键点有：
作为最后一步，应进行可行性研究（概念验证），以确定该工具是否在所测试的软件和当前基础设施内有效运行，或在必要时确定为有效使用该工具而需要对该基础设施进行的修改。
完成工具选择和成功进行可行性研究（概念验证）后，将选择的工具引入组织通常从试点项目开始，试点项目有以下目的：
在组织内成功地评估、实施、部署和持续支持工具的因素包括：
同样重要的是保证工具在技术上和组织上集成到软件开发生存周期中，同时包括独立负责操作的组织和/或第三方供应商。
有关使用测试执行工具的经验和建议，可以参见 Graham 2012。
如果我的场景是这样开始的:@my-tagScenarioOutline:AdminuserchangesemailGivenIregisterarandomemailaddress...是否可以在单个步骤定义中读取场景大纲文本或@my-tag？例如，在Iregisterarandomemailaddress步骤中，如果它在给定场景或标记值下运行，我想打印调试信息。 最佳答案 您不能直接从步骤定义中访问该信息。如果您需要该信息，则必须在beforeHook期间捕获它。cucumberv3+下面的beforehook将捕获特征名称、场景
1、接口的概念系统与系统之间，组件与组件之间，数据传递交互的通道2、接口的类型按协议划分：http、tcp、IP按语言划分：C++、java、PHP……按范围划分：系统之间多个内部系统之间内部系统与外部系统之间程序之间方法与方法之间、函数与函数之间、模块与模块之间3、接口测试的概念对系统或组件之间的接口进行测试，校验传递的数据正确性和逻辑依赖关系的正确行。4、接口测试的原理主要针对服务器，模拟客户端向服务器发送请求，通过工具或者代码来测试服务器针对客户端请求回发的响应数据是否与预期结果一致。5、接口测试的特点符合质量控制前移的理念可以发现一些页面操作发现不了的问题接口测试低成本高效益接口测试是
目录简介ROS诞生背景ROS的设计目标ROS与ROS2安装ROS1.配置ubuntu的软件和更新2.设置安装源3.设置key4.安装5.配置环境变量安装可能出现的问题安装构建依赖卸载ROS架构1.设计者2.维护者3.立足系统架构:ROS可以划分为三层ROS通信机制话题通信理论模型流程通信样例自定义消息的通信服务通信理论模型服务通信自定义srv参数服务器理论模型参数操作常用命令简介rosnoderostopicrosmsgrosservicerossrvrosparam常用API初始化话题与服务相关对象C++回旋函数C++对比时间1.时刻2.持续时间3.持续时间与时刻运算4.设置运行频率(非常常
Nginx实现10万+并发在优化内核时，可以做的事情很多，不过，我们通常会根据业务特点来进行调整，当Nginx作为静态web内容服务器、反向代理或者提供压缩服务器的服务器时，期内核参数的调整都是不同的，概述：由于默认的linux内核参数考虑的是最通用场景，这明显不符合用于支持高并发访问的Web服务器的定义，所以需要修改Linux内核参数，让Nginx可以拥有更高的性能；注：本文以PDF持续更新，最新尼恩架构笔记、面试题的PDF文件，请从下面的链接获取：码云参考关键的Linux内核优化参数/etc/sysctl.conf修改/etc/sysctl.conf来更改内核参数修改好配置文件，执行sys
首先，恭喜你发现了宝藏。本文章集成了2023全网优秀的开源攻防武器项目，包含：信息收集工具（自动化利用工具、资产发现工具、目录扫描工具、子域名收集工具、指纹识别工具、端口扫描工具、各种插件....etc...）漏洞利用工具（各大CMS利用工具、中间件利用工具等项目........）内网渗透工具（隧道代理、密码提取.....）应急响应工具甲方运维工具等其他安全攻防资料整理，供攻防双方使用。重点提醒：本项目工具来源于互联网，是否含带木马及后门请自行甄别！！Hvv来即，请大家提高警惕！！！受限于篇幅原因，无法全部展示，如果你需要的话，可以评论区告诉我！ 1、半/全自动化利用工具项目简介项目地址项目名
引言ChatGPT是什么？ChatGPT是一款先进的自然语言处理（NLP）模型，由OpenAI开发和维护。它基于OpenAI的第四代生成预训练Transformer（GPT-4）架构，旨在通过深度学习技术理解和生成人类语言。ChatGPT可以与用户进行自然、流畅的交流，为各种场景提供智能问答和文本生成能力。GPT-4架构继承了GPT-3的优势，同时在性能、规模和功能上得到了进一步提升。GPT-4采用了大规模的神经网络和强大的注意力机制，使得它能够在多样化的任务中表现出色，例如对话生成、自动编写文章、编程帮助等。通过在大量文本数据上进行预训练，GPT-4获得了对语言结构、语法和语义的深入理解。O
我在define(...)中编写了大量代码如以下格式-define(['angular'],function(angular){functionfoo(){console.log("Hi");}functionfoo2(){console.log("Hi");}functionfoo3(){console.log("Hi");}})Eclipse缺少所有outlineview这种格式的输出，意思是什么都不显示。如何让它支持这种格式，意思是让我了解所有函数和变量声明？这里附上了我当前的大纲View- 最佳答案 JSDT插件是JavaS
1.hook是什么?GitLabhook可用于拦截特定事件（如push代码），以便实现功能扩展。主要有两类hook：webhookscustomerhooks其中customerhooks具有客户端和服务器端配置，现在主要讲一下服务器端hook配置2.服务器端的hook怎么配置往GitLab服务器push提交点，会按顺序先后执行服务器上的pre-receive、update和post-receive三种类型的钩子脚本。2.1单仓库钩子（两种方法）方法一：找到仓库所在目录。（14.0版本以后只能靠gitlab服务器管理员寻找hash存储路径）在仓库xxx.git目录下创建custom_hooks
最全LaTeX数学公式、字母符号、上下标、列表矩阵、公式注释、分数二进制数、分割字符、逻辑集合论、否定符号等1.公式示例E(T)=∑(p,q)ϵκ∣∣p−Tq∣∣2E(T)=\sum_{(p,q)\epsilon\kappa}\mid\midp-T_q\mid\mid^2E(T)=(p,q)ϵκ∑∣∣p−Tq∣∣2E(T)=∑(p,q)ϵκ((p−Tq)⋅np)2E(T)=\sum_{(p,q)\epsilon\kappa}((p-T_q)\cdotn_p)^2E(T)=(p,q)ϵκ∑((p−Tq)⋅np)2x+y2x(hi)\bold\tag{hi}x+y^{2x}x+y2x(h
前方高能，请准备好小板凳，本文篇幅很长，由于是初学，如有不合适的还请大神指导。最近在研究C#连接Mysql，并实现数据的读写，发现里面还有很多需要注意的，研究过程也遇到不少问题，现在将本人研究的成果分享出来，供需要的朋友学习，最终界面如下图所示，左边为数据写入的功能区（将datagridview控件的数据写入到数据库文件中），右边为数据读取与编辑、添加、查询、删除功能区（将数据库文件读取到datagridview控件中，并实现datagridview控件的编辑能够映射到数据库文件中同步更改）。话不多说，下面直接上代码。1.将表格数据写入到数据库主要功能是根据数据库名称，表格名称将随机生成的da
