18a - 2026 AI 测试工具全景

传统测试：
  "点击 id 为 submit-btn 的按钮"
  → 按钮 id 改名后测试失败 ❌

Agentic 测试：
  "提交表单"
  → AI 理解意图，找到正确的按钮，即使 UI 变了也能通过 ✅

选择决策树：

团队规模 < 5 人，预算有限？
  → Bug0 Studio（$250/月，自助模式）

需要保证覆盖率，不想自建 QA 团队？
  → QA Wolf（全托管，保证 80% 覆盖率）
  → Bug0 Managed（$2,500/月，4 周交付）

已有 Playwright/Selenium 测试套件，想加 AI 自愈？
  → mabl（$499/月起，IDE 集成好）
  → Katalon（免费版可用，企业版联系销售）

企业级合规需求？
  → Virtuoso（NLP 驱动，企业级支持）
  → QA Wolf（SOC 2 合规）

# 安装 Bug0 CLI
$ npm install -g @bug0/cli
 
# 初始化项目
$ bug0 init
 
# 用自然语言创建测试
$ bug0 create "用户登录后，导航到设置页面，修改用户名为 test_user，
  点击保存，验证页面显示'设置已保存'的成功提示"
 
# 运行测试
$ bug0 run
 
# CI 模式运行
$ bug0 run --ci

为以下用户流程创建 Agentic E2E 测试：

应用类型：[Web App / Mobile App / Desktop App]
关键用户流程：
1. [流程描述，如：用户注册 → 邮箱验证 → 首次登录 → 引导流程]
2. [流程描述]
3. [流程描述]

要求：
- 使用自然语言描述，不要硬编码选择器
- 每个流程包含验证点（期望看到什么）
- 考虑异常路径（网络错误、输入无效）
- 标注关键业务断言

在 Kiro 中的 Spec-Driven 方式：

1. design.md 中定义正确性属性（Correctness Properties）：
   
   Property 1: 文件哈希一致性
   - 对于任意文件 f，hash(f) 在多次计算中必须返回相同结果
   
   Property 2: 同步完整性
   - 同步完成后，远程文件集合必须等于本地文件集合（排除忽略规则）

2. tasks.md 中包含对应的测试任务：
   
   - [ ] 5.1 实现 Property 1 的 Property-Based Test
   - [ ] 5.2 实现 Property 2 的 Property-Based Test

3. 执行测试任务时，Kiro 自动：
   - 生成 property-based test 代码
   - 运行测试
   - 如果失败，分析反例（counter-example）
   - 判断是代码 bug 还是 spec 问题

基于以下代码，生成全面的单元测试：

文件：[粘贴代码或引用文件路径]

要求：
1. 单元测试：覆盖正常路径、边缘场景、错误处理
2. 使用 [Jest / Vitest / Pytest / Go testing] 框架
3. 不要使用 mock，尽量测试真实逻辑
4. 测试命名要描述性强，格式：should_[预期行为]_when_[条件]
5. 每个测试函数只验证一个行为
6. 包含以下场景：
   - 空输入 / null / undefined
   - 边界值（最大、最小、零）
   - 错误输入（类型错误、格式错误）
   - 并发场景（如适用）

传统单元测试：
  test("1 + 1 = 2")           → 只验证一个例子
  test("0 + 0 = 0")           → 又一个例子
  test("-1 + 1 = 0")          → 还是一个例子

Property-Based Testing：
  test("对于任意 a, b: a + b = b + a")  → 验证所有输入的交换律
  test("对于任意 a: a + 0 = a")         → 验证所有输入的单位元
  → 框架自动生成 100+ 随机输入进行验证

属性模式速查表：

1. 往返（Round-trip）：encode(decode(x)) == x
2. 幂等性（Idempotent）：f(f(x)) == f(x)
3. 不变量（Invariant）：sort(xs).length == xs.length
4. 交换律（Commutative）：f(a, b) == f(b, a)
5. 等价性（Oracle）：fast_impl(x) == reference_impl(x)
6. 归纳（Inductive）：如果 P(n) 成立，则 P(n+1) 也成立
7. 困难验证，容易检查：生成结果容易验证但难以直接计算

use proptest::prelude::*;
 
proptest! {
    /// Property: 文件哈希的确定性
    /// Validates: Requirements 1.2
    #[test]
    fn hash_is_deterministic(
        content in prop::collection::vec(any::<u8>(), 0..10000)
    ) {
        let hash1 = compute_hash(&content);
        let hash2 = compute_hash(&content);
        assert_eq!(hash1, hash2, "同一内容的哈希必须相同");
    }
 
    /// Property: 忽略规则的一致性
    /// Validates: Requirements 2.1
    #[test]
    fn ignore_rules_are_consistent(
        path in "[a-z]{1,10}(/[a-z]{1,10}){0,5}",
        pattern in "(\\*\\.[a-z]{1,4}|[a-z]+/)"
    ) {
        let engine = IgnoreEngine::new(vec![pattern.clone()]);
        let result1 = engine.should_ignore(&path);
        let result2 = engine.should_ignore(&path);
        assert_eq!(result1, result2);
    }
}

import fc from 'fast-check';
 
describe('SyncEngine Properties', () => {
  // Property: 同步操作的幂等性
  // Validates: Requirements 3.1
  test('sync is idempotent', () => {
    fc.assert(
      fc.property(
        fc.array(fc.record({
          path: fc.stringMatching(/^[a-z\/]+$/),
          content: fc.string(),
          modified: fc.date()
        })),
        (files) => {
          const result = computeSyncPlan(files, files);
          // 如果本地和远程相同，同步计划应该为空
          expect(result.actions).toHaveLength(0);
        }
      )
    );
  });
 
  // Property: 排序的稳定性
  test('sort preserves length', () => {
    fc.assert(
      fc.property(
        fc.array(fc.integer()),
        (arr) => {
          const sorted = [...arr].sort((a, b) => a - b);
          expect(sorted.length).toBe(arr.length);
        }
      )
    );
  });
});

为以下代码设计 Property-Based Testing：

代码：[粘贴代码]

要求：
1. 使用 [fast-check / proptest / Hypothesis / jqwik] 框架
2. 定义至少 3 个属性：
   a. [属性 1 描述，如：往返属性]
   b. [属性 2 描述，如：幂等性]
   c. [属性 3 描述，如：不变量]
3. 为每个属性设计智能生成器，约束到有效输入空间
4. 不要使用 mock，测试真实逻辑
5. 每个属性用注释标注 "Validates: Requirements X.Y"
6. 考虑收缩策略，确保反例可读

视觉测试策略决策：

组件库 / 设计系统？
  → Chromatic（Storybook 原生集成）

全页面跨浏览器？
  → Applitools（Visual AI，低误报）
  → Percy（性价比高）

预算有限？
  → Lost Pixel（开源）
  → BackstopJS（开源）

需要视觉 + 功能测试合一？
  → askui（视觉 AI 驱动交互）

LLM 输出评估的四个维度：

1. 忠实度（Faithfulness）
   - 输出是否基于提供的上下文？
   - 是否存在幻觉（编造事实）？

2. 相关性（Relevance）
   - 输出是否回答了用户的问题？
   - 是否包含无关信息？

3. 一致性（Consistency）
   - 相同输入是否产生语义一致的输出？
   - 不同表述的同一问题是否得到一致答案？

4. 安全性（Safety）
   - 输出是否包含有害内容？
   - 是否泄露敏感信息？

# promptfoo.yaml
prompts:
  - "用一句话总结以下文章：{{article}}"
  - "作为专业编辑，请用不超过 30 字总结：{{article}}"
 
providers:
  - openai:gpt-4o
  - anthropic:claude-sonnet-4-20250514
 
tests:
  - vars:
      article: "人工智能在 2026 年..."
    assert:
      - type: llm-rubric
        value: "总结准确反映原文核心观点"
      - type: similar
        value: "AI 在 2026 年的发展趋势"
        threshold: 0.7
      - type: javascript
        value: "output.length <= 100"

# 运行评估
$ npx promptfoo eval
 
# 查看结果
$ npx promptfoo view

为以下 LLM 应用设计评估方案：

应用描述：[如：基于 RAG 的客服问答系统]
输入类型：[如：用户问题 + 检索到的文档片段]
输出类型：[如：自然语言回答]

请设计：
1. 至少 5 个评估指标（忠实度、相关性、完整性、简洁性、安全性）
2. 每个指标的评分标准（1-5 分）
3. 至少 10 个测试用例，覆盖正常和边缘场景
4. LLM-as-Judge 的评估 prompt
5. 自动化评估的 Promptfoo 配置

传统模糊测试：
  随机字节 → 程序 → 大部分输入被拒绝（格式不对）
  效率：低，大量无效输入

AI 增强模糊测试：
  LLM 分析代码结构 → 生成语义有效但边界的输入 → 程序 → 更高命中率
  效率：高，输入更有针对性

# JavaScript/TypeScript 项目
$ npm install --save-dev @stryker-mutator/core
$ npx stryker init
$ npx stryker run
 
# 查看变异测试报告
# 关注 "survived" 的变异体——这些是测试盲区

变异测试报告关键指标：

- Mutation Score = 被杀死的变异体 / 总变异体 × 100%
- 目标：> 80%（核心业务逻辑应 > 90%）

变异体状态：
  ✅ Killed：测试检测到了变异 → 测试有效
  ❌ Survived：测试没检测到变异 → 测试有盲区！
  ⏱️ Timeout：变异导致无限循环 → 通常算作 killed
  🚫 No Coverage：没有测试覆盖这段代码 → 需要补充测试

              ┌───────────┐
              │  E2E 测试  │  ← Agentic Testing（Bug0 / mabl / Testers.AI）
              │  (5-10个)  │     AI 像人一样测试关键用户流程
             ┌┴───────────┴┐
             │  集成测试     │  ← AI 生成 + 人工审查
             │  (适量)      │     API 测试、组件集成测试
            ┌┴─────────────┴┐
            │  单元测试       │  ← AI 生成 + Property-Based Testing
            │  (大量)        │     Qodo / Kiro / fast-check / proptest
           ┌┴───────────────┴┐
           │  变异测试        │  ← 测试质量验证
           │  (CI 中自动)     │     Stryker / PIT / cargo-mutants
          ┌┴─────────────────┴┐
          │  静态分析          │  ← AI 驱动的 lint + 安全扫描
          │  (自动)           │     ESLint + AI 规则 / clippy / Qodo 审查
          └───────────────────┘

# .github/workflows/ai-test-suite.yml
name: AI-Powered Test Suite
 
on: [push, pull_request]
 
jobs:
  static-analysis:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: AI Code Review
        run: npx @qodo/cli review --ci
      - name: Lint
        run: npm run lint
      - name: Type Check
        run: npm run typecheck
 
  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit Tests
        run: npm test
      - name: Property-Based Tests
        run: npm run test:pbt
 
  mutation-tests:
    runs-on: ubuntu-latest
    needs: unit-tests
    steps:
      - uses: actions/checkout@v4
      - name: Mutation Testing
        run: npx stryker run
      - name: Check Mutation Score
        run: |
          SCORE=$(cat reports/mutation/mutation.json | jq '.mutationScore')
          if (( $(echo "$SCORE < 80" | bc -l) )); then
            echo "Mutation score $SCORE% is below 80% threshold"
            exit 1
          fi
 
  visual-tests:
    runs-on: ubuntu-latest
    needs: unit-tests
    steps:
      - uses: actions/checkout@v4
      - name: Visual Regression
        run: npx percy exec -- npm run test:visual
        env:
          PERCY_TOKEN: ${{ secrets.PERCY_TOKEN }}
 
  e2e-tests:
    runs-on: ubuntu-latest
    needs: [unit-tests, visual-tests]
    steps:
      - uses: actions/checkout@v4
      - name: Agentic E2E Tests
        run: bug0 run --ci
        env:
          BUG0_API_KEY: ${{ secrets.BUG0_API_KEY }}

真正的自愈：
✅ #add-to-cart 变成 .btn-cart → 自动更新选择器，测试通过
✅ 按钮从页面顶部移到底部 → 自动找到新位置
✅ 表单增加了一个新字段 → 跳过新字段，完成原有流程
✅ 页面重新设计但功能不变 → 视觉模型重新理解布局

假的自愈（营销话术）：
❌ 只是重试失败的测试（retry ≠ self-heal）
❌ 需要人工确认每次修复
❌ 只能处理简单的 CSS 类名变更
❌ 选择器库预定义了备选方案（不是真正的 AI 理解）

第 1 周：基础层
├── 静态分析：ESLint + TypeScript strict mode（免费）
├── 单元测试：Vitest + fast-check PBT（免费）
└── AI 代码审查：Qodo 免费版

第 2 周：集成层
├── API 集成测试：Vitest + Supertest（免费）
├── 组件测试：Playwright 组件测试（免费）
└── 变异测试：Stryker（免费，CI 中运行）

第 3 周：视觉 + E2E 层
├── 视觉回归：Percy（$399/月）
├── Agentic E2E：Bug0 Studio（$250/月，覆盖 5 个关键流程）
└── 总月费：$649（预算内）

持续维护：
├── CI 自动运行全部测试
├── PR 触发 Qodo 代码审查
├── 每周审查变异测试报告
└── 每月更新 E2E 测试覆盖的用户流程