29119 框架核心

• 29119 标准的组成部分（过程、文档、术语）
• 29119 的多部分结构（29119-1 至 29119-5）
• 29119 与测试管理的衔接

ISO/IEC/IEEE 29119 是国际软件测试标准，采用多部分结构：29119-1（概念与定义）——定义测试术语与基础概念，建立统一语言；29119-2（测试过程）——定义组织测试过程、测试管理过程与动态测试过程以及各过程的活动与任务；29119-3（测试文档）——规定测试文档模板，如测试计划、测试设计说明、测试用例说明、测试日志、测试事件报告、测试总结报告；29119-4（测试技术）——定义黑盒（specification-based）、白盒（structure-based）与经验（experience-based）测试技术及其应用；29119-5（关键词驱动测试）——定义关键词驱动（keyword-driven）测试的框架与动作词抽象。其核心是"过程、文档、术语"三位一体：以标准化的测试过程为主线，配以统一的文档模板与术语，保证测试活动可管理、可追溯、可审计。29119 可作为组织测试过程的参考框架，也可用于审计与合规认证。

29119 的"过程+文档+术语"结构是标准的核心。测试者应理解其多部分组成的定位，以及过程、文档、术语如何协同支撑标准化的测试管理体系。

• 测试管理过程与动态测试过程的定义
• 两个过程的输入输出与信息流
• 过程接口的衔接机制

29119 中测试管理过程（Test Management Process）负责测试策略与计划的制定、测试监控与控制、测试完成报告的编写，是"治理层面"；动态测试过程（Dynamic Test Process）在具体测试级别内执行测试分析与设计、测试实现、测试执行、测试环境建立与维护等，是"执行层面"。两者的输入输出关系：测试管理过程输出测试计划、测试策略、测试监控与测试完成报告，作为动态测试过程的控制输入；动态测试过程向上反馈测试进度、测试结果、缺陷数据与测试日志，作为管理过程监控与决策的依据。接口衔接：通过"测试计划→测试任务分配→执行数据反馈→监控与调整→完成报告"的闭环衔接，管理过程下达测试基准与计划，动态过程执行并回传数据，管理过程据此调整策略与资源。IDT（测试管理）与动态测试过程通过明确的输入/输出文档（测试计划、测试日志、测试报告）衔接，保证过程的可控与可审计。

管理过程"管"、动态过程"做"，二者通过计划下达与结果反馈闭环衔接。测试者应理解两个过程的输入输出关系与接口，保证测试受控可追溯。

• 基于风险测试的流程（识别、评估、缓解）
• 风险贯穿测试计划、设计与执行
• 风险变化对测试的调整触发

29119 强调基于风险的测试（Risk-Based Testing），风险贯穿测试全流程。风险识别：在测试计划阶段识别产品风险（功能、性能、安全等）与项目风险（进度、资源等），形成风险清单。风险评估：按可能性与影响评估风险等级，确定风险优先级，作为测试优先级与覆盖的依据。风险缓解：根据风险等级制定缓解措施——高风险区域采用更强的测试技术与更充分的覆盖、优先执行、增加资源，低风险区域适度覆盖。风险贯穿各阶段：测试计划依风险确定范围与优先级，测试设计依风险选择技术与用例密度，测试执行依风险安排执行顺序与回归范围。风险变化触发测试调整：当需求变更、缺陷集中、生产事件等导致风险变化时，重新评估风险等级，调整测试范围、优先级、资源与策略。29119 通过风险驱动的动态调整，使测试资源聚焦于最高风险区域。

基于风险测试是"识别-评估-缓解-动态调整"的闭环。风险是测试优先级与覆盖的核心依据，风险变化应触发重新评估与测试调整。

• 测试项（Test Item）与测试基准（Test Basis）的定义
• 测试依据的分层（需求、设计、代码）
• 分层对测试条件与用例设计的影响

测试项（Test Item）是被测试的对象（如组件、系统、功能模块），测试基准（Test Basis）是测试设计所依据的信息来源（如需求、设计、代码、用户故事）。29119 强调测试依据分层：需求层（需求规格、用户故事、业务规则）——黑盒测试的基准，据此设计功能测试条件与用例；设计层（架构设计、详细设计、接口规范）——依据设计信息设计集成与接口测试条件；代码层（源代码、内部结构）——白盒测试的基准，据此设计语句、分支、判定覆盖的用例。依据分层对测试条件与用例设计的影响：不同层级的基准决定测试的视角与粒度——需求层关注"系统是否满足需求"（黑盒），设计层关注"组件间是否正确协作"（集成/接口），代码层关注"内部逻辑是否正确"（白盒）；测试条件应基于对应的测试基准提取，用例设计技术随层级选择（黑盒技术用于需求层，白盒技术用于代码层）。分层明确保证测试覆盖各层次、无遗漏无冗余。

测试基准分层决定测试的视角与粒度。需求层用黑盒、设计层用集成/接口、代码层用白盒，测试条件与用例设计应匹配对应基准。

• 组织级测试策略（Test Policy/Strategy）的定义
• 测试策略的定义要素
• 组织级测试策略的落地方式

29119 区分组织级测试策略（Test Policy 与 Test Strategy）：Test Policy（测试方针）是组织最高层的测试纲领，声明组织对测试的原则、目标与承诺（如质量标准、合规要求、测试投入水平）；Test Strategy（测试策略）进一步细化测试方针，描述组织如何实施测试（如测试级别、测试技术、测试工具、风险策略、测试环境）。定义要素包括：测试目标与范围、测试原则、测试级别与类型、测试环境、测试工具、风险策略、质量指标、资源与职责、测试文档要求。落地方式：将组织级测试策略转化为项目级测试计划，通过建立测试流程、定义标准与模板、提供工具与培训、设定质量指标与审计机制来贯彻；组织级策略为各项目提供统一框架，项目在其指导下细化具体测试方案，并向上反馈结果以持续完善组织策略。CTFL v4 与 29119 都强调组织级策略是标准化测试的基础。

组织级测试策略是"方针+策略"两层，为各项目提供统一测试框架。落地靠流程、标准、工具、指标与审计的体系化支撑。

• 29119 五个部分的划分与定位
• 各部分的工程语义与作用
• 五个部分如何协同支撑测试工程

ISO/IEC/IEEE 29119 由五部分构成，各部分具有清晰的工程语义：29119-1（概念与定义）——建立统一的测试术语与基础概念，为组织与工具提供共同语言，消除沟通歧义；29119-2（测试过程）——定义组织测试、测试管理、动态测试等过程模型及活动任务，为测试工程提供流程框架，是"怎么做"的规范；29119-3（测试文档）——规定测试计划、测试设计、测试用例、测试日志、测试事件报告、测试总结报告等文档模板，保证测试产物标准化、可追溯、可审计；29119-4（测试技术）——定义黑盒、白盒、经验三类测试技术及其应用，指导"如何设计测试用例"；29119-5（关键词驱动测试）——定义关键词驱动测试框架与动作词抽象，用于自动化测试的高层抽象与复用。五部分协同：1 提供语言，2 提供流程，3 规范文档，4 指导技术，5 支撑自动化，共同构成完整的测试工程体系。

29119 五部分构成"语言、流程、文档、技术、自动化"的完整工程链路。测试者应理解各部分的定位与协同，将其应用于测试体系建设。

• 29119-2 测试过程模型的组成
• 组织测试过程与动态测试过程的边界
• 测试用例在过程模型中的位置

29119-2 定义了一套测试过程模型，包括组织测试过程（Organizational Test Process）、测试管理过程（Test Management Process）与动态测试过程（Dynamic Test Process）。组织测试过程是组织级层面，负责制定组织测试策略、管理组织测试资源、改进测试过程，是"组织统筹"；测试管理过程是项目级治理，负责测试计划、监控与控制、完成报告；动态测试过程是执行层面，负责在具体测试级别内执行测试分析与设计、测试实现、测试执行、测试环境建立与维护。工程边界：组织测试过程定义了"组织如何组织测试"（策略、资源、改进），动态测试过程定义了"具体如何执行测试"（设计、实现、执行用例），测试管理过程在两者之间起承上启下作用。测试用例（Test Case）是动态测试过程中的核心产物，产生于测试分析与设计阶段，用于指导测试执行，是动态测试过程与文档（29119-3）衔接的载体。

29119-2 的边界是"组织统筹-项目管理-执行操作"三层。测试用例是动态测试过程的核心产物，连接测试设计与执行。

• 29119-3 各类测试文档模板的用途
• 各文档在测试生命周期中的位置
• 文档模板的工程价值（标准化、可追溯、可审计）

29119-3 规定了测试文档模板，各文档承载不同工程价值：测试计划（Test Plan）——描述测试目标、范围、策略、资源与进度，是测试工作的总纲；测试设计说明（Test Design Specification）——描述测试条件、测试技术的应用与测试分析结果，指导用例设计；测试用例说明（Test Case Specification）——定义具体测试用例的输入、预期结果与前置条件，是测试执行的基础；测试过程说明（Test Procedure Specification）——描述测试用例的执行步骤与顺序，指导测试执行；测试日志（Test Log）——记录测试执行过程、结果与事件，提供执行证据；测试事件报告（Test Incident Report）——记录测试中发现的缺陷与异常，支持缺陷管理与修复；测试总结报告（Test Summary Report）——汇总测试结果、评估质量、给出结论，支持发布决策。这些文档模板构成"计划-设计-执行-记录-总结"的完整测试文档链，保证测试可追溯、可审计、可复现，是标准化的工程价值所在。

29119-3 文档模板覆盖测试全生命周期，形成"计划-设计-用例-过程-日志-事件-总结"的完整链条。测试者应理解各文档的用途与衔接，保证测试文档化与可审计。

• 29119-4 三类测试技术的分类
• 各类技术的代表方法与适用场景
• 测试技术矩阵的工程应用

29119-4 按测试依据将测试技术分为三类：specification-based（基于规格的测试技术，即黑盒）——依据需求/规格设计用例，代表方法包括等价类划分、边界值分析、决策表、状态转换、用例测试、错误猜测等，适用于需求明确时验证系统功能与行为；structure-based（基于结构的测试技术，即白盒）——依据代码内部结构设计用例，代表方法包括语句覆盖、决策覆盖、条件覆盖、路径覆盖等，适用于测试代码逻辑与分支，多在单元/组件测试中使用；experience-based（基于经验的测试技术）——依据测试者经验与领域知识设计用例，代表方法包括探索式测试、检查清单、错误猜测等，适用于补充发现未知缺陷与边界情况。测试技术矩阵：将三类技术按被测对象、风险、覆盖目标进行组合规划，形成"需求驱动+结构补充+经验增强"的完整覆盖策略。工程应用上，测试者应根据系统复杂度、风险、需求可用性与成本选择技术组合，实现覆盖与效率的平衡。

29119-4 的三类技术与 CTFL v4 对应（黑盒/白盒/经验）。测试技术矩阵指导测试者按风险与覆盖目标组合技术，实现全面而高效的测试设计。

• 29119 与 CTFL 的定位差异
• 两者的内容对应与协同
• 两者在实践中的综合应用

ISO/IEC/IEEE 29119 与 ISTQB CTFL 定位不同：29119 是国际标准（Standard），由 ISO/IEC/IEEE 制定，规定"测试应当如何组织和执行"的规范性要求，是流程与文档的基准，用于合规、审计与体系建立；CTFL（ISTQB 基础级认证）是资格认证（Certification），由 ISTQB 制定，规定"测试者应当具备哪些知识"的课程体系，用于个人能力认证与知识提升。两者内容高度协同：29119 的测试过程、测试技术、测试文档与 CTFL 的测试流程、测试级别、测试设计技术、测试管理等内容相互对应，CTFL 知识是对 29119 标准的实践扩展与教育化。差异：29119 更强调组织的规范性与合规性（文档、过程、审计），CTFL 更强调个人理解与应用（概念、情境、与敏捷/DevOps 结合）。实践中常用 CTFL 知识提升个人能力，用 29119 建立组织测试体系，两者相辅相成。

29119 是"组织标准"，CTFL 是"个人认证"，二者内容协同、定位互补。实践中应结合使用：以 CTFL 知识驱动实践，以 29119 建立规范化体系。

• 29119-2 与 ISO 9001、CMMI 的关系
• 三个标准在质量管理与过程改进中的协同
• 测试过程在质量管理体系中的定位

ISO/IEC/IEEE 29119-2 定义测试过程，ISO 9001 是通用质量管理体系标准，CMMI 是能力成熟度模型，三者从不同层面协同支撑组织质量。ISO 9001 关注组织整体质量管理体系（过程、记录、持续改进），测试过程作为其中验证与确认环节，通过 29119 的规范化测试过程支撑 ISO 9001 的"过程受控、记录完整、持续改进"要求。CMMI 提供过程成熟度框架（如验证与确认过程域），29119-2 的测试过程可作为 CMMI 验证/确认过程域的实践参考，帮助组织达成更高成熟度等级。协同方式：组织以 ISO 9001 建立质量管理体系框架，以 CMMI 规划过程改进路径，以 29119-2 落实具体的测试过程与文档，三者形成"体系框架+改进模型+测试规范"的协同。工程价值在于：测试过程有据可依、可审计、可改进，支持组织通过质量认证与过程成熟度评估。

29119-2 提供测试过程规范，ISO 9001 提供质量体系框架，CMMI 提供改进模型，三者协同支撑组织测试与质量管理。

• 29119-3 测试计划模板的内容要素
• 敏捷与传统项目测试计划的差异
• 测试计划模板在不同项目中的裁剪

29119-3 的测试计划模板定义了测试计划应包含的内容要素（如测试目标、范围、策略、风险、资源、进度、退出准则等），在传统项目与敏捷项目中呈现不同工程形态。传统（瀑布）项目：测试计划是一次性、详细的大文档，在项目初期制定并基本固定，覆盖全部测试级别与完整周期，强调事前规划、文档完整、评审严格。敏捷项目：测试计划更加轻量、持续演进，计划在迭代开始时细化并随迭代调整，采用"计划即持续活动"的方式，测试计划与迭代计划、用户故事结合，文档精简、更聚焦当前迭代与风险，并强调快速反馈。工程差异要点：计划粒度（整体 vs 迭代）、制定时机（一次性 vs 持续）、文档详细度（完整 vs 精简）、应对变化（固定 vs 动态裁剪）。29119-3 模板作为通用框架，可依据项目类型裁剪，敏捷项目可精简模板、引入滚动计划，传统项目保留完整正式计划。

29119-3 测试计划模板是通用框架，敏捷项目需裁剪为轻量持续式计划，传统项目保留完整正式式计划。测试者应能按项目类型适配模板。

• 关键词驱动测试（keyword-driven）的概念
• 动作词（action word）抽象层次
• 动作词到 Robot Framework 等框架的映射

29119-5 定义关键词驱动测试（keyword-driven testing）框架，其核心思想是将测试用例抽象为高层的"动作词/关键词"（action word），动作词封装具体执行逻辑，测试用例由动作词序列组成，实现测试逻辑与执行细节分离。动作词抽象层次：数据层（测试数据）、动作层（具体操作，如"登录""点击"）、业务层（业务动作，如"下单"）、测试脚本层（用例编排）。映射到 Robot Framework 等框架：动作词对应框架中的关键字（Keyword），可用库关键字（如 SeleniumLibrary 的 Click、Input）或自定义用户关键字（User Keyword）封装业务动作；测试用例通过动作词调用，测试数据由外部数据文件（如表格、变量）驱动，实现"测试脚本与数据分离、业务人员可编写用例"。工程应用价值：提高测试可复用性、降低维护成本、支持非技术人员参与测试设计、便于跨平台与多语言复用。Robot Framework、Selenium 等框架广泛支持此类模式。

关键词驱动是"动作词抽象+数据驱动"的自动化模式。动作词映射为框架关键字，实现用例与实现分离，提升复用与可维护性。

• 安全关键行业的测试合规要求
• 29119 在汽车、医疗、航空行业的应用
• 29119 与其他行业标准的协同

在 automotive、medical、aerospace 等安全关键行业，软件测试不仅是质量要求，更是合规与监管要求。29119 在这些行业的合规价值在于：提供国际公认的测试过程、文档与术语标准，帮助组织满足行业监管对测试的规范性、可追溯性与可审计性要求；29119 的测试文档模板（测试计划、测试日志、测试事件报告、测试总结报告）为监管审计提供完整证据链，证明测试活动受控、缺陷被管理、质量被评估。在汽车行业，29119 配合 ISO 26262（功能安全）应用于安全相关软件的测试；在医疗器械行业，29119 配合 IEC 62304（医疗器械软件生命周期）支撑验证与确认；在航空航天行业，29119 配合 DO-178 等标准支撑软件验证。29119 作为通用测试标准，为各行业提供基础测试框架，与行业专属标准协同，满足合规与认证要求。

29119 在安全关键行业提供"测试过程+文档+审计证据"的合规基础，并与 ISO 26262、IEC 62304、DO-178 等行业标准协同。

• 测试（Testing）与质量保证（QA）的定义
• 两者概念与职责的边界
• 测试与 QA 在组织中的协同

29119-1 对测试与质量保证（QA）进行了明确区分。测试（Testing）是验证与确认软件产品是否满足需求、发现缺陷的活动，属于"产品验证"层面，关注"产品是否做对"，通过执行测试、设计用例、报告缺陷来提供质量信息。质量保证（QA）是预防性与过程性活动，通过建立质量流程、标准、评审、度量和改进机制来保证"过程是否做对"，关注质量体系与过程改进，旨在预防缺陷而非发现缺陷。职责划分：测试负责具体执行、发现并报告缺陷，评估产品当前质量；QA 负责制定质量规范、监督过程遵循、进行过程评审与改进、管理质量体系。二者协同：测试为 QA 提供缺陷与质量数据，QA 通过过程改进减少缺陷产生，两者共同构成"预防（QA）+发现（测试）"的质量保障体系。边界清晰但不可互相替代——测试不能替代 QA 的过程保障，QA 也不能替代测试的缺陷发现。

测试是"验证产品"，QA 是"保障过程"。测试发现缺陷、QA 预防缺陷，二者协同构成质量保障体系，职责边界清晰。

• 29119 认证与符合性评估的商业价值
• 要求 29119 合规的行业与客户
• 合规对组织业务的促进作用

ISO/IEC/IEEE 29119 认证与符合性评估的商业价值在于：证明组织具备国际标准的测试能力与过程，提升客户信任与市场竞争力，满足招标与供应链准入要求，降低采购方对软件质量的疑虑。要求 29119 合规的行业与客户主要包括：安全关键行业（汽车、航空航天、医疗、轨道交通、核电等）——监管要求严谨的测试过程与文档；政府与公共服务部门——对供应商测试规范性有明确要求；大型企业采购方——在供应商审核中要求测试过程符合国际标准；金融、保险等受监管行业——对软件质量与合规有严格要求。合规价值体现在：通过审计与认证获得市场准入资格、减少客户重复审核、提升投标成功率、建立可复现的测试体系降低质量风险。29119 合规常作为组织质量与测试能力的差异化卖点。

29119 合规的商业价值在于"市场准入+客户信任+标准化体系"。安全关键行业与受监管采购方通常要求 29119 合规。

• 测试设计与实现过程的输入输出
• 测试条件到测试用例的转换
• 转换过程的可控性保障

29119-2 中测试设计与实现过程（Test Design & Implementation）的输入包括：测试基准（需求、设计）、测试条件、测试计划与测试策略、测试环境信息等；输出包括：测试用例（Test Case）、测试过程（Test Procedure）、测试数据、测试环境与测试脚本等。从测试条件到测试用例的转换是核心环节，其受控性体现在：每个测试条件导向一个或多个测试用例，保证"条件有对应用例"；测试用例定义前置条件、输入数据、执行步骤与预期结果，使测试可执行、可判定；通过需求追踪矩阵（RTM）建立"测试条件-测试用例-需求"的追踪关系，确保覆盖完整、无遗漏无冗余；测试用例需经评审确认，保证设计质量；测试设计技术（黑盒/白盒/经验）按 29119-4 规范应用，保证用例设计的系统性。受控的关键是：明确的输入输出定义、追踪关系、评审机制与文档化，使转换过程可追溯、可审计。

测试设计与实现是"测试条件→测试用例"的受控转换，依靠追踪矩阵、评审与文档化保障覆盖与质量。测试者应理解输入输出与转换机制。

• 29119 在敏捷环境中的裁剪原则
• 文档驱动过程与短迭代、持续测试的共存
• 可简化或自动化的活动

29119 是文档驱动标准，在敏捷环境中需裁剪以适配短迭代与持续测试。裁剪原则：在保持测试过程核心（计划、设计、执行、监控、完成）与可追溯性的前提下，精简文档、缩短周期、强化自动化。与短迭代共存：测试计划从一次性大文档转化为轻量、滚动演进的形式，随迭代细化；测试设计与用例与用户故事、迭代同步推进，快速反馈；测试执行嵌入持续集成/持续交付（CI/CD）流水线，实现持续测试。可简化或自动化的活动：文档可简化——合并测试计划与迭代计划、精简模板、用工具化追踪替代文档化；测试实现可自动化——自动化测试脚本、测试数据生成、环境搭建（环境即代码）；监控可自动化——测试结果的自动收集、覆盖率与缺陷指标的自动统计报告；回归测试自动化替代大量手工执行。通过裁剪，29119 的过程框架在敏捷中保持受控与可追溯，同时满足迭代速度与持续测试需求。

29119 在敏捷中的裁剪是"过程保留、文档精简、自动化强化"。测试者应理解如何在保持受控可追溯的前提下，适配短迭代与持续测试。

• 测试事件报告的内容要素
• 缺陷信息的标准化
• 标准化对沟通、审计与缺陷分析的价值

29119-3 规定测试事件报告（Test Incident Report）用于记录测试中发现的问题与缺陷，其内容要素包括：事件标识（唯一编号）、事件标题与描述、严重级别（Severity）与优先级（Priority）、复现步骤与前置条件、实际结果与预期结果、环境信息（版本、配置、平台）、发现时间与发现者、关联的测试用例与需求、影响范围、根因分析、处理状态与责任人等。缺陷信息标准化：定义统一的字段、严重级别/优先级分级、状态流转与命名规范，使不同团队、不同项目对缺陷的描述一致、可比较。标准化的价值：跨团队沟通——统一的缺陷描述与分级便于开发、测试、产品快速理解与处理；审计——完整的缺陷记录与追踪提供合规证据；缺陷分析——标准化的缺陷数据（级别、类型、模块、阶段）支持缺陷趋势、聚类与根因分析，驱动过程改进。29119-3 的标准化为缺陷管理提供可追溯、可分析的证据基础。

测试事件报告标准化缺陷信息的字段、分级与状态，支撑跨团队沟通、审计与缺陷分析。测试者应掌握事件报告的核心要素与标准化意义。