# 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、测试条件/风险、测试用例、结果和缺陷之间维护追溯；追溯支持覆盖和残余风险判断。
- 进入条件是开始活动的前提；退出条件定义何时可宣告完成。典型退出条件包括覆盖、未解决缺陷、失败用例及计划测试是否执行。
- 测试独立性有助于挑战开发和需求阶段的认知偏差，但不能代替开发者对代码的熟悉；多个独立层级组合更合适。
- 时间或预算耗尽可以停止测试，但只有利益相关者明确接受残余风险时才可发布，不能自动记为测试通过。

来源：
- https://istqb.org/sdm_downloads/istqb-certified-tester-foundation-level-syllabus-v4-0/
- https://www.istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/

### ISO/IEC/IEEE 29119 与 ISO/IEC 25010

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

来源：
- https://www.iso.org/standard/81291.html
- https://www.iso.org/standard/79429.html
- https://www.iso.org/standard/78176.html

### OWASP ASVS 与 WSTG

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

来源：
- https://owasp.org/www-project-application-security-verification-standard/
- https://owasp.org/www-project-web-security-testing-guide/

### NIST SSDF 1.1

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

来源：
- https://csrc.nist.gov/pubs/sp/800/218/final
- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf

### Google SRE 与分层测试

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

来源：
- https://sre.google/sre-book/testing-reliability/
- https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html
- https://martinfowler.com/articles/practical-test-pyramid.html

### Flaky tests

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

来源：
- https://docs.pytest.org/en/stable/explanation/flaky.html
- https://docs.pytest.org/en/stable/reference/exit-codes.html
- https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html

### 证据 provenance

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

来源：
- https://slsa.dev/spec/v1.2/provenance

### AI Agent 特有安全与独立性

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

来源：
- https://genai.owasp.org/llmrisk/llm01-prompt-injection/
- https://developers.openai.com/api/docs/guides/agent-builder-safety
- https://docs.github.com/en/actions/how-tos/security-for-github-actions/security-guides/security-hardening-for-github-actions
- https://www.nasa.gov/ivv-overview/

## 对 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。