软件测试过程模型
§1摘要与结论
软件测试过程模型把测试描述为可治理、可管理、可实施的分层过程：组织级制定测试方针与策略，管理级规划、监控与收尾测试项目，动态级设计、实现、执行并报告具体测试，可配合不同开发生命周期使用。
别名：test process、软件测试过程、测试过程模型、29119、分层测试过程 | 英文：Software Testing Process Model | 类型：方法 / process
§2局部关系图
§3原理 · 为什么
把测试视为过程，是为了让测试活动可规划、可管理、可复现，而不是依赖个人经验临时决定。测试过程模型将测试活动按治理层级组织：最高层面向组织，规定测试方针、策略与过程改进，为所有项目提供统一的方向与标准；中间层面向具体项目或测试活动，负责任务规划、资源与进度的监控以及测试收尾；最底层面向具体执行，完成测试设计、用例实现、环境搭建、执行与结果报告。这种分层使测试的责任、产物与决策点清晰可追溯，便于在不同项目间复用与评估。过程模型不绑定特定的开发生命周期：它提供可裁剪的框架，团队可依据瀑布、迭代或敏捷的节奏调整各过程的展开方式与形式化程度。其价值在于把测试从「做得差不多」的经验活动，转变为有定义、有产物、可审计、可改进的工程过程，并在组织范围内沉淀可复用的实践。
§4机制 · 如何运作
过程模型通过在层级之间规定输入、活动、产物与角色来运作。组织级过程的产物包括测试方针与组织测试策略，为下属层级设定约束与目标；管理级据此制定测试计划、监控测试状态并形成测试完成报告，决定范围、资源、进度、风险与退出条件；动态级依据计划开展测试设计与实现，产出测试用例、测试规程、测试数据与测试环境，执行并记录测试结果与事件报告。各层的文档模板与过程活动相互映射，使上一层的决策在下一层有对应的执行产物，下一层的证据又能回流支撑上一层的判断。过程还定义测试与其他生命周期活动的接口，如需求、设计、实现与运维，使测试不再是孤立阶段，而能与开发、交付协同。裁剪是过程应用的关键：团队依据规模、风险、法规与开发模式选择必要的过程与文档，避免形式化开销压倒实际价值。
§5工程 · 怎么落地
实践时应先评估组织的目标、风险与开发模式，选择过程模型中真正必要的过程与产物，并明确裁剪理由，避免照搬全部模板造成文档负担。在组织层面建立统一的测试方针与策略，规定质量目标、测试范围原则与度量方式；在项目层面把测试计划与进度、范围、风险管理结合，明确各阶段的进入与退出条件、角色职责与沟通机制；在执行层面把测试设计、环境准备、执行与结果报告形成可重复的流程，使测试结果可追溯、可复现。过程产物应与需求、设计等制品建立追溯关系，使覆盖情况与变更影响可被核查。对敏捷或持续交付场景，可压缩文档形式但保留关键决策与证据，把过程活动嵌入迭代与流水线中。最后应建立过程改进机制：用缺陷来源、测试有效性、返工等数据定期评估过程，识别薄弱环节并调整，使测试过程随组织成熟度与业务变化持续演进。对小型或快速迭代的团队，应优先保留决策与证据，压缩文档形式，避免过程模板成为交付的额外负担。
§6权衡卡
形式化的测试过程模型也有代价与争议。
其一是开销与僵化风险：完整的层级、过程与文档模板对小团队或快速变化的项目可能过于沉重，填表与评审挤占了本可用于测试设计的时间，且文档一旦滞后反而误导。
其三是形式与实质的背离：过程合规不等于测试有效，把过程产物齐全当作质量保证的证据，会掩盖测试本身是否真的揭示了风险。
因此过程模型应以可裁剪、可演进的框架方式应用，把形式化程度与项目风险、规模、法规要求匹配，并始终以测试的实际有效性而非文档数量作为衡量标准。
反例之一是为满足认证而机械产出文档，测试范围与深度并未随之改善。
反例之二是完全否定过程、退回纯个人经验，使测试无法在团队与项目之间复用与评估。
- 其二是共识与适用性问题：标准化的过程模型可能难以兼顾认知性、探索性测试的实际方式，也未必适配所有组织文化与开发模式，强行推行会遭到抵触，甚至导致团队保留两套流程、彼此脱节。
- 因此过程模型的成败取决于它能否被裁剪为贴合语境的最小必要集合，而不是它覆盖了多少活动与文档。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7案例带
插件 DAG RC5→RC7 升级
一次知识库随上游源码版本升级的级联维护：以三层差异分析把 219 个包收敛为 26 个实质变更包，经编译、运行时、组合三类依赖判定更新 DAG 数据后全量重生成页面，并以静态门控加渲染验证收口。
Open Code Review 图谱
对阿里开源 AI 代码审查 CLI 做源码级解析并构建「知识 + 实践资产 + AI 索引」三合一知识图谱的工程案例。
AI Agent 架构 DAG 复盘
对四个工作日内独立完成三个异构对象 DAG 分析的方法论复盘，总结「采集→建模→生成→门控→交付」可复用管线与关键教训。
§8信源与核验
核验结论：官方工作站确认现行共 8 个部分（Part 1/2/3/4/5/6/11/13），其中 Part 6/11/13 为技术报告；29119 取代 IEEE 829、IEEE 1008、BS 7925-1/-2 [STD-024]
§9原始关系清单
展开：本节点的全部原始关系边（2 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 依赖关联 | ← MTH-I-06 | 质量门控与持续集成 E-494 | 质量门控依赖测试过程模型的管理框架 |
| 实现 | ← TEC-I-02 | 关键字驱动测试框架 E-817 | 29119-5 关键字驱动测试实现分层测试过程模型 |