Vanson's Eternal Blog

AI编码之如何测试

Ai coding.png
Published on
/28 mins read/---

AI编码之如何测试

核心思路:人工搭框架 → 配置 Skill → 跟 AI 说,生成测试 → 本地验证。


目录

  1. 整体流程
  2. 第一步:搭建 Playwright 框架
  3. 第二步:固化 AI 生成规范
  4. 第三步:配置 Cursor Skill
  5. 第四步:运行 Skill 生成测试
  6. 日常工作流
  7. 常用命令

1. 整体流程

人工做(一次性)                  跟 AI 说(每次迭代)                本地验证
─────────────────                ───────────────────────────         ──────────────
安装 Playwright              →   运行 @generate-test Skill       →   npx playwright test
配置 playwright.config.ts        输入目标文件 + 测试场景               带界面调试 --headed
建目录结构                       AI 读取文件及所有 import 依赖         查看 HTML 报告
写 CLAUDE.md 固化规范            理解业务逻辑和数据结构
配置 Cursor Skill                Mock 接口,生成测试脚本
                                 自动命名,写入 tests/ 目录

2. 第一步:搭建 Playwright 框架

这部分人工做一次,后续不用动。

2.1 安装

npm install -D @playwright/test
npx playwright install chromium

2.2 playwright.config.ts

import { defineConfig, devices } from '@playwright/test'
 
export default defineConfig({
  testDir: './tests',
  fullyParallel: true,
  retries: 0,
  reporter: [['html'], ['list']],
 
  use: {
    baseURL: 'http://localhost:3000',
    trace: 'on-first-retry',
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
  },
 
  // 自动启动 Next.js,无需手动 npm run dev
  webServer: {
    command: 'npm run dev',
    url: 'http://localhost:3000',
    reuseExistingServer: true,
    timeout: 120 * 1000,
  },
 
  projects: [{ name: 'chromium', use: { ...devices['Desktop Chrome'] } }],
})

2.3 目录结构

my-nextjs-app/
├── app/                        ← Next.js 页面
├── components/
├── hooks/
├── types/
│
├── tests/                      ← 所有测试文件
│   ├── e2e/                    ← E2E 测试(AI 生成后存放在这里)
│   │   ├── auth/
│   │   ├── checkout/
│   │   └── dashboard/
│   ├── visual/                 ← 视觉回归测试
│   ├── fixtures/
│   │   ├── base.ts             ← 共享 fixture(登录态等)
│   │   └── pages/              ← Page Object Model
│   └── mocks/                  ← Mock 数据
│
├── .cursor/
│   └── rules/
│       └── generate-test.mdc  ← Cursor Skill(核心)
│
├── playwright.config.ts
├── CLAUDE.md                   ← AI 生成规范
└── package.json

3. 第二步:固化 AI 生成规范

在项目根目录创建 CLAUDE.md。Skill 触发后 AI 自动读取这份规范,不需要每次重复描述要求。

# CLAUDE.md
 
## 测试生成规范
 
### 项目信息
 
- 框架:Next.js 14 App Router
- 测试框架:Playwright + TypeScript
- baseURL:http://localhost:3000
 
### 文件输出位置
 
- E2E 测试:tests/e2e/[模块名]/[场景名].spec.ts
- Page Object:tests/fixtures/pages/[页面名]Page.ts
- Mock 数据:tests/mocks/[页面名].json
 
### 文件命名规则
 
- 根据测试场景自动命名,使用 kebab-case
- 例:「用户完整结账流程」→ checkout-complete-flow.spec.ts
- 例:「登录失败场景」→ login-failure.spec.ts
 
### 选择器规则(按优先级)
 
1. getByRole() 首选,语义化
2. getByLabel() 表单元素
3. getByText() 文本内容
4. getByTestId() 组件加 data-testid
5. 禁止 CSS selector 和 XPath
 
### 每个测试必须包含
 
- POM 类(封装所有页面操作)
- Mock 数据 JSON(所有接口必须 mock,数据结构与 TS 类型一致)
- 正常流程 + 异常场景 + 边界值
- waitForLoadState('networkidle') 等待 SSR hydration
- page.route() 拦截所有接口调用
 
### 禁止事项
 
- 禁止 page.waitForTimeout()(固定等待)
- 禁止 CSS class / XPath 定位
- 禁止测试之间共享状态
- 禁止依赖真实后端接口

4. 第三步:配置 Cursor Skill

配置一次,之后在 Cursor 里输入 @generate-test,Skill 会引导你输入文件和场景,AI 自动完成剩余所有工作。

创建文件 .cursor/rules/generate-test.mdc

---
name: generate-test
description: 理解指定文件及其依赖,基于场景生成 Playwright 测试脚本
---
 
请提供以下信息:
 
1. **目标文件路径**(如 app/checkout/page.tsx)
2. **测试场景描述**(如「用户完整结账流程,包含地址填写和支付」)
 
收到后我会:
 
- 读取目标文件及其所有 import 的依赖文件(components、hooks、types 等)
- 理解完整的业务逻辑、数据结构和接口定义
- 基于你描述的场景 Mock 所有接口(数据结构与 TS 类型严格匹配)
- 按照 CLAUDE.md 规范生成完整测试脚本:
  - Page Object Model → tests/fixtures/pages/
  - Mock 数据 → tests/mocks/
  - 测试用例 → tests/e2e/
- 根据场景描述自动命名文件(kebab-case)
- 生成完成后自动 review,输出评分和潜在问题
- 给出精确的运行命令,并询问是否直接执行
 
生成完成后会提示:
 
> 测试文件已生成:tests/e2e/checkout/checkout-complete-flow.spec.ts
> Review 评分:91分,无明显问题
>
> 运行命令:
>
> ```bash
> npx playwright test tests/e2e/checkout/checkout-complete-flow.spec.ts --headed
> ```
>
> 是否现在直接运行?
 
如果你回复「是」或「运行」,我会立即在终端执行这条命令。
执行完成后:
 
- 通过 → 告知结果,完成
- 失败 → 读取错误信息,分析原因,给出修复方案,修复后再次运行

5. 第四步:运行 Skill 生成测试

5.1 日常使用(Cursor)

在 Cursor Chat 里输入:

@generate-test

AI 会提示你输入:

请告诉我:
1. 目标文件路径?
2. 要测试的场景?

你回答,例如:

1. app/checkout/page.tsx
2. 用户完整结账流程,包含地址填写、优惠券使用和支付

AI 自动完成:

读取 app/checkout/page.tsx
    ↓
顺着 import 读取所有依赖
  · components/CartItem.tsx
  · components/CouponInput.tsx
  · hooks/useCart.ts
  · hooks/usePayment.ts
  · types/order.ts
    ↓
理解业务逻辑 + 数据结构 + 接口定义
    ↓
生成三个文件:
  ✓ tests/fixtures/pages/CheckoutPage.ts
  ✓ tests/mocks/checkout.json
  ✓ tests/e2e/checkout/checkout-complete-flow.spec.ts
    ↓
自动 review:[91分] 覆盖完整,Mock 数据结构与类型匹配

5.2 生成结果示例

Page Objecttests/fixtures/pages/CheckoutPage.ts

import { Page, Locator } from '@playwright/test'
 
export class CheckoutPage {
  readonly addressInput: Locator
  readonly cityInput: Locator
  readonly couponInput: Locator
  readonly applyButton: Locator
  readonly submitButton: Locator
 
  constructor(private page: Page) {
    this.addressInput = page.getByLabel('收货地址')
    this.cityInput = page.getByLabel('城市')
    this.couponInput = page.getByLabel('优惠券码')
    this.applyButton = page.getByRole('button', { name: '使用优惠券' })
    this.submitButton = page.getByRole('button', { name: '提交订单' })
  }
 
  async goto() {
    await this.page.goto('/checkout')
    await this.page.waitForLoadState('networkidle')
  }
 
  async fillAddress(street: string, city: string) {
    await this.addressInput.fill(street)
    await this.cityInput.fill(city)
  }
 
  async applyCoupon(code: string) {
    await this.couponInput.fill(code)
    await this.applyButton.click()
  }
 
  async placeOrder() {
    await this.submitButton.click()
  }
}

Mock 数据tests/mocks/checkout.json

数据结构由 AI 根据 types/order.ts 自动生成,和真实类型严格匹配

{
  "cart": {
    "items": [{ "id": "1", "name": "商品A", "qty": 2, "price": 99 }],
    "total": 198
  },
  "couponValid": { "code": "SAVE20", "discount": 20, "valid": true },
  "couponInvalid": { "code": "INVALID", "valid": false, "message": "优惠券不存在" },
  "paymentSuccess": { "orderId": "ORD-001", "status": "paid" },
  "paymentFailed": { "status": "failed", "message": "余额不足" }
}

测试用例tests/e2e/checkout/checkout-complete-flow.spec.ts

import { test, expect } from '@playwright/test'
import { CheckoutPage } from '../../fixtures/pages/CheckoutPage'
import mockData from '../../mocks/checkout.json'
 
test.describe('用户完整结账流程', () => {
  test.beforeEach(async ({ page }) => {
    await page.route('**/api/cart', (route) => route.fulfill({ json: mockData.cart }))
  })
 
  test('正常下单:填写地址 + 使用优惠券 + 支付成功', async ({ page }) => {
    await page.route('**/api/coupon', (route) => route.fulfill({ json: mockData.couponValid }))
    await page.route('**/api/payment', (route) => route.fulfill({ json: mockData.paymentSuccess }))
 
    const checkout = new CheckoutPage(page)
    await checkout.goto()
    await checkout.fillAddress('南京路1号', '上海')
    await checkout.applyCoupon('SAVE20')
 
    await expect(page.getByText('已优惠 ¥20')).toBeVisible()
 
    await checkout.placeOrder()
    await expect(page).toHaveURL('/order/success')
    await expect(page.getByText('订单提交成功')).toBeVisible()
  })
 
  test('优惠券无效,显示错误提示', async ({ page }) => {
    await page.route('**/api/coupon', (route) => route.fulfill({ json: mockData.couponInvalid }))
 
    const checkout = new CheckoutPage(page)
    await checkout.goto()
    await checkout.applyCoupon('INVALID')
 
    await expect(page.getByRole('alert')).toContainText('优惠券不存在')
  })
 
  test('支付失败,显示失败提示', async ({ page }) => {
    await page.route('**/api/coupon', (route) => route.fulfill({ json: mockData.couponValid }))
    await page.route('**/api/payment', (route) => route.fulfill({ json: mockData.paymentFailed }))
 
    const checkout = new CheckoutPage(page)
    await checkout.goto()
    await checkout.fillAddress('南京路1号', '上海')
    await checkout.placeOrder()
 
    await expect(page.getByRole('alert')).toContainText('余额不足')
    await expect(page).toHaveURL('/checkout')
  })
})

5.3 复杂页面:结合 Playwright MCP

交互复杂或页面有动态渲染时,让 Claude 同时读代码 + 看真实页面,生成更准确:

配置(一次性):

npx @playwright/mcp@latest

claude_desktop_config.json

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

使用(Claude Desktop 里说):

读取 app/checkout/page.tsx 和它引入的所有文件,
再打开 localhost:3000/checkout 看实际页面,
基于「用户完整结账流程」场景,
按照 CLAUDE.md 规范生成测试脚本。

6. 日常工作流

新功能开发

写完组件代码
    ↓
Cursor 里输入 @generate-test
    ↓
回答提示:
  · 文件:app/xxx/page.tsx
  · 场景:[描述你要测试的核心流程]
    ↓
AI 读取文件及所有依赖,生成测试脚本 + review 评分
    ↓
AI 提示运行命令,回复「是」直接执行
    ↓
  · 通过 → 完成
  · 失败 → AI 读取报错,分析原因,修复后重新运行

测试失败时

如果在 Skill 执行过程中失败,AI 会自动分析报错并修复,不需要手动介入。

如果是单独跑测试失败:

npx playwright test --headed     ← 带界面看失败过程
    ↓
npx playwright show-report       ← 看截图和详细日志
    ↓
回到 Cursor,把报错贴给 AI:
「这个测试为什么失败,怎么修?」
    ↓
AI 分析 + 修复 + 询问是否重新运行
    ↓
回复「是」→ 自动重跑验证

7. 常用命令

# 运行所有测试
npx playwright test
 
# 带界面运行(本地调试首选)
npx playwright test --headed
 
# 只跑某个场景文件
npx playwright test tests/e2e/checkout/checkout-complete-flow.spec.ts
 
# 只跑某个模块目录
npx playwright test tests/e2e/checkout/
 
# 查看 HTML 报告
npx playwright show-report
 
# 更新视觉回归基准截图
npx playwright test tests/visual/ --update-snapshots

uniapp H5 + Playwright:可测链路与测试结果标准清单

1. 文档目的

本文用于梳理 uniapp 开发的 H5 场景下,使用 Playwright 做自动化测试时:

  • 哪些链路适合测
  • 每类链路的测试目标是什么
  • 测试结果标准应该如何定义
  • 断言应覆盖哪些维度
  • 如何避免“只看页面提示”或“只看接口返回”的片面判断

2. 总体原则

E2E 自动化测试的通过标准,不应只看某一个点,而应采用 多层验收

推荐原则:

以“业务闭环是否真正完成”为核心, 以“用户可见结果”为主断言, 以“路由状态 / 网络请求 / 数据副作用 / 异常处理”为辅助断言。

也就是说:

  • 不是只看页面提示正常
  • 不是只看接口返回成功
  • 而是看这条链路是否真的完成了用户目标

3. 测试结果标准的核心维度

每条链路建议从以下 6 个维度定义测试结果标准。

3.1 用户可见结果

这是最高优先级。

关注点:

  • 页面是否展示正确内容
  • 成功 / 失败提示是否正确
  • 按钮状态是否正确
  • 弹窗、列表、金额、状态是否正确呈现
  • 用户是否能继续完成任务

3.2 页面状态与路由状态

关注点:

  • 是否跳转到正确页面
  • URL / query 参数是否正确
  • 页面标题、关键区域是否符合预期
  • 刷新后状态是否保持
  • 返回、重进后流程是否仍成立

3.3 网络请求与接口契约

关注点:

  • 请求是否发出
  • 请求时机是否正确
  • 请求次数是否正确
  • 请求参数 / header / token 是否正确
  • 响应成功后前端是否正确消费结果

3.4 业务数据与副作用

关注点:

  • 本地存储是否更新
  • 登录态 / token 是否生效
  • 服务端数据是否真正写入
  • 列表、详情、订单、地址等后续页面是否能读到新数据
  • 购物车、优惠券、库存等状态是否正确变化

3.5 异常处理与边界行为

关注点:

  • 接口失败时是否提示正确
  • loading 是否消失
  • 按钮是否恢复可点击
  • 是否避免重复提交
  • 是否阻止脏数据展示
  • 是否回滚到安全状态

3.6 非功能维度

按需选择,不是每条都必须覆盖。

可选关注点:

  • 性能:是否在合理时间内完成
  • 幂等:重复点击是否只生效一次
  • 兼容:不同浏览器 / 视口是否一致
  • 可用性:禁用态、焦点、滚动、弹层是否正常
  • 安全性:未授权访问是否被拦截

4. 断言设计原则

推荐采用 三层断言法

4.1 第一层:主结果断言

只保留最能证明业务成功的 1 个核心结果。

例如:

  • 登录后进入个人中心并显示昵称
  • 下单后进入订单详情页
  • 搜索后列表展示符合条件的结果

4.2 第二层:关键状态断言

补 1~3 个高价值状态。

例如:

  • URL 正确
  • 请求参数正确
  • token 已写入
  • 详情页数据正确

4.3 第三层:异常保护断言

只在高风险链路中补充。

例如:

  • 防重复提交
  • loading 正常结束
  • 接口失败后按钮恢复
  • 页面不残留旧数据

5. 可测链路清单


5.1 登录链路

5.1.1 可测场景

  • 手机号 + 验证码登录
  • 账号密码登录
  • 登录成功后跳首页
  • 登录成功后回跳原始受限页面
  • 登录失败提示
  • token 失效后重新登录
  • 已登录用户访问登录页的处理

5.1.2 主测试目标

验证用户能完成登录,并且登录态真正生效。

5.1.3 测试结果标准

主断言

  • 登录成功后进入目标页
  • 页面展示用户昵称 / 头像 / 个人信息入口

辅助断言

  • 登录请求发出且参数正确
  • token / session 已写入本地存储
  • 刷新后仍保持登录态
  • 原本受限页面现在可访问

异常断言

  • 验证码错误时提示明确
  • 登录失败后按钮恢复可点击
  • loading 正常结束
  • 不应错误写入 token

5.1.4 推荐关注维度

  • 用户可见结果
  • 路由状态
  • 本地存储副作用
  • 网络请求正确性
  • 异常恢复

5.2 权限拦截链路

5.2.1 可测场景

  • 未登录访问受限页面
  • 无权限用户访问特殊页面
  • 登录后回跳原页面
  • token 过期后重新鉴权
  • 退出登录后重新访问受限资源

5.2.2 主测试目标

验证权限控制真正生效,而不是只做表面提示。

5.2.3 测试结果标准

主断言

  • 未登录用户访问受限页面时跳转到登录页
  • 登录成功后返回原始目标页面

辅助断言

  • URL 中保留回跳信息
  • 页面不展示敏感内容
  • 登录后权限恢复正常

异常断言

  • token 失效后应重新登录
  • 不应通过直接改 URL 绕过权限
  • 错误状态下不应显示旧敏感数据

5.2.4 推荐关注维度

  • 用户可见结果
  • 页面 / 路由状态
  • 安全性
  • 登录态副作用

5.3 搜索与筛选链路

5.3.1 可测场景

  • 输入关键词搜索
  • 切换筛选条件
  • 排序切换
  • 清空筛选
  • 翻页 / 加载更多
  • 从列表进入详情页
  • 返回列表后条件保留

5.3.2 主测试目标

验证筛选条件真实作用到结果,而不只是 UI 显示变化。

5.3.3 测试结果标准

主断言

  • 列表内容符合搜索 / 筛选 / 排序条件

辅助断言

  • 搜索 / 筛选请求参数正确
  • 页面显示当前已选条件
  • URL / query 参数正确
  • 返回后条件保持

异常断言

  • 无结果时展示空态
  • 接口异常时展示错误提示
  • 切换条件时 loading 正常结束
  • 不应展示旧结果残留

5.3.4 推荐关注维度

  • 用户可见结果
  • 路由状态
  • 网络参数正确性
  • 页面状态稳定性

5.4 列表 -> 详情链路

5.4.1 可测场景

  • 从列表进入详情页
  • 带 query / id 进入详情
  • 详情页加载成功
  • 返回列表后状态保持
  • 非法 id / 数据不存在时处理

5.4.2 主测试目标

验证路由跳转与详情数据展示正确。

5.4.3 测试结果标准

主断言

  • 点击列表项后进入对应详情页
  • 页面展示正确详情数据

辅助断言

  • URL 参数正确
  • 请求的详情 id 正确
  • 返回列表后滚动位置 / 条件按预期处理

异常断言

  • 非法 id 时展示空态 / 错误态
  • 接口失败时提示明确
  • 页面不应残留上一个详情页的数据

5.4.4 推荐关注维度

  • 页面 / 路由状态
  • 网络请求正确性
  • 用户可见结果
  • 异常处理

5.5 表单填写与提交链路

5.5.1 可测场景

  • 新增地址
  • 编辑个人资料
  • 提交报名表单
  • 联系方式填写
  • 多字段校验
  • 提交成功 / 失败

5.5.2 主测试目标

验证表单校验、提交与保存结果正确。

5.5.3 测试结果标准

主断言

  • 提交成功后进入成功页 / 返回列表页并展示新数据

辅助断言

  • 必填项校验正确
  • 错误格式阻止提交
  • 提交请求体字段正确
  • 刷新后数据仍存在

异常断言

  • 提交失败时提示明确
  • 按钮恢复可点击
  • loading 消失
  • 不应产生重复数据

5.5.4 推荐关注维度

  • 用户可见结果
  • 表单校验行为
  • 网络请求正确性
  • 数据持久化副作用
  • 异常恢复

5.6 上传链路

5.6.1 可测场景

  • 图片上传
  • 附件上传
  • 多文件上传
  • 删除已上传文件
  • 非法格式阻止上传
  • 超大文件处理

5.6.2 主测试目标

验证上传结果真实生效,而不只是前端预览成功。

5.6.3 测试结果标准

主断言

  • 页面展示上传成功后的图片 / 文件项
  • 提交后详情页可见该文件

辅助断言

  • 上传接口成功
  • 文件名称 / url / 缩略图正确
  • 删除后页面与数据都同步消失

异常断言

  • 非法格式时阻止上传
  • 上传失败时可重试
  • 页面不残留假成功状态

5.6.4 推荐关注维度

  • 用户可见结果
  • 网络请求
  • 数据副作用
  • 异常处理

5.7 下单 / 提交流程链路

5.7.1 可测场景

  • 购物车提交订单
  • 立即购买
  • 选择地址
  • 使用优惠券
  • 金额计算
  • 提交订单成功 / 失败
  • 防重复提交

5.7.2 主测试目标

验证用户能完成订单创建,并且订单数据正确落地。

5.7.3 测试结果标准

主断言

  • 成功进入订单结果页 / 订单详情页
  • 订单号存在
  • 订单状态正确
  • 商品、数量、金额正确

辅助断言

  • 创建订单请求只发一次
  • 请求体中的商品、地址、优惠券参数正确
  • 购物车状态按预期更新
  • 刷新详情页后仍能查到该订单

异常断言

  • 接口失败后提示明确
  • 按钮恢复
  • loading 结束
  • 连点不会生成多笔订单

5.7.4 推荐关注维度

  • 用户可见结果
  • 数据副作用
  • 网络契约
  • 幂等性
  • 异常恢复

5.8 支付前确认链路

5.8.1 可测场景

  • 从订单详情进入支付确认页
  • 校验待支付金额
  • 校验支付方式选择
  • 支付前状态检查
  • 禁止重复发起支付

5.8.2 主测试目标

验证支付前页面数据正确,且支付入口触发条件正确。

5.8.3 测试结果标准

主断言

  • 进入支付确认页
  • 页面展示正确支付金额与订单信息

辅助断言

  • 支付前状态检查请求正确
  • 支付方式选择生效
  • 禁用条件时支付按钮不可点击

异常断言

  • 订单已失效时提示明确
  • 状态异常时阻止继续支付
  • 页面不应显示过期的支付信息

5.8.4 推荐关注维度

  • 用户可见结果
  • 页面状态
  • 请求正确性
  • 安全性 / 异常保护

5.9 购物车链路

5.9.1 可测场景

  • 加入购物车
  • 增减数量
  • 删除商品
  • 选择 / 取消选择商品
  • 全选 / 反选
  • 购物车金额联动

5.9.2 主测试目标

验证购物车状态与金额展示始终一致。

5.9.3 测试结果标准

主断言

  • 购物车商品列表与金额展示正确

辅助断言

  • 增减数量后金额实时更新
  • 删除商品后列表同步更新
  • 重新进入页面后状态一致

异常断言

  • 库存不足时提示明确
  • 非法数量不允许提交
  • 不应出现前端金额与后端结算不一致的明显错误状态

5.9.4 推荐关注维度

  • 用户可见结果
  • 页面状态
  • 数据副作用
  • 异常处理

5.10 退出登录链路

5.10.1 可测场景

  • 手动退出登录
  • token 过期被动退出
  • 退出后访问个人中心
  • 退出后访问受限资源

5.10.2 主测试目标

验证登录态清理彻底,权限控制恢复到未登录状态。

5.10.3 测试结果标准

主断言

  • 退出后页面显示未登录状态
  • 访问个人页 / 受限页会跳登录

辅助断言

  • token / 用户缓存已清除
  • 页面昵称、头像等登录态信息消失
  • 刷新页面后仍为未登录状态

异常断言

  • 不应残留旧用户信息
  • 不应还能访问受限页面
  • 不应展示伪登录状态

5.10.4 推荐关注维度

  • 用户可见结果
  • 权限状态
  • 本地存储副作用
  • 安全性

6. 测试结果标准模板

每条用例都可以按下面模板来写。

6.1 通用模板

链路名称:
前置条件:
操作步骤:
 
主断言:
- 最能证明业务成功的结果
 
辅助断言:
- 页面 / 路由状态
- 网络请求正确性
- 数据副作用
- 本地存储 / 登录态 / 权限态
 
异常断言:
- 接口失败后的表现
- loading / 按钮恢复
- 防重复提交
- 脏数据保护
 
非功能断言(按需):
- 性能
- 幂等
- 兼容
- 可用性
- 安全性
 
 
## 参考文档
 
[AI 测试全体系详解(自动化测试框架 + 智能缺陷检测 + A/B 测试优化)](https://mp.weixin.qq.com/s/JF0cLs2C6eDhCVWp11hVEw)
 
[从代码巡检看软件测试:AI已经开始替代功能测试了](https://mp.weixin.qq.com/s/GRPF9vjj2y-em4NvhSyNgg)
 
[从人工到AI驱动:天猫测试全流程自动化变革实践](https://developer.aliyun.com/article/1685362)
 
[如何让AI帮你做前端自动化测试?我们这样落地了](https://developer.aliyun.com/article/1672102)