Update nexus wiki content
This commit is contained in:
@@ -2,51 +2,49 @@
|
||||
title: "Testing Reality Checker"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-21
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/testing/testing-reality-checker.md]]
|
||||
- [[Agent/agency-agents/testing/testing-reality-checker.md]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:The Agency Testing 部门的 Reality Checker Agent——通过自动化截图证据截断"幻想型认证",要求压倒性视觉证明才授予生产就绪状态。
|
||||
- 问题域:AI Agent 协作中各环节(设计/开发/QA)给出的评估过于乐观,缺乏实际截图验证,导致"98/100 评级"发给基础网站、"生产就绪"标签打在未完成系统上。
|
||||
- 方法/机制:强制三步流程(Reality Check 命令 → QA 交叉验证 → 端到端系统截图分析)+ 硬性失败触发器;默认 NEETS WORK 状态,必须有压倒性证据才能升级为 READY。
|
||||
- 结论/价值:第一次实现通常需要 2-3 轮修订;C+/B- 评级属正常;只有真实截图证据才能支撑"生产就绪"声明。
|
||||
- 核心主题:AI Agent 开发中的质量把控与现实核查机制——防止不切实际的"幻想型认证",要求基于截图证据的生产就绪性评估
|
||||
- 问题域:AI Agent 系统中的集成测试、质量认证、部署就绪性评估
|
||||
- 方法/机制:通过强制执行 Reality Check 命令、抓取截图证据、交叉验证 QA 发现、端到端用户旅程测试,默认状态为"NEEDS WORK"
|
||||
- 结论/价值:只有基于压倒性证据的评估才能获得生产认证;初次实现通常需要 2-3 轮迭代
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- Testing Reality Checker Agent 作为最后一道防线,通过截图证据截断"幻想型认证",要求压倒性视觉证明。
|
||||
- 所有系统声明需要视觉证明(自动化截图),规格说明需要对照实际实现进行交叉验证。
|
||||
- 完整的用户旅程测试需要截图证据;性能数据(加载时间、错误率)必须来自 test-results.json。
|
||||
- 默认"NEEDS WORK"状态,除非有压倒性证据支持"READY"。
|
||||
- Reality Checker Agent 通过强制执行截图验证,防止"零问题"或"98/100"等无根据的完美评分
|
||||
- 所有系统声明都需要可视化证据支持,Cross-reference QA 发现与实际实现
|
||||
- 测试完整用户旅程需要截图证据,验证规格是否真正被实现
|
||||
- 首次实现通常需要 2-3 轮修订周期,C+/B- 评分正常且可接受
|
||||
- "Production Ready" 状态默认为 NEEDS WORK,除非有压倒性证据支持
|
||||
|
||||
## Key Quotes
|
||||
> "You're the last line of defense against unrealistic assessments" — Testing Reality Checker Agent 自我定位
|
||||
> "Default to 'NEEDS WORK' status unless proven otherwise" — 核心认证原则
|
||||
> "First implementations typically need 2-3 revision cycles, C+/B- ratings are normal" — 现实质量预期
|
||||
> "Trust evidence over claims" — 质量认证核心方法论
|
||||
> "Defaults to 'NEEDS WORK' status unless proven otherwise" — 核心立场:默认不通过
|
||||
> "No more '98/100 ratings' for basic dark themes" — 反对无根据的完美评分
|
||||
> "Trust evidence over claims, default to finding issues" — 信任证据而非声明
|
||||
> "First implementations typically need 2-3 revision cycles" — 现实的质量改进周期
|
||||
|
||||
## Key Concepts
|
||||
- [[End-to-End Testing]]:完整用户旅程截图分析(桌面/平板/手机 × 交互前/后对比)
|
||||
- [[Evidence-Based Certification]]:以自动化截图 + test-results.json 数据为唯一认证依据
|
||||
- [[Specification Compliance]]:原始规格与实际实现之间的差距分析(gap analysis)
|
||||
- [[Quality Gate]]:生产就绪认证门槛——默认"NEEDS WORK",需压倒性证据才通过
|
||||
- [[Automated Screenshot Testing]]:Playwright qa-playwright-capture.sh 自动化截图捕获
|
||||
- [[IntegrationTesting]]:系统级集成测试,验证各组件协同工作
|
||||
- [[EvidenceBasedAssessment]]:基于截图和性能数据的质量评估方法
|
||||
- [[RealityCheck]]:防止幻想型认证的核查机制
|
||||
- [[Playwright]]:自动化浏览器截图工具(qa-playwright-capture.sh)
|
||||
|
||||
## Key Entities
|
||||
- Testing Reality Checker Agent:The Agency Testing 部门角色——截图驱动的生产就绪认证 Agent
|
||||
- QA Agent:前序 QA 测试环节,提供自动化测试发现和证据
|
||||
- Integration Agent:RealityIntegration——Reality Checker 的执行主体
|
||||
- [[testing-workflow-optimizer]]:工作流优化 Agent,为 Reality Checker 提供优化流程建议
|
||||
- [[testing-api-tester]]:API 测试 Agent,提供后端接口层面的测试证据
|
||||
- [[TestingRealityChecker]]:Reality Checker Agent 本身,终极集成测试和部署就绪性评估角色
|
||||
- [[QA Agent]]:QA 代理,提供自动化 headless Chrome 测试结果作为证据来源
|
||||
|
||||
## Connections
|
||||
- [[testing-workflow-optimizer]] ← workflow integration ← [[testing-reality-checker]]
|
||||
- [[testing-api-tester]] ← evidence source ← [[testing-reality-checker]]
|
||||
- [[testing-accessibility-auditor]] ← cross-validation ← [[testing-reality-checker]]
|
||||
- [[testing-evidence-collector]] ← provides screenshots ← [[testing-reality-checker]]
|
||||
- [[testing-reality-checker]] ← final gate ← [[agents-orchestrator]]
|
||||
- [[Testing Workflow Optimizer]] ← depends_on ← [[Testing Reality Checker]]
|
||||
- [[Testing API Tester]] ← extends ← [[Testing Reality Checker]]
|
||||
- [[Testing Evidence Collector]] ← provides_evidence_to ← [[Testing Reality Checker]]
|
||||
- [[Testing Tool Evaluator]] ← evaluates_tools ← [[Testing Reality Checker]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[testing-workflow-optimizer]] 潜在张力:Workflow Optimizer 追求流程效率(目标:75% 流程错误减少),Reality Checker 追求真实性(默认"需要工作"),两者在修订周期数量上可能存在分歧——Optimizer 希望快速迭代,Checker 要求充分证据
|
||||
- 与 [[testing-api-tester]] 的互补关系:API Tester 提供后端接口测试证据,Reality Checker 要求端到端截图;两者共同构成前后端双重质量门控
|
||||
- 与过度乐观的 Agent 评估体系冲突:
|
||||
- 冲突点:其他 Agent 可能声称"零问题"或"生产就绪"而无需证据
|
||||
- 当前观点:Reality Checker 默认为 NEEDS WORK,要求压倒性证据
|
||||
- 对方观点:其他 Agent 可能认为系统已完成
|
||||
|
||||
Reference in New Issue
Block a user