AI测试日报7.2：最新AI测试方向解析

日期：2026-07-01 范围：AI 辅助测试、代码覆盖率、CI/CD 安全、依赖合规、测试成本治理

今日最引人注目的变化，并非新增一个能生成测试的模型，而是测试治理正被直接集成到平台控制层面：覆盖率下降可阻止代码合并，许可证不合规可阻止依赖进入生产环境，不可信触发器不再污染默认分支缓存，AI 消耗也能按团队和个人设定预算。

同时，LLM 测试能力正从“生成输入和断言”扩展到“将自然语言需求转化为可审计规则，并检查实现语义”。这可能缓解部分测试预言机问题，但论文也明确指出了两个限制：温度为 0 时仍会产生不同结果，且规则提取的召回率尚未评估。因此，这种能力适合作为前移的补充证据，不能替代动态测试和人工确认。

GitHub 于 6 月 30 日宣布，可通过分支规则集在覆盖率不达标时阻止 PR 合并。规则支持两种阈值：最低覆盖率，以及相对于默认分支允许的最大下降幅度；两者也可同时启用。团队可先用评估模式观察影响，再切换到活动模式强制执行。

这使覆盖率从“报表指标”升级为平台级质量门禁。更稳妥的配置并非简单追求全局高百分比，而是同时设置一个基线下限和较小的增量退化阈值。对遗留系统而言，后者尤其重要：即使整体覆盖率暂时不高，也能先阻止新代码继续稀释测试。

需要注意的是，覆盖率仅证明代码被执行，而不证明断言有效。建议与变异测试、关键路径用例、缺陷逃逸率和高风险模块的差异覆盖率结合使用，避免“为了通过门禁而补充空断言”。

GitHub Actions 于 6 月 26 日开始对特定不可信事件签发只读缓存令牌。此前，pull_request_target、issue_comment 以及来自 fork PR 的 workflow_run 级联等事件，可能获得默认分支范围的读写缓存权限。外部可控代码一旦写入恶意缓存，后续可信的 push 或 schedule 工作流恢复缓存时，可能执行任意代码并泄露生产密钥。

新规则在“外部人员可触发”且“执行上下文使用共享默认分支 SHA”两个条件同时成立时禁止写缓存。恢复缓存不受影响；若保存被拒绝，actions/cache 会发出告警，但作业继续执行。

对测试团队的影响是：一些 PR 测试可能不再回写依赖或构建缓存，首次运行时间会增加。正确的迁移方式是由可信的 push 工作流预热和保存缓存，让不可信 PR 只读复用；不应为了恢复速度而重新放宽高风险事件权限。

近期工业经验论文提出两阶段流程：ruleMiner 从自然语言需求中提取规范且可证伪的规则，同时将歧义、矛盾和不可验证表述单独记录为 requirements_specs_issues；随后 codeAuditor 根据触发条件、约束、禁止状态及跨文件证据检查代码实现，而非仅做关键词匹配。

论文报告，该方法在智能汽车 WiFi 安全需求案例中，可验证超过 50% 过去仅能通过软件测试评估的需求，并发现了一个后来被修复的高优先级缺陷。其价值在于补足传统静态分析难以发现的业务逻辑错误，例如“需求要求乘法、实现却做了加法”这类语法合法但语义错误的问题。

但其证据仍属早期：规则提取的完整性和召回率未被评估；即使温度设为 0，相同输入多次运行仍会输出不同规则，因此研究采用 1 至 3 次运行后汇总的策略。落地时应保留需求原文、抽取规则、代码证据和人工裁决四层可追溯链，并对等价改写进行变形测试。

GitHub 于 6 月 30 日开放开源许可证合规预览。企业可用规则集定义统一许可证策略；当 PR 新增或修改依赖时，平台自动检查许可证并标注不合规项。问题必须通过删除或替换依赖、修改策略，或创建包级例外来处理，之后才能合并。

这补齐了测试流水线中常被忽略的“可发布性验证”。自动化测试即使全部通过，如果依赖许可证违反组织政策，产物仍不能安全交付。建议将许可证检查与漏洞扫描、SBOM 生成、依赖