AI 测试平台：怎么做的更好？
AI 测试平台：怎么做的更好？
- 整体规划：从手工做测试，变成“AI 帮人做重复工作”，再到“AI 串起需求、用例、数据、执行、报告和知识沉淀”
- AI辅助半自动化（2.0）：一体化测试平台，集 AI 需求分析、测试用例、API、UI 、APP测试等，核心是地基、资产、孵化智能、大统一
- AI全流程自动化（ 3.0） ：为纯 AI 自动化而生，核心是提升效率和功能完整复刻
- AI 自动设计用例
- 高覆盖测试用例：设计优化
- 测试点生成，考虑 4 类 14 个维度
- 特殊场景，需要增强设计
- AI 自动执行用例
- 顶配 Testhub 局限性
- AI + 时代全能，生产级多智能体测试系统（4.0）：动态协同的智能体群，核心是提升质量
- 智能化测试
整体规划：从手工做测试，变成“AI 帮人做重复工作”，再到“AI 串起需求、用例、数据、执行、报告和知识沉淀”
从人工散点测试 → AI辅助半自动化→ AI全流程自动化 → AI+时代全能
测试链路主要靠人工推动，流程分散、效率低下、数据覆盖不全且复用性差
人工设计用例容易受主观影响，测试数据构造耗时且易遗漏，结果校验繁琐且易出错，测试报告依赖人工整理，迭代响应迟缓 —跟不上 AI 开发的进度。
过去的问题：
- 需求、用例、脚本、报告分散在不同地方
- 大量时间消耗在整理、编写、回归、解释
- 测过但证据不完整，复盘依赖个人记忆
- 自动化和人工测试割裂，资产复用不足
AI辅助半自动化（2.0）：一体化测试平台，集 AI 需求分析、测试用例、API、UI 、APP测试等，核心是地基、资产、孵化智能、大统一
开源项目：testhub
全方位：市面上 AI 辅助测试，都是在【点】上做事，有的生成用例、有的造测试数据、有的写接口脚本等，但拼不到一起
一体化：
- 测试人员不缺 AI，缺的是 — 【测试流程本身的割裂和碎片化，没有打通数据流转，消除各种工具切换的摩擦】
- 需求分析用一个工具，用例管理用另一个，造数据要开五六个网页，跑接口用Postman，搞UI自动化又要切到代码编辑器
- 每天在工具间疲于奔命，大量的时间花在了复制粘贴和上下文切换上
AI测试用例，增加了专属生成用例 skill+评审skill：
- 像人工写 100 条，需要一天时间；而 AI 是几分钟搞定，提效非常明显
平台化 + 智能化改造，配置小龙虾（安全可控+长期记忆升级）：
- 资产沉淀：不会引入了半年 AI，什么资产都沉淀不下来 ---- 导致不能交给下一个接手的人用 & 长期下来没有进步 ---- 数据沉淀下来，不仅能提升团队水平，还可以用于养龙虾；
- 可以自己养龙虾：从最初的自动化探索性测试，到安全测试、性能测试的全面尝试。在安全测试这块不仅快速、准确，甚至能弥补团队的技术短板。前期扎实的基础建设，当项目线上真的出现安全事故时，AI军团能展现了惊人的价值。提供了超乎想象的支撑和资源补给，极大地缓解整个团队的工作压力，成为了最坚实的后盾。
我自己实测：付费顶配的 Testhub，主要是打通数据链路，但测试还是需要自己手动通过元素定位（UI测试），接口测试（通过 Google 浏览器导入 network HAR 文件，导入不全），还是不能满足提升效率的需求，跟不上 AI 开发的进度。
AI全流程自动化（ 3.0） ：为纯 AI 自动化而生，核心是提升效率和功能完整复刻
AI 自动设计用例
- 智能去除AI生成相似用例；
- 解析带图片的pdf和docx文档，最好是能直接读取 Figma
- 多智能体推理架构：不只是“一条Prompt”，每个Agent负责不同的QA视角：覆盖、异常、可追溯性等，协同产出更可靠的结果。
- 测试用例生成提升：输入大量正样本测试用例与负样本非测试用例训练，对大量测试结果与日志分析，找出测试缺陷的模式与规律，产生测试报告与缺陷列表。通过对历史测试结果与缺陷报告的深度学习训练，可以建立软件缺陷的检测模型，然后自动分析新测试结果中的缺陷
高覆盖测试用例：设计优化
- 如果是提示词生成测试用例，业界普遍反映，直接生成的用例可用率普遍低于30% — 越长的文档，越差。
因为仅凭一份往往写得不够全面和精确的需求文档，AI相当于在盲猜。
哪怕是基于 很好的测试skill，让大模型去读取信息的时候，也会有各种隐性关系丢失，特别是 A依赖B，B依赖C，C依赖D 的长逻辑链（最简单的情况），实际上是 长逻辑链 + 复杂多变的多步多个方向（长逻辑网络）。
再加上，全流程测试技能（需求分析、需求拆解、测试方案设计、测试点生成、批量生成测试用例、批量用例评审、看情况补充或循环流程）
都是同一个智能体在跑，上下文一直在压缩，不管什么智能体，当上下文到达 70% 以上，都会开始降智，压缩信息就会丢失信息。
如果基于 RAG + 提示词，可以到达 50% - 60%。
如果再加上一个智能体递归推导流程，可以到达 80%：
- 功能点提取
- 测试场景提取
- 测试点提取
- 测试用例提取
- 测试脚本提取
- 测试数据提取
- 用例review 反思机制
如果再加上一个图谱，解决各种图片之间、各种接口之间、各种段落之间的依赖和关联关系，可以到达 90% 以上。
剩余 10%，加上提示词设计了，推荐上图：需求分析、需求拆解、测试方案设计、测试点生成、批量生成测试用例、批量用例评审、看情况补充或循环流程
如果基于探索学习的生成方法，可以到达 90% 以上，但额外好处是，方便智能体自动化。
测试点生成，考虑 4 类 14 个维度
| 编号 | 检查维度 | 核心检查问题 | 测试关注点 |
|---|---|---|---|
| 跑通主流程相关的 | 正常流程 | 核心路径走得通吗？ | 主功能全链路畅通，数据正确生成/更新，页面跳转与反馈符合预期。 |
| 跑通主流程相关的 | 异常流程 | 输入错了、网络断了、依赖挂了，系统怎么反应？ | 友好错误提示、自动重试/降级、系统不崩溃、数据不损坏。 |
| 跑通主流程相关的 | 边界值 | 最大值、最小值、临界值、空值，系统能hold住吗？ | 长度/数值/日期边界、空字符串、null、大文件、0与负数。 |
| 数据和权限相关的 | 权限 | 没登录的人能不能访问？能不能越权操作？ | 未登录拦截、角色/资源隔离、水平/垂直越权校验。 |
| 数据和权限相关的 | 数据校验 | 前后端校验一致吗？必填项控了吗？ | 前端做体验校验，后端做安全校验，校验规则一致且不可绕过。 |
| 数据和权限相关的 | 状态流转 | 状态机有没有非法迁移？有没有不可达状态？ | 状态跳转合法、不允许逆向/跳过、所有状态可到达且可退出。 |
| 工程稳定性相关的 | 并发 | 多个人同时操作同一资源会怎样？ | 超卖/超扣、数据一致、锁机制、乐观锁/悲观锁效果。 |
| 工程稳定性相关的 | 幂等 | 重复提交会不会产生重复数据？ | 网络重试、按钮连点、支付/下单等接口重复调用结果一致。 |
| 工程稳定性相关的 | 接口 | 参数缺失、类型错误、分页边界，接口扛得住吗？ | 必填/可选参数校验、类型格式校验、分页越界、排序字段非法。 |
| 工程稳定性相关的 | 数据库 | 写入对不对？事务回滚了没有？ | 字段类型/长度匹配、关联表一致、异常场景数据完整回滚。 |
| 质量和回归相关的 | 日志审计 | 关键操作记了没有？敏感信息脱敏了没有？ | 关键增删改查留痕、操作人/时间/IP可追溯、密码/手机号脱敏。 |
| 质量和回归相关的 | 兼容性 | 多浏览器、多设备、多端，表现一致吗？ | 主流浏览器、移动端/PC分辨率、操作系统、App版本兼容。 |
| 质量和回归相关的 | 性能 | 响应时间、资源占用、长时间运行稳不稳定？ | 接口响应<阈值、CPU/内存无泄漏、长时间运行不卡顿不崩溃。 |
| 质量和回归相关的 | 回归 | 新功能上线不影响老功能吗？ | 核心老用例全量或自动化回归，确保历史功能不受影响。 |
特殊场景，需要增强设计
金额计算和AI交互确实是两类“出事概率极高、且一出事就是大事”的场景，常规14维度覆盖不全，需要强制补测。
一、金额类场景（硬性补测）
触发条件：需求中出现“金额/价格/折扣/满减/优惠券/支付/退款/预算/余额”等关键词时，必须执行以下测试：
| 测试分类 | 具体测试点 | 预期/说明 |
|---|---|---|
| 精度 | 小数位保留几位？（如分、厘） | 需与产品/财务确认，常见2位/4位 |
| 精度 | 四舍五入还是银行家舍入？ | 财务系统多用银行家舍入，需确认 |
| 精度 | 浮点数运算是否会丢精度？ | 用Decimal或整数分存储，不用float |
| 边界 | 金额为0时，计算/展示/支付是否正常？ | 不报错、不崩溃 |
| 边界 | 金额为负数时，系统是否拦截？ | 业务上通常不允许负金额 |
| 边界 | 预算刚好用完的临界点（如满100减10，正好100） | 优惠生效、余额归零正常 |
| 边界 | 金额极大值（如9,999,999,999.99） | 数据库字段/前端显示不溢出 |
| 组合规则 | 满减叠加折扣，计算顺序是否正确？ | 先折扣再满减，还是反过来？需明确 |
| 组合规则 | 多个优惠冲突时，优先级是否正确？ | 如不可叠加的券同时使用时拦截 |
| 组合规则 | 优惠叠加上限（如最多叠加3张） | 超过上限时拦截或提示 |
| 累计扣减 | 多笔扣减后，余额是否准确？ | 每一笔扣减日志可追溯 |
| 累计扣减 | 余额不足时是否拒绝扣减？ | 不能扣成负数 |
| 累计扣减 | 并发扣减（如同时下单），数据是否一致？ | 用乐观锁/悲观锁保证 |
| 退款回滚 | 部分退款时，金额计算是否正确？ | 按比例退还是按固定金额退？需确认 |
| 退款回滚 | 退款后预算/余额是否完整恢复？ | 恢复后数据与历史一致 |
| 退款回滚 | 多次部分退款叠加，最终是否与总额一致？ | 如分3次退完，总退款=原金额 |
二、AI交互类场景（硬性补测）
触发条件：需求涉及“AI对话/智能助手/内容生成/智能推荐/意图识别/问答系统”等关键词时，必须执行以下测试：
| 测试分类 | 具体测试点 | 预期/说明 |
|---|---|---|
| 意图理解 | 用户表达模糊时（如“帮我查一下那个”），系统如何处理？ | 追问澄清或给出合理候选 |
| 意图理解 | 多意图混合输入（如“帮我订票顺便查天气”），能否正确拆分？ | 主次意图都能响应 |
| 意图理解 | 无意义输入（乱码/表情/单字），系统如何反馈？ | 友好提示，不崩溃 |
| 歧义澄清 | 有歧义时是追问还是直接猜测？ | 追问为佳，避免错误执行 |
| 歧义澄清 | 追问话术是否合理、自然？ | 不机械、不重复循环追问 |
| 上下文一致性 | 多轮对话中，上下文信息是否完整传递？ | 如第1轮说“北京”，第2轮问“天气”，应查北京天气 |
| 上下文一致性 | 超出上下文窗口长度时，如何处理？ | 截断/摘要/提示，且不丢失核心信息 |
| 拒答 | 违法违规内容（涉黄/涉政/暴力）是否有效拒答？ | 拒答并引导至合规方向 |
| 拒答 | 超出AI能力范围的问题，如何回复？ | 明确告知无法回答，不编造 |
| 幻觉控制 | 事实性内容（如历史时间、法律条文）是否准确？ | 需与可信数据源交叉验证 |
| 幻觉控制 | 不确定的信息，是否明确标注“仅供参考/AI生成”？ | 不能以确定口吻输出不确定内容 |
| 安全 | Prompt注入攻击（如“忽略之前的指令”），是否防护？ | 不被诱导输出违规内容 |
| 安全 | 用户输入中是否泄露他人隐私信息（如手机号）？ | 识别并脱敏/拒绝处理 |
| 输出稳定性 | 同一输入多次调用，输出差异是否在可接受范围？ | 语义一致，不出现矛盾回复 |
| 输出格式 | 输出是否满足约定格式（如JSON/表格/列表）？ | 格式不解析失败，不吐出markdown乱码 |
三、与14维度的关系
这两类不是替代14维度，而是在14维度基础上强制叠加：
| 14维度原有项 | 金额场景增强 | AI场景增强 |
|---|---|---|
| D03 边界值 | +金额为0/负/极大/临界 | +上下文窗口边界 |
| D07 并发 | +并发扣减一致性 | +多轮并发对话 |
| D08 幂等 | +重复支付/退款不重复 | +相同提问重复计费？ |
| D10 数据库 | +金额字段精度/事务回滚 | +对话记录完整保存 |
| D02 异常流程 | +扣减失败回滚 | +AI服务超时/降级 |
| D05 数据校验 | +金额格式/非法字符 | +Prompt注入/敏感词过滤 |
| D11 日志审计 | +每笔金额变动留痕 | +每次AI调用输入/输出留痕 |
AI 自动执行用例
常见的智能体工具：
- Web 自动化 Agent: Playwright-MCP Playwright-Cli Browser-Use
- App 自动化 Agent: Appium-mcp AppAgent
- Windows Mac GUI 自动化 Agent: Appium PyAutoGUI
- 视觉驱动智能体: MidScene
多模态大模型可以让我们更好的分析通用的 UI 界面。
不过缺点也很明显，响应慢，获取的信息量不够全，通常需要结合控件树进行综合分析。
不建议只使用视觉识别大模型。
因为在一些更加复杂的案例场景中，需要获取在可视 UI 之下的深层数据以实现更快更稳定的测试，这是视觉识别无法做到的典型场景。
开发的测试方案：
- Browser Use + Pytest + LLM、MidScene.JS + LLM、Midscene.js + UI-TARS + LLM 的 UI自动化；
- Pytest + Allure + LLM 接口自动化
- AI驱动的全栈式代码审查：缺陷检测、合规校验与架构优化
- AI渗透测试
顶配 Testhub 局限性
如果单把各个模块拎出来的话，会存在这个情况。
比如：接口测试不如国产的ApiFox、UI自动化可能不如那种带录制的影刀RPA、APP测试可能不如网易本身的AirtestIDE
毕竟是一家【专门的 + 科技公司 + 大团队】，在这一个门类里沉淀了【很多年】
所以，我们是做平台化 + 智能化 + 高效化 + 一体化 + 可无限成长的潜能 + 测试工程体系升级 + 高覆盖率测试用例，不依赖个体经验
不是在一个点上跟他们竞争，而是在多个维度打造竞争力
- 一个维度比的是长度
- 俩个维度比的是面积
- 三个维度比的是体积
- 当多个维度有比较优势，多维度意义就会几何级数的增长
AI + 测试，本身也不是一个单点工具问题，而是测试工程体系升级问题。
从需求到可靠的测试覆盖，分钟级完成，而不是一个迭代周期。
从临时助手的 AI （缺上下文时补造业务规则、生成常见路径遗漏特定风险等）到变成 可靠测试能力 的超级数字员工。
从测试设计缓慢、手工且不一致、测试逻辑沉淀在个人脑中、无可追溯、无迭代闭环、模板工具 ≠ 真实测试覆盖、AI生成更快更多 ≠ 质量证据链，
到研发团队能不能更早暴露风险、减少返工、保留证据，并让能力在团队之间复用
像影刀 2G、ApiFox 500M、Airtest 也得几百兆，AI用例生成也得找个工具吧，Hermes 再单独弄一套
而且影刀不会给你二开，ApiFox 不会给你私有化部署
可以在 AI 上直接调用 postman 等，实现二开。
AI + 时代全能，生产级多智能体测试系统（4.0）：动态协同的智能体群，核心是提升质量
AI测试 不是 工具效率问题，AI 最容易改变 产出速度，但测试关心的不是产出速度，而是产出能否成为质量证据
OpenAI、Claude 封禁但又自己使用的，模型解决安全漏洞
智能化测试
测试设计：多智能体推理架构 + 用例生成，配置 知识图谱RAG算法（如 lightrag，可改成多模态图RAG）：
- 因为必须是按照企业内部文档生成，大模型上下文不足，可以增加一个外挂知识库
- 文档、图片、接口、多个段落之间，是相互关联，A 依赖 B，B 依赖 C，C 依赖 D，只有 图，才能很好处理 长链条 + 分支多变的 结构关系
- 知识图谱建模，智能体执行速度更快，因为智能体如果是视觉驱动网页测试，就只能一步一步执行，但如果是图谱建模网页测试，经常可以一步直接跳几步。
测试执行：
- Playwright 只能完成一些简单的功能；Midscene.js 视觉驱动太慢了；
- 市面上没有现成的工具，需要自己开发 — 测试执行自动化智能体、模型驱动测试、智能探索测试 ReACT
专项测试：
- 性能、安全、测试左移、测试右移、精准测试
缺陷发现：
- 缺陷挖掘、缺陷发现、日志分析、代码分析、执行流分析
工作流：
- 变更自动分析
- 全流程自动化，整合到一起，自动提交 bug