企业官网建设流程全解析

OBLITERATUS 测试质量程序风险登记表解析：10 项核心风险与四层验证门禁的落地机制

【免费下载链接】OBLITERATUSOBLITERATE THE CHAINS THAT BIND YOU项目地址: https://gitcode.com/GitHub_Trending/ob/OBLITERATUS

本文围绕 OBLITERATUS 仓库中的测试质量程序（Testing Quality Program）风险登记表展开，逐项拆解 TQ-R1～TQ-R10 共 10 项已识别风险及其缓解措施，并结合仓库内的 CI 策略文件、校验脚本与测试用例，说明这些缓解机制如何在四层验证架构中真正落地。读完本文，你将理解这套测试质量程序如何防止覆盖率造假、如何让 PR CI 保持离线与稳定、如何管理硬件条件测试、如何控制供应链暴露与测试时长，以及如何保证条件证据不被跨提交复用。

一、背景：测试质量程序与四层验证架构

OBLITERATUS 的测试质量程序建立在四层显式验证架构之上（见 架构草图）：

1. 强制 PR 门禁（Mandatory PR gate）——仅 CPU、离线运行的单元与边界契约测试，包含包构建、lint、分支/行覆盖率、警告、JUnit 报告与构建产物。
2. 离线集成门禁（Offline integration gate）——使用微型本地模型/配置夹具，验证流水线组合、checkpoint 保存/重载、评估与报告链路。
3. 质量深度门禁（Quality-depth gate）——属性测试、重复测试，以及对高后果纯模块的选择性变异测试。
4. 条件环境门禁（Conditional environment gates）——加速器、可选后端、模型下载、网络与远程服务类作业，均带明确的前置条件。

这套架构有几个关键设计约束：pytest markers 是层与层之间的选择契约；GitHub Actions 作业必须产出可保留的证据，并且绝不静默地把必须通过的失败转换为成功；工具版本由项目控制；默认门禁不得访问外部服务、不得继承用户模型缓存、不得要求凭据。

覆盖率演进按波次推进并形成 Gate 门槛：测量波（保留 49% 行覆盖率下限并建立分支基线）→ 边界波（仓库行覆盖率 ≥55%、变更行 ≥90%、触及的关键模块 ≥70%）→ 集成波（仓库行覆盖率 ≥60%）→ Gate 1（仓库行 ≥70%、分支 ≥55%，成熟 CPU 可测范围行 ≥90%、分支 ≥78%）→ Gate 2（仓库行 ≥75%、分支 ≥60%，成熟 CPU 可测范围行 ≥92%、分支 ≥80%，并增加"已安装包 CLI 配置到报告"的纵向切片）。Gate 1 质量决策记录 表明该门禁已实际运行并通过（2026-08-15，PR #90 审计通过，post-merge 主分支 7 个作业全部成功）。

精确阈值与排除图由 ci/test-quality-policy.json 拥有，测试责任分配由 ci/test-risk-map.json 拥有——这正是风险登记表各缓解措施的具体载体。

二、风险登记表总览

以下为 风险登记表 的完整内容：

下面逐项深入解析风险与缓解机制的源码级实现。

三、TQ-R1：如何防止"无行为断言的覆盖率造假"

风险：开发者为凑覆盖率而写空断言测试，导致覆盖率数字虚高、行为无人保证。

缓解落地：质量策略强制要求覆盖率与行为断言、变异信号共同把关：

• 变异测试分数门槛：ci/test-quality-policy.json 的minimums.mutation_score设定为 85.0，变异分数是衡量"杀掉变异体"比例的信号，直接打击只跑不验证的测试。
• 契约面与必测测试绑定：ci/test-risk-map.json 为 11 个契约面（如core-pipeline、analysis-methods、evaluation-and-benchmarks）逐一指定required_tests，例如analysis-methods面要求 tests/test_numerical_contracts.py、tests/test_projection_math_contracts.py 等。
• 变异策略被测试锁定：tests/test_quality_policy.py 直接断言pyproject.toml中[tool.mutmut]的配置，包括mutate_only_covered_lines = true、timeout_constant = 2.0以及required_mutation_targets列表，防止变异门禁被悄悄放宽。
• 属性测试与数值不变式：仓库以 tests/test_property_contracts.py、tests/test_numerical_contracts.py 等验证数学/统计属性，属于文档要求的"属性场景"。

四、TQ-R2：保证默认 CI 完全离线

风险：CI 一旦默认下载模型或访问外部服务，就会变慢、不可复现、甚至泄露凭据。

缓解落地，这条由三层机制共同保证：

1. 严格 markers 契约：pyproject.toml启用--strict-markers并显式登记 markers 列表，网络类测试（如network、download）与 CPU 单元测试被严格区分。
2. 默认门禁排除条件测试：ci/pr-test-policy.json 的excluded_test_prefixes明确排除tests/conditional/目录——该目录下的网络/下载类测试（如 tests/conditional/test_network_services.py、tests/conditional/test_model_download_runtime.py）不会进入默认 PR 门禁。
3. 条件测试单独工作流：ci/conditional-test-policy.json 定义独立的条件测试工作流，节奏为"每周一次 + 发布时 + 随时手动触发"；即使涉及模型下载，也固定到不可变资源：hf-internal-testing/tiny-random-gpt2仓库的固定 revision，且trust_remote_code: false，缓存按仓库、revision、runner OS、Python 版本键控。

架构草图同时强调：默认门禁不得访问外部服务、不得继承用户模型缓存、不得要求凭据——这就是"空缓存、离线环境"的工程化表达。

五、TQ-R3：让硬件测试不再破坏 PR CI

风险：GPU/Jetson/MPS 等硬件测试一旦进入常规 PR 流水线，就会因缺硬件、资源抢占而制造 flaky 或阻塞。

缓解落地：

• 条件化调度：ci/conditional-test-policy.json 的gates数组定义了 10 个条件门禁（model-download-runtime、external-evaluation、network-services、operator-ui、cuda-runtime、bitsandbytes-runtime、jetson-runtime、mps-runtime、mlx-runtime、remote-execution），每个门禁声明runner标签、prerequisites与expected_cost。例如cuda-runtime要求ENABLE_CUDA_GATE=true与专用 CUDA runner；jetson-runtime要求受信手动触发、真实 Jetson 硬件与 JetPack 对齐的 CUDA PyTorch 运行时。
• 环境豁免机制：同一文件中的environment_waivers记录了当前无法执行的门禁（CUDA、bitsandbytes、MPS、MLX、remote），每条豁免都带规范 issue、opened/expires日期，并明确"豁免生效期间不主张相关运行时支持"的blocked_claim——用制度防止"没测过却声称支持"。
• 文档化前置：硬件运行前置条件在 Jetson 平台文档 与 共享 GPU 主机部署文档 中说明，配合 tests/conditional/test_jetson_runtime.py、tests/conditional/test_cuda_runtime.py 等测试使用。

六、TQ-R4：工具供应链的固定与审计

风险：CI 引入的第三方 Action/工具被替换或携带漏洞，形成供应链攻击面。

缓解落地：

• 不可变 pin 清单：ci/digests.txt 逐条列出每个 Action 与工具的不可变 pin：如actions/checkout、actions/setup-python、actions/upload-artifact、actions/download-artifact、actions/attest，以及rhysd/actionlint（带 SHA-256）、astral-sh/uv（pypi:0.12.4）、gitleaks/gitleaks（带 SHA-256），每条都记录 resolved version、pin 日期与 rationale（如 "baseline pin (#59)"、"SLSA provenance and SBOM attestations (#142)"）。
• 漏洞/密钥/许可证三策略：ci/supply-chain-policy.json 规定：漏洞采用fail-all-severities（因 OSV 不保证归一化严重级别，所有已知漏洞一律阻塞，除非存在未过期异常）；密钥扫描采用fail-all-findings且报告 100% 脱敏；许可证采用精确许可名单（Apache-2.0、BSD、MIT、MPL-2.0、PSF-2.0 等）。
• 审计证据与校验：actions/attest用于生成 SLSA provenance 与 SBOM 证明；scripts/check_supply_chain_policy.py 与 tests/test_supply_chain_policy.py 负责策略一致性校验；完整策略见 供应链策略文档。

七、TQ-R5：警告预算与第三方噪音的隔离

风险：启用-W error后，第三方依赖的弃用警告会让 CI 无谓失败。

缓解落地：质量策略把警告作为可量化预算而非一刀切。ci/test-quality-policy.json 的minimums.warning_budget为 0，而 scripts/check_quality_policy.py 的BASELINE_FLOORS同样把warning_budget基线固定为 0.0——从策略结构看，"零警告"是目标，但实现通过窄化、文档化的过滤规则只对项目自有代码的警告强制，第三方噪音被明确排除在预算之外。任何阈值调整都必须通过threshold_exceptions走显式审批（要求new_value与当前值一致、非空 reason、规范的 OBLITERATUS issue 前缀与过期日期），防止静默放宽。

八、TQ-R6：变异/属性任务的反馈时间控制

风险：变异测试跑全仓库会产生指数级测试组合，拖垮反馈周期。

缓解落地：

• 范围收缩到小纯模块：pyproject.toml的[tool.mutmut]把变异目标限定在runtime_contracts.py、persistence_contracts.py、evaluation/lm_eval_integration.py、analysis/numerical_contracts.py、analysis/whitened_svd.py等高后果纯模块，并设置required_mutation_targets；tests/test_quality_policy.py 断言这些目标配置不可漂移（同时断言reporting/report.py不在变异名单、test_telemetry_failure_contracts.py不在 mutmut 而在 repeat gate 中）。
• 深度门禁单独运行并限时：质量深度作业是独立 job，tests/test_quality_policy.py 断言其timeout-minutes == 45，并通过BLIS_NUM_THREADS、MKL_NUM_THREADS、OMP_NUM_THREADS等环境变量把数值库线程压到 1，避免线程竞争导致的时长漂移。
• repeat gate 与 mutation gate 分离：scripts/run_repeat_gate.py 承载重复测试，repeat_gate时长预算（总时长 ≤180 秒、单次 pass ≤75 秒）在 ci/test-quality-policy.json 中定义，由 scripts/check_quality_policy.py 的validate_duration_evidence强制。

九、TQ-R7：安装包与 checkout 行为一致性

风险：源码树中测试通过，但打包安装后因缺少入口点、资源未包含等原因行为不同。

缓解落地：离线集成门禁包含已安装发行版冒烟测试。典型案例是 tests/test_offline_integration.py 中的test_installed_package_cli_executes_offline_checkpoint_to_report_slice——它"通过离线 checkpoint-to-report CLI 边界演练已安装发行版"。由于该测试超过默认单用例预算，被显式登记为owned_slow_tests条目（见 ci/test-quality-policy.json）：归属@maintainers、最大 120 秒、带理由与 issue、2026-08-15 开启、2026-11-13 过期。配套的 tests/test_package_export_contracts.py 与 tests/test_cli_boundaries.py 进一步验证包导出与 CLI 边界。Gate 2 阶段即要求"已安装包 CLI 配置到报告"纵向切片，正是本风险缓解的目标形态。

十、TQ-R8：数值测试的设备/dtype 脆弱性

风险：浮点运算在 CPU/CUDA/MPS 或不同 dtype 下结果不同，直接断言数值会让测试在后端切换时碎裂。

缓解落地：数值逻辑与设备边界被显式分离：

• 数值不变式契约：obliteratus/analysis/numerical_contracts.py等模块把数值语义固化为契约，由 tests/test_numerical_contracts.py、tests/test_projection_math_contracts.py、tests/test_whitened_svd_oracles.py 验证；ci/test-risk-map.json 中analysis-methods契约面覆盖这些测试。
• 设备选择集中收口：obliteratus/device.py 统一负责 CPU/CUDA/Apple 后端的 device 与 dtype 选择，其conditional_gates指向cuda-runtime、jetson-runtime、mps-runtime，即设备相关行为只在对应后端条件门禁中验证。
• 后端证据分开保留：每个后端有独立证据路径——tests/conditional/test_cuda_runtime.py、tests/conditional/test_mps_runtime.py、tests/conditional/test_jetson_runtime.py、tests/conditional/test_mlx_runtime.py——避免用 CPU 结果冒充 GPU 行为。

十一、TQ-R9：条件证据的提交级新鲜度

风险：条件门禁（如 GPU 测试）是定时运行的，若把旧提交的证据当成新提交的证明，会掩盖回归。

缓解落地，由两条硬性规则构成：

1. 候选 SHA 校验：仅软件可生成的（software-only）条件证据必须匹配候选提交（candidate commit），证据过期即失效。
2. 异常严格化：证据过期时的异常豁免必须同时满足——给出理由、给出规范的数字编号 OBLITERATUS issue、且过期时间距申请日不超过 30 天（架构草图原文："A stale evidence exception requires a reason, a canonical numeric OBLITERATUS issue, and an expiry no more than 30 days away"）。

配套参数见 ci/conditional-test-policy.json：条件证据保留 30 天、最大证据年龄 8 天；仓库还以 tests/test_conditional_evidence_freshness.py 与.aiwg/reports/doc-sync-last-run.json记录并校验证据同步状态，防止证据时间线漂移。

十二、TQ-R10：测试时长所有权与 10 分钟作业上限

风险：测试随功能增长，单测越来越慢，贡献者反馈时间被悄悄侵蚀。

缓解落地，这是 Gate 3 的核心主题：

• 全量计时保留：pytest 把已注册的测试层 markers 附加到每个 JUnit testcase；证据归一化器保留套件总时长、每个 testcase 时长、最慢测试汇总与 marker 聚合，且不破坏 schema version 1 的既有消费者。
• 四级预算：ci/test-quality-policy.json 的duration_budgets规定：按 Python 版本（3.10/3.11/3.12）每套件 ≤240 秒；单个 testcase ≤15 秒；按 marker（cpu/integration/unmarked）各 ≤120 秒；repeat gate 总时长 ≤180 秒、单 pass ≤75 秒。
• 慢测试所有权与过期：超过单用例预算的测试必须进入owned_slow_tests（归属@owner、理由、issue、max_seconds、90 天审查窗口内过期），例如上文提到的已安装包冒烟测试。逾期不处理即被策略拒绝。
• 执行侧硬上限：GitHub Actions 独立把每个强制 Python 测试作业限制为 10 分钟（架构草图："GitHub Actions independently caps each mandatory Python test job at ten minutes"）。
• flaky/quarantine 管理：校验脚本 scripts/check_quality_policy.py 强制执行：30 天窗口内同一测试 flake 达到 2 次必须进入 quarantine；quarantine 最多 30 天，需@owner、理由、issue、开启/过期日期，且过期即失效。证据保留 90 天、flake 观察窗口 30 天，全部作为test_evidence字段被校验。

十三、校验脚本与测试：如何验证这套质量程序本身

风险登记表的每一条缓解措施，仓库都有对应的机器校验，防止制度被静默放宽：

• scripts/check_quality_policy.py——校验不可变质量下限、成熟 CPU 范围测量（从覆盖率报告中剔除仅文档化的环境边界后计算行/分支百分比）、阈值异常与时长预算；
• scripts/check_test_risk_map.py 与 ci/test-risk-map.json——校验每个模块的风险分类（cpu-contract/mixed-runtime/conditional-runtime）与必测测试绑定；
• scripts/check_conditional_policy.py 与 scripts/check_supply_chain_policy.py——分别校验条件门禁与供应链策略；
• scripts/select_pr_tests.py——按 ci/pr-test-policy.json 的always_tests与infrastructure_paths规则选择 PR 测试集；
• 策略一致性测试： tests/test_quality_policy.py、tests/test_pr_test_selection.py、tests/test_ci_policy.py、tests/test_test_risk_map.py、tests/test_supply_chain_policy.py、tests/test_conditional_gate_scripts.py。

本地运行示例（在仓库根目录）：

# 校验质量策略结构与不可变下限 python scripts/check_quality_policy.py --policy ci/test-quality-policy.json # 校验测试风险映射 python scripts/check_test_risk_map.py --map ci/test-risk-map.json # 校验供应链策略 python scripts/check_supply_chain_policy.py --policy ci/supply-chain-policy.json # 运行质量策略一致性测试 python -m pytest tests/test_quality_policy.py tests/test_ci_policy.py tests/test_supply_chain_policy.py

十四、小结

OBLITERATUS 的测试质量程序风险登记表不是一张静态表格，而是一套可执行的治理闭环：10 项风险（TQ-R1～TQ-R10）各自对应仓库内真实存在的策略文件、校验脚本与测试断言。覆盖率造假由变异分数与必测测试绑定遏制；默认 CI 离线由 markers 契约与tests/conditional/排除保证；硬件测试由条件工作流与豁免声明隔离；供应链由不可变 pin 与多策略审计锁定；数值脆弱性由不变式契约与后端分离证据消化；证据新鲜度由候选 SHA 校验与 30 天过期规则守护；反馈时间由四级时长预算与 10 分钟作业上限兜底。这套机制的设计核心可以概括为一句话：把质量要求变成机器可校验的配置，把例外变成必须有人负责、且会过期的显式记录。

进一步阅读：完整风险登记见 .aiwg/risks/risks-testing-quality-program.md，架构设计见 .aiwg/architecture/sketch-testing-quality-program.md，需求用例见 .aiwg/requirements/UC-testing-quality-program.md，测试规划见 .aiwg/testing/master-test-plan.md。

【免费下载链接】OBLITERATUSOBLITERATE THE CHAINS THAT BIND YOU项目地址: https://gitcode.com/GitHub_Trending/ob/OBLITERATUS