第 1-3 章：基础/SDLC/静态测试

• 瀑布、敏捷、DevOps 三种开发模型下测试时机的差异
• 测试活动在 SDLC 中的定位与前置后置关系
• 不同模型中测试角色的扮演与最佳实践

在瀑布模型中，测试是顺序的验证阶段，各开发阶段（需求、设计、编码）完成后才进入系统测试，测试发现缺陷的成本高、返工量大，因此最佳实践是尽早进行静态测试与评审、明确各阶段退出准则。在敏捷模型中，测试与开发并行、在每个迭代内集成，测试右移到验收、左移到用户故事细化和验收标准（ATDD/TDD），测试人员与开发、产品组成跨职能团队，测试自动化成为核心。在 DevOps 模型中，测试与 CI/CD 流水线深度融合，属于持续测试（Continuous Testing），测试脚本在每次提交、构建、部署时自动执行，并行测试、环境即代码、生产环境监测（测试右移）成为常态。CTFL v4 强调测试应贯穿整个 SDLC 而非独立阶段，并随模型差异调整测试策略与自动化程度。

核心是"测试与开发模型的适配性"——不同的 SDLC 决定了测试的时机、节奏、自动化程度与反馈闭环。测试者应能说明每种模型下测试如何前置后置，以及质量如何内建。

• 测试与调试目标的本质区别
• 两者的输入输出与责任分工
• 测试人员与开发人员在此过程中的角色

测试（Testing）的目标是发现缺陷并提供质量信息，属于验证活动，其输入是测试件与测试用例，输出是测试结果与缺陷报告；测试可由测试人员执行，且测试本身不改变被测代码。调试（Debugging）的目标是定位根本原因并修复缺陷，属于开发活动，其输入是缺陷现象与相关证据，输出是修复后的代码与缺陷修复记录；调试通常由开发人员完成，涉及分析、定位、修改和验证。二者责任边界清晰：测试发现"存在缺陷的证据"，调试找出"缺陷在哪、如何修"。工具上，测试更多使用测试设计与管理工具、自动化测试框架、覆盖率工具；调试更多使用调试器、日志分析、性能剖析器、断点追踪。CTFL v4 强调测试人员不应混淆二者，测试发现缺陷后应移交开发进行调试，测试人员再验证修复。

这是 ISTQB 基础概念，常考二者的目标与责任差异。测试是"初始验证"，调试是"修复活动"，测试不修复、调试不负责系统性验证，二者结合才完成缺陷闭环。

• 静态测试的定义与收益（早期发现缺陷、降低成本）
• 四种评审类型的严格程度与适用场景
• 评审与静态分析的关系

静态测试不执行被测代码，通过检查工作产品（需求、设计、代码、文档）来发现缺陷，主要手段是评审（Review）与静态分析。其收益包括：早期发现缺陷、降低缺陷修复成本、发现"执行中难以发现"的缺陷（如规范不符合、死代码、逻辑缺陷）、提高质量意识与团队沟通。四种评审类型按严格程度递增：非正式评审（Informal Review）最轻量，无需正式流程，适合快速检查与达成共识；走查（Walkthrough）由作者带领逐步解说，适合教学、达成理解与发现缺陷；技术评审（Technical Review）由技术专家基于技术规范检查，适合评估技术方案与发现技术缺陷；审查（Inspection）最正式，有明确角色、检查清单与度量收集，适合高风险、高价值且需要严格质量保证的工作产品。CTFL v4 建议根据风险与目的选择评审类型。

评审类型的选择依据是"严格程度与成本"的权衡。审查最严格但成本最高，适用于关键交付物；非正式评审最轻量，适用于日常同步。静态测试的价值在于前置发现缺陷。

• 测试计划在敏捷中的轻量化与持续演进
• 测试监控与控制如何在迭代中实时执行
• 敏捷中质量内建与每日反馈

在敏捷迭代中，测试计划不再是一次性的大文档，而是转化为轻量、持续演进的活动：测试计划在计划会议（Sprint Planning）中细化，覆盖迭代范围、测试策略、测试环境与风险，并写入迭代任务；测试监控通过每日站会、看板、燃尽图、测试自动化报告等实时跟踪进度与质量，关注通过率、缺陷数量、覆盖率等指标；测试控制则根据监控结果在迭代内快速调整——如发现缺陷爆炸则增加测试时间、调整优先级、缩减非关键测试范围。CTFL v4 强调敏捷中测试计划是"持续性的"而非"阶段性的"，测试人员在迭代中持续协作，监控与控制紧密嵌入每日节奏，避免交付末期才暴露问题。

敏捷的裁剪核心是"轻量化、持续化、反馈闭环"。测试计划、监控、控制从集中的正式活动变为嵌入迭代节奏的协作活动，强调实时反馈与快速调整。

• 七个测试活动的基本顺序与依赖
• 每个活动的输入输出
• 测试流程与测试级别的映射

七个测试活动构成测试流程：计划（Test Planning）输入为测试基准、项目约束与风险，输出为测试计划与通过/退出准则；监控（Test Monitoring）输入为测试计划与执行数据，输出为进度报告与偏差；分析（Test Analysis）输入为测试基准与需求，输出为测试条件；设计（Test Design）输入为测试条件，输出为测试用例与需求追踪；实现（Test Implementation）输入为测试用例，输出为测试脚本、测试数据与测试环境；执行（Test Execution）输入为测试环境与测试脚本，输出为测试日志与缺陷报告；完成（Test Completion）输入为测试结果与缺陷数据，输出为测试总结报告与经验教训。这些活动在瀑布中顺序执行，在敏捷中可重叠、增量进行。

七个活动是 ISTQB 测试流程的核心，理解其输入输出能帮助测试者系统规划测试工作。CTFL v4 强调活动可裁剪、可重叠，但逻辑依赖关系清晰。

• 测试左移的内涵（前置到需求/设计/编码）
• 测试右移的内涵（延伸到生产/运行环境）
• 两者结合的持续质量保障

测试左移（Shift-Left）指将测试活动尽可能提前到 SDLC 早期，包括在需求阶段进行评审与验收标准定义（ATDD）、在设计阶段进行评审与测试设计、编码阶段通过 TDD/静态分析/单元测试即时验证，从而在缺陷成本最低的阶段发现并修复问题。测试右移（Shift-Right）指将质量验证延伸到生产环境与实际运行，包括金丝雀发布、灰度验证、生产监控、A/B 测试、用户反馈与生产日志分析，以验证真实用户场景与系统在真实负载下的表现。左移降低缺陷成本、提升效率，右移验证真实体验与可靠性，二者结合实现"建-测-运"全链路质量保障。CTFL v4 强调测试应贯穿 SDLC 全阶段，而非仅中间的一段。

左移是"尽早测"，右移是"在真实环境验"。二者互补：左移解决"缺陷成本高"，右移解决"测试环境与生产环境差异"。测试者应能说明各自的具体手段与价值。

• 静态分析工具的定位与技术手段
• 静态分析的局限性（误报、漏报、无法发现运行时问题）
• 静态分析与评审的互补

静态分析工具通过扫描源代码（不执行）来检测潜在缺陷，如未初始化变量、空指针、越界、死代码、安全漏洞、代码规范违规等，其定位是自动化、快速地完成人类评审难以覆盖的检查，适合在 CI 中持续运行。但静态分析工具存在明显局限：一是大量误报（False Positive），需要人工确认；二是可能漏报（False Negative），难以发现复杂的逻辑缺陷、并发问题、业务逻辑错误；三是它只能分析"代码内部"，无法发现需求缺陷、设计缺陷与运行时行为问题。因此静态分析应与评审互补——评审发现人为主的逻辑与需求问题，静态分析发现规则性的代码问题，两者结合覆盖更全面。

静态分析工具是"自动化检查规则"，适合检测可规则化的缺陷，但不是万能的。测试者应了解其优势与误报/漏报平衡，避免过度依赖工具。

• 评审者独立程度与缺陷发现能力的关系
• 独立性与测试心理学（盲点、偏见）的关联
• 有效沟通与建设性评审氛围

评审中参与者的独立程度越高，越容易发现缺陷：作者对自己工作产品存在"盲点"和"生产偏见"，难以客观发现缺陷；独立的评审者（未参与编写）能更客观地识别问题。因此选择合适的独立评审者（如同行、专家、独立测试人员）能显著提升评审效果。测试心理学关注人的因素：测试者应避免"确认偏见"（只找印证自己期望的证据）、避免与作者产生对抗，应用"独立性"与"建设性沟通"原则——通过共情、基于事实而非人格的反馈、鼓励开放讨论来营造安全的评审氛围。CTFL v4 强调独立性是评审有效性的关键因素，但也要平衡成本与协作。

独立程度与缺陷发现能力正相关，但过度独立可能降低协作效率。测试心理学强调在独立性与沟通之间取得平衡，用建设性方式反馈缺陷。

• CTFL v4 的章节结构与内容调整
• 测试技术分类的变化（黑盒/白盒/经验）
• 敏捷与 DevOps 内容如何融入

CTFL v4（2023 年发布）相比 v3 进行了结构性调整：章节调整为"基础概念、SDLC 中的测试、静态测试、测试分析与设计、测试管理、测试工具"六章，并将"测试技术"统一为黑盒、白盒、经验（experience-based）三大类，取代 v3 中较为分散的划分；v4 将敏捷与 DevOps 相关内容融入各章（如 SDLC 中的测试、测试管理），而非作为独立章节，强调测试在持续交付中的角色；v4 增加了对测试基础、测试条件、测试设计的更深入论述，并强化了风险、跟踪与测试控制的实践。对备考而言，v4 更强调理解与情境应用而非机械记忆；对实战而言，v4 引导测试者将技术选择、敏捷协作与工具落地结合。

v4 的核心变化是"结构化重构"与"强调情境化"。备考者应关注六大章的框架与三类测试技术的分类，实战者应关注测试如何嵌入敏捷与 DevOps 流程。

• 测试显示缺陷存在（Absence-of-errors fallacy）的哲学含义
• 测试通过证明了什么、不能证明什么
• 测试完备性与完全性缺陷

"测试显示缺陷存在"（Testing shows the presence of defects）是 ISTQB 的基本原则之一，指测试只能证明缺陷的存在，而不能证明缺陷不存在。即使测试全部通过，也只能说明"已覆盖范围内未发现缺陷"，不能证明软件没有缺陷——因为测试是不完备的，无法穷尽所有输入与场景。因此，全部通过不等于"没有缺陷"，可能只是测试用例覆盖不足、未能触及缺陷所在的路径。为避免误判，应：谨慎设计充分且覆盖需求与风险的测试用例，采用覆盖率与缺陷消除率等指标，结合探索式测试与评审补充测试盲区，并强调"质量内建"而非仅依赖测试通过。CTFL v4 提醒测试者避免"无缺陷谬误"（absence-of-errors fallacy），即认为软件没有缺陷就一定能交付成功。

该原则是测试哲学的核心，常考"测试能证明什么"。测试提供的是"未发现缺陷"的证据而非"无缺陷"的保证，测试者应通过充分覆盖与持续改进降低风险。

• 测试的根本目的（提供质量信息）
• 测试支持的决策类型（发布、风险、改进）
• 测试的验证与确认双重角色

测试的根本目的是通过验证和确认提供质量相关的信息，以支持决策、降低风险。除了发现缺陷，测试还提供以下信息：一是产品质量与就绪度评估，为发布/不发布决策提供依据；二是风险识别与评估，帮助了解未覆盖区域的风险暴露；三是需求符合性验证，确认系统是否满足需求与验收标准；四是缺陷模式与趋势分析，支持过程改进与开发质量提升；五是持续改进依据，通过测试结果反馈推动需求、设计、代码质量的优化。因此测试不仅是"找缺陷"，更是"质量信息的提供者"，为管理、开发、产品等多方决策输入信息。CTFL v4 强调测试的价值在于提供决策所需的信息。

测试的根本目的应从"信息提供"角度理解。测试者不应只关注缺陷数量，而应关注测试如何支撑质量与风险决策。

• 敏捷测试四象限的划分维度
• 四象限与测试级别的对应
• 敏捷中测试的目的（助力开发/评估产品）

敏捷测试四象限（Brian Marick 提出）以"技术/业务"与"面向开发/面向产品"为两轴，划分四个象限：Q1（技术导向、面向开发）——单元测试与组件测试，助力开发；Q2（业务导向、面向开发）——功能测试、验收测试、用户故事测试，助力开发；Q3（业务导向、面向产品）——探索式测试、场景测试等，评估产品；Q4（技术导向、面向产品）——非功能测试（性能、安全等），评估产品。与 ISTQB 测试级别对应：Q1 对应组件/单元测试与集成测试；Q2 对应系统测试与验收测试；Q3 对应系统测试中的探索性测试与专项测试；Q4 对应非功能测试（性能、安全等）。四象限强调敏捷中测试兼顾"助力开发"与"评估产品"双目的。

四象限是敏捷测试的经典框架，帮助测试者规划测试活动分布。其对应关系是"目的"（开发/产品）与"技术/业务"的组合，而非严格的一一映射。

• 评审有效性的度量指标
• 评审效率的度量指标
• 评审度量的目的与改进

评审有效性和效率可通过度量数据评估。有效性指标关注"评审能发现多少缺陷，是否值得"：包括评审发现的缺陷数量、缺陷密度（每千行/每页的缺陷数）、评审缺陷占比（评审发现的缺陷占总缺陷的比例）、重大缺陷占比等。效率指标关注"评审投入产出"：包括每人每小时评审的工作量、每缺陷花费的评审小时数、评审准备时间与会议时间比例、评审通过率等。通过对比不同评审类型、不同评审者的效率与有效性，可发现评审弱点（如会议时间过长、准备不足、检查清单无效），从而优化评审流程。评审度量应基于收集的缺陷与时间数据，并与历史基线对比，驱动持续改进。

有效性回答"评审是否发现缺陷"，效率回答"评审是否划算"。两者结合可评估评审价值，并指导评审类型选择与流程优化。

• ISTQB 认证的价值（标准化、语言、职业认可）
• 认证的局限（不替代实战能力）
• CTFL 知识的迁移场景与继续学习路径

ISTQB 认证的价值在于：提供统一的测试术语与知识体系，便于跨团队跨组织沟通；作为职业能力证明，提升就业竞争力与认可度；系统的 CTFL 知识帮助测试者建立测试方法论（测试流程、设计技术、管理、工具），为实践提供理论框架。其局限在于：认证是"知识测试"而非"能力证明"，无法替代实战经验、工具熟练度与业务理解；且标准知识需结合具体项目情境迁移。CTFL 知识可迁移到需求分析、测试设计、缺陷管理、测试策略制定等场景。继续学习路径包括：ISTQB 高级认证（CTAL：测试经理、测试分析员、测试技术分析员、安全/性能等专项）、专家级认证，以及结合 ISO 29119、DevOps、敏捷、云原生等现代实践持续提升。

认证是"敲门砖"与"知识框架"，实战是"能力积累"。测试者应理解认证的价值与边界，并通过高级认证与新技术实践持续升级。

• 测试级别（组件/集成/系统/验收）与测试活动的关系
• 七个测试活动在不同级别的应用
• 测试过程与级别的从属关系

测试级别（组件、集成、系统、验收）与测试活动（计划、监控、分析、设计、实现、执行、完成）之间是"级别执行活动"的关系：每个测试级别都执行同一套测试活动，但活动的内容、深度与工具因级别而异。例如，组件测试中，分析、设计、执行针对组件内部逻辑（常由开发结合单元测试完成）；系统测试中，分析、设计基于系统需求，执行针对端到端功能；验收测试中，分析基于验收标准，执行确认需求满足。测试过程（Test Process）是组织级的流程框架，测试级别是过程在特定对象上的应用，七个活动是每个级别内通用的活动序列。CTFL v4 强调测试活动在各级别间可复用于指导工作，只是对象与粒度不同。

核心是"活动通用、级别差异"——七个活动是通用蓝图，各测试级别据此展开，但对象（组件/系统/整机）、基准（设计/需求/合同）与粒度不同。

• 测试估算的方法与考虑因素
• 测试进度监控的指标与手段
• 进度偏差的识别与纠正措施

测试估算用于确定测试所需的工作量、资源与时间，方法包括专家判断、类比估算、三点估算、基于任务分解的估算等，考虑因素有测试范围、复杂度、风险、环境、团队能力与历史数据。测试进度监控通过进度报告、测试执行率、缺陷收敛趋势、剩余测试量与计划对比来识别偏差。识别偏差的方法：将实际执行进度与计划基线对比，监控测试通过率、缺陷密度、覆盖率、剩余工作量等关键指标。纠正措施包括：增加或调整测试资源、调整测试范围与优先级、优化测试策略（如增加自动化）、分批处理缺陷、与相关方沟通重新评估计划。CTFL v4 强调监控是持续活动，偏差应尽早发现并采取控制措施。

估算为计划提供基线，监控发现偏差，控制纠正偏差。三者构成"计划-监控-控制"闭环，测试者应掌握偏差识别指标与纠正手段。

• 探索式测试与脚本化测试的定义与特点
• 两者的定位差异（结构化 vs 自由探索）
• 组合使用的策略

脚本化测试（Scripted Testing）基于预先设计的测试用例与预期结果执行，具备可重复性、可追踪性与可度量性，适合验证明确需求、回归测试与自动化，但需要预先设计且可能僵化。探索式测试（Exploratory Testing）采用"同时学习、设计、执行"的自由方式，测试者根据经验与直觉探索，用测试章程（Charter）引导，更灵活，能发现脚本化测试覆盖不到的缺陷与边界情况，但可重复性差、依赖测试者能力。两者定位互补：脚本化测试保证需求覆盖与回归稳定，探索式测试补充发现未知缺陷与真实场景问题。组合策略：先用脚本化测试保障核心需求与回归，再针对高风险区域、复杂功能、新功能用探索式测试补充；在敏捷迭代中，探索式测试与脚本化测试常并行，探索式测试结果可转化为脚本化用例。

脚本化测试"测已知"，探索式测试"探未知"。测试者应根据需求确定性、风险与时间选择两者组合，灵活动态最优。

• 正式评审（审查）的流程阶段
• 各阶段的活动内容与责任人
• 评审角色的分工

正式评审（如审查）过程分为多个阶段：规划（Planning）——由评审负责人（Review Leader）确定评审目标、范围、角色、时间与检查清单，并准备评审材料；启动（Initiation）——作者（Author）向评审者分发工作产品，说明背景与评审重点；个人准备（Individual Review）——各评审者（Reviewer）独立检查工作产品，按检查清单记录问题，识别缺陷；评审会议（Review Meeting）——主持人（Moderator）召集评审者讨论结果，确认缺陷，输出评审决议；返工（Rework）——作者根据评审结论修订工作产品，纠正缺陷；跟踪结论（Follow-up）——评审负责人或主持人验证返工结果，确认缺陷已修复，宣布评审完成。各阶段责任人：规划与跟踪由评审负责人/主持人负责，材料准备由作者负责，独立检查由评审者负责，返工由作者负责，最终确认由主持人负责。

正式评审的关键是"角色分离+流程受控"：作者不审查自己的缺陷，主持人独立裁决，跟踪确认闭环。清晰的阶段与责任人划分保证评审客观有效。