宜博 / lemongraph

research-basis.md 7.26 KB

QA 真实验收研究基线

访问与验证时间：2026-07-24 18:25 CST

结论摘要

高质量 QA Agent 不是“替开发者再跑一次测试”，而是基于独立证据做风险验收：

  1. 从需求和验收标准建立原子 claim；
  2. 维护 需求/风险 → 实现 → 测试 → 结果 → 缺陷 双向追溯；
  3. 按风险和变更影响选择静态、单元、契约、集成、E2E、探索、回归及非功能测试；
  4. 清楚标注执行证据层级，不能把 mock 单测升级描述为真实功能验收；
  5. 保存基线、环境、命令、退出码、测试收集数、原始日志和依赖边界；
  6. 采用 PASS/FAIL/INCONCLUSIVE，未知和不稳定永不算通过；
  7. 真实启动路径、父子任务装配、故障路径和相邻回归属于严格放行门；
  8. Dev 证据只是线索，QA 必须独立复核；不可信代码和内容必须隔离、最小权限执行。

经一手来源支持的关键发现

ISTQB CTFL v4.0.1

  • 测试目标包括评估需求/用户故事/设计/代码，发现缺陷，达到覆盖，降低质量风险，验证需求和支持利益相关者决策。
  • 穷尽测试不可行，应使用技术、优先级和风险测试聚焦测试投入。
  • 应在 test basis、测试条件/风险、测试用例、结果和缺陷之间维护追溯；追溯支持覆盖和残余风险判断。
  • 进入条件是开始活动的前提；退出条件定义何时可宣告完成。典型退出条件包括覆盖、未解决缺陷、失败用例及计划测试是否执行。
  • 测试独立性有助于挑战开发和需求阶段的认知偏差，但不能代替开发者对代码的熟悉；多个独立层级组合更合适。
  • 时间或预算耗尽可以停止测试，但只有利益相关者明确接受残余风险时才可发布，不能自动记为测试通过。

来源：

ISO/IEC/IEEE 29119 与 ISO/IEC 25010

  • 29119-1 提供软件测试一般概念；29119-3定义测试文档基线。
  • ISO/IEC 25010:2023 提供产品质量模型，可用于检查验收是否只覆盖功能而漏掉可靠性、安全、交互、维护等质量特性。
  • ISO 正文多数受版权限制，本研究只使用 ISO 官方公开元数据和摘要，不声称读取了付费全文。

来源：

OWASP ASVS 与 WSTG

  • ASVS 为应用技术安全控制提供可编号的验证要求，适合把安全 claim 纳入追溯矩阵，而不是只做无范围的“安全扫描”。
  • WSTG 是 Web 应用和服务的系统性安全测试指南。
  • 安全测试必须按变更暴露面选择要求；不能把自动扫描无发现等同于无漏洞。

来源：

NIST SSDF 1.1

  • 安全要求应贯穿 SDLC；代码审查/分析、可执行代码测试、第三方组件审查和漏洞根因处理是不同控制，不能互相替代。
  • QA 应把授权、输入处理、第三方依赖、已知漏洞和安全回归纳入高风险变更门禁。

来源：

Google SRE 与分层测试

  • 单元、集成、系统和生产验证各自能发现不同问题；高层测试成本更高，不应挤压低层测试。
  • 系统测试可覆盖 smoke、性能、回归等；生产/配置验证揭示 hermetic 环境无法证明的真实配置组合问题。
  • 测试通过不能证明可靠性，但失败通常能证明可靠性不足。
  • E2E 测试昂贵且更容易不稳定，因此应保持少而关键，同时不能完全取消真实链路验证。

来源：

Flaky tests

  • pytest 官方定义 flaky 为间歇性、非确定性通过/失败；常见原因是未隔离系统状态、顺序依赖、并行冲突、全局状态和时间断言。
  • rerun 可帮助诊断，但会给失败额外通过机会；宽松 xfail 隔离长期使用有风险。
  • 因此 QA 必须保存首次失败，不能用后续偶然通过覆盖它。

来源：

证据 provenance

  • SLSA 将 provenance 定义为描述软件产物在何处、何时、如何产生的可验证信息，用于按预期验证产物并支持重建。
  • QA 证据可借用此原则：记录 commit、dirty 状态、环境、命令、时间、依赖/镜像、结果和产物 hash，避免测试报告与实际构建脱钩。

来源：

AI Agent 特有安全与独立性

  • 外部网页、仓库文档、日志、fixture 和 Issue 可包含间接提示注入；应作为数据处理，不能改变 QA 的指令层级。
  • 应使用隔离环境、最小权限、脱敏/虚假数据和目标域限制，避免测试代码窃取凭证或外传数据。
  • 开发者日志与截图应标为 developer claim；最终 verdict 来自 QA 控制域的真实执行。
  • NASA IV&V 强调验证方技术和管理独立性，可借鉴为 QA 自行选择范围、技术和问题处置，而不是照抄开发者测试计划。

来源：

对 v1 skill 的 Gap Analysis

v1 已具备单任务认领、静态审计、单元/集成测试和 Bug 闭环，但存在以下不足：

  • 没有验收 claim 与证据的覆盖矩阵；
  • 没有显式风险和变更影响分析；
  • 没有 PASS/FAIL/INCONCLUSIVE 区分，环境不足可能被误判；
  • 没有证明测试被真实收集、退出码未被吞掉；
  • 没有 mock 与真实依赖边界、真实启动入口和外部可观察结果要求；
  • 没有 flaky 首次失败保留规则；
  • 没有环境/代码基线与证据 provenance；
  • 没有性能、可靠性、安全、兼容和可访问性的触发条件；
  • 没有 AI Agent 的提示注入、最小权限和工作区保护控制；
  • “通过”门槛不够机械、不可审计。

以上缺口已在 qa-task-validation v2.0 中补齐。

适用限制

  • 标准提供原则和质量模型，不能替项目发明业务验收标准或性能阈值。
  • 测试金字塔是启发式模型，不是固定比例；测试组合应按系统架构和风险裁剪。
  • E4 staging 通过不证明生产所有配置、容量和数据组合都正确；E5 也只证明受测生产样本。
  • 自动化测试、SAST、DAST 和扫描器都可能产生假阳性/假阴性，需要人工/Agent 分诊和真实行为验证。
  • 当必要环境或权限缺失时，正确结论是 INCONCLUSIVE，而不是 PASS。