AI编码之如何测试
核心思路:人工搭框架 → 配置 Skill → 跟 AI 说,生成测试 → 本地验证。
目录
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 chromium2.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 Object(tests/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@latestclaude_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-snapshotsuniapp 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) On this page
- AI编码之如何测试
- 目录
- 1. 整体流程
- 2. 第一步:搭建 Playwright 框架
- 2.1 安装
- 2.2 playwright.config.ts
- 2.3 目录结构
- 3. 第二步:固化 AI 生成规范
- 4. 第三步:配置 Cursor Skill
- 5. 第四步:运行 Skill 生成测试
- 5.1 日常使用(Cursor)
- 5.2 生成结果示例
- 5.3 复杂页面:结合 Playwright MCP
- 6. 日常工作流
- 新功能开发
- 测试失败时
- 7. 常用命令
- uniapp H5 + Playwright:可测链路与测试结果标准清单
- 1. 文档目的
- 2. 总体原则
- 3. 测试结果标准的核心维度
- 3.1 用户可见结果
- 3.2 页面状态与路由状态
- 3.3 网络请求与接口契约
- 3.4 业务数据与副作用
- 3.5 异常处理与边界行为
- 3.6 非功能维度
- 4. 断言设计原则
- 4.1 第一层:主结果断言
- 4.2 第二层:关键状态断言
- 4.3 第三层:异常保护断言
- 5. 可测链路清单
- 5.1 登录链路
- 5.1.1 可测场景
- 5.1.2 主测试目标
- 5.1.3 测试结果标准
- 主断言
- 辅助断言
- 异常断言
- 5.1.4 推荐关注维度
- 5.2 权限拦截链路
- 5.2.1 可测场景
- 5.2.2 主测试目标
- 5.2.3 测试结果标准
- 主断言
- 辅助断言
- 异常断言
- 5.2.4 推荐关注维度
- 5.3 搜索与筛选链路
- 5.3.1 可测场景
- 5.3.2 主测试目标
- 5.3.3 测试结果标准
- 主断言
- 辅助断言
- 异常断言
- 5.3.4 推荐关注维度
- 5.4 列表 -> 详情链路
- 5.4.1 可测场景
- 5.4.2 主测试目标
- 5.4.3 测试结果标准
- 主断言
- 辅助断言
- 异常断言
- 5.4.4 推荐关注维度
- 5.5 表单填写与提交链路
- 5.5.1 可测场景
- 5.5.2 主测试目标
- 5.5.3 测试结果标准
- 主断言
- 辅助断言
- 异常断言
- 5.5.4 推荐关注维度
- 5.6 上传链路
- 5.6.1 可测场景
- 5.6.2 主测试目标
- 5.6.3 测试结果标准
- 主断言
- 辅助断言
- 异常断言
- 5.6.4 推荐关注维度
- 5.7 下单 / 提交流程链路
- 5.7.1 可测场景
- 5.7.2 主测试目标
- 5.7.3 测试结果标准
- 主断言
- 辅助断言
- 异常断言
- 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 可测场景
- 5.10.2 主测试目标
- 5.10.3 测试结果标准
- 主断言
- 辅助断言
- 异常断言
- 5.10.4 推荐关注维度
- 6. 测试结果标准模板
- 6.1 通用模板

