ln-23-test-suite-auditor

测试套件审计员

目标： 将测试组合视为一个只读的生命周期与可信度系统进行审计。确定它能检测哪些重要故障，哪些证据不可信或已过时，以及哪些新增、变更、整合、退役或明确遗漏能够构成最精简且可持续的测试组合。

执行约定： 按顺序排列的复选框即为完成定义。对每一项，内部跟踪其状态：PENDING、有具体证据支持的 PROVEN、有证据证明条件不存在的 CLEARED，或存在缺口的 UNPROVEN；阅读、委派或工具故障都不构成证明。每完成一个部分后都要重新核对各项。返回前，解决所有 PENDING 项，只统计 PROVEN 和 CLEARED；对所有缺口应用本技能的判定和审批规则。 保留用户意图、范围和现有授权。继续已获授权的工作；仅在存在影响重大的未决选择或需要外部审批时提问。根据实际风险调整审查深度，不得悄然跳过检查。保留依赖关系和安全顺序；除此之外，应针对每项义务选择适当的验证方法。

工具路由

需求	首选工具	适用情形	后备方案
源码和测试清单	原生文件列表、搜索、清单及测试配置	梳理领域、测试类型、运行器、夹具和生成内容区域	仓库目录树加已知测试入口
测试与代码的关系	语言服务器或宿主原生代码智能工具	映射单元、调用方、实现、路由和测试目标	通过名称和路径搜索，并经直接读取验证
执行与可信度	通过 Shell 运行仓库定义的测试命令	确定通过或失败状态、耗时、顺序依赖或可复现性	检查 CI 结果和配置；将执行标记为不可用
覆盖率和遗漏行为	现有覆盖率工具和报告	覆盖率数据已配置，且与源码范围可比较	静态映射行为与测试；不得编造百分比
不稳定性和隔离证据	使用仓库支持的重复、随机排序、并行或种子控制运行	怀疑测试依赖顺序、时间、随机性或共享状态	检查历史记录、CI 日志和代码路径证据
断言强度	阅读测试、失败输出及已配置的变异测试	确定测试是否会因有实际意义的行为缺陷而失败	将反事实推理与具体断言关联
框架语义	官方测试运行器或框架文档	结论取决于生命周期、夹具、重试、隔离或模拟行为	查阅一手来源的网络资料；否则标记为 UNVERIFIED

仅运行安全的测试和诊断命令。审计期间不得重写快照、更新黄金文件、重新生成夹具或接受输出变更。

证据规则

• 覆盖率表示执行情况，而非证明。重要行为必须有断言或可观测的判定依据。
• 如果慢速测试是保护关键流程的唯一手段，它就不是低价值测试；如果快速测试证明的只是框架行为，它就不是高价值测试。
• 必须区分不稳定测试导致的失败、间歇性失败的产品依赖项，以及真正非确定性的需求。
• 建议删除测试时，必须证明其测试依据已过时，或者其他证据以同等或更高的可信度覆盖了所有仍需验证的行为和故障模式。
• 建议合并测试时，必须证明覆盖存在重复或分散，并保留不同的业务场景和故障场景、判定依据的强度及故障定位能力；测试更大并不天然更好。
• 不能仅因数值启发式评分较低，就将已知回归防护测试或罕见关键边界情况的唯一证明列为删除对象。
• 真实依赖项本身并不意味着测试有缺陷。应评估其版本、状态、所有权、重置方式、可用性和故障证据是否足以保证结果可复现。
• 将测试组合操作（KEEP、ADD、UPDATE、MERGE、DELETE、NO_TEST）与执行状态（PASS、FAIL、BLOCKED、UNPROVEN、QUARANTINED）分开。NO_TEST 必须有现存证明、其他控制措施或明确接受剩余风险作为依据。
• 默认不要求建立新的注册表。优先使用可从仓库原生测试路径、行为名称、标签、需求、CI 配置和评审证据中推导出的可追溯性。
• 只有在外部测试指南能说明此测试套件中的具体弱点时，它才具有可操作性。

检查清单

1. 梳理测试组合与基线

• 检测测试运行器、配置、命令、目录、固定装置、工厂、快照、黄金文件、手动脚本、覆盖率及变异测试工具。
• 将源代码领域和关键入口映射到单元、集成、契约、端到端及手动测试范围。
• 在有证据的情况下，将需求、产品风险、事故、公开契约和变更行为追溯到测试及结果；找出当前没有测试依据的测试，以及没有可信证明的测试依据要素。
• 阅读仓库说明和 CI 配置，识别必需的测试套件、环境假设、重试、分片及排除项。
• 在可行的情况下运行有代表性的测试套件和必需的门禁；记录环境、耗时、退出状态、发现和执行的范围、失败、跳过及重试情况。标出静默地未选中任何测试的必需测试套件。
• 在评估测试组合前，将生成内容、供应商代码、示例、迁移历史和基础设施固定装置与产品测试区分开。
• 保持审计只读，并披露获准命令创建的任何缓存或测试产物。

2. 审计产品价值和覆盖范围

• 找出独特且关键的本地逻辑：资金、身份验证、授权、数据完整性、算法、领域规则、破坏性操作和不可逆工作流。
• 将每项关键行为追溯到至少一个测试，该测试的判定依据会因相应缺陷而失败；名称或路径匹配以及行覆盖率只能作为发现线索。
• 找出那些只是在重复验证语言、框架、数据库引擎、ORM、HTTP 客户端、密码学、序列化器或库的行为，却未断言仓库自有的配置、查询、架构、适配、验证、故障处理或可观察结果的测试。
• 检查端到端测试是否跨越与风险相关、符合生产环境的边界，并证明最终持久化结果或用户可见结果，而不只是中间状态、页面或模拟调用。
• 找出缺少端到端验证的关键流程，以及行为已由更可靠的较低层级覆盖、但成本高昂的端到端测试。
• 在故障合理且代价高昂的情况下，检查错误、重试、超时、授权、并发、迁移、兼容性和恢复行为。
• 使用覆盖率数据定位未执行的关键路径，然后检查行为和断言，再报告缺口。
• 将每项实质性缺口和范围内受影响的测试分类为 KEEP、ADD、UPDATE、MERGE、DELETE 或 NO_TEST，并根据影响、可能发生的故障、独特性、可信度和维护成本说明理由；当有价值的意图仍然存在，但其依据、设置、边界、断言或判定依据需要改变时，使用 UPDATE。

3. 审计隔离性和确定性

• 检查共享数据库、文件系统、环境、进程、网络、缓存、时钟、随机数生成器和全局状态是否会在测试间泄漏。
• 检查成功和失败情况下的设置与清理、唯一测试数据、事务边界、清理操作，以及并行安全的资源所有权。
• 仅使用有助于区分原因的模式诊断疑似不稳定测试：单独运行、套件内运行、固定种子重复运行、随机或反向排序运行，或并行执行。保留首次失败、顺序、种子、工作进程和环境信息；在证据确定原因或有限诊断预算耗尽时停止。
• 检测时间、时区、区域设置、随机性、休眠、调度器和竞态敏感性；行为依赖时钟或种子时，要求时钟或种子可控。
• 对真实依赖和模拟器，核实版本固定、就绪状态、命名空间或状态重置、故障清理、凭据和 CI 可用性，而不是假定真实依赖或模拟依赖必然更可取。
• 检查重试和隔离规则，确保它们保留首次失败和可复现性数据，而不是将初次失败转为静默通过。
• 要求每项隔离测试都在通过结果之外保持可见，并有负责人或决策流程，以及具体的恢复、替换或退役触发条件；隔离是一种执行状态，而非测试组合的处置措施。
• 根据重复证据、日志和失败路径，区分测试不稳定与产品真实的间歇性缺陷。

4. 审查结构、维护情况和判定依据

• 检查测试布局是否遵循源代码领域或清晰的类型分类约定，以及贡献者能否找到归属的测试。
• 查找孤立测试、已禁用的测试套件、重复的测试夹具、零散的场景覆盖、过大的文件，以及难以辨明归属的扁平目录。
• 根据当前风险审查临时特征测试、迁移测试、兼容性测试、事件测试、变通方案测试和回归测试。已修复的事件不意味着可以移除相应的回归防护；在建议合并或删除测试之前，必须确认相关行为已过时，或有可信的替代覆盖。
• 检查测试名称和编排是否体现行为意图、前置条件、操作和预期结果，而不是叙述实现过程。
• 根据可观察契约和本地化策略，使用稳定且符合项目惯例的语义定位器（角色、可访问名称、标签）或显式 ID／测试钩子。避免依赖样式、位置、时序和偶然的结构。当文案本身是要求时，应单独处理精确文案断言；如果已有可靠的语义定位器，不要仅为添加钩子而要求修改产品代码。
• 检查断言是否具体，是否能证明否定结果，是否平衡覆盖状态和交互，是否提供有用的失败信息，以及是否能抵御误报。
• 标记缺少有意义判定依据的测试、过弱的真值判断、对偶然产物或无法审查的输出进行快照的测试、宽泛地接受异常的测试，以及绕过被测行为的模拟。保留能够独立证明所需契约的快照或隐式失败判定依据。
• 检查预期值是否来自独立契约、示例、不变量或黄金产物，而不是在测试中重现实现的计算逻辑。
• 检查模拟对象、伪对象、模拟器和生成的客户端是否存在契约偏移；如果偏移可能造成错误信心，则要求添加契约测试，或通过其他可信方式与真实边界进行比对。
• 在使用默认值的测试可能掩盖硬编码端口、限制、超时、路径或功能行为时，测试非默认配置值。
• 对关键的判定依据薄弱案例，使用已有的变异测试结果或安全且有针对性的反事实检查；不要强制要求在整个代码库范围内进行变异测试。
• 审查手动测试是否具备可复现的设置、快速失败行为、明确的预期证据、幂等性、清理步骤、可移植性和操作说明。
• 检查测试夹具和辅助工具的抽象是否易于理解且默认值是否合理；构建器中的隐藏行为不得使重要测试条件变得不可见。
• 审查门禁的设置位置和测试套件成本：必需门禁应防范重大的发布风险；较慢的诊断性或探索性证据应便于查找，但不应造成不必要的日常交付阻碍。

5. 验证发现并报告

• 只有当生命周期、夹具、隔离、重试或模拟行为可能改变发现时，才研究运行器或框架语义；使用与版本匹配的官方资料。
• 在安全的前提下，复现高严重性信任失效，并保留命令、种子、顺序和环境证据。
• 对根因相同的发现进行去重，例如全局夹具导致多个套件不稳定。
• 应用实质性门槛：必须有具体证据表明存在关键证明缺口、错误置信、交付风险，或在有证据支持的规模下反复产生维护成本。排除个人偏好、理论上的纯粹性、泛泛的最佳实践、假设性的规模问题和合理的替代方案；应要求说明结果或约束，而不是偏好的实现方式。
• 对外部修正，应以版本匹配的官方约定为依据；未解决的权衡应采用一手工程资料。引用有依据的机制；对于本地缺陷，本地证据即可。
• 根据尚未得到证明的关键行为、错误置信、交付受阻和维护负担，将发现归类为 P0-P3。
• 有证据时，报告有助于决策的组合指标：按证明状态划分的重要风险、处置分布、必需门禁的结果与耗时、跳过项、重试、隔离，以及孤立或过时的候选项。不得将测试总数、未排除跳过项的通过率、原始覆盖率和级别占比单独作为质量目标。
• 当无法访问必需的关键测试套件、环境或判定依据，且没有可信的静态或历史替代证据时，使用 BLOCKED；当证据表明关键行为尚未得到证明、必需门禁失败，或不可信的关键部分仍造成错误置信时，使用 FAIL；仅在存在非阻塞性的组合或维护风险时使用 CONCERNS；只有在必需证据可信且不存在关键缺口时才使用 PASS。

自检

• 返回前核对。 检查各项证据、需求覆盖、矛盾、范围、结论和适用的清理工作。修正报告或获授权修改的产物。复用有效证据；不要自动重新扫描代码库或重跑已成功的命令。仅针对相关变更、失败或尚未解决的证据重复检查。披露剩余缺口。

输出约定

使用用户所用语言，按以下顺序报告；保留全部五个字段，并且每项事实只陈述一次。结果较少时，每个字段可占一行；省略空表格，不要复制链接指向的产物：

1. 结果： 技能专属结论及有依据的结果。
2. 范围： 已审查／变更的范围、排除项、基线和重要假设。
3. 证据： 下方列出的技能专属字段；区分事实、推断和未经验证的说法。链接到产物；适合时使用表格。
4. 验证： 检查及其结果、无法获取的证据，以及适用的清理工作／外部状态。
5. 完成情况： Checklist: X/Y complete；Incomplete: None，或列出每项 UNPROVEN 的原因、对结果的影响和确切的后续操作；以及剩余风险和必需的决策。

技能专属证据： 测试依据／受保护的风险 → 现有测试或缺失的证明 → 组合处置 → 判定依据 → 门禁／结果 → 替代证据或退役触发条件。若有证据，应涵盖关键行为、隔离、维护、断言强度、生命周期、组合净影响、必需门禁／诊断门禁、耗时、跳过项、重试和隔离。发现必须注明优先级、测试位置、未覆盖的缺陷类别、影响、不可接受的权衡和最小修正；保留独特覆盖，并区分组合处置与执行状态。