CSTQB笔记-基础级CTFL（更新中）

1 测试基础

1.1 什么是测试？

1.1.1 测试目的

典型的测试目的为：

评估工作产品，eg.需求、用户故事、设计和代码

触发失效并发现缺陷

确保所需的被测对象的覆盖率

降低软件质量不足的风险等级

验证是否已满足指定需求

验证测试对象是否符合合同、法律和监管要求

向利益相关方提供信息，使他们能够做出明智的决策

建立对被测对象质量的信心

确认被测对象是否完整并按利益相关方的预期工作

1.1.2 测试与调试

测试，可以触发由软件缺陷引发的失效（通过动态测试），也可以直接发现测试对象中的缺陷（通过静态测试）。

当动态测试触发失效时，调试涉及查找失效原因（缺陷）、分析并消除这些原因（缺陷）。

典型的调试过程包括：重现失效、诊断（寻找缺陷）、修复缺陷。

注：静态测试目的：发现缺陷，调试目的：消除缺陷；静态测试直接发现缺陷，不需要重现或诊断

调试过程后的测试：

确认测试：检查修复是否解决了问题。（最好由执行初始测试的同一个人来完成）
回归测试：检查修复是否导致测试对象的其他部分出现失效。

1.2 为什么需要测试？

1.2.1 测试对成功的贡献

测试提供了经济高效的发现缺陷的办法

测试提供了在软件开发生存周期（SDLC）的各个阶段直接评估测试对象质量的方法

测试为用户提供了开发项目的间接代表，测试人员确保他们对用户需求的理解贯穿于整个开发生存周期

为满足合同或法律要求，或监管标准，也可能需要进行测试

1.2.2 测试和质量保证（QA）

测试活动是以产品为导向的纠正方法，侧重于支持实现适当质量级别的活动

质量保证（QA）是以过程为导向的预防性方法，侧重于过程的实施和改进

关系：质量控制(QC)的形式包括：测试（主要形式）、形式化方法（模型检查和正确性证明）、模拟和原型设计

测试结果的使用差异：

测试中，测试结果用于修复缺陷
质量保证中，测试结果提供关于开发和测试过程执行情况的反馈

1.2.3 错误、缺陷、失效和根本原因

人会犯错误，从而产生缺陷，进而导致失效。
缺陷可以在哪里找到？------文档（eg.需求规格说明或测试脚本）、源代码、支持的工作产品（eg.构建文件）
缺陷不是一定会导致失效------某些缺陷在执行时总是会导致失效，有些在特定情况下导致失效，有些缺陷可能永远不会导致失效
导致失效的原因：错误、缺陷、环境因素...(错误和缺陷不是导致失效的唯一原因)

1.3 测试原则

测试显示了缺陷的存在，而不能说明缺陷不存在。（仅降低了测试对象中未发现缺陷的可能性）

穷尽测试是不可能的。（与其试图进行穷尽测试，不如使用测试技术、测试用例优先级和基于风险的测试来聚焦测试工作）

早期测试可以节省时间和费用。（应尽早开始静态测试和动态测试）

缺陷的集群效应。（大多数缺陷出现在少数系统组件中，或者少数系统组件是引起大多数操作失败的原因）

测试会无效。（重复多次相同的测试，在检测新缺陷方面会变得越来越无效。克服该影响的措施：可能需要修改现有的测试和测试数据，并且可能需要编写新的测试用例。特殊情况：某些情况下，重复相同的测试可能会产生有益的结果，eg.自动化回归测试中）

测试活动依赖于测试周境。（周境不同，测试方法也不同）

不存在缺陷的谬论。（期望软件验证会确保系统的成功是一种谬论，即误解。除验证外，还应进行确认。）

注：确认在前，验证在后。

确认：和用户确认是否符合需求
验证：看实现结果是否与需求相一致

1.4 测试活动、测试件和测试角色

1.4.1 测试活动和任务

测试过程由以下主要活动组成，这些活动看似遵循逻辑顺序，但通常采用迭代或并行方式实施。

测试完成	通常发生在项目里程碑处（eg.发布、迭代结束、测试级别完成），针对任何未解决的缺陷、变更请求或产品代办事项。	测试完成报告

1.4.2 周境中的测试过程

测试的执行方式将取决于多种环境因素，包括：

利益相关方（需要、期望、需求、合作意愿等）
团队成员（技能、知识、经验水平、工作效率、培训要求等）
业务领域（测试对象的重要性、已识别的风险、市场要求、特定的法律法规等）
技术因素（软件类型、产品架构、使用的技术等）
项目约束（范围、时间、预算、资源等）
组织因素（组织架构、现有政策、已在应用的实践等）
软件开发生存周期（工程实践。开发方法等）
工具（可用性、易用性、依从性等）

1.4.3 测试件

测试件是测试活动所创建的输出工作产品。适当的配置管理可确保工作产品的一致性和完整性。

测试完成	测试完成报告、后续项目或迭代的改进行动项、文档化的经验教训和变更请求（eg.产品待办事项）。

1.4.4 测试依据和测试件之间的可追溯性()

可追溯性指在测试过程中，能够清晰追踪测试依据（如需求、设计文档）与测试件（如测试用例、测试脚本）之间的关联关系。这种关联确保测试覆盖完整，便于问题定位和变更管理。

测试用例对需求的可追溯性可以验证测试用例是否覆盖了需求
测试用例对风险的可追溯性可用于评估测试对象中剩余风险的级别

1.4.5 测试活动中的角色

测试活动的2个主要角色：测试管理角色和测试角色。这两个角色所承担的活动和任务取决于项目和产品的周境、人员的技能以及组织等因素。

测试	对测试的工程（技术）方面负有整体责任	测试分析、测试设计、测试实施和测试执行等

注：

测试管理角色开展工作的方式因周境而异。例如：

在敏捷软件开发中，一些测试管理任务可由敏捷团队处理。
对于跨多个团队或整个组织的任务可由开发团队之外的测试经理执行。

测试管理角色可以由团队领导、测试经理、开发经理等担任，也可以一个人同时承担测试和测试管理的角色。

1.5 测试中的基本技能和良好实践

1.5.1 测试所需的通用技能

测试知识（例如，通过使用测试技术提高测试的有效性）
全面、细致、好奇心、注重细节、有条不紊（对识别缺陷，尤其对发现难以发现的缺陷）
良好的沟通技巧、积极的倾听、具有团队合作精神（与所有利益相关方有效互动，以可理解的方式向他人传递信息，并报告和讨论缺陷）
分析性思维、批判性思维、创造力（用以提高测试的有效性）
技术知识（提高测试效率，例如使用适当的测试工具）
领域知识（能够理解并于最终用户/业务代表沟通）

1.5.2 完整团队办法

能够在团队环境中有效地工作并积极为团队目标作出贡献，是测试人员重要的技能。完整团队方法基于这项技能构建。

完整团队方法中：

所有团员都具有各种类型任务的知识和能力，并且每个人都要对质量负责。
团队成员共享相同的工作空间（物理或虚拟），共址工作有助于沟通和互动。
可提升团队活力，产生协同效益。

测试人员与其他成员的密切合作：

与业务代表协作------帮助他们创建适合的验收测试
与开发人员协作------达成测试策略和测试自动化方法的共识
测试人员能够向团队其他成员传授测试知识，从而影响产品的开发

由于对周境的依赖，完整团队方法可能并不总是适用，某些状况下，如安全关键系统，可能需要更高水平的测试独立性。

1.5.3 测试独立性

作者和测试人员之间存在认知偏差->因此一定的独立性可以使测试人员更有效地发现缺陷。
独立性并不能取代熟悉性->开发人员可以高效地发现自己代码中的许多缺陷。

无独立性------交由作者进行测试

一定的独立性------来自作者同一团队的同行进行测试

高独立性------组织内非作者团队的测试人员进行测试

非常高的独立性------组织外部的测试人员进行测试

对于大多数项目而言，通常最好使用多个独立性级别的测试。

eg.

开发人员------组件测试和组件集成测试

测试团队------系统测试和系统集成测试

业务代表------验收测试

测试独立性的优势在于：

测试人员与开发人员相比，更可能识别出不同类型的失效和缺陷
独立的测试人员可以验证、质疑或推翻利益相关方在系统规格说明和系统实施期间所做的假设

测试独立性的缺点在于：

独立的测试人员可能会与开发团队脱离，可能导致缺乏协作、沟通出现问题或与开发团队形成对立关系
开发人员可能会丧失对质量的责任感
独立的测试人员可能被视为瓶颈，或被指责为发布延迟负有责任

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

2.1 软件开发生存周期（SDLC）中的测试

SDLC模型定义了软件开发过程中不同开发阶段和活动类型之间的逻辑和时间关系。SDLC模型的示例包括：顺序开发模型（eg.瀑布模型、V模型）、迭代开发模型（eg.螺旋模型、原型模型）和增量开发模型（eg.统一软件开发过程）。

软件开发过程中的活动也可以通过更详细的软件开发方法和敏捷实践来描述。eg.验收测试驱动开发（ATDD）、行为驱动开发（BDD）、领域驱动开发（DDD）、极限编程（XP）、特征驱动开发（FDD）、看板、精益管理、Scrum和测试驱动开发（TDD）。

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

测试活动的范围和时间安排（eg.测试级别和测试类型）
测试文档的详细程度
测试技术和测试方法的选择
测试自动化程度
测试人员的角色和职责

eg.

顺序开发模型中------无法在软件开发生存周期早期进行动态测试；
某些迭代开发模型和增量开发模型中------每个迭代中，静态测试和动态测试都可以在所有测试级别上执行；频繁的增量交付需要快速反馈和全面回归测试；
敏捷项目中------更倾向于轻量级的工作产品文档和全面测试自动化，以便更容易进行回归测试；
大部分人工测试往往使用基于经验的测试技术，不需要事前进行大量的测试分析和设计

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

良好的测试实践包括以下内容：

每个软件开发活动都有相应的测试活动，以便对所有开发活动进行质量控制
不同测试级别具有特定且不同的测试目标，可以确保测试既全面又避免冗余
给定测试级别的测试分析和设计始于相应的软件开发生存周期开发阶段，以便测试能够遵循早期测试的原则
相关工作产品的初稿完成时，测试人员应立即参与评审工作产品，以便早期测试和缺陷检索，从而支持测试左移

2.1.3 测试是软件开发的驱动力

测试驱动开发（TDD）、验收测试驱动开发（ATDD）和行为驱动开发（BDD）：

将测试定义为指导开发的手段；
测试在编写代码之前定义，实现了早期测试的原则并遵循测试左移；
支持迭代开发模型

行为驱动开发	* 用简化的自然语言编写测试用例来表达应用程序的期望行为，使利益相关方容易理解，通常使用Given/When/Then格式 * 测试用例应自动转化为可执行的测试

注：上述所有方法，通常应用自动化测试，以确保将来改写或重构的代码质量。

2.1.4 DevOps与测试

DevOps 的全称是 Development and Operations （开发与运维）。旨在通过自动化、协作（实现协同效应）和持续改进缩短软件交付周期，提高系统可靠性和效率。DevOps提倡团队的自主权、快速反馈、集成工具链以及持续集成（CI）和持续交付（CD）等技术实践。

从测试的角度看，DevOps的好处包括：

代码质量的快速反馈，并判断变更是否对现有代码产生不利影响。
持续集成（CI）通过鼓励开发人员提交高质量的代码，并辅以组件测试和静态分析，在测试中实现左移
促进自动化过程，如CI/CD，有助于建立稳定的测试环境
能更加关注非功能质量特性，如性能效率、可靠性
交付流水线的自动化，减少人工重复测试的需求
由于自动化回归测试的规模和范围，降低了回归风险

DevOps面临的风险与挑战：

必须定义和建立DevOps交付流水线
必须引入和维护CI/CD工具
测试自动化需要额外资源，这些资源可能难以建立和维护

从用户的角度来说，仍然需要人工测试。

2.1.5 左移

测试早期介入的原则有时被称为"左移"，左移原则上建议测试应早期进行，eg.代码实现或组件集成前开始测试，但不能因此忽视SDLC的后期测试。

许多良好的实践可以说明如何实现测试"左移"：

从测试人员的视角评审规格说明。通常可以发现潜在的缺陷，如规格说明表述模糊、不完整和不一致。
编码之前编写测试用例，在代码实现过程中通过测试用具运行代码。
使用持续集成（CI）和持续交付（CD），提供快速反馈和自动化组件测试，可以在代码提交到代码库时运行源代码测试
在动态测试之前或作为自动化过程的一部分对源代码进行静态分析。
在可能的情况下，从组件测试级别开始进行非功能测试。

注：

左移可能会在过程早期增加培训、工作量和成本，但可以节省过程后期的工作量和成本。
对于左移，重要的是让利益相关方相信并接受此种理念。

2.1.6 回顾与过程改进

回顾会议（也称项目总结会议和项目回顾）作为发布的里程碑。回顾会议的时间和组织方式取决于所采用的特定软件开发生存周期模型。参与者不仅限于测试人员。

哪些工作是成功的->保留
哪些工作是没成功->改进
如何整合改进->保持未来成功

应记录结果，通常作为测试完成报告的一部分。

测试的典型收益包括：

增加测试的有效性和效率（eg.实施过程改进的建议）
提高测试件的质量（eg.联合评审测试过程）
增强团队凝聚力和学习能力（eg.提出问题，列出改进点）
提高测试依据的质量（eg.处理和解决需求范围和质量方面的缺陷）
改善开发和测试之间的合作（eg.定期评审和优化协作）

2.2 测试级别和测试类型

2.2.1 测试级别（5个）

测试级别	测试对象	执行人员	测试环境	备注
组件测试（又名单元测试）	单独组件	开发人员	在开发环境中进行	特殊支持-测试用具或单元测试框架
组件集成测试（又名单元集成测试）	组件之间的接口及交互			重度依赖于集成策略方法，如自底向上集成，自顶向下集成或大爆炸集成
系统测试	整个系统或产品的总体行为或能力，包含覆盖"端到端业务"的功能测试以及针对非功能质量特性的测试	独立测试团队	非功能质量特性的测试-一个完整性系统在具有代表性的测试环境中测试-易用性测试
系统集成测试	被测系统与其他系统以及外部服务的接口的测试		最好是与运行环境类似的测试环境
验收测试	确认和展示部署准备情况（意味着系统满足了用户的业务要求）	潜在用户		验收测试的主要形式-用户验收测试（UAT）、运行验收测试、合同验收测试、法规验收测试、Alpha测试和Beta测试

为避免测试活动的重叠，测试级别可以通过（非详尽）属性列表来区分：测试对象、测试目的、测试依据、缺陷和失效、方法和职责。

2.2.2 测试类型（4 个）

功能测试：检查功能完整性、功能正确性和功能适合性
非功能测试：测试"系统表现得多好"
黑盒测试：检查系统行为是否与规格说明描述一致
白盒测试：通过测试将底层结构覆盖达到一个可以接受的水平

上述四种测试类型都可应用到所有的测试级别，尽管每个测试级别的重点有所不同。

2.2.3 确认测试和回归测试（必考点---两者的不同点）

变更，通常指对组件和系统输出的改进-增加新特征 或修改代码以移除缺陷进行修复

确认在先，回归在后

回归测试	确认变更未造成任何不良后果，包括已经经过确认测试的修复	不局限于测试对象本身，还可以与环境相关，建议首先进行影响分析以优化回归测试的范围	回归测试套件会被多次运行，用例数量会随着每次迭代或发布而有所增加 ------因此优先考虑自动化回归测试（早期开始，在持续集成（CI）时，如DevOps，最好也包括自动化回归测试）；

如果缺陷修复和/或变更发生在某些测试级别上，对测试对象进行的确认测试和/或回归测试就需要在所有涉及的测试级别上进行。

2.3 维护测试

有多不同类别的维护，可以是修正错误、应对环境变更、改进性能或改善维护性，因此，维护可以包括计划内的发布/部署和计划外的发布/部署（热修复）。

维护测试的范围通常依赖于：

变更引起的风险程度
现有系统的规模
变更的大小

维护以及维护测试的触发因素可以有以下几类：

修改，eg.计划中的改进（如，基于发布版本），修正错误产生的变更，或者热修复
运行环境的升级或者迁移
退役，如应用程序的生存周期即将结束。测试数据归档

3 静态测试

3.1 静态测试基础

3.1.3 静态测试和动态测试的差异（最大差异：是否执行软件）

静态测试直接发现缺陷 ，动态测试引发失效。

3.2.1 利益相关方早期和频繁反馈的好处

早期和频繁反馈有助于早期沟通 潜在的质量问题。

利益相关方的频繁反馈可以防止误解需求 ，确保早期理解和实施需求变更 。有助于开发团队更好地理解构建的软件，专注于利益相关方的价值最大化，积极应对识别的风险。

4 测试分析和设计

4.1 测试技术概述

测试技术支持测试人员开展测试分析（测试什么）和测试设计（如何测试）。测试技术有助于以系统的方式开发相对较小但充分的测试用例集。测试技术可以帮助测试人员定义测试条件、识别覆盖项，并识别测试数据。