AI 辅助测试工作方法

一、需求来了，如何用 AI 辅助生成测试点？

1. 真实工作场景

测试人员经常拿到这样的输入：

• PRD 需求文档
• 原型图说明
• 用户故事
• 需求变更说明
• 会议纪要
• 产品口头描述
• 业务流程图

传统做法是测试人员自己阅读需求，然后拆测试点。
AI 可以帮助你做第一轮拆解，快速生成测试思路，但最终测试点仍需要人工确认。

2. 使用 AI 的正确流程

建议流程如下：

需求文档 ↓ AI 提取业务规则 ↓ AI 生成测试点 ↓ AI 补充异常和边界场景 ↓ 测试人员审核、筛选、补充 ↓ 形成正式测试用例或测试清单

3. 让 AI 生成测试点时，需要提供什么？

不要只说：

帮我生成测试点。

这样输出会很泛。

更好的输入方式是提供：

• 需求背景
• 功能目标
• 用户角色
• 业务流程
• 字段规则
• 权限规则
• 状态流转
• 异常处理
• 兼容性要求
• 性能要求
• 已知风险点

4. 推荐 Prompt 模板

你是一名资深测试工程师，请根据下面的需求说明生成测试点。 要求覆盖以下维度： 1. 正常功能流程 2. 异常流程 3. 边界值场景 4. 权限控制 5. 数据校验 6. 状态流转 7. 前后端交互 8. 数据库一致性 9. 兼容性 10. 性能风险 11. 安全风险 12. 历史缺陷可能复发点 请用表格输出，字段包括： 模块、测试点、测试类型、前置条件、测试数据、预期结果、优先级。 需求内容如下： 【粘贴需求文档】

5. 示例：需求为“用户登录”

假设需求是：

用户可以使用手机号和验证码登录。验证码 5 分钟内有效。连续输错 5 次验证码后账号锁定 10 分钟。登录成功后进入首页。

AI 应生成的测试点可以包括：

6. 测试人员需要重点审核什么？

AI 生成测试点后，不要直接复制使用。需要检查：

1. 是否符合真实业务规则
2. 是否遗漏核心主流程
3. 是否遗漏状态流转
4. 是否补充了异常和边界场景
5. 是否包含权限、风控、安全场景
6. 是否和历史缺陷相关
7. 是否存在 AI 编造的不存在功能

二、接口文档来了，如何生成接口测试用例？

1. 真实工作场景

后端提供接口文档后，测试人员需要设计接口用例，通常包括：

• 正常请求
• 参数为空
• 参数类型错误
• 参数长度超限
• 枚举值错误
• token 异常
• 权限异常
• 数据不存在
• 重复提交
• 并发请求
• 业务状态不允许

这些场景非常适合 AI 辅助生成初稿。

2. 接口用例生成流程

接口文档 ↓ AI 解析接口字段 ↓ AI 生成正向用例 ↓ AI 生成反向用例 ↓ AI 补充边界、权限、幂等、并发场景 ↓ 测试人员审核业务规则 ↓ 沉淀接口测试用例

3. 提供给 AI 的接口信息

最好包括：

接口名称： 请求方式： 接口地址： 请求头： 鉴权方式： 请求参数： 参数类型： 是否必填： 字段长度： 枚举值： 业务规则： 返回示例： 错误码说明：

4. 推荐 Prompt 模板

你是一名资深接口测试工程师，请根据以下接口文档生成接口测试用例。 请覆盖： 1. 正常请求 2. 必填参数缺失 3. 参数为空 4. 参数类型错误 5. 参数长度边界 6. 枚举值非法 7. token 缺失 8. token 过期 9. token 无权限 10. 数据不存在 11. 重复提交 12. 幂等性 13. 并发请求 14. 业务状态不允许 15. 返回字段校验 请用表格输出： 用例编号、测试场景、请求方法、请求路径、请求参数、前置条件、预期状态码、预期返回、优先级。 接口文档如下： 【粘贴接口文档】

5. 示例：创建订单接口

接口信息：

接口名称：创建订单 请求方式：POST 接口地址：/api/order/create 鉴权方式：Bearer Token 请求参数： productId：商品ID，Long，必填 quantity：购买数量，Integer，必填，范围 1-99 addressId：收货地址ID，Long，必填 couponId：优惠券ID，Long，非必填 业务规则： 1. 商品必须存在且上架 2. 库存必须充足 3. 收货地址必须属于当前用户 4. 优惠券必须有效且未过期 5. 不允许重复提交生成重复订单

AI 生成的接口用例示例：

6. 接口用例的人工确认点

AI 生成接口用例后，测试人员要重点确认：

• 错误码是否符合项目规范
• 参数约束是否真实存在
• 接口是否支持幂等
• 是否需要检查数据库
• 是否需要构造特殊状态数据
• 是否涉及第三方服务
• 是否需要联调上下游系统
• 是否有安全越权风险

三、自动化脚本不会写，如何用 AI 辅助完成？

1. 真实工作场景

很多测试人员知道测试思路，但不会写自动化脚本。AI 可以作为“代码助手”，帮助完成：

• 接口自动化脚本
• UI 自动化脚本
• 数据驱动脚本
• 断言逻辑
• 前置数据准备
• 后置数据清理
• Jenkins 集成脚本
• Allure 报告配置

2. 不建议这样问 AI

不要简单输入：

帮我写自动化脚本。

这样 AI 不知道你用什么语言、什么框架、什么项目结构。

3. 正确输入方式

你应该告诉 AI：

语言：Python 测试框架：pytest 请求库：requests 报告：Allure 配置方式：从 config.yaml 读取 base_url 和 token 用例数据：从 Excel 或 YAML 读取 接口文档：如下 断言规则：校验 status_code、code、message、data.id 需要包含：前置创建数据、后置清理数据

4. 推荐 Prompt 模板：生成接口自动化脚本

你是一名测试开发工程师，请根据以下接口测试用例生成 Python + pytest + requests 自动化测试脚本。 要求： 1. 使用 pytest 编写 2. 使用 requests 发送请求 3. 支持 base_url 配置 4. 支持 token 请求头 5. 每个测试方法包含清晰断言 6. 正常场景断言 status_code、业务 code、返回 data 7. 异常场景断言错误码和错误信息 8. 对创建的数据进行后置清理 9. 代码结构清晰，可直接放入项目中改造 接口文档： 【粘贴接口文档】 测试用例： 【粘贴接口测试用例】

5. 示例脚本：pytest 接口自动化

importrequestsimportpytest BASE_URL="https://test.example.com"TOKEN="your_test_token"@pytest.fixturedefheaders():return{"Authorization":f"Bearer{TOKEN}","Content-Type":"application/json"}deftest_create_order_success(headers):url=f"{BASE_URL}/api/order/create"payload={"productId":10001,"quantity":1,"addressId":20001,"couponId":None}response=requests.post(url,json=payload,headers=headers)res=response.json()assertresponse.status_code==200assertres["code"]==0assertres["data"]["orderNo"]isnotNonedeftest_create_order_quantity_zero(headers):url=f"{BASE_URL}/api/order/create"payload={"productId":10001,"quantity":0,"addressId":20001}response=requests.post(url,json=payload,headers=headers)res=response.json()assertresponse.status_codein[200,400]assertres["code"]!=0assert"数量"inres["message"]or"quantity"inres["message"]deftest_create_order_without_token():url=f"{BASE_URL}/api/order/create"payload={"productId":10001,"quantity":1,"addressId":20001}response=requests.post(url,json=payload)res=response.json()assertresponse.status_code==401orres["code"]in[401,10001]

6. AI 生成脚本后必须检查

AI 生成脚本通常不能直接投入生产使用，需要人工检查：

7. 进一步让 AI 改造成项目可用代码

你可以继续追问 AI：

请把上面的脚本改造成如下目录结构： project/ config/ config.yaml common/ request_util.py token_util.py testcases/ test_order.py data/ order_cases.yaml 要求： 1. 封装统一请求方法 2. 测试数据放到 yaml 3. pytest 参数化执行 4. 支持 Allure 测试报告

这样 AI 能继续帮助你把单个脚本改造成自动化框架雏形。

四、测试执行失败，如何分析日志和定位问题？

1. 真实工作场景

自动化测试、接口测试、CI 构建、服务联调时经常失败，例如：

• 接口返回 500
• 自动化断言失败
• 请求超时
• 数据库连接失败
• token 失效
• 环境配置错误
• 上游服务不可用
• UI 元素定位不到
• Jenkins 构建失败

AI 可以帮助快速归类问题、提取关键日志、给出排查路径。

2. 日志分析流程

失败日志 ↓ AI 提取错误摘要 ↓ AI 判断错误类型 ↓ AI 给出可能原因 ↓ AI 给出排查步骤 ↓ 测试人员结合环境验证 ↓ 定位缺陷或环境问题

3. 推荐 Prompt 模板

你是一名测试开发工程师，请分析以下测试失败日志。 请按以下结构输出： 1. 错误摘要 2. 关键日志 3. 错误类型判断 4. 可能原因，按概率排序 5. 影响范围 6. 建议排查步骤 7. 可能的修复建议 8. 是否更像是代码缺陷、测试脚本问题、测试数据问题、环境问题 9. 建议补充的测试用例 日志如下： 【粘贴日志】

4. 示例：接口返回 500

日志：

POST /api/order/create status_code=500 response={"code":500,"message":"Internal Server Error"} java.lang.NullPointerException at com.demo.order.service.OrderService.createOrder(OrderService.java:128) at com.demo.order.controller.OrderController.create(OrderController.java:45) request body: { "productId": 10001, "quantity": 1, "addressId": 99999 }

AI 分析结果应该类似：

1. 错误摘要： 创建订单接口返回 500，服务端发生 NullPointerException。 2. 关键日志： OrderService.createOrder(OrderService.java:128) 请求参数 addressId=99999。 3. 可能原因： - addressId 对应地址不存在，服务端未做空值判断。 - addressId 不属于当前用户，查询结果为空。 - 测试数据中地址 ID 无效。 - 后端缺少参数合法性校验。 4. 问题类型判断： 更像是后端代码健壮性问题，同时也可能存在测试数据无效问题。 5. 建议排查： - 查询数据库确认 addressId=99999 是否存在。 - 确认该地址是否属于当前登录用户。 - 查看 OrderService.java 第 128 行代码。 - 检查创建订单接口对无效 addressId 是否有明确错误处理。 6. 修复建议： - 如果地址不存在，应返回业务错误码，而不是 500。 - 服务端增加空值判断。 - 补充 addressId 不存在的接口测试用例。

5. 日志分析时要注意数据脱敏

不要直接把以下内容发给外部 AI：

• 用户手机号
• 身份证
• 银行卡
• token
• cookie
• 生产数据库地址
• 内网 IP
• 密码
• 真实订单号
• 真实客户信息

建议先脱敏：

手机号：138****1234 token：Bearer xxxxxx 用户ID：user_001 订单号：order_001

五、测试报告怎么写得更专业、更有结论？

1. 真实工作场景

很多测试报告只是罗列数据：

执行用例 100 条，通过 95 条，失败 5 条。 发现缺陷 20 个。

这类报告缺少结论，管理者和项目负责人最关心的是：

• 能不能上线？
• 还有什么风险？
• 核心功能是否可用？
• 严重问题是否解决？
• 遗留问题是否可接受？
• 哪些模块质量较差？
• 后续需要关注什么？

AI 可以帮助把零散数据整理成专业测试报告。

2. 测试报告应包含哪些内容？

建议结构：

一、测试结论 二、测试范围 三、测试环境 四、测试执行情况 五、缺陷统计 六、核心功能验证情况 七、遗留问题与风险 八、上线建议 九、后续改进建议

3. 推荐 Prompt 模板

你是一名测试负责人，请根据以下测试数据生成一份专业测试报告。 要求： 1. 语言正式、简洁 2. 先给明确测试结论 3. 说明是否建议上线 4. 总结核心功能质量 5. 分析主要缺陷和风险 6. 对遗留问题给出风险评估 7. 给出后续改进建议 测试信息如下： 版本号： 测试周期： 测试范围： 测试环境： 执行用例数： 通过用例数： 失败用例数： 阻塞用例数： 缺陷总数： 严重缺陷： 一般缺陷： 轻微缺陷： 已修复缺陷： 遗留缺陷： 核心流程验证结果： 遗留风险： 上线时间要求：

4. 示例测试报告结论

测试结论： 本次测试覆盖用户登录、商品浏览、购物车、订单创建、支付回调、订单查询等核心业务流程。共执行测试用例 286 条，通过 274 条，失败 12 条，通过率 95.80%。 测试过程中共发现缺陷 32 个，其中严重缺陷 3 个、一般缺陷 18 个、轻微缺陷 11 个。截至当前，3 个严重缺陷已全部修复并回归通过，仍遗留 4 个一般缺陷和 3 个轻微缺陷。 从测试结果看，核心下单链路、支付回调链路、订单查询链路已验证通过，系统主流程具备发布条件。但订单导出在大数据量场景下仍存在响应时间较长的问题，建议上线后加强监控，或限制单次导出数据量。 综合评估：本版本可有条件上线。上线前需确认遗留缺陷业务方已接受，并完成生产监控、回滚方案和灰度验证准备。

5. 专业测试报告的关键点

一份专业报告不是单纯“写得好看”，而是要有判断：

六、团队想做智能化测试，应该怎么设计落地路径？

1. 先明确：AI 测试不是一步到位

很多团队一开始就想做：

AI 自动写用例 AI 自动执行测试 AI 自动判断缺陷 AI 自动发报告

这个目标太大，容易失败。

更合理的路径是：

先辅助人 再增强流程 再接入平台 最后部分自动化决策

七、智能化测试落地路径设计

阶段一：个人效率提升

目标：让测试人员先把 AI 用起来。

适合场景：

1. 生成测试点
2. 补充边界场景
3. 生成接口测试用例
4. 整理缺陷复现步骤
5. 生成测试报告初稿

落地方式：

• 建立团队 Prompt 模板库
• 明确哪些场景可以用 AI
• 要求 AI 输出必须人工审核
• 形成统一用例和报告格式

产出物：

测试点生成模板 接口用例生成模板 日志分析模板 缺陷单整理模板 测试报告模板

阶段二：测试资产标准化

目标：让 AI 有高质量输入。

AI 的输出质量高度依赖输入质量。团队需要先把测试资产标准化：

如果文档混乱，AI 很难稳定输出高质量结果。

阶段三：接入测试平台

目标：让 AI 和测试流程结合，而不是单独聊天。

可接入的平台包括：

• 需求管理平台
• 接口管理平台
• 测试用例管理平台
• 自动化测试平台
• Jenkins / GitLab CI
• 缺陷管理平台
• 日志平台
• 监控平台

典型流程：

需求变更 ↓ AI 生成测试点 ↓ 同步到用例管理平台 ↓ 接口文档变更 ↓ AI 生成接口用例 ↓ 自动化框架生成脚本初稿 ↓ CI 执行自动化 ↓ AI 分析失败日志 ↓ 自动生成缺陷草稿 ↓ AI 生成测试报告

阶段四：知识库增强

目标：让 AI 更懂团队业务。

团队可以建设测试知识库，内容包括：

1. 产品业务规则
2. 接口文档
3. 数据库表说明
4. 状态流转图
5. 权限矩阵
6. 历史缺陷库
7. 线上事故复盘
8. 自动化框架规范
9. 测试报告模板
10. 常见错误码说明

通过知识库增强，AI 输出会更贴近真实业务。

阶段五：智能回归和变更影响分析

这是更高级的阶段。

当需求或代码发生变化时，AI 可以辅助判断：

• 哪些模块受影响
• 哪些接口需要回归
• 哪些自动化用例需要执行
• 哪些历史缺陷可能复发
• 哪些下游系统可能受影响
• 哪些数据表和报表需要验证

推荐 Prompt：

你是一名测试架构师，请根据以下变更内容进行测试影响分析。 请输出： 1. 变更摘要 2. 直接影响模块 3. 间接影响模块 4. 受影响接口 5. 受影响数据库表 6. 受影响业务流程 7. 建议回归范围 8. 高风险场景 9. 需要补充的测试用例 10. 是否建议增加自动化回归用例 变更内容： 【粘贴需求变更、代码变更、接口变更】

八、不同角色如何使用 AI？

1. 功能测试工程师

适合使用 AI 做：

• 需求测试点拆解
• 边界场景补充
• 测试用例生成
• 缺陷复现步骤整理
• 测试报告生成

2. 接口测试工程师

适合使用 AI 做：

• 接口用例设计
• 参数组合分析
• 错误码覆盖
• 接口自动化脚本生成
• 接口失败日志分析

3. 测试开发工程师

适合使用 AI 做：

• 自动化框架代码生成
• 脚本重构
• CI/CD 集成
• 日志分析
• 失败用例归因
• 测试工具开发

4. 测试负责人

适合使用 AI 做：

• 测试计划生成
• 测试报告总结
• 质量风险分析
• 变更影响分析
• 团队规范制定
• 测试资产治理

九、AI 辅助测试的最佳实践

1. 输入越具体，输出越有用

低质量输入：

帮我写测试用例。

高质量输入：

请根据以下登录需求生成测试用例，要求覆盖手机号格式、验证码有效期、错误次数限制、账号锁定、token 生成、安全风控、异常提示、兼容性，输出表格。

2. 不要让 AI 直接决定上线

AI 可以辅助总结风险，但上线决策必须由测试负责人、研发负责人、产品负责人共同确认。

3. AI 输出必须经过人工审核

尤其是以下内容：

• 测试用例
• 自动化脚本
• 缺陷原因判断
• 影响范围分析
• 测试结论
• 上线建议

4. 建立团队 Prompt 模板库

建议至少沉淀以下模板：

需求测试点生成模板 接口用例生成模板 边界场景补充模板 自动化脚本生成模板 失败日志分析模板 缺陷单整理模板 测试报告生成模板 变更影响分析模板

5. 建立 AI 使用安全规范

明确禁止输入：

• 生产用户隐私
• token
• 密码
• 密钥
• 生产数据库连接
• 未脱敏日志
• 公司核心机密

十、推荐的一套完整 AI 辅助测试工作流

1. 需求阶段 - AI 辅助理解需求 - AI 生成测试点 - AI 补充边界和异常场景 2. 设计阶段 - AI 生成测试用例 - AI 生成接口测试用例 - AI 做变更影响分析 3. 执行阶段 - AI 辅助生成自动化脚本 - AI 辅助构造测试数据 - 自动化平台执行测试 4. 分析阶段 - AI 分析失败日志 - AI 判断失败类型 - AI 整理缺陷复现步骤 5. 总结阶段 - AI 生成测试报告 - AI 总结遗留风险 - AI 给出上线建议草稿 6. 沉淀阶段 - 将测试点、用例、缺陷、报告沉淀到知识库 - 优化 Prompt 模板 - 持续提升 AI 输出质量

十一、最终建议

对于测试团队来说，AI 辅助测试最适合从以下几个点开始：

第一优先级

AI 生成测试点 AI 补充边界场景 AI 生成接口测试用例 AI 整理缺陷复现步骤 AI 生成测试报告

这些场景风险低、收益明显、容易落地。

第二优先级

AI 生成自动化脚本 AI 分析失败日志 AI 做变更影响分析

这些场景价值更高，但需要更多项目上下文和工程规范。

第三优先级

AI 接入测试平台 AI 接入 CI/CD AI 接入缺陷系统 AI 接入日志平台 AI 建设测试知识库

这是团队级智能化测试建设方向。

总结

AI 辅助测试的核心不是“让 AI 替测试人员工作”，而是让测试人员更快、更全面、更标准地完成工作。

它最适合解决这些问题：

需求看不全 → AI 帮你拆测试点 边界想不全 → AI 帮你补场景 接口用例写得慢 → AI 帮你生成初稿 自动化不会写 → AI 帮你生成脚本雏形 失败日志太长 → AI 帮你提取关键原因 缺陷描述混乱 → AI 帮你整理复现步骤 测试报告没结论 → AI 帮你提炼风险和上线建议 团队想智能化 → AI 帮你搭建流程和知识库

真正有效的落地方式是：

AI 生成初稿，测试人员审核； AI 提供建议，测试人员判断； AI 提升效率，测试团队保证质量。