# 云服务测试的 AI 转型: 六个方向、五项能力、四类工具

```{contents}
```

团队要借助 AI 转型,测试是被低估的最佳切入点。这篇文章面向云服务测试团队,回答三个问题:**从哪里切入(方向)、人要会什么(能力)、要把什么固化下来(工具)**,并给出一条 90 天可执行的落地路线。

## 结论先放在前面

1. **测试比开发更适合先做 AI 转型**:产出物是用例、脚本、报告这类"人能直接读懂的资产",AI 生成的东西可以立刻被人工评审,不需要像业务代码那样跑起来才知道对错;
2. **方向优先级**:测试用例生成 > 失败日志分诊 > 接口契约脚本 > 团队知识库 > 环境与混沌工程——前两个见效最快,建议从这里试点;
3. **能力建设只有一条主线**:会提问 → 会给上下文 → 会评审 → 会工具化。工具化之前的所有环节,都是个体技巧,不成团队资产;
4. **落地节奏**:第 1 个月个人提效,第 2~3 个月流程集成,第 3 个月之后再把验证过的环节自动化。不要一步到位做全自动;
5. **团队 AI 架构一句话**:让 AI 消费团队资产(git 版本化的知识 + 评审过的模板),而不是个人记忆——知识从个人收藏变成团队基础设施,人从存储者变成评审者。

## 为什么测试团队适合先做 AI 转型

| 测试工作的特点 | 为什么适合 AI |
|--------------|---------------|
| 产出是文档和代码 | 用例、脚本、报告本身就是可读资产,AI 产出可以被逐行评审,人工兜底成本低 |
| 输入高度规整 | 需求文档、OpenAPI 规范、错误码表都是结构化材料,恰是 AI 最擅长的"读规整材料、产规整产物" |
| 重复劳动占比高 | 用例矩阵展开、错误码穷举、日志翻找,正是 AI 替代收益最大的部分 |
| 有天然评审者 | 用例对不对,测试工程师对照需求就能判;不像业务代码需要完整运行环境 |

对比开发团队:AI 写的业务代码引入的缺陷可能要上线才暴露,而 AI 写的测试用例引入的缺陷,会在评审时直接被测试工程师拦下。**同样的技术,在测试侧的风险小一个数量级**,所以转型阻力小、见效快。

## 云服务测试的特殊性: AI 的机会所在

云服务测试和普通软件测试不一样的地方,恰恰是 AI 最能发挥的地方:

| 云服务特点 | 测试关注点 | AI 能做什么 |
|-----------|-----------|------------|
| API 优先 | 接口契约、版本兼容 | 从 OpenAPI 文档直接生成契约测试,API 变更后自动同步脚本 |
| 多租户 | 隔离性、越权访问 | 生成"租户 A 资源 vs 租户 B 令牌"的越权用例矩阵 |
| 弹性与配额 | 限流、配额边界、并发 | 枚举边界值:配额满、并发超配、突发流量 |
| 计费 | 计量准确性 | 生成计费对账用例(用量统计 vs 账单) |
| SLA/SLO | 可用性、容灾切换 | 从架构文档生成故障场景清单和混沌实验设计 |
| 错误码繁多 | 全量错误路径覆盖 | 穷举几十个错误码,每个错误码配一条用例——人最容易漏,机器最不容易漏 |

最后一行值得单独说:**错误码覆盖是云服务功能测试里性价比最高的盲区治理**。一个云服务几十个接口、每个接口十几个错误码,人工展开必然遗漏;而"每个错误码一条用例、断言错误码与提示信息"这类机械工作,正是 AI 的理想输入。

## 方向一: 测试用例生成与评审(优先级最高)

场景:需求文档 + OpenAPI 文档 → 结构化测试用例。这是见效最快的方向,因为输入最规整、产出最易评审。

```text
你是资深云服务测试专家。阅读 docs/requirements/vpc.md 和 openapi/vpc.yaml,
为 VPC 模块设计测试用例, 保存到 tests/cases/vpc.md, 要求:

1. 每个接口按固定矩阵展开: 正常流 / 参数边界 / 权限(未认证、跨租户越权) / 配额与限流 / 每个错误码各一条
2. 云服务专项: 资源隔离、并发创建删除、状态机非法跃迁
3. 每条用例包含: 编号 / 前置条件 / 步骤 / 预期结果 / 优先级(P0-P2)
4. 预期结果必须引用文档中的原文出处; 文档没有明确说明的, 标"需澄清", 不许编造
```

最后一条是质量关键,和[结对编程](./pair-coding.md)里"审查必须给出文件:行号"是同一个原则:**强制证据,输出才可证伪**。不约束这一点,AI 会一本正经地编造预期结果,而编造的用例比没有更糟——它污染的是整个用例库的可信度。

生成之后接评审闭环(生成与评审分开,防止"自己认可自己"):

```bash
claude -p "你是测试评审员, 只审 tests/cases/vpc.md, 不要修改任何文件。
对照 docs/requirements/vpc.md 和 openapi/vpc.yaml 逐项检查:
1. 遗漏: 哪些需求点/接口/错误码没有对应用例
2. 错误: 哪些预期结果与文档矛盾
3. 每条意见给出 需求文档出处 + 用例编号, 按 阻断/建议 分级, 不写客套话" \
  --dangerously-skip-permissions --allowedTools "Read,Grep,Glob"
```

把评审意见喂回生成方修订,一到两轮即可。实测收益:一个模块的用例设计从 2~3 人日降到 2~3 小时,错误码覆盖率从人工的六七成接近全量。

## 方向二: 接口契约测试脚本生成

用例评审通过后,让 AI 直接把用例落成可执行脚本:

```text
根据 openapi/vpc.yaml 和 tests/cases/vpc.md 中 P0/P1 用例, 生成 pytest 接口测试,
保存到 tests/api/test_vpc.py, 要求:
- 框架 pytest + requests, base_url 和 token 从环境变量读取
- 响应体用 jsonschema 断言
- 每个测试标注对应的用例编号, 方便回溯
- 禁止修改 openapi 和用例文件
```

更有价值的场景是**维护**:云服务 API 演进快,脚本跟着改是最磨人的活。让 AI 只处理 diff:

```text
openapi/vpc.yaml 本次变更: 新增字段 FlowLogEnabled; DeleteVpc 新增 409(资源仍被引用)。
只更新 tests/api/test_vpc.py: 补充新字段断言和 409 场景, 其余用例保持不动。
```

把"只改 diff 波及的部分"写进指令,可以避免 AI 顺手重写整个文件、引入无关变更。

## 方向三: 失败日志分诊(团队价值最大)

测试团队的隐形负担不是执行测试,而是**翻失败日志**。一次 nightly 几百个用例失败,人工逐个定位根因要半天。把日志喂给 AI 做第一轮分诊:

```bash
kimi -p "你是云服务测试失败分诊专家。下面是 CI 失败日志和最近 20 条提交。
只输出一个 JSON 对象, 不要 markdown 代码块:
{\"root_cause\": \"一句话根因\", \"evidence\": \"关键日志原文\",
 \"suspect_commits\": [\"hash\"], \"is_flaky\": true/false,
 \"confidence\": 0到1, \"suggested_owner\": \"嫌疑模块\", \"next_action\": \"建议下一步\"}

日志:
$(tail -n 800 ci-failure.log)

最近提交:
$(git log --oneline -20)"
```

结构化输出是为了程序化处理:CI 失败时由 webhook 触发,把 JSON 结论作为评论写到流水线/MR 上,测试工程师上班看到的是**已分好类的失败清单**,而不是一坨日志。按 `is_flaky` 和 `suggested_owner` 分组后,同根因的失败合并处理,定位工作量通常能砍一半以上。

```{note}
分诊结论定位到"嫌疑",不是"定罪"。confidence 低的条目原样附上关键日志行,保留人工深挖的入口——AI 负责收敛范围,人负责最终判断。
```

## 方向四: 测试环境与数据构造

- **环境即代码**:用自然语言描述拓扑(3 节点集群、双 AZ、模拟 3 个租户),让 AI 生成 terraform/ansible,人工 review 后入库;
- **测试数据构造**:生成造数脚本——多租户资源、海量小对象、计费流量,比手写快得多;
- **环境排障**:把 cloud-init 日志、服务状态、组件版本打包喂给 AI,先做一轮"常见病因"筛查。

环境类操作有真实副作用,原则参考[结对编程](./pair-coding.md)的边界:**AI 出草稿,人审后执行,执行权限不交给 AI**。

## 方向五: 可靠性测试与混沌实验

可靠性测试的设计工作量大于执行。让 AI 从架构文档出发:

```text
阅读 docs/architecture/object-storage.md, 为对象存储设计可靠性测试:
1. 按故障域列出故障场景: 单机宕机、磁盘满、网络分区、依赖服务超时、时钟跳变
2. 每个场景按"假设-注入方式-验证指标(SLO)-预期表现"四段式输出
3. 区分: 已覆盖(引用现有用例) / 建议新增
```

四段式输出直接就是混沌实验的设计文档,评审后交给混沌平台执行。AI 在这里的价值是**穷举故障组合**——人容易想到"杀节点",不容易系统想到"依赖超时 + 重试风暴 + 配额打满"的叠加场景。

## 方向六: 团队知识库与新人上手

团队转型要快速上手,靠的是把分散在老人脑子里的知识固化下来:

- **最小可行方案**:把 API 文档、错误码表、排障手册、发布流程放进 Agent 的工作区(`AGENTS.md` / skill 机制),新人问"DeleteVpc 报 409 怎么查",AI 直接引用内部文档回答,而不是泛泛的互联网答案;
- **进阶方案**:历史 bug 单、事故复盘接入 RAG 检索,让 AI 回答"以前有没有类似的失败模式";
- **新人上手**:给新人配一个"AI 导师"会话,学习材料就是团队模板库和真实模块,上手周期从数周压到数天。

## 方向怎么选: 优先级总表

| 方向 | 见效速度 | 上手难度 | 自动化潜力 | 适合试点 |
|------|---------|---------|-----------|---------|
| 一、用例生成与评审 | 快(当次见效) | 低 | 中 | ✅ 首选 |
| 二、契约测试脚本 | 快 | 低 | 高 | ✅ 与一捆绑 |
| 三、失败日志分诊 | 中(需积累日志) | 中 | 高 | ✅ 第二步 |
| 六、知识库与上手 | 中 | 低 | 中 | ✅ 并行做 |
| 四、环境与数据 | 中 | 中 | 中 | 第二步 |
| 五、可靠性与混沌 | 慢(需设计评审) | 高 | 低 | 第三步 |

选型原则:**先"读多写少、人易评审"的,后"有真实副作用"的**。用例和分诊的产出错了,人看一眼就能纠正;环境操作错了,可能要重建一套集群。

## 需要的能力: 五项

### 1. 上下文工程(最核心)

AI 产出的质量上限,取决于喂给它的材料。同一句"帮我写 VPC 的用例",只给接口名是泛泛而谈,给齐需求文档 + OpenAPI + 错误码表 + 历史用例,产出可直接进入评审。**团队要有人专门维护这些"输入资产":文档规整、版本最新、可被引用**。这是一项新的、明确的岗位职责。

### 2. Prompt 设计与模板化

把个人经验沉淀成团队共享的模板库,每个模板遵守三条纪律(与[结对编程](./pair-coding.md)同宗):

1. **强制证据**:预期结果引用文档出处,审查意见给出行号;
2. **禁止编造**:文档没写的标"需澄清";
3. **约定格式**:结构化输出(JSON/固定表格),便于程序化处理和回归比对。

### 3. 评审能力

人是最后防线,评审能力是测试团队的传统优势,要刻意迁移到 AI 产出物上。两个放大手段:

- **双模型评审**:生成与评审用不同厂商的模型或不同会话,盲区不重叠(见[结对编程](./pair-coding.md)的盲区互补分析);
- **抽查制度**:对 AI 产出按 10% 比例人工全量复核,用实际错误率校准对 AI 的信任度,而不是凭感觉。

### 4. 工具化能力

把验证过的个人用法固化成脚本和流水线:CI 里的分诊 bot、用例生成的 `make new-cases MODULE=vpc`、定时跑的评审闭环。技能要求不高,会写 shell、会接 webhook 就够,关键是**有"固化"的意识**。

### 5. 数据安全与合规

- 测试数据分级:脱敏后的测试数据才能进云端模型,prompt 里禁止出现真实租户标识、密钥、内部地址;
- 敏感环境(客户现场、涉密项目)用本地模型兜底,部署方式见[本地 AI 服务](./local-ai-service.md);
- 密钥走环境变量或密钥管理系统,绝不写进 prompt 模板库。

### 能力成熟度自查

| 等级 | 状态 | 特征 |
|------|------|------|
| L1 | 当搜索引擎 | 问概念、查语法,收益仅限个人 |
| L2 | 个人助手 | 写用例/脚本/分诊,但用法散落各人 |
| L3 | 流程集成 | 模板库共享、CI 接入、产出物入库 |
| L4 | 半自主 | Agent 执行测试、分诊、提修复建议,人审关键节点 |

团队目标定在 L3;L4 只在分诊这类"读多写少"的环节试点,不要全域铺开。

## 构建的工具: 四类

### 1. 用例生成流水线

把方向一固化成一个脚本,新模块接入时一条命令出初稿 + 评审意见:

```bash
#!/usr/bin/env bash
# new-cases.sh — 需求+API 文档 → 测试用例初稿 → 跨模型评审意见
# 用法: ./new-cases.sh <模块名>
set -euo pipefail
MODULE="${1:?用法: ./new-cases.sh <模块名>}"

echo "==> [1] 生成用例初稿"
kimi -p "你是资深云服务测试专家。阅读 docs/requirements/$MODULE.md 和 openapi/$MODULE.yaml,
为 $MODULE 模块设计测试用例, 保存到 tests/cases/$MODULE.md, 要求:
1. 每个接口按矩阵展开: 正常流 / 参数边界 / 权限 / 配额限流 / 每个错误码各一条
2. 每条用例: 编号 / 前置条件 / 步骤 / 预期结果 / 优先级
3. 预期结果必须引用文档原文出处; 文档没写的标'需澄清', 不许编造"

echo "==> [2] 跨模型评审"
claude -p "你是测试评审员, 只审 tests/cases/$MODULE.md, 不要修改任何文件。
对照 docs/requirements/$MODULE.md 和 openapi/$MODULE.yaml 检查遗漏与错误,
每条意见给出 文档出处 + 用例编号, 按 阻断/建议 分级, 不写客套话" \
  --dangerously-skip-permissions --allowedTools "Read,Grep,Glob" \
  > "tests/cases/$MODULE.review.md"

echo "==> 完成: 初稿 tests/cases/$MODULE.md, 评审意见 tests/cases/$MODULE.review.md"
echo "==> 人工处理评审意见后, 再跑契约脚本生成"
```

注意脚本止步于"初稿 + 评审意见"——**合并定稿是人的动作**,这把最终判断权留在了团队手里。

### 2. 失败分诊 bot

方向三的固化:CI 失败 webhook → 拉日志 → 调 `kimi -p` 分诊 → 结论写回流水线评论。一个 Jenkins/GitLab CI 的伪配置:

```yaml
# .gitlab-ci.yml 片段: 测试失败时触发分诊
after_script:
  - |
    if [ "$CI_JOB_STATUS" == "failed" ]; then
      curl -s -H "PRIVATE-TOKEN: $TOKEN" "$CI_API_URL/projects/$CI_PROJECT_ID/jobs/$CI_JOB_ID/trace" \
        | tail -n 800 > /tmp/ci.log
      ./triage.sh /tmp/ci.log   # 内部调用 kimi -p, 输出 JSON 结论
      # 结论作为 comment 发到 MR, 按 suggested_owner 分组
    fi
```

### 3. 测试知识库

最小可行版本不需要向量数据库:把 API 文档、错误码表、排障手册、事故复盘放进 Agent 工作区,用 `AGENTS.md` 写明"回答必须引用这些文件";查询量大了再升级 RAG(检索增强生成)。内容维护责任到人,**知识库腐化是这类工具死掉的头号原因**。

### 4. 团队 Prompt/Skill 模板库

上述所有 prompt 和脚本进独立 git 仓库,版本管理、评审合入、定期复盘修订。这是团队 AI 能力真正的载体——**人走了,模板还在;模型换了,模板还能用**。

## 团队 AI 架构: 从"个人收藏"到团队基础设施

前面的方向、能力、工具解决的是"怎么用";这一节解决"知识存在哪、归谁管"——这是转型从中期走向长期的分水岭。

### 个人知识模式的四个问题

转型初期最常见的形态:每个工程师自己收藏 prompt、自己记笔记、有价值的聊天记录躺在个人账号里。这和转型前"知识存在个人脑子里"没有本质区别,只是存储介质变了:

| 问题 | 后果 |
|------|------|
| 知识随人走 | 老员工离职,模板和踩坑记录一起消失 |
| 错误被制度化 | 个人 prompt 里的问题(编造的断言、过期的错误码)无人评审,被团队反复复用,错得越来越一致 |
| AI 没有团队上下文 | 每个人从零向 AI 描述业务,AI 只能给通用答案,深度停留在互联网平均水平 |
| 重复造轮子 | 五个人各自调试"让 AI 稳定输出 JSON"的写法,产出五份互不兼容的半成品 |

### 架构原则: 知识分层, 让 AI 消费团队资产

一句话:**AI 的答案质量,取决于它读到的团队资产,而不是提问者个人的记忆。** 落地为四层:

```{mermaid}
flowchart TB
    subgraph L1[数据源层]
        A1[需求 / API 文档 / 错误码表]
        A2[历史 bug 单 / 事故复盘]
        A3[CI 日志 / 测试报告]
    end
    subgraph L2[知识层: git 版本化的单一事实源]
        B1[团队文档库]
        B2[检索 RAG]
    end
    subgraph L3[模板层: 评审合入的版本库]
        C1[Prompt 模板库]
        C2[Skill / AGENTS.md]
    end
    subgraph L4[执行层: 流水线与 bot]
        D1[CI 分诊 bot]
        D2[用例生成流水线]
    end
    L1 --> L2 --> L3 --> L4
    D1 -- 复盘沉淀 --> L2
    D2 -- 评审沉淀 --> L3
```

| 层 | 内容 | 关键纪律 |
|----|------|---------|
| 数据源层 | 需求、API 文档、错误码表、历史 bug、CI 日志 | 源头规整,每类材料有明确维护责任人 |
| 知识层 | 团队文档库(git 管理)+ 检索(RAG) | 单一事实源:文档更新走 MR,AI 永远读最新版,杜绝"群里发的 Excel 才是准的" |
| 模板层 | 验证过的 prompt 模板、skill、AGENTS.md | 像代码一样评审合入、版本化;个人实验成熟后才允许晋升进来 |
| 执行层 | CI 分诊、用例生成等流水线 | 只许消费模板层,不允许在流水线脚本里藏私有 prompt |

### 飞轮: 每次 AI 协作都让团队更聪明

这套架构的复利来自一个闭环:

**AI 产出 → 人评审 → 有价值的部分沉淀回知识层/模板层 → 下一次 AI 调用起点更高。**

举例:某次分诊 bot 把限流误判成代码缺陷,工程师复盘后发现"该服务限流返回 429 且响应体为空"。这条经验没有停留在个人脑子里,而是补进了知识层的排障手册、和模板层分诊 prompt 里的一行判断("先检查响应体是否为空")。下次同类失败,整个团队的分诊结论都更准。**经验的所有权从个人变成团队,是这套架构相对个人收藏的本质差异。**

### 人的角色跟着变

存储交给 git,检索交给 RAG,重复执行交给流水线;人从"知识的存储者"变成"知识的评审者与策展人"——判断什么值得沉淀、沉淀得对不对。这部分判断无法外包给 AI,它恰恰是团队最核心的竞争力。

### 治理: 两条低成本规则

1. **模板即代码**:prompt/skill 进 git,变更走 MR,至少一人评审。它和个人收藏夹的本质区别不是工具,是"有人替质量背书";
2. **沉淀触发器**:每次 AI 协作复盘只问一句"这次有什么值得固化?"——不许写新文档,只在现有模板或文档上做增量修订,把沉淀成本压到最低。

```{note}
分层不是一步到位。第一个月可以只用"模板层进 git"一条规则起步;知识层的 RAG 等查询量真的大了再上。架构的价值在于边界清晰,不在于一次建全。
```

## 落地路线: 90 天

| 阶段 | 时间 | 动作 | 验收标准 |
|------|------|------|---------|
| 试点 | 第 1 个月 | 选 1 个模块跑通"用例生成 + 评审 + 脚本生成";建模板库仓库 | 该模块用例设计耗时下降 50%+ |
| 集成 | 第 2~3 个月 | 分诊 bot 接入 CI;知识库最小版上线;第二批模块推广 | 失败定位时长(MTTR)下降;新人生成首份用例 < 1 天 |
| 自动化 | 第 3 个月起 | 验证过的环节半自动化;引入双模型评审闭环;月度复盘模板 | 分诊准确率稳定;模板库月均更新 |

度量指标盯住四个:**用例设计耗时、失败定位时长、自动化覆盖率、flaky 率**。不要度量"AI 生成了多少内容"——生成量不是价值,节省的时间和提升的覆盖才是。

## 常见坑

| 坑 | 现象 | 处理 |
|----|------|------|
| 盲信 AI 的预期结果 | 用例库混入编造的断言 | 强制引用文档出处;抽查制度校准信任度 |
| 上下文给太少 | 输出泛泛而谈,没法用 | 需求文档 + OpenAPI + 错误码表 + 历史用例给齐 |
| 生产数据进 prompt | 真实租户标识、密钥外泄 | 数据分级脱敏;敏感环境用本地模型 |
| 一步到位做全自动 | 错误放大无人察觉 | 先半自动 + 人审,稳定一个环节再自动化下一个 |
| 个人经验不沉淀 | 效果好的用法随人走 | 模板库仓库化,评审合入 |
| 生成脚本风格不一 | 难维护、难 code review | 约定框架与目录规范,lint 强制 |
| 知识库腐化 | AI 引用过期文档答错 | 维护责任到人,文档变更同步更新 |
| 成本失控 | 全员全任务用旗舰模型 | 强模型干评审,便宜模型干生成类杂活(见[多模型辩论](./multi-model-debate.md)的成本分工) |

## 总结

- **方向**:用例生成与评审、契约脚本、失败分诊先行,知识库并行,环境与混沌随后;
- **能力**:上下文工程是核心,加上模板化、评审、工具化、数据安全五项,团队目标定在 L3(流程集成);
- **工具**:用例生成流水线、分诊 bot、知识库、模板库——四件就够,先把一件做透;
- **节奏**:90 天三步走,每个环节"半自动 + 人审"跑稳了再放开自动化,判断权始终在团队手里。

## 参考资料

- [Kimi Code + Claude Code 结对编程: 一个开发, 一个审查](./pair-coding.md)——双模型评审闭环与审查 prompt 写法
- [只有一个 Claude Code: 让多个模型讨论方案和 review 代码](./multi-model-debate.md)——单模型多角色的成本分工
- [从 0 开始搭建一个 Agent](./agent.md)——理解 Agent 的工具调用机制
- [从 0 开始搭建本地 AI 服务](./local-ai-service.md)——敏感环境的本地模型兜底
- [从学习到生产](./production-deployment.md)——模型服务化部署
- [OpenAPI Specification](https://spec.openapis.org/oas/latest.html)
- [Principles of Chaos Engineering](https://principlesofchaos.org/)
- [pytest 官方文档](https://docs.pytest.org/)