Web 端 AI 测试专项
这一篇不把 Web 当成“就是浏览器页面”来讲，而是把一个真实的 AI Web 产品拆开：输入区、会话区、流式输出、Markdown 渲染、上传下载、浏览器兼容、登录态、前端状态恢复。每一层为什么会出问题、怎么测，会讲得更细。
别把 Web 端 AI 产品只理解成“一个浏览器页面”。
一个真正可用的 Web 端 AI 产品，至少同时包含 4 层：浏览器环境、前端状态管理、接口调用链、结果渲染层。你在页面上看到的每一次“发送、流式展示、停止生成、切换会话、上传文件”，背后都是这几层一起工作。 所以 Web 端 AI 测试的难点，不在于页面有没有显示出来，而在于：页面状态是不是跟后端状态同步、流式过程是不是稳定、异常时用户有没有被正确告知、浏览器差异会不会把同一套能力测出两种结果。
图 1：Web 端 AI 产品的最小结构图 浏览器：输入、滚动、快捷键、剪贴板、上传 ↓ 前端状态：当前会话、发送中、停止中、恢复中、登录态 ↓ 接口层：普通请求、流式请求、上传接口、历史会话接口 ↓ 展示层：Markdown、代码块、引用、附件、复制、错误提示
| 用户在页面上看到的现象 | 背后真正可能出问题的层 | 测试时应该怎么想 |
|---|---|---|
| 发送后一直转圈 | 流式结束帧没收口 / 前端状态没落地 | 别只看 UI，要抓网络面板和状态变化 |
| 切会话后消息串了 | 会话 id 绑定错 / 前端缓存污染 | 多会话、多标签页联动测 |
| 代码块排版乱 | Markdown 解析或样式问题 | 看生成过程，不只看最终结果 |
| 上传成功提示已出，模型却读不到文件 | 上传成功与会话绑定不是一回事 | 拆成上传成功、解析成功、绑定成功三段看 |
02. 先把测试边界分清
Web 端测试最容易乱，是因为边界没拆开。项目里经常出现一句话：“页面有问题。”其实这句话信息量非常低。更专业的做法，是先拆成下面几层。
接口和规则是否对 → 前端状态和交互是否稳 → 浏览器能力是否一致 → 最终展示是否对用户友好
| 容易混淆 | 前者 | 后者 |
|---|---|---|
| 接口成功 vs 页面成功 | 后端确实给了数据 | 前端确实正确消费并展示了数据 |
| 上传成功 vs 文件可用 | 文件进了存储服务 | 文件被业务侧解析并绑定到当前会话 |
| 结束了 vs 收口了 | 后端不再发送内容 | 前端 loading、按钮状态、滚动状态都恢复了 |
一个很接地气的判断方法。
如果你还说不清某个问题到底是“接口层”“状态层”还是“展示层”，那说明你手上的证据还不够。Web 端 AI 测试比普通页面更依赖证据链：网络面板、录屏、控制台、request id、会话 id，一样都别嫌麻烦。
2.1 Web 端 AI 测试常用证据
浏览器 DevTools
看网络请求、SSE / WebSocket 帧、接口返回、静态资源缓存、Console 报错。
录屏 / 动图
很多流式闪烁、按钮状态异常、滚动跳动，只看截图根本说不清。
03. 输入区和交互
输入区不是一个小组件，它是用户对产品“敢不敢继续用”的第一道判断。尤其 AI 产品常常支持长文本、粘贴代码、多行输入、快捷键发送、停止生成、重新提问，这些都比普通搜索框复杂得多。
3.1 输入区至少要拆的测试点
| 类别 | 具体要看什么 | 常见缺陷 |
|---|---|---|
| 输入行为 | 单行、多行、换行、快捷键发送 | Enter 和 Shift+Enter 逻辑混乱 |
| 粘贴行为 | 纯文本、代码块、富文本、图片粘贴 | 粘贴后格式污染、特殊字符丢失 |
| 长文本 | 超长输入、滚动性能、编辑体验 | 卡顿、丢字、光标乱跳 |
| 发送状态 | 发送按钮禁用、重复点击、失败重试 | 一次点击发两次请求 |
| 中断状态 | 停止生成按钮是否及时生效 | 点了停止但页面继续刷内容 |
3.2 很多问题都藏在输入法和粘贴里
- 中文输入法组合输入时，按回车到底是选词还是发送？
- 粘贴一段带缩进的代码，空格和换行有没有被吞？
- 超长文本滚动时，输入框高度变化会不会把页面顶乱？
- 发送中立刻编辑下一条内容，是否会误改当前会话草稿？
一个高频线上缺陷。
用户只点了一次发送，但前端没有及时锁按钮，结果发了两次请求。用户看到的是两段几乎一样的答案，会误以为模型抽风；实际上是前端交互幂等没控制住。
| 用例 | 步骤 | 预期 |
|---|---|---|
| 中文输入法下回车不误发 | 使用拼音输入未上屏内容时按回车 | 只完成选词，不触发发送 |
| 发送中重复点击按钮 | 连续点击发送按钮 3 次 | 只发 1 次请求，按钮状态明确 |
| 粘贴代码块保留格式 | 粘贴带缩进的 Python 代码 | 换行、缩进、特殊字符保留正确 |
04. 会话区和消息组织
AI Web 产品很少只是单轮问答。大多数产品都有：会话列表、历史消息、当前线程、新建会话、删除会话、重命名、历史恢复、引用上下文。这里一旦状态没管住，页面表面不一定报错，但用户会明显觉得“很乱”“不放心”。
| 现象 | 高概率根因 | 建议怎么测 |
|---|---|---|
| 切换会话时旧消息闪进新会话 | 前端缓存未及时清空 | 快速切换多个会话并录屏 |
| 删除会话后右侧内容还停留在旧线程 | 选中状态与列表状态不同步 | 删除当前会话、非当前会话各测一遍 |
| 刷新后会话列表在，但消息拉不回来 | 列表和内容接口恢复策略不一致 | 刷新恢复拆成列表恢复和消息恢复 |
| 新建会话后还带着上一轮上下文 | 会话 id 没切换干净 | 带敏感内容的两条会话来回切 |
4.1 这类问题不要只做 happy path
- 连续创建多个会话并快速切换。
- 在生成中切到另一个会话，再切回来。
- 开两个浏览器标签页，用同一账号操作同一个会话。
- 删除、重命名、置顶后刷新，看状态是否还原正确。
单标签页测试会漏什么
你会漏掉本地缓存冲突、会话列表覆盖、跨标签页状态广播不一致这些典型问题。
多标签页测试为什么值钱
很多真实用户就是开多个页签比对答案、看历史记录、边问边查资料。这个场景很常见，不是“乱点”。
05. 流式输出为什么最难
Web 端 AI 产品最影响用户体感的，往往不是最终答案对不对，而是过程顺不顺。流式输出一旦抖动、乱序、卡死、结束不明确，用户会第一时间感觉“这个产品不稳”。 图 2：流式输出的页面生命周期
点击发送 → 按钮锁定 / 显示停止生成 → 首包到达 / 内容逐步渲染 → 结束帧 / 错误帧 / 用户停止 → loading 收口 / 状态恢复 / 允许下一次发送
| 维度 | 检查点 | 为什么重要 |
|---|---|---|
| 开始阶段 | 首字是否来得足够快、按钮是否进入发送中 | 决定用户有没有“卡死”的第一印象 |
| 过程阶段 | 内容是否乱序、重复、闪烁、跳版 | 用户会直接觉得“生成有问题” |
| 结束阶段 | 是否明确结束、按钮是否恢复、能否继续提问 | 很多页面假死都出在收口阶段 |
| 异常阶段 | 断网、服务端异常、手动停止是否可感知 | 避免用户对产品状态产生误判 |
| 异常场景 | 重点确认 | 常见坏结果 |
|---|---|---|
| 中途断网 | 页面能否感知中断并结束 loading | 页面一直显示生成中 |
| 服务端结束帧丢失 | 前端是否有兜底超时或终止策略 | 答案已经完整，按钮还不恢复 |
| 用户手动停止 | 停止后是否仍有晚到内容写入 | 停止无效、内容继续滚动 |
这里特别适合录屏回看。因为很多问题最终结果看起来是对的，但过程错了：中间闪一下、按钮晚恢复两秒、停止后偷偷又补几行。截图很难说明这些，录屏一目了然。
06. Markdown / 代码块 / 富文本渲染
大模型输出很少是纯文本。只要涉及 Markdown、代码块、表格、引用、链接、图片、公式，渲染层就会产生大量细节问题。尤其在流式场景下，半成品内容更容易把版式打乱。
| 内容类型 | 典型问题 | 测试提醒 |
|---|---|---|
| Markdown 标题 / 列表 | 流式过程中层级跳动、列表断裂 | 不要只看最终态，过程也要看 |
| 代码块 | 反引号没闭合，整段样式崩掉 | 复制按钮、横向滚动、语法高亮都要看 |
| 表格 | 列宽错位、窄屏溢出 | 桌面端和窄窗口各测一次 |
| 链接 / 引用 | 链接不可点、跳错页、引用错位 | 检查可访问性和安全性 |
| 超长回答 | 滚动卡顿、复制不完整 | 真实项目里很常见，不要省略 |
一个常见误区。
很多团队把“渲染问题”理解成前端样式问题，其实不是。它往往是“流式内容分段 + Markdown 解析 + CSS + 浏览器渲染 + 安全策略”几层共同作用的结果。
07. 文件上传、下载、会话绑定
只要页面支持图片、文档、附件，复杂度会立刻提高。因为你在同时处理三种状态：前端显示状态、上传传输状态、后端解析和会话绑定状态。三者不是一回事。
前端选择文件 → 上传过程 → 服务端解析 → 绑定当前会话并被模型消费
| 点 | 具体检查 | 为什么常出问题 |
|---|---|---|
| 文件选择 | 支持类型、大小限制、拖拽、粘贴 | 浏览器和组件差异大 |
| 上传过程 | 进度、取消、失败重试、重复上传 | 前端状态很容易和后端状态脱节 |
| 解析结果 | 图片预览、文档解析、异常提示 | 上传成功不代表解析成功 |
| 会话绑定 | 刷新、切会话、历史恢复后文件是否还在 | 绑定关系常常被忽略 |
| 下载导出 | 文件名、编码、权限校验 | 导出环节常被临时加上，回归不充分 |
提单时别只写“上传失败”。
更有价值的写法是：前端是否已显示成功、后端是否收到、解析是否成功、会话是否绑定、模型是否真的引用了文件。你把问题拆细，研发定位速度会快很多。
08. 登录态、多标签页、刷新恢复
很多 Web 端问题表面像展示问题，实际是状态没管住。尤其 AI 产品会把登录态、会话态、本地草稿、正在生成的请求、历史缓存同时放在页面里，任何一层收口不稳都会出错。
| 场景 | 要看什么 |
|---|---|
| 登录过期 | 发送前过期、发送中途过期、刷新后过期分别怎么表现 |
| 多标签页 | 同账号不同页签是否互相污染会话和草稿 |
| 刷新恢复 | 刷新后是否回到正确会话，正在生成的内容如何处理 |
| 草稿缓存 | 草稿是否意外带到另一个会话或另一个账号 |
| 登出 / 切账号 | 本地缓存是否清理干净 |
这一块最适合做“用户乱点测试”：开两个标签页、快速切会话、刷新后立即重试、登录过期时继续点发送。这些看上去不规矩，但真实用户就是会这样用。
09. 浏览器兼容与响应式
Web 端不需要一开始就扫遍所有浏览器，但主流浏览器和高风险能力必须先测清楚。AI 产品里的高风险能力通常是：流式、上传、复制、粘贴、长列表滚动、代码块渲染、下载。
| 维度 | 优先覆盖 | 重点关注 |
|---|---|---|
| 浏览器 | Chrome、Safari、Edge | 流式兼容、剪贴板、下载行为 |
| 窗口尺寸 | 常规桌面、窄窗口、超宽屏 | 会话列表收起、代码块横向滚动、表格溢出 |
| 输入设备 | 键盘、触控板、鼠标滚轮 | 快捷键、滚动定位、复制行为 |
| 可访问性 | 键盘可达、焦点、语义标签 | 按钮可操作、状态可感知 |
为什么 Safari 经常要单独看
剪贴板、下载、输入法、某些滚动细节和 Chrome 表现并不完全一样，AI 页面对这些能力依赖又比较重。
响应式不是只看缩小窗口
更要看：代码块会不会把布局撑爆，会话列表收起后还能不能顺手切换历史记录，超长答案滚动有没有卡顿。
10. Web 端测试策略
如果你要真正落地一轮 Web 端 AI 测试，不要所有点一起铺。更建议分层推进：先把主流程和证据链抓稳，再补复杂状态，最后补兼容和体验。
| 阶段 | 目标 | 建议产出 |
|---|---|---|
| 第一阶段 | 主流程可用：输入、发送、流式、停止 | 主流程冒烟单、录屏证据 |
| 第二阶段 | 状态稳定：会话、刷新恢复、多标签页 | 状态矩阵、问题归因表 |
| 第三阶段 | 复杂能力：上传、下载、富文本渲染 | 文件链路清单、渲染样例库 |
| 第四阶段 | 端体验：浏览器兼容、响应式、可访问性 | 兼容矩阵、风险说明 |
测试对象：Web 端 AI 问答页
本轮目标：验证主流程、流式收口、会话状态和文件链路
浏览器范围：Chrome / Safari / Edge
风险重点：重复发送、停止生成、刷新恢复、多标签页、上传后无法引用
证据要求：网络面板、录屏、console、request id、会话 id
不在本轮：老旧浏览器、低优先级后台页面Web 端上线前必看
| 项 | 是否确认 | 备注 |
|---|---|---|
| 输入 / 发送主流程正常 | □ | 含重复点击保护 |
| 流式结束、手动停止都能正确收口 | □ | 保留录屏 |
| 会话切换、刷新恢复、多标签页稳定 | □ | 至少测 2 个账号场景 |
| Markdown / 代码块 / 表格渲染正确 | □ | 含超长内容 |
| 上传、解析、绑定、引用链路完整 | □ | 不是只看上传成功提示 |
| 主浏览器兼容通过 | □ | Chrome / Safari / Edge |
11. 常见缺陷和回归单
11.1 Web 端 AI 的高频缺陷
| 缺陷 | 常见触发方式 | 对用户的感受 |
|---|---|---|
| 回答明明结束了，页面还在转圈 | 结束帧丢失或前端未收口 | “页面卡住了” |
| 切换会话后出现上一条会话的内容 | 缓存污染、会话 id 串用 | “历史记录不可信” |
| Safari 下复制代码块格式全乱 | 剪贴板实现差异 | “结果看着对，复制出来不能用” |
| 上传成功后模型说没看到附件 | 解析或会话绑定失败 | “产品提示和实际能力不一致” |
| 登录过期后继续提问，页面假装在生成 | 过期处理和发送状态没联动 | “不知道自己到底有没有发出去” |
标题：Web 问答页在 Safari 17 下停止生成后仍持续追加内容
环境：macOS 14 / Safari 17 / 生产预发环境
前置条件：打开流式回答，问题内容较长
步骤：
1. 输入一条长问题并发送
2. 在返回第 5 行文字时点击“停止生成”
3. 观察页面内容、网络面板和按钮状态
实际结果：按钮恢复为“发送”，但内容仍持续追加约 2 秒，共新增 4 行
预期结果：点击停止后页面不再追加内容，状态与网络行为一致
证据：录屏、Network 截图、request_id
推测：前端停止状态已切换，但晚到 chunk 仍被渲染层消费回归时的一句提醒。
Web 端 AI 测试最值得盯的，不是“页面有没有出来”，而是“过程顺不顺、状态稳不稳、异常时用户有没有被准确告知”。
12. 下一步怎么接着学
如果 Web 端这页你已经能跟住了，下一步建议去看移动端。移动端会把权限、生命周期、弱网、机型差异、系统打断全部带进来，难度会再上一层。
下一篇
继续看 移动端 AI 测试专项，把系统权限、键盘、切后台、弱网和多模态入口吃透。
复盘建议
拿你们现在的 Web AI 页做一次“输入区、会话区、流式、上传、状态管理”五层拆解，你会很快发现原来很多问题压根不是一个层级。
补充练习与参考答案
补充练习
- 把一个 Web AI 问答页拆成 5 层，并分别写出一个重点测试点。
- 设计 2 条流式输出相关的异常回归用例。
- 如果上传成功但模型说没看到附件，你会先查哪几层？
参考答案要点
- 常见五层可拆为输入层、会话层、流式渲染层、附件层和状态管理层。
- 流式异常至少要测停止生成后是否仍追加内容、结束帧丢失后页面是否能正确收口。
- 上传问题优先排查上传绑定、会话关联、解析状态和服务端是否真的收到附件引用。