OBLITERATUS 测试质量程序风险登记表解析10 项核心风险与四层验证门禁的落地机制【免费下载链接】OBLITERATUSOBLITERATE THE CHAINS THAT BIND YOU项目地址: https://gitcode.com/GitHub_Trending/ob/OBLITERATUS本文围绕 OBLITERATUS 仓库中的测试质量程序Testing Quality Program风险登记表展开逐项拆解 TQ-R1TQ-R10 共 10 项已识别风险及其缓解措施并结合仓库内的 CI 策略文件、校验脚本与测试用例说明这些缓解机制如何在四层验证架构中真正落地。读完本文你将理解这套测试质量程序如何防止覆盖率造假、如何让 PR CI 保持离线与稳定、如何管理硬件条件测试、如何控制供应链暴露与测试时长以及如何保证条件证据不被跨提交复用。一、背景测试质量程序与四层验证架构OBLITERATUS 的测试质量程序建立在四层显式验证架构之上见 架构草图强制 PR 门禁Mandatory PR gate——仅 CPU、离线运行的单元与边界契约测试包含包构建、lint、分支/行覆盖率、警告、JUnit 报告与构建产物。离线集成门禁Offline integration gate——使用微型本地模型/配置夹具验证流水线组合、checkpoint 保存/重载、评估与报告链路。质量深度门禁Quality-depth gate——属性测试、重复测试以及对高后果纯模块的选择性变异测试。条件环境门禁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-15PR #90 审计通过post-merge 主分支 7 个作业全部成功。精确阈值与排除图由 ci/test-quality-policy.json 拥有测试责任分配由 ci/test-risk-map.json 拥有——这正是风险登记表各缓解措施的具体载体。二、风险登记表总览以下为 风险登记表 的完整内容ID风险可能性影响缓解措施TQ-R1无行为断言的覆盖率造假中高要求边界/负向/属性场景并审查变异信号TQ-R2默认 CI 下载模型或访问服务中高严格 markers、空缓存、离线环境、排除网络测试TQ-R3硬件测试使 PR CI 不稳定或不可用高中条件化定时/手动工作流并文档化前置条件TQ-R4工具新增造成供应链暴露中高固定来源、显式更新策略、审计/SBOM 证据TQ-R5警告强制因第三方噪音失败中中分类警告、使用窄化文档化过滤、渐进式预算TQ-R6变异/属性任务超出有效反馈时间中中定位小纯模块深度门禁单独运行TQ-R7安装包行为与 checkout 不同中高干净的 wheel 与 sdist 安装冒烟测试TQ-R8数值测试对设备/dtype 脆弱中高不变式/容差契约后端特定证据分开TQ-R9条件证据被复用于不同提交中高候选 SHA 校验异常需理由、规范 issue 与 30 天内过期TQ-R10测试增长悄悄侵蚀贡献者反馈时间中中保留每个测试/标记的计时策略拥有套件与重复预算慢测试所有权过期作业 10 分钟上限下面逐项深入解析风险与缓解机制的源码级实现。三、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 一旦默认下载模型或访问外部服务就会变慢、不可复现、甚至泄露凭据。缓解落地这条由三层机制共同保证严格 markers 契约pyproject.toml启用--strict-markers并显式登记 markers 列表网络类测试如network、download与 CPU 单元测试被严格区分。默认门禁排除条件测试ci/pr-test-policy.json 的excluded_test_prefixes明确排除tests/conditional/目录——该目录下的网络/下载类测试如 tests/conditional/test_network_services.py、tests/conditional/test_model_download_runtime.py不会进入默认 PR 门禁。条件测试单独工作流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_GATEtrue与专用 CUDA runnerjetson-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/uvpypi: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_targetstests/test_quality_policy.py 断言这些目标配置不可漂移同时断言reporting/report.py不在变异名单、test_telemetry_failure_contracts.py不在 mutmut 而在 repeat gate 中。深度门禁单独运行并限时质量深度作业是独立 jobtests/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 测试是定时运行的若把旧提交的证据当成新提交的证明会掩盖回归。缓解落地由两条硬性规则构成候选 SHA 校验仅软件可生成的software-only条件证据必须匹配候选提交candidate commit证据过期即失效。异常严格化证据过期时的异常豁免必须同时满足——给出理由、给出规范的数字编号 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 秒按 markercpu/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 次必须进入 quarantinequarantine 最多 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-R1TQ-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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OBLITERATUS 测试质量程序风险登记表解析：10 项核心风险与四层验证门禁的落地机制
OBLITERATUS 测试质量程序风险登记表解析10 项核心风险与四层验证门禁的落地机制【免费下载链接】OBLITERATUSOBLITERATE THE CHAINS THAT BIND YOU项目地址: https://gitcode.com/GitHub_Trending/ob/OBLITERATUS本文围绕 OBLITERATUS 仓库中的测试质量程序Testing Quality Program风险登记表展开逐项拆解 TQ-R1TQ-R10 共 10 项已识别风险及其缓解措施并结合仓库内的 CI 策略文件、校验脚本与测试用例说明这些缓解机制如何在四层验证架构中真正落地。读完本文你将理解这套测试质量程序如何防止覆盖率造假、如何让 PR CI 保持离线与稳定、如何管理硬件条件测试、如何控制供应链暴露与测试时长以及如何保证条件证据不被跨提交复用。一、背景测试质量程序与四层验证架构OBLITERATUS 的测试质量程序建立在四层显式验证架构之上见 架构草图强制 PR 门禁Mandatory PR gate——仅 CPU、离线运行的单元与边界契约测试包含包构建、lint、分支/行覆盖率、警告、JUnit 报告与构建产物。离线集成门禁Offline integration gate——使用微型本地模型/配置夹具验证流水线组合、checkpoint 保存/重载、评估与报告链路。质量深度门禁Quality-depth gate——属性测试、重复测试以及对高后果纯模块的选择性变异测试。条件环境门禁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-15PR #90 审计通过post-merge 主分支 7 个作业全部成功。精确阈值与排除图由 ci/test-quality-policy.json 拥有测试责任分配由 ci/test-risk-map.json 拥有——这正是风险登记表各缓解措施的具体载体。二、风险登记表总览以下为 风险登记表 的完整内容ID风险可能性影响缓解措施TQ-R1无行为断言的覆盖率造假中高要求边界/负向/属性场景并审查变异信号TQ-R2默认 CI 下载模型或访问服务中高严格 markers、空缓存、离线环境、排除网络测试TQ-R3硬件测试使 PR CI 不稳定或不可用高中条件化定时/手动工作流并文档化前置条件TQ-R4工具新增造成供应链暴露中高固定来源、显式更新策略、审计/SBOM 证据TQ-R5警告强制因第三方噪音失败中中分类警告、使用窄化文档化过滤、渐进式预算TQ-R6变异/属性任务超出有效反馈时间中中定位小纯模块深度门禁单独运行TQ-R7安装包行为与 checkout 不同中高干净的 wheel 与 sdist 安装冒烟测试TQ-R8数值测试对设备/dtype 脆弱中高不变式/容差契约后端特定证据分开TQ-R9条件证据被复用于不同提交中高候选 SHA 校验异常需理由、规范 issue 与 30 天内过期TQ-R10测试增长悄悄侵蚀贡献者反馈时间中中保留每个测试/标记的计时策略拥有套件与重复预算慢测试所有权过期作业 10 分钟上限下面逐项深入解析风险与缓解机制的源码级实现。三、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 一旦默认下载模型或访问外部服务就会变慢、不可复现、甚至泄露凭据。缓解落地这条由三层机制共同保证严格 markers 契约pyproject.toml启用--strict-markers并显式登记 markers 列表网络类测试如network、download与 CPU 单元测试被严格区分。默认门禁排除条件测试ci/pr-test-policy.json 的excluded_test_prefixes明确排除tests/conditional/目录——该目录下的网络/下载类测试如 tests/conditional/test_network_services.py、tests/conditional/test_model_download_runtime.py不会进入默认 PR 门禁。条件测试单独工作流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_GATEtrue与专用 CUDA runnerjetson-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/uvpypi: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_targetstests/test_quality_policy.py 断言这些目标配置不可漂移同时断言reporting/report.py不在变异名单、test_telemetry_failure_contracts.py不在 mutmut 而在 repeat gate 中。深度门禁单独运行并限时质量深度作业是独立 jobtests/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 测试是定时运行的若把旧提交的证据当成新提交的证明会掩盖回归。缓解落地由两条硬性规则构成候选 SHA 校验仅软件可生成的software-only条件证据必须匹配候选提交candidate commit证据过期即失效。异常严格化证据过期时的异常豁免必须同时满足——给出理由、给出规范的数字编号 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 秒按 markercpu/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 次必须进入 quarantinequarantine 最多 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-R1TQ-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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
