trust-but-verify

信任，但要验证

对所有系统声明、测试结果和假设进行审慎验证，通过独立验证而非盲目信任，避免产生虚假的信心并加快问题发现。

何时使用我

在以下情况下使用此技能：

• 测试通过了，但你怀疑仍可能存在问题
• 文档声称功能可用，但你想要验证
• 系统记忆／大脑／进度跟踪显示某项功能已构建
• 利益相关方根据报告认定某项功能已存在
• 你需要在作出关键决策前验证假设
• 构建抵御误报和盲点的能力
• 准备生产发布或高风险变更
• 加入质量信号不确定的系统

我会做什么

1. 识别声明

• 提取声明，来源包括：

  • 测试结果和覆盖率报告
  • 系统文档和规范
  • 进度跟踪和记忆系统
  • 利益相关方的期望和假设
  • 部署日志和监控仪表板
  • 团队沟通和状态更新

• 对声明分类，依据包括：

  • 关键程度（任务关键型或锦上添花）
  • 可验证性（易于测试或含糊不清）
  • 来源可信度（可信来源或未知来源）
  • 距上次验证的时间（新近或过时）

2. 设计验证策略

• 选择合适的验证方法：

  • 独立执行测试（与原测试不同）
  • 系统探测和健康检查
  • 用户场景模拟
  • 数据验证和完整性检查
  • 性能基准测试
  • 安全渗透测试
  • 对比文档与实现

• 与其他测试类型协同：

  • 使用单元测试，但以不同方式运行
  • 使用不同数据运行集成测试
  • 使用边缘情况执行端到端测试
  • 执行混沌测试以验证韧性声明
  • 开展可用性测试以验证用户体验声明

3. 执行审慎验证

• 有意质疑假设：

  • 如果测试测错了对象怎么办？
  • 如果测试因错误原因而通过怎么办？
  • 如果功能可以运行，但不符合用户预期怎么办？
  • 如果系统现在可以运行，但负载增加后无法运行怎么办？
  • 如果文档与实现不一致怎么办？

• 在不同情境下执行验证：

  • 不同环境（不只是测试环境）
  • 不同数据集（不只是测试数据）
  • 不同用户角色（不只是顺利路径）
  • 不同时段（不只是即时验证）
  • 不同故障条件（不只是成功路径）

4. 检测并报告差异

• 对比声明与验证结果：

  • 识别假阳性（声明属实，但验证失败）
  • 识别假阴性（声明不实，但验证通过）
  • 衡量偏差程度（轻微或严重差异）
  • 跟踪验证置信度

• 生成可执行的见解：

  • 发现的具体差异
  • 根因假设
  • 影响评估
  • 优先级建议
  • 验证方法的有效性

按声明类型划分的验证策略

对于“测试通过”声明：

• 验证测试质量：测试是否确实在测试正确的内容？
• 检查测试覆盖率：测试是否覆盖关键路径和边缘情况？
• 审查测试数据：测试数据是否真实且全面？
• 执行替代测试：运行类似但不同的验证测试
• 检查测试环境：测试环境是否与生产环境一致？

对于“功能已构建”声明：

• 验证功能：功能是否确实按描述运行？
• 检查用户体验：功能是否易用且直观？
• 验证集成：功能是否能与其他组件协同工作？
• 测试边缘情况：功能如何处理异常情况？
• 验证文档：文档是否与实现一致？

对于“系统运行中”声明：

• 健康检查：系统是否确实在运行并能响应？
• 负载测试：系统在预期负载下表现如何？
• 故障测试：系统如何处理故障？
• 监控验证：监控系统是否确实能捕获问题？
• 备份验证：备份是否确实可以还原？

对于“记忆／进度”声明：

• 验证完成情况：声称完成的工作是否确实完成？
• 检查质量：已完成的工作是否达到生产就绪状态？
• 验证依赖项：依赖项是否确实存在且能正常工作？
• 审查实现：实现是否符合设计？
• 测试交付成果：交付成果是否确实解决了问题？

示例

# Verify test results claims
npm run verify:test-results -- --test-suite "user-authentication"
npm run verify:test-coverage -- --module "payment-processing"

# Verify feature claims  
npm run verify:feature -- --feature "checkout-flow" --claim "handles 1000 concurrent users"
npm run verify:feature -- --feature "report-generation" --claim "exports to PDF format"

# Verify system operational claims
npm run verify:system-health -- --component "database" --claim "redundant and fault-tolerant"
npm run verify:system-performance -- --endpoint "/api/orders" --claim "response < 200ms"

# Verify progress/memory claims
npm run verify:progress -- --task "implement-payment-webhook" --claim "completed and tested"
npm run verify:documentation -- --section "api-reference" --claim "accurately describes endpoints"

# Comprehensive verification
npm run verify:all-claims           # Verify all identified claims
npm run verify:critical-claims      # Verify only critical claims
npm run verify:stale-claims         # Verify claims not recently checked

# Integration with other testing
npm run verify:with -- --test-type chaos --claim "system-resilient"
npm run verify:with -- --test-type security --claim "no-vulnerabilities"
npm run verify:with -- --test-type usability --claim "user-friendly"

输出格式

Trust But Verify Report
──────────────────────────────
Verification Context: Pre-production release validation
Total Claims Identified: 47
Claims Verified: 23 (priority order)
Verification Duration: 2 hours 15 minutes

Critical Claim Verification Results:

1. Claim: "Payment processing tests pass with 100% coverage"
   Source: CI/CD pipeline report
   Verification Strategy: Independent test execution + coverage analysis
   Result: ❌ DISCREPANCY FOUND
   - Tests pass but don't validate currency conversion rates
   - Coverage shows 100% but misses error handling paths
   - Test data uses only USD, missing other currencies
   Recommendation: Add currency conversion tests, expand test data

2. Claim: "System handles 5000 concurrent users"
   Source: Performance test report from 2 weeks ago
   Verification Strategy: Fresh load test with different patterns
   Result: ⚠️ PARTIALLY VERIFIED
   - System handles 5000 users but response time degrades by 300%
   - Database connection pool exhausted at 4500 users
   - CPU usage reaches 95% at target load
   Recommendation: Optimize database connections, add autoscaling

3. Claim: "User registration feature complete"
   Source: Project management system
   Verification Strategy: End-to-end testing + security review
   Result: ✅ VERIFIED
   - Registration flow works correctly
   - Email verification functional
   - Password security requirements enforced
   - No security vulnerabilities found

4. Claim: "Monitoring alerts configured for all critical errors"
   Source: DevOps runbook
   Verification Strategy: Error injection + alert monitoring
   Result: ❌ DISCREPANCY FOUND
   - Database connection errors not alerting
   - Payment gateway timeouts not monitored
   - Alert thresholds too high for business impact
   Recommendation: Review and update alert configuration

5. Claim: "Backup system tested and functional"
   Source: System documentation
   Verification Strategy: Actual backup restore test
   Result: ⚠️ PARTIALLY VERIFIED
   - Backup creation works
   - Restore process documented but untested
   - Restore time exceeds RTO (Recovery Time Objective)
   Recommendation: Test full restore, optimize restore process

Verification Confidence Assessment:
  - High Confidence: 8 claims (thoroughly verified)
  - Medium Confidence: 10 claims (partially verified)
  - Low Confidence: 5 claims (insufficient verification)
  - Failed Verification: 5 claims (discrepancies found)

Critical Issues Requiring Attention:
  1. Payment currency conversion untested (business risk: high)
  2. Database connection pool limits scalability (performance risk: high)
  3. Missing critical error alerts (operational risk: medium)
  4. Backup restore untested (recovery risk: medium)

Verification Effectiveness:
  - False positives prevented: 3 (would have caused production issues)
  - Assumptions challenged: 12 (revealed hidden risks)
  - Verification time vs value: High ROI (2 hours prevented days of issues)
  - Recommendations generated: 7 actionable improvements

Next Steps:
  1. Address critical discrepancies before release
  2. Improve test coverage for payment processing
  3. Optimize database connection management
  4. Update monitoring and alert configuration
  5. Schedule regular verification for high-risk claims

注意事项

• 信任但验证是一种思维方式，而不只是技术流程
• 根据风险和重要性平衡验证投入
• 记录验证方法和结果，以便审计追踪
• 利用验证结果改进原有测试和声明
• 将验证视为持续进行的过程，而非一次性工作
• 让不同视角参与验证（新的视角能发现不同的问题）
• 随时间衡量验证效果
• 向利益相关者透明地分享验证结果
• 利用验证加深对系统的理解，而不只是发现故障
• 根据所学内容调整验证策略
• 请记住：没有证据不等于证明不存在