前言

最近咨询和参加了 ISTQB 的基础级认证考试，至于为什么是基础级呢？之前没有了解，这个认证得从基础级考起，基础级过了才能参加高级认证，高级认证至少过 2 门才能参加专家级认证。最开始没看这些内容去做了一些模拟题，发现三分之一的题都不会做（看来基础知识还是丢的太多了）
证书是否有用看个人情况而定，不过学习的内容却是和测试职业息息相关，并且会定期更新内容，不像软考还在用 20 年前的知识。本篇根据考试点把基础级内容做了摘抄，详细内容可以参考：https://kdocs.cn/l/cb2QDOWUdHR2

测试基础

1、测试目的

典型的测试目的为：
· 评估工作产品，例如需求、用户故事、设计和代码
· 触发失效并发现缺陷
· 确保所需的被测对象的覆盖率
· 降低软件质量不足的风险级别
· 验证是否已满足指定需求
· 验证测试对象是否符合合同、法律和监管要求
· 向利益相关方提供信息，使他们能够做出明智的决策
· 建立对被测对象质量的信心认证测试工程师
· 确认被测对象是否完整并按利益相关方的预期工作

2、测试与调试

测试和调试是不同的活动。测试可以触发由软件缺陷引发的失效（通过动态测试），也可以直接发 现测试对象中的缺陷（通过静态测试）。
当动态测试触发失效时，调试涉及查找失效原因（缺陷）、分析并消除这些原因。这种情况下，典型调试过程包括：
· 重现失效
· 诊断（找到根本原因）
· 修复失效的原因
随后的确认测试将检查修复是否解决了问题。确认测试最好是由执行初始测试的同一个人来完成。
还可以执行后续的回归测试，以检查修复是否导致测试对象的其他部分出现失效
静态测试是为了发现缺陷，而调试则是为了消除缺陷。因为静态测试是直接发现缺陷，并且不会导致失效。

3、测试对成功的贡献

测试提供了经济高效的发现缺陷的方法。这些缺陷可以通过后续活动进行消除（通过调试——一种非测试活动），因此测试间接地提高测试对象的质量。
测试提供了在软件开发生存周期（SDLC）的各个阶段直接评估测试对象质量的方法。这些措施是大型项目管理活动的一部分，有助于做出进入软件开发生存周期（SDLC）下一阶段的决策，例如决定版本是否发布。
测试为用户提供了开发项目的间接代表，测试人员确保他们对用户需求的理解贯穿于整个开发生存周期。另一种方法是让用户代表参与开发项目，但由于成本高且缺乏合适的用户，通常是不好操作。
为了满足合同或法律要求，或遵守监管标准，也可能需要进行测试。

4、测试和质量保证（QA）

人们经常混用术语 “测试” 和 “质量保证”(QA)，但测试和 QA 并不相同。测试是质量控制 (QC) 的一种形式。
质量控制（QC）是以产品为导向的纠正方法，侧重于支持实现适当质量级别的活动。测试是质量控制的主要形式，而其他方法包括形式化方法（模型检查和正确性证明）、模拟和原型设计。
质量保证（QA）是以过程为导向的预防性方法，侧重于过程的实施和改进。它的工作原理是，如果正确遵循良好的过程，就会产生良好的产品。质量保证（QA）适用于开发和测试过程，是项目中每个人的责任。
测试结果会被质量保证（QA）和质量控制（QC）使用。在质量控制（QC）中，测试结果用于修复缺陷，而在质量保证（QA）中，测试结果提供关于开发和测试过程执行情况的反馈。

5、错误、缺陷、失效

人会犯错误（error、mistake），从而产生缺陷（defect、fault，bug），进而导致失效（failure）
缺陷可以在文档（如需求规格说明或测试脚本）中找到、在源代码中或者在支持工件中（例如构 建文件）找到。
软件开发生存周期（SDLC）早期生成的工件中的缺陷，如果未被发现，通常会导致生 存周期后期产生带有缺陷的工件。
如果代码中的缺陷被执行，系统可能无法按照应有的方式执行，或者执行了不应该执行的操作，从而导致失效。

6、测试原则

多年来，人们已经提出了许多测试原则，提供了适用于所有测试的通用指南。例如：
· 1.测试显示了缺陷的存在，而不能说明缺陷不存在。
· 2.穷尽测试是不可能的。
· 3.早期测试可以节省时间和费用。
· 4.缺陷的集群效应。
· 5.测试会无效。
· 6.测试活动依赖于测试周境。
· 7.不存在缺陷的谬论。
详细内容可以参考：https://kdocs.cn/l/cb2QDOWUdHR2

7、测试活动

测试过程通常由以下主要活动组成。尽管这些活动看似遵循逻辑顺序，但通常采用迭代或者并行 方式实施。这些测试活动通常需要针对系统和项目进行裁剪。
测试规划 包括定义测试目的，在整体环境的约束下选择可达到目的的最佳方法。
测试监测和控制。测试监测包括持续检查所有测试活动，并且将实际进度与计划进行比较。测试控制包括采取必要的行动来实现测试目的。
测试分析 包括分析测试依据以识别可测试的特征，定义相关测试条件的优先级，以及有关的风险和风险级别。对测试依据和测试对象进行评估，以识别它们可能包含的缺陷并评估其可测试性。测试分析通常由掌握测试技术的人员提供支持。测试分析根据可度量的覆盖准则回答 “测试什么？” 的问题。
测试设计 包含如何将测试条件转化成测试用例和其他测试件（例如，测试章程）。这项活动通常与识别覆盖项有关，可以作为具体选择哪些测试用例输入的指南。测试技术可用于支持此活动。测试设计还包括定义测试数据需求、设计测试环境以及确认所需的基础设施和工具。测试设计回答 “如何测试？” 的问题。
测试实施 包括创建或获取测试执行所需的测试件（例如测试数据）。测试用例可以被组织到测试规程中，并且经常被组装成测试套件使用。创建人工和自动化的测试脚本。为实现高效的测试执行，测试规程要按照优先级在测试执行进度表中排序。构建测试环境，并验证其设置的正确性。
测试执行 包括根据测试执行进度表执行测试（测试运行）。测试执行既可以人工进行也可以自动进行。测试执行可以采取多种形式，包括持续测试或结对测试会话。将测试的实际结果与预期结果进行比较。记录测试结果。分析导致异常发生的可能原因。该分析以观察到的失效为依据报告异常。
测试完成 活动通常发生在项目里程碑处（例如，发布、迭代结束、测试级别完成），针对任何未解决的缺陷、变更请求或产品待办事项列表。未来可能有用的测试件都会被识别并归档，或移交给适当的团队。测试环境被恢复到约定状态。对测试活动进行分析，以确定未来迭代、发布或项目的经验教训和改进。创建测试完成报告并与利益相关方沟通。

8、测试件

测试件是根据测试活动所创建的输出工作产品。不同组织在生成、结构、命名、组织和管理工作产品方面存在显著差异。适当的配置管理可确保工作产品的一致性和完整性。以下是工作产品列表的部分内容：
测试规划 工作产品包括：测试计划、测试进度表、风险记录表以及入口和出口准则
测试监测和控制 工作产品包括：测试过程报告、文档化的控制指令和风险信息
测试分析 工作产品包括：（按优先级排序）测试条件（例如，验收准则），在测试依据中发现的有关缺陷的缺陷报告（如果该缺陷还没有被直接修复）。
测试设计 工作产品包括：（按优先级排序）测试用例、测试章程、覆盖项、测试数据需求和测试环境需求。
测试实施 工作产品包括：测试规程、自动化测试脚本、测试套件、测试数据、测试执行计划和测试环境要素。测试环境要素的实例包括：桩、驱动器、模拟器和服务虚拟化。
测试执行 工作产品包括：测试日志和缺陷报告
测试完成 工作产品包括：测试完成报告、后续项目或迭代的改进行动项、文档化的经验教训和变更请求（例如，产品待办事项）。

9、测试依据和测试件之间的可追溯性

为了实施有效的测试监测和控制，测试过程中建立和维护测试依据元素、与元素相关的测试件（例如测试条件、风险、测试用例）、测试结果和发现的缺陷之间的可追溯性非常重要。
准确的可追溯性可支持覆盖评估，测试依据中定义可衡量的覆盖准则非常有用。覆盖准则可以作为关键绩效指标，推动活动的进行，以展示测试目的达成的程度。例如：
· 测试用例对需求的可追溯性可以验证测试用例是否覆盖了需求。
· 测试结果对风险的可追溯性可用于评估测试对象中剩余风险的级别。
除了评估覆盖范围之外，良好的可追溯性还可以确定变更的影响、促进测试审计，并有助于满足 IT 治理准则。良好的可追溯性还可以通过包含测试依据元素的状态，使得测试进度报告和测试完成报告更易于理解。也有助于以可理解的方式向利益相关方传达测试技术方面的问题。可追溯性提供了针对业务目标评估产品质量、过程能力和项目进展的信息。

10、测试所需的通用技能

· 测试知识（例如，通过使用测试技术提高测试的有效性）。
· 全面、细致、好奇心、注重细节、有条不紊（对识别缺陷，尤其对于发现难以发现的缺陷）。
· 良好的沟通技巧、积极的倾听、具有团队合作精神（与所有利益相关方有效互动，以可理解的方式向他人传递信息，并报告和讨论缺陷）。
· 分析性思维、批判性思维、创造力（用以提高测试的有效性）。
· 技术知识（提高测试效率，例如使用适当的测试工具）。
· 领域知识（能够理解并与最终用户/业务代表沟通）。
测试人员经常是坏消息的传递者。责怪坏消息的传递者是常见的人类特质。因此，沟通技巧对于测试人员来说至关重要。传达测试结果可能被视为对产品及其作者的批评。确认偏见（Confirmationbias）可能会使人们难以接受与当前信念不符的信息。尽管测试对项目的成功和产品质量有很大贡献，但有些人可能会将测试视为破坏性的活动。为了改善这种观点，应以建设性的方式沟通有关缺陷和失效的信息。

11、测试独立性

因为作者和测试人员之间存在认知偏差（cognitive biases）（参阅 Salman，1995），因此一定程度的独立性可以使测试人员更有效地发现缺陷。
工作产品可以交由作者进行测试（无独立性），或交由来自作者同一团队的同行进行测试（一定的独立性），或交由组织内非作者团队的测试人员进行测试（高独立性），或交由组织外部的测试人员进行测试（非常高的独立性）。对于大多数项目而言，通常最好使用多个独立性级别的测试。例如，开发人员进行组件测试和组件集成测试，测试团队进行系统测试和系统集成测试，业务代表进行验收测试。
测试独立性的主要优势在于，独立的测试人员与开发人员相比，由于背景、技术视角、以及认知偏向的差异，更可能识别出不同类型的失效和缺陷。此外，独立的测试人员可以验证、质疑或推翻利益相关方在系统规格说明和系统实施期间所做的假设。
尽管如此，测试独立性也存在一些缺点。独立的测试人员可能与开发团队脱离，可能导致缺乏协作、沟通出现问题或与开发团队形成对立关系。开发人员可能会丧失对质量的责任感。独立测试人员可能被视为瓶颈，或被指责为发布延迟负有责任。

12、软件开发生存周期中的测试

软件开发生存周期（SDLC）模型是对软件开发过程的抽象、概要表述。SDLC 模型定义了软件开发过程中不同开发阶段和活动类型之间的逻辑和时间关系。SDLC 模型的示例包括：顺序开发模型（例如瀑布模型、V 模型）、迭代开发模型（例如螺旋模型、原型模型）和增量开发模型（例如统一软件开发过程）。

13、软件开发生存周期对测试的影响

测试必须适应软件开发生存周期才能成功。软件开发生存周期的选择会对以下几个方面产生影响：
· 测试活动的范围和时间安排（例如测试级别和测试类型）
· 测试文档的详细程度
· 测试技术和测试方法的选择
· 测试自动化程度
· 测试人员的角色和职责
在顺序开发模型中，测试人员通常在软件开发的初期阶段参与需求评审、测试分析和测试设计。可执行代码通常在后期阶段创建，因此通常无法在软件开发生存周期早期进行动态测试。
在某些迭代和增量开发模型中，每次迭代都会提供可工作的增量原型或产品。也就是说在每个迭代中，静态和动态测试都可以在所有测试级别上执行。频繁的增量交付需要快速反馈和全面回归测试。
在敏捷项目中，更倾向于轻量级的工作产品文档和全面测试自动化，以便更容易进行回归测试。大部分人工测试往往使用基于经验的测试技术，不需要事前进行大量的测试分析和设计。

14、软件开发生存周期与良好的测试实践

无论选择哪种软件开发生存周期模型，良好的测试实践包括以下内容：
· 每个软件开发活动，都有相应的测试活动，以便对所有开发活动进行质量控制
· 不同测试级别具有特定且不同的测试目标，可以确保测试既全面又避免冗余
· 给定测试级别的测试分析和设计始于相应的软件开发生存周期开发阶段，以便测试能够遵循早期测试的原则
· 相关文档的初稿完成时，测试人员立即参与评审工作产品，以便早期测试和缺陷检测，从而支持测试左移方法

15、测试是软件开发的驱动力

测试驱动开发（TDD）：
· 通过测试用例来指导编码（而不是详尽的软件设计）（Beck 2003）。
· 先编写测试，后编写代码以满足测试，最后对测试和代码进行重构。
验收测试驱动开发（ATDD）：
· 作为系统设计过程的一部分，从验收准则中导出测试（Gärtner 2011）。
· 在部分应用程序开发前，编写测试，以满足测试的要求。
行为驱动开发（BDD）：
· 用简化的自然语言编写测试用例来表达应用程序的期望行为，利益相关方容易理解，通常使用 Given/When/Then 格式（Chelimsky 2010）。
· 自动将测试用例转化为可执行的测试。

16、DevOps 与测试

DevOps 提倡团队的自主权、快速反馈、集成工具链以及持续集成（CI）和持续交付（CD）等技术实践。通过 DevOps 交付流水线，软件团队可以更快地构建、测试和发布高质量的代码（Kim 2016）。
从测试的角度来看，DevOps 的好处包括：
· 代码质量的快速反馈，并判断变更是否对现有代码产生不利影响。
· 持续集成（CI）通过鼓励开发人员提交高质量的代码，并辅以组件测试和静态分析，在测试中实现左移方法。
· 促进 CI/CD 自动化过程，有助于建立稳定的测试环境。
· 更加关注非功能性质量特性（例如性能、可靠性）。
· 交付流水线的自动化，减少人工重复测试的需求。
· 由于自动化回归测试的规模和范围，降低了回归风险。
然而，DevOps 也面临着某些风险和挑战，包括：
· 必须定义和建立 DevOps 交付流水线。
· 必须引入和维护 CI/CD 工具。
· 测试自动化需要额外资源，这些资源可能难以建立和维护。
尽管 DevOps 提供了高度自动化测试，但从用户的角度来说，仍然需要人工测试。

17、测试左移的方法

测试早期介入的原则有时被称为 “左移”，这是软件开发生存周期中较早进行测试的方法。左移建议测试应该早期进行（例如，代码实现或组件集成前开始测试），但不能因此忽视软件开发生存周期的后期测试。
许多良好的实践可以说明如何实现测试 “左移”，包括：
· 从测试的角度评审规格说明。对规格说明进行评审通常可以发现潜在的缺陷，例如规格说明表述模糊、不完整和不一致。
· 编码之前编写测试用例，在代码实现过程中通过测试用具（test harness）运行代码。
· 使用持续集成（CI）和持续交付（CD），提供快速反馈和自动化组件测试，可以在代码提交到代码库时运行源代码测试。
· 在动态测试之前或作为自动化过程的一部分对源代码进行静态分析。
· 在可能的情况下，从组件测试级别开始进行非功能性测试。这是左移形式之一，因为非功能性测试类型通常在系统完整且代表性的测试环境就绪后，在软件开发生存周期的后期执行。

18、回顾与过程改进

回顾会议（也称为 “项目总结会议/post-project meetings” 和项目回顾）作为发布的里程碑，通常在项目或迭代结束后，按需召开。回顾会议的时间和组织方式取决于所采用的特定软件开发生存周期模型。主要讨论以下内容：
· 哪些工作是成功的，应予以保留？
· 哪些工作没成功，可以改进？
· 如何整合改进并保持未来成功？
回顾对于成功实施持续改进至关重要，对任何建议的改进都要进行跟踪。
测试的典型收益包括：
· 增加测试的有效性/效率（例如，实施过程改进的建议）。
· 提高测试件的质量（例如，联合评审测试过程）。
· 团队凝聚力和学习能力（例如，提出问题，列出改进点）。
· 提高测试依据的质量（例如，处理和解决需求范围和质量方面的缺陷）。
· 改善开发和测试之间的合作（例如，定期评审和优化协作）。

19、测试级别和测试类型

测试级别：
· 组件测试（也称为单元测试），侧重于对单独组件的测试。
· 组件集成测试（也称为单元集成测试），侧重于对组件之间的接口及交互进行测试。
· 系统测试，关注于对整个系统或产品的总体行为和能力，通常包含覆盖 “端到端业务” 的功能测试以及针对非功能质量特性的测试。
· 系统集成测试，侧重于对被测系统与其他系统以及外部服务的接口的测试。
· 验收测试，侧重于确认和展示部署准备情况，这意味着系统满足了用户的业务要求。
测试类型：
· 功能测试是用于评估组件或系统应该执行的功能的测试。
· 非功能测试是用于评估组件或系统除功能特性之外的其他属性。
· 黑盒测试，是基于规格说明并根据测试对象外部的文档生成测试的测试技术。
· 白盒测试，是基于结构并根据系统的实施或系统的内部结构（如代码、结构、工作流和数据流）生成测试的测试技术。

20、确认测试和回归测试

确认测试用于确认原有缺陷是否已经被成功修复的测试。包括：
· 执行先前由于存在缺陷而失败了的所有测试用例。
· 增加新的测试，以覆盖由于修复缺陷引发的任何变更。
回归测试确认变更未造成任何不良后果，包括已经经过确认测试的修复。
回归测试套件会被多次运行，通常回归测试用例的数量会随着每次迭代或发布而有所增加，因此可以优先考虑自动化回归测试。这些测试的自动化应该在项目的早期开始。在使用持续集成（CI）时，比如 DevOps，最好也包括自动化回归测试。根据情况，可能包括不同级别的回归测试。

21、静态测试

与动态测试相比，静态测试不需要执行被测软件。通过人工检查（例如评审）或借助工具（例如静态分析），对代码、过程规格说明、系统架构规格说明或其他工作产品进行评估。
测试目的包括提高质量、检测缺陷以及评估可读性、完整性、正确性、可测试性和一致性等特性。静态测试可用于验证和确认。
几乎任何工作产品都可使用静态测试进行检查。例如，需求规格说明文档、源代码、测试计划、测试用例、产品代办项、测试章程、项目文档、合同和模型。
静态测试可以在软件开发生存周期的早期阶段检测缺陷，从而实现早期测试的原则。静态测试还可以识别动态测试无法检测到的缺陷（例如，无法访问的代码、没有按预定实现的设计模式、不可执行的工作产品缺陷）。
与动态测试相比，静态分析可以更有效地检测代码缺陷，从而减少代码缺陷的数量，并且降低开发的总体工作量。

22、静态测试和动态测试差异

静态测试和动态测试相辅相成。二者具有相似的目的，例如支持工作产品中缺陷的检测，但也存在一些差异，例如：
· 静态测试和动态测试（通过失效分析）都可以检测错误，但是有些错误类型只能通过静态测试或动态测试来发现。
· 静态测试直接发现缺陷，而动态测试引发失效，并通过随后的分析确定相关缺陷。
· 静态测试可以更容易检测出在代码路径上的缺陷，这些缺陷在动态测试中很少被执行，或很难到达。
· 静态测试可用于不可执行的工作产品，而动态测试只能用于可执行的工作产品。
· 静态测试可用于测量不依赖于执行代码的质量特性（例如，维护性），而动态测试可用于测量依赖于执行代码的质量特性（例如，性能效率）。
通过静态测试更容易和/或更经济地发现的典型缺陷包括：
· 需求缺陷（例如，不一致、含糊不清、矛盾、遗漏、不准确、重复）。
· 设计缺陷（例如，低效的数据库结构、模块化程度低）。
· 特定类型的代码缺陷（例如，未定义值的变量、未声明的变量、无法访问或重复的代码、过度复杂的代码）。
· 与标准的偏差（例如，未遵守编码规范中的命名约定）。
· 错误的接口规格说明（例如，参数的数量、类型或顺序不匹配）。
· 特定类型的安全性漏洞（例如，缓冲区溢出）。
· 测试依据覆盖的差距或不准确（例如，验收准则的漏试）。

23、测试用例设计

等价类划分：
· 基于给定分区中的所有元素都会被测试对象以相同方式处理的预期将数据划分为多个分区（称为等价类）。如果测试用例测试了等价类中的一个值，并检测到缺
陷，那么任何来自同一等价类的其他值的测试用例也应该能够检测到这个缺陷。因此，每个分区执行一个测试就足够了。包含有效值的分区称为有效等价类。包含无效值的分区称为无效等价类。
边界值分析：
· 边界值分析（BVA）是基于执行等价类边界的技术。因此，边界值分析只能用于有序分区。分区的最小值和最大值是它的边界值。
· 二值边界值分析中（Craig 2002，Myers 2011），每个边界值都有两个覆盖项：该边界值以及属于相邻分区的最近邻值。为了让二值边界值达到 100% 的覆盖率，测试用例必须执行所有的覆盖项，即所有已识别的边界值。覆盖率是由已被执行的边界值的数量，除以已识别的边界值总数度量，并以百分比表示。
· 三值边界值分析中（Koomen 2006，O’Regan 2019），每个边界值都有三个覆盖项：该边界值以及两侧的相邻值。因此，在三值边界值分析中，某些覆盖项可能不是边界值。为了让三值边界值分析达到 100% 的覆盖率，测试用例必须执行所有的覆盖项，即已识别的边界值及其相邻值。覆盖率是由已被执行的边界值及其相邻值的数量，除以已识别的边界值及其相邻值的总数度量，并以百分比表示。
判定表测试：
· 判定表用于测试系统需求的实现，这些需求指定了不同的条件组合产生不同的结果。判定表是记录复杂逻辑（如业务规则）的有效方法。
· 条件的符号如下：“T”（true）表示满足条件；“F”（false）表示不满足条件；“-” 表示条件的取值与动作结果不相关；“N/A” 表示该条件对于给定的规则是不可行的。动作中的 “X” 表示动作应该发生；空白表示动作不应该发生。
状态转移测试：
· 状态转移图通过显示系统可能的状态和有效的状态转移来模拟系统的行为。转移由事件触发，该事件可能由守护条件进一步限定。假设转移是瞬时的，有时可能导致软件采取动作。常见的转移标签语法如下：“事件 [守护条件] / 动作”。
· 基于状态转移图或状态表的测试用例通常表示为事件序列，这些事件会导致一系列的状态变化（和动作，如果需要）。一个测试用例可以并且通常会覆盖状态之间的若干次转移。
状态转移测试有多种覆盖准则，本次讨论其中的三种：
· 在全状态覆盖中，覆盖项是状态。为了达到 100% 的全状态覆盖率，测试用例必须确保所有状态都被访问到。
· 在有效转移覆盖（也称为 0-switch 覆盖）中，覆盖项是单个有效转移。为了达到 100% 的覆盖率，测试用例必须执行所有的有效转移。
· 在全转移覆盖中，覆盖项是状态表中显示的所有转移。为了达到 100% 的全转移覆盖率，测试用例必须执行所有的有效转移，并尝试执行无效转移。在单个测试用例中仅测试一个无效转移有助于避免错误屏蔽，即一个缺陷阻止另一个缺陷被发现的情况。

24、白盒测试技术

所有白盒技术都具有的基本优点是，在测试期间考虑到整个软件实现，这有助于在软件规格说明模糊、过时或不完整时检测缺陷。
仅执行黑盒测试不能提供实际代码覆盖率的度量。白盒覆盖率的度量数据提供了客观的覆盖率度量，并提供了必要的信息，以允许生成额外的测试来提高覆盖率，从而增加对代码的信心。本文介绍两种与代码相关的白盒测试技术：
· 语句测试：在语句测试中，覆盖项是可执行语句。目的是设计测试用例，通过执行代码中的语句，直到达到可接受的覆盖率级别。达到 100% 语句覆盖率时，能确保代码中的所有可执行语句至少已被执行过一次。
· 分支测试：在控制流图中，分支指的是两个节点之间的控制转移，它显示了源代码语句在测试对象中执行时的可能顺序。每次控制转移可以是无条件的（如直线式代码）或有条件的（如判定结果）。在分支测试中，覆盖项是分支。目的是设计测试用例，以执行代码中的分支，直到达成可接受的覆盖率级别为止。当达到 100% 的分支覆盖时，代码中的所有分支，不满足条件的以及满足条件的，都被测试用例执行。分支覆盖包含语句覆盖。任何一组测试用例，如果实现了 100% 的分支覆盖率，也就实现了 100% 的语句覆盖率（但反之不成立）。

25、基于经验的测试技术

以下各节将讨论常用的基于经验的测试技术：
· 错误猜测：错误猜测是基于测试人员的知识来预测错误、缺陷和失效发生的技术，包括：以前软件的运行方式、开发人员常犯的错误类型以及由这些错误导致的缺陷类型、其他类似应用软件产生的失效类型。故障攻击是实现错误猜测的一种系统方法。这项技术要求测试人员创建或获取一份可能的错误、缺陷和失效列表，并设计测试来识别与缺陷相关的错误、暴露缺陷、或导致失效。
· 探索性测试：测试人员在了解有关测试对象的同时，设计、执行和评估测试。这种测试用于更深入地了解测试对象，使用重点测试进行深入探索，并为未测试的区域创建测试。测试人员使用包含测试目的的测试章程来指导测试。探索性测试在规格说明文档较少或不充分时，或测试的时间压力大的情况下很有帮助。探索性测试
也有助于作为对其他更正式测试技术的补充。
· 基于检查表的测试：测试人员设计、实施和执行测试以覆盖检查表中的测试条件。检查表可以基于经验、对用户重要的知识，或者对软件失效原因和方式的理解来构建。在缺乏详细的测试用例的情况下，基于检查表的测试可以为测试提供指南和某种程度的一致性。

26、验收准则

用户故事的验收准则是实现用户故事必须满足的条件，以便被利益相关方接受。从这个角度来看，验收准则可以被视为测试应该覆盖的测试条件。验收准则通常是对话的结果，验收准则用于：
· 定义用户故事的范围。
· 利益相关方之间达成共识。
· 描述正向和反向场景。
· 作为用户故事验收测试的依据。
· 实现准确规划和估算。
编写用户故事的验收准则有几种方式。最常见的两种格式是：
· 面向场景（例如，BDD 中使用的 Given/When/Then 格式）
· 面向规则（例如，要点验证列表，或输入 - 输出（I/O）映射的表格形式）

27、验收测试驱动开发 (ATDD)

ATDD 是测试先行（test-first）的一种方法。测试用例在实现用户故事之前创建。测试用例由具有不同视角的团队成员创建，例如客户、开发人员和测试人员（Adzic 2009）。测试用例可以人工或自动化执行。
第一步是进行规格说明讨论会，在此过程中解决了用户故事中的不完整、模糊或缺陷。
下一步是创建测试用例，可以由整个团队或测试人员单独完成。测试用例基于验收准则，并且视为软件运行方式的实例。
通常，第一批测试用例是正向测试，确认在没有异常或错误条件下的正确行为，并包括按照预期执行的活动序列。在完成正向测试用例后，团队应进行反向测试。最后，团队还应涵盖非功能质量特性（例如性能效率、易用性）。
测试用例必须覆盖用户故事的所有特性，并且不应超出故事范围。
当以测试自动化框架支持的格式进行捕获时，开发人员可以在实现用户故事描述的特征时编写支持代码，从而自动化测试用例。

28、测试人员对迭代和发布规划的贡献

在迭代软件开发生存周期（SDLC）中，通常会出现两种规划：发布规划和迭代规划。
发布规划着眼于产品的发布，定义和重新定义产品待办事项，并可能涉及将较大的用户故事细化为一组较小的用户故事。它还作为跨所有迭代中测试方法和测试计划的基础。参与发布规划的测试人员参与编写可测试的用户故事和验收准则，参与项目和质量风险分析，估算与用户故事相关的测试工作量，确定测试方法，并为发布计划进行测试。
迭代规划着眼于完成单个迭代，并关注迭代待办事项。参与迭代规划的测试人员参与用户故事的详细风险分析，确定用户故事的可测试性，将用户故事分解为任务（尤其是测试任务），估算所有测试任务的测试工作量，并识别和细化测试对象的功能和非功能方面。

29、测试入口准则和测试出口准则

入口准则定义了开展特定活动的先决条件。如果不符合入口准则，这项活动很可能会变得更困难、耗时、成本高昂、风险更大。出口准则定义了完成测试活动必须达到的目标。
典型的入口准则包括：资源的可用性（例如，人员、工具、环境、测试数据、预算、时间）、测试件的可用性（例如，测试依据、可测试的需求、用户故事、测试用例）和测试对象的初始质量水平（例如，所有冒烟测试都已通过）。
典型的出口准则包括：充分性度量（例如，已实现的覆盖级别、未解决的缺陷数量、缺陷密度、失败的测试用例数量）和完成标准（例如，已执行计划的测试、已执行的静态测试、已报告发现的所有缺陷、已自动化的所有回归测试）。

30、估算技术

测试工作量估算包括预测满足测试项目目的所需的测试相关工作量。小任务的估算通常比大任务的估算更准确。因此，当估算大任务时，可以将其分解为一组较小的任务，然后再对其进行估算。
· 基于比率的估算。例如，如果在以前的项目中，开发与测试的工作量比为 3:2，而在当前项目中，预计开发工作量为 600 人日，那么测试工作量可以估算为 400 人日。
· 外推。例如，团队可以将即将迭代的测试工作量外推为最近三次迭代的平均工作量。
· 宽带德尔菲。这是基于专家的迭代技术，专家进行基于经验的估算。每一位专家独立估算工作量。收集到的结果如果存在超出商定边界范围的偏差，专家们将讨论他们目前的估算。然后，要求每个专家根据反馈重新独立估算。不断重复此过程，直到达成共识。
· 三点估算。在这种基于专家的技术中，专家做出三个估算：最乐观的估算（a）、最可能的估算（m）和最悲观的估算（b）。最终估算（E）是它们的加权算术平均值。在该技术最流行的版本中，估算值计算为 E=（a+4*m+b）/6。该技术的优点是允许专家计算测量误差：SD=（b–a）/6。例如，如果估算值（人时）为：a=6，m=9 和 b=18，则最终估算值为 10±2 人时（即 8 至 12 人时），因为 E=（6+4*9+18）/6=10，SD=（18-6）/6=2。

31、测试用例优先级排序

最常用的测试用例优先级策略如下：
· 基于风险的优先级：测试执行顺序基于风险分析的结果。优先执行覆盖最重要风险的测试用例。
· 基于覆盖范围的优先级：测试执行顺序基于覆盖（例如，语句覆盖）。优先执行覆盖率最高的测试用例。另外一种优先级策略称为附加覆盖优先级，优先执行能达到最高覆盖的测试用例；后续的每个测试用例都是达到最高附加覆盖率的测试用例。
· 基于需求的优先级：测试执行的顺序基于测试用例对应需求的优先级。需求优先级由利益相关方定义。优先执行最重要需求相关的测试用例。

32、测试金字塔

测试金字塔是表明不同测试可能具有不同颗粒度的模型。通过说明不同级别的测试自动化支持的不同目标，测试金字塔模型支持团队的测试自动化和测试工作量分配。各金字塔层表示测试集。层越高，测试颗粒度就越粗，测试独立性越弱和测试执行速度越慢。底层的测试规模小、独立性强、快速，只检查部分功能，因此通常需要大量测试来实现合理的覆盖率。顶层代表复杂的、高级别的、端到端的测试。这些高层的测试通常比底层的测试慢，并且它们通常检查大块的功能，因此通常只需要其中的几个测试就可以实现合理的覆盖。
最初的测试金字塔模型（Cohn 2009）定义了三层：“单元/组件测试”、“服务测试” 和 “UI 测试”。另一个流行的模型定义了单元（组件）测试、集成（组件集成）测试和端到端测试。也可以使用其他测试级别。

33、测试象限

Brian Marick（Marick 2003，Crispin 2008）定义的测试象限将敏捷软件开发中的测试级别与适当的测试类型、活动、测试技术和工作产品组合在一起。
该模型可视化了这些内容，以确保所有适当的测试类型和测试级别都包含在 SDLC 中，解释了某些测试类型比其他测试类型与某些测试级别相关性更强，以此支持测试管理。在这个模型中，测试可以是面向业务的，也可以是面向技术的。测试还可以支持团队（即指导开发）或评价产品（即根据预期衡量其行为）。这两种观点的结合决定了四个象限：
· 象限 Q1（面向技术，支持团队）。此象限包含组件和组件集成测试。这些测试应该是自动化的，并包含在持续集成（CI）过程中。
· 象限 Q2（面向业务，支持团队）。此象限包含功能测试、实例、用户故事测试、用户体验原型、API 测试和模拟测试。这些测试检查验收准则，可以是人工的，也可以是自动的。
· 象限 Q3（面向业务，评价产品）。这个象限包含探索性测试、易用性测试和用户验收测试。这些测试是面向用户的，通常是人工测试。
· 象限 Q4（面向技术，评价产品）。此象限包含冒烟测试和非功能性测试（易用性测试除外）。这些测试通常是自动化的。

34、风险管理

风险管理的主要活动包括：
风险分析。产品风险分析包括风险识别和风险评估。风险识别就是生成一份全面的风险清单。风险评估包括：对已识别的风险进行分类，确定其风险可能性、风险影响和级别，确定优先级，并提出处理方法。
产品风险分析可能会影响测试的充分性和范围。其结果可以用于：
· 确定要进行的测试范围。
· 确定特定的测试级别，提供建议执行的测试类型。
· 确定采用的测试技术和达到的覆盖。
· 估算每项任务所需的测试工作量。
· 进行测试优先级排序，以尽早发现关键缺陷。
· 确定是否可以采用除测试之外的其他活动来降低风险。
风险控制。产品风险控制包括为应对已识别和评估的产品风险而采取的所有措施。产品风险控制由风险缓解和风险监测组成。风险缓解包括实施风险评估中提出的行动，以降低风险级别。风险监测的目的是确保缓解行动有效，获取进一步信息以改进风险评估，以及识别新出现的风险。
风险分析后，可能有多种风险应对方案，例如通过测试缓解风险、接受风险、转移风险或应急计划（Veenendaal 2012）。可以通过测试缓解产品风险的活动如下：
· 选择具有适当经验和技能水平、适合特定风险类型的测试人员。
· 应用适当级别的测试独立性。
· 实施评审及静态分析。
· 应用适当的测试技术和覆盖级别。
· 针对受影响的质量特性应用适当的测试类型。
· 执行动态测试，包括回归测试。

35、测试监测、测试控制和测试完成

测试监测关注测试相关信息的收集。该信息可用于评估测试过程，并测量测试出口准则或与测试出口准则关联的测试活动是否已经满足，例如产品风险、需求、或验收准则是否达到了覆盖目标。
测试控制通过使用测试监测提供的信息，以控制指令的方式提供指导或必要的纠正措施，以达成最有效和最高效的测试。
控制指令的示例包括：
· 已识别的风险成为问题时，重新确定测试优先级。
· 重新评估由于返工而导致的测试项是否满足入口或出口准则。
· 调整测试进度表以应对测试环境交付延迟的问题。
· 在必要的时间和地点增加新资源。
测试完成从已完成的测试活动中收集数据，总结经验、整合测试件和收集任何其他相关信息。测试完成活动发生在项目里程碑处，如测试级别已完成、敏捷的迭代已结束、测试项目已完成（或取消）、软件系统已发布、或维护版本已完成。
常见的测试中使用的度量包括：
· 项目进度度量（如：任务完成情况、资源使用情况、测试工作量）。
· 测试进度度量（如：测试用例实施进度、测试环境准备进度、已执行/未执行测试用例数、通过/失败的测试用例数、测试执行时间）。
· 产品质量度量（如：可用性、响应时间、平均失效时间）。
· 缺陷度量（如：发现和修复的缺陷数和优先级、缺陷密度、缺陷检测率）。
· 风险度量（如：遗留风险级别）。
· 覆盖率度量（如：需求覆盖率、代码覆盖率）。
· 成本度量（如：测试成本、组织的质量成本）。
在测试监测和控制期间，测试团队为了让利益相关方随时了解情况，向他们提供测试进度报告。测试进度报告通常以固定频率（如：每天、每周等）生成，包括：
· 测试周期。
· 测试进度（如：进度提前或延迟），包括任何显著偏差。
· 测试的阻碍及解决方案。
· 测试度量。
· 测试周期内的新风险和变化的风险。
· 为下一周期计划测试。
测试完成报告使用测试进度报告和其他数据。典型的测试完成报告包括：
· 测试总结。
· 基于原始测试计划（即：测试目的和出口准则）的测试和产品质量评估。
· 与测试计划的偏差（如：与计划的进度表、持续时间和工作量的差异）。
· 测试障碍和解决方案。
· 基于测试进度报告的测试度量。
· 未缓解的风险，未修复的缺陷。
· 与测试相关的经验教训。
沟通测试状态，可能的选项包括：
· 与团队成员和其他利益相关方进行口头沟通。
· 仪表盘（如：CI/CD 仪表盘、任务板、燃尽图）。
· 电子沟通渠道（如：电子邮件、聊天工具）。
· 在线文档。
· 正式测试报告。

36、配置管理

在测试中，配置管理（CM）提供了识别、控制和跟踪工作产品的规程，如测试计划、测试策略、测试条件、测试用例、测试脚本、测试结果、测试日志和测试报告作为配置项。为了恰当的支持测试工作，配置管理（CM）确保：
· 所有的配置项，包括测试项（测试对象的各个部分），均唯一标识、版本控制、变更跟踪，并与其他配置项建立关联，以确保在整个测试过程中的可追溯性。
· 所有标识的文档和软件项在测试文档中都被明确引用。
持续集成、持续交付、持续部署以及和其相关的测试通常作为自动化的 DevOps 流水线的一部分来实现，其中通常包括自动化的配置管理（CM）。

37、缺陷管理

发现缺陷是测试的主要目标之一，在软件生存周期中的任何阶段都可能报告异常，其形式取决于软件生存周期。缺陷管理过程至少包括处理从发现到关闭各个异常的工作流程以及分类规则。工作流程通常包括记录报告的异常、分析和分类、决定适当的响应（如修复或保持原样）以及最终关闭缺陷报告的活动。
典型的缺陷报告包括以下目的：
· 向负责处理和解决缺陷报告的人员提供足够信息，以解决问题。
· 为跟踪工作产品质量提供途径。
· 为改进开发和测试过程提供思路。
动态测试期间记录的缺陷报告通常包括：
· 唯一标识符。
· 标题，简要总结所报告的异常情况。
· 发现异常的日期、提交的组织、作者及其角色。
· 测试对象和测试环境的标识。
· 缺陷的周境（如：运行的测试用例、执行的测试活动、软件生存周期阶段，以及其他相关信息，如使用的测试技术、检查表或测试数据）。
· 重现失效和解决方案的描述，包括可检测到异常的步骤、以及任何相关的测试日志、数据库转储、屏幕截图或者记录。
· 期望结果和实际结果。
· 缺陷针对利益相关方的利益或需求的严重程度（影响程度）。
· 修复的优先级。
· 缺陷的状态（如：打开、延迟、重复、待修复、待确认测试、重新打开、关闭、拒绝）。
· 引用（如：测试用例）。

38、测试活动中的工具支持

测试工具支持并促进许多测试活动。示例包括但不限于：
· 管理工具 — 通过促进 SDLC、需求、测试、缺陷和配置的管理，提高测试过程的效率。
· 静态测试工具 — 支持测试人员执行评审和静态分析。
· 测试设计和实施工具 — 有助于生成测试用例、测试数据和测试规程。
· 测试执行和覆盖工具 — 有助于自动化测试执行和复盖率测量。
· 非功能性测试工具 — 允许测试人员执行难以执行或不可能人工执行的非功能性测试。
· DevOps 工具 — 支持 DevOps 交付流水线、工作流跟踪、自动化构建过程、CI/CD。
· 协作工具 — 促进沟通。
· 支持可扩展性和部署标准化的工具（例如，虚拟机、容器化工具）。
· 其他有助于测试的工具（例如，电子表格是测试活动环境中的测试工具）。

39、测试自动化的收益和风险

仅仅获得测试工具并不能保证成功，每种新工具都需要付出努力才能实现真正持久的收益（例如，工具的引入、维护和培训）。另外，工具存在风险，需要加以分析和缓解。
应用测试自动化的潜在收益包括：
· 减少重复性的人工活动以节省时间。
· 通过更高的一致性和可重复性来防止简单的人为错误。
· 更客观的评估（例如，覆盖率），并提供人工无法实现的过于复杂的测量。
· 更容易得到测试的相关信息，以支持测试管理和测试报告。
· 减少测试执行时间，以提供更早的缺陷检测、更快的反馈和更早时间的上市。
· 让测试人员有更多时间设计新的、更深入、更有效的测试。
应用测试自动化的潜在风险包括：
· 对工具抱有不切实际的期望。
· 对引入工具、维护测试脚本和更改现有人工测试过程所需的时间、成本和人力的估计不准确。
· 适合人工测试时，却使用测试工具。
· 过于依赖工具，例如忽视了必要的测试人员的批判性思维。
· 所依赖的工具供应商可能会倒闭、工具可能会报废、工具供应商将工具出售给其他供应商，或工具供应商提供较差的支持。
· 使用可能被遗弃的开源软件，开源软件没有办法升级更新，或者如要进一步的开发其内部组件可能需要相当频繁的更新。
· 自动化工具与开发平台不兼容。
· 没有选择符合监管要求和/或安全标准的合适工具。

其他
以上就是基础级考试内容的测试基础部分的摘抄，基本上 1 个点对应 1 个衍生题，对应的模拟题为：
CTFL_基础级 4.0 版模拟卷 A 问题 v1.0_CN1.0（中文版）https://kdocs.cn/l/cpEdh7v6qMOq
CTFL_基础级 4.0 版模拟卷 A 答案 v1.0_CN1.0（中文版）https://kdocs.cn/l/coLqXVN8usph
CTFL_基础级 4.0 版模拟卷 B 问题 v1.6_CN1.0（中文版）https://kdocs.cn/l/cdLqbasOJbrS
CTFL_基础级 4.0 版模拟卷 B 答案 v1.6_CN1.0（中文版）https://kdocs.cn/l/cadjE9b0IFvU
CTFL_基础级 4.0 版模拟卷 C 问题 v1.5_CN1.0（中文版）https://kdocs.cn/l/cayTH6mYLoc1
CTFL_基础级 4.0 版模拟卷 C 答案 v1.5_CN1.0（中文版）https://kdocs.cn/l/cnpPb0XnOhb6
CTFL_基础级 4.0 版模拟卷 D 问题 v1.4_CN1.0（中文版）https://kdocs.cn/l/ckpFcto8nFVi
CTFL_基础级 4.0 版模拟卷 D 答案 v1.4_CN1.0（中文版）https://kdocs.cn/l/ciCaPRbCnzg9