2026/8/2 4:54:36
FEATURED · 精选文章 
适用读者经常用 Python / pytest 写自动化、写压测脚本的测试工程师核心观点AI 效率的关键不是把提示词写得更长而是把上下文、流程和经验工程化。一、为什么测试工程师特别适合做提示词工程测试开发的工作有一个天然优势输入输出边界清晰。一个接口测试请求是什么、断言是什么、Pass/Fail 的标准是什么一个压测脚本并发多少、SLA 是多少、P95 要低于多少一个自动化用例前置条件、操作步骤、预期结果这些本来就是测试用例的基本要素。而 AI Coding AgentClaude Code、Codex、Cursor 等恰恰最擅长处理有清晰规格说明spec的任务。问题不在于 AI 能不能写测试代码而在于你怎么给它上下文。我见过太多这样的提示词“帮我写一个登录接口的压测脚本。”AI 很听话但它不知道你的接口字段、鉴权方式、成功标准、环境地址、并发模型……于是它只能合理想象结果就是一堆看起来专业、跑起来报错、断言形同虚设的代码。解决方案不是换更贵的模型而是把项目建成 AI 能看懂的工程。二、AI 测试工程化总览五步工作流下图是我目前用的完整工作流从需求澄清到沉淀复用形成闭环这套流程的核心心法是先让 AI 反问再让它动手需求澄清避免幻觉先写失败测试再写实现TDDAI 的自愈循环才有锚点跑红绿灯自动修复autonomous run-and-fix loop人工只审关键路径把判断力用在刀刃上沉淀为 Skill下次零成本复用三、把项目建成 AI 能秒懂的工程结构很多团队用 AI 写代码效率低是因为项目本身对 AI 不友好配置散落、没有统一入口、接口契约只在某个人脑子里。下图是一个推荐的标准化工程目录结构让 AI Agent 一眼看懂项目、自动读取上下文几个关键设计原则参考图中颜色标注目录/文件作用为什么重要.claude/skills/压测/接口测试/评审等可复用技能AI 自动识别并按流程执行不用每次重新教.claude/AGENTS.md项目级入口背景、规则、默认读取顺序最重要的配置文件AI 进项目先读它docs/api-spec.md接口契约Swagger/HAR 转写杜绝 AI 编造字段prompts/templates/TDD、压测、评审等Prompt 模板模块化、可版本化、可团队共享tests/performance/baselines/历史性能基线AI 自动对比回归不再凭感觉.env.example环境变量模板不提交真实密钥安全红线AI 也必须遵守经验花 1 小时把AGENTS.md和api-spec.md写好后续每个任务的 Token 消耗和返工次数都会显著下降。这正符合Token 优化的本质——输入端把上下文准备充分比在输出端反复纠辩便宜得多。四、核心实战用 TDD 三色循环让 AI 交付可信代码这是我用 AI 写 pytest / Locust 脚本时最稳定的模式源自当前主流的 AI Coding Agent 实践Claude Code、Codex 等均已验证4.1 RED先写失败的测试禁止实现提示词骨架为 [目标函数/接口] 写测试使用 pytest / Locust。 要求 1. 只写测试不要实现函数/脚本 2. 每个测试只验证一件事命名遵循 should_X_when_Y 3. 覆盖正常路径、边界值、错误路径、鉴权失败 4. 断言要具体不要只 assert truthy 5. 跑一次确认测试是红灯确实失败关键约束明确告诉 AI “不要实现”——否则它会连函数一起写出来测试就变成了为已有实现量身定制失去发现 bug 的能力。4.2 GREEN最小实现让测试通过禁止改测试上面的测试目前失败。请用最小改动让测试通过。 约束 - 不要修改测试文件 - 不要修改断言 - 不要顺手重构无关代码 - 实现完成后跑全量测试确认全绿这就是autonomous run-and-fix loop的核心AI 自己跑、自己看失败、自己修直到绿灯。4.3 REFACTOR在绿灯保护下重构测试已全绿。请重构 [文件]提升可读性/性能/复用性。 约束 - 每次改动后必须重跑测试 - 行为不能变只改善结构 - 删除重复代码、提取公共 Fixture4.4 一个真实收益数据参考社区实践一份 30 行的 specAI 能生成 1500 行左右的测试套件。手写要 2 天AI 生成 人工 review 半天搞定且边界覆盖比手写更系统。五、AI 写压测脚本从 0 到可运行 Locust/k65.1 让 AI 先生成测试计划再写代码不要一步到位要脚本分两步Step 1 — 生成测试计划不写代码我要对 [接口/链路] 做压测。请先输出一份测试计划包含 - 测试类型冒烟/负载/压力/峰值/耐久 - 并发模型与阶段ramp-up / steady / ramp-down - 关键 SLAP95、错误率、RPS 目标 - 测试数据来源与参数化策略 - 需要监控的指标 不要写代码。Step 2 — 按计划实现基于上面的计划生成 Locust / k6 脚本 - 鉴权从 /auth/login 获取 JWT每个 VU 独立 - 成功判定HTTP 200 且业务 code 0 且关键字段存在 - 失败请求必须记录原因不要静默吞掉 - 从 fixtures/ 读取测试数据不硬编码 - 设置 thresholdsp(95)500ms、错误率0.1% - 输出 JSON summary 供 Grafana/报告使用5.2 一份可直接用的 Locust 模板AI 生成 人工微调importosimportrandomimportlocustfromlocustimportHttpUser,task,betweenimportrequestsclassOrderUser(HttpUser):wait_timebetween(1,3)defon_start(self):# 从环境变量读凭证绝不硬编码respself.client.post(/api/login,json{username:os.getenv(TEST_USERNAME),password:os.getenv(TEST_PASSWORD),},)assertresp.status_code200,f登录失败:{resp.text}self.tokenresp.json()[data][token]self.headers{Authorization:fBearer{self.token}}task(3)defcreate_order(self):payload{productId:random.choice([1001,1002,1003]),quantity:1,addressId:88,}withself.client.post(/api/order/create,jsonpayload,headersself.headers,catch_responseTrue,)asresp:ifresp.status_code!200:resp.failure(fHTTP{resp.status_code}:{resp.text})elifresp.json().get(code)!0:resp.failure(f业务失败:{resp.text})else:resp.success()5.3 用 AI 分析压测结果、自动定位瓶颈Locust / k6 跑完会产出大量 CSV/JSON。这一步让 AI 当性能分析师这是本次压测的 requests_stats.csv请 1. 计算 P50/P95/P99、平均 RPS、错误率 2. 用孤立森林/统计方法标记响应时间异常高的接口 3. 与 baselines/ 下的历史基线对比标出回归项 4. 输出 Top 3 瓶颈假设 验证建议这样就把跑压测升级成了持续性能守护——每次跑完自动对比基线、自动报警。六、Token 优化让 AI 测试工程越用越便宜很多团队用 AI 觉得烧 Token 太快本质是没做工程化。下面是四象限策略四条可执行原则输入端把接口契约、技术栈、验收标准写进docs/和prompts/templates/AI 一次读取、多次复用而不是每个任务重新解释一遍项目输出端约束输出格式“只输出代码”/“只输出 diff”/“输出 JSON 报告”禁止 AI 堆砌解释性废话上下文分层项目级AGENTS.md→ 模块级api-spec.md→ 任务级当前 Prompt按需注入不全量塞进上下文复用是真正的省钱把高频流程生成压测脚本、评审测试代码、对比性能基线固化为 Skill复用次数越多单次边际成本越低七、AI 测试工程的红线这些坑必须人工把关AI 能提效但测试工程师的判断力不可替代。这几条红线建议写进你的AGENTS.md红线风险对策AI 编造接口字段脚本跑通但测的是空气提供真实 Swagger/HAR做事实核查只断言 HTTP 200业务失败被误判成功强制校验业务 code 关键字段测试 mock 过多改坏实现也能绿灯故意改错一行实现验证测试会变红测试与实现一起飘双双偏离 spec每次改代码后 diff 检查测试文件是否被偷偷改了硬编码密钥/Token凭证泄露.env.example模板化CI 检查真实密钥过度测试维护成本爆炸删掉同行为不同写法的重复用例压测打生产事故脚本内硬编码host必须为测试域名CI 门禁特别重要的一条单元测试可以让 AI 写 90%但端到端 / 集成测试要坚持人工写 90%——因为 E2E 反映的是你们公司的真实业务流AI 不知道。八、可落地的五步实施清单如果你今天就想动手按这个顺序走建统一入口写AGENTS.md说清项目背景、目录、规则、AI 默认读取顺序整理 prompts/config把角色约束、技术栈、输出格式、模型配置放到固定位置沉淀高频 Skill选你最重复的 2~3 个流程生成压测脚本 / 生成接口测试 / 评审测试代码固化目标、步骤、禁区、交付格式拆分复杂任务按设计 → 实现 → 验证 → 沉淀切成小节点逐步交付记录效果并迭代跟踪 Token 消耗、返工次数、缺陷定位时间、复用次数用数据驱动优化九、总结回到开头那句话AI 效率的关键不是把提示词写得更长而是把上下文、流程和经验工程化。对测试开发来说这件事尤其划算——我们的工作本来就是规格驱动的。把接口契约、验收标准、测试策略、历史基线整理成 AI 能读的工程文件再配合 TDD 三色循环和 Skill 沉淀同样的模型产出质量会有质的区别。最后送一句给同样在写 pytest / Locust 的你AI 接管的是机械劳动留给你的是判断——哪些断言真正保护业务、哪些场景值得压测、哪些红线绝不能碰。这些判断全是经验性工作新人做不来AI 也替代不了。注意点用好AI工具可以大大缩短压测流程提高压测执行效率也可以快速提升自动化测试能力而非从0-1去学习某个技术栈AI时代你需要的是某一块领域的知识并且用好AI去执行一边用AI设计、执行落地一边跟着AI去学习去了解相干的技术栈或者领域知识最终成为自己的一个技能和工作流。互动话题你用 AI 写测试脚本时踩过最离谱的幻觉坑是什么欢迎评论区交流我可以帮你把常见坑整理成一份可复用的review_checklist.mdSkill。
【用 AI 重塑软件测试效率：从“写提示词“到“建工程“的实战指南】
适用读者经常用 Python / pytest 写自动化、写压测脚本的测试工程师核心观点AI 效率的关键不是把提示词写得更长而是把上下文、流程和经验工程化。一、为什么测试工程师特别适合做提示词工程测试开发的工作有一个天然优势输入输出边界清晰。一个接口测试请求是什么、断言是什么、Pass/Fail 的标准是什么一个压测脚本并发多少、SLA 是多少、P95 要低于多少一个自动化用例前置条件、操作步骤、预期结果这些本来就是测试用例的基本要素。而 AI Coding AgentClaude Code、Codex、Cursor 等恰恰最擅长处理有清晰规格说明spec的任务。问题不在于 AI 能不能写测试代码而在于你怎么给它上下文。我见过太多这样的提示词“帮我写一个登录接口的压测脚本。”AI 很听话但它不知道你的接口字段、鉴权方式、成功标准、环境地址、并发模型……于是它只能合理想象结果就是一堆看起来专业、跑起来报错、断言形同虚设的代码。解决方案不是换更贵的模型而是把项目建成 AI 能看懂的工程。二、AI 测试工程化总览五步工作流下图是我目前用的完整工作流从需求澄清到沉淀复用形成闭环这套流程的核心心法是先让 AI 反问再让它动手需求澄清避免幻觉先写失败测试再写实现TDDAI 的自愈循环才有锚点跑红绿灯自动修复autonomous run-and-fix loop人工只审关键路径把判断力用在刀刃上沉淀为 Skill下次零成本复用三、把项目建成 AI 能秒懂的工程结构很多团队用 AI 写代码效率低是因为项目本身对 AI 不友好配置散落、没有统一入口、接口契约只在某个人脑子里。下图是一个推荐的标准化工程目录结构让 AI Agent 一眼看懂项目、自动读取上下文几个关键设计原则参考图中颜色标注目录/文件作用为什么重要.claude/skills/压测/接口测试/评审等可复用技能AI 自动识别并按流程执行不用每次重新教.claude/AGENTS.md项目级入口背景、规则、默认读取顺序最重要的配置文件AI 进项目先读它docs/api-spec.md接口契约Swagger/HAR 转写杜绝 AI 编造字段prompts/templates/TDD、压测、评审等Prompt 模板模块化、可版本化、可团队共享tests/performance/baselines/历史性能基线AI 自动对比回归不再凭感觉.env.example环境变量模板不提交真实密钥安全红线AI 也必须遵守经验花 1 小时把AGENTS.md和api-spec.md写好后续每个任务的 Token 消耗和返工次数都会显著下降。这正符合Token 优化的本质——输入端把上下文准备充分比在输出端反复纠辩便宜得多。四、核心实战用 TDD 三色循环让 AI 交付可信代码这是我用 AI 写 pytest / Locust 脚本时最稳定的模式源自当前主流的 AI Coding Agent 实践Claude Code、Codex 等均已验证4.1 RED先写失败的测试禁止实现提示词骨架为 [目标函数/接口] 写测试使用 pytest / Locust。 要求 1. 只写测试不要实现函数/脚本 2. 每个测试只验证一件事命名遵循 should_X_when_Y 3. 覆盖正常路径、边界值、错误路径、鉴权失败 4. 断言要具体不要只 assert truthy 5. 跑一次确认测试是红灯确实失败关键约束明确告诉 AI “不要实现”——否则它会连函数一起写出来测试就变成了为已有实现量身定制失去发现 bug 的能力。4.2 GREEN最小实现让测试通过禁止改测试上面的测试目前失败。请用最小改动让测试通过。 约束 - 不要修改测试文件 - 不要修改断言 - 不要顺手重构无关代码 - 实现完成后跑全量测试确认全绿这就是autonomous run-and-fix loop的核心AI 自己跑、自己看失败、自己修直到绿灯。4.3 REFACTOR在绿灯保护下重构测试已全绿。请重构 [文件]提升可读性/性能/复用性。 约束 - 每次改动后必须重跑测试 - 行为不能变只改善结构 - 删除重复代码、提取公共 Fixture4.4 一个真实收益数据参考社区实践一份 30 行的 specAI 能生成 1500 行左右的测试套件。手写要 2 天AI 生成 人工 review 半天搞定且边界覆盖比手写更系统。五、AI 写压测脚本从 0 到可运行 Locust/k65.1 让 AI 先生成测试计划再写代码不要一步到位要脚本分两步Step 1 — 生成测试计划不写代码我要对 [接口/链路] 做压测。请先输出一份测试计划包含 - 测试类型冒烟/负载/压力/峰值/耐久 - 并发模型与阶段ramp-up / steady / ramp-down - 关键 SLAP95、错误率、RPS 目标 - 测试数据来源与参数化策略 - 需要监控的指标 不要写代码。Step 2 — 按计划实现基于上面的计划生成 Locust / k6 脚本 - 鉴权从 /auth/login 获取 JWT每个 VU 独立 - 成功判定HTTP 200 且业务 code 0 且关键字段存在 - 失败请求必须记录原因不要静默吞掉 - 从 fixtures/ 读取测试数据不硬编码 - 设置 thresholdsp(95)500ms、错误率0.1% - 输出 JSON summary 供 Grafana/报告使用5.2 一份可直接用的 Locust 模板AI 生成 人工微调importosimportrandomimportlocustfromlocustimportHttpUser,task,betweenimportrequestsclassOrderUser(HttpUser):wait_timebetween(1,3)defon_start(self):# 从环境变量读凭证绝不硬编码respself.client.post(/api/login,json{username:os.getenv(TEST_USERNAME),password:os.getenv(TEST_PASSWORD),},)assertresp.status_code200,f登录失败:{resp.text}self.tokenresp.json()[data][token]self.headers{Authorization:fBearer{self.token}}task(3)defcreate_order(self):payload{productId:random.choice([1001,1002,1003]),quantity:1,addressId:88,}withself.client.post(/api/order/create,jsonpayload,headersself.headers,catch_responseTrue,)asresp:ifresp.status_code!200:resp.failure(fHTTP{resp.status_code}:{resp.text})elifresp.json().get(code)!0:resp.failure(f业务失败:{resp.text})else:resp.success()5.3 用 AI 分析压测结果、自动定位瓶颈Locust / k6 跑完会产出大量 CSV/JSON。这一步让 AI 当性能分析师这是本次压测的 requests_stats.csv请 1. 计算 P50/P95/P99、平均 RPS、错误率 2. 用孤立森林/统计方法标记响应时间异常高的接口 3. 与 baselines/ 下的历史基线对比标出回归项 4. 输出 Top 3 瓶颈假设 验证建议这样就把跑压测升级成了持续性能守护——每次跑完自动对比基线、自动报警。六、Token 优化让 AI 测试工程越用越便宜很多团队用 AI 觉得烧 Token 太快本质是没做工程化。下面是四象限策略四条可执行原则输入端把接口契约、技术栈、验收标准写进docs/和prompts/templates/AI 一次读取、多次复用而不是每个任务重新解释一遍项目输出端约束输出格式“只输出代码”/“只输出 diff”/“输出 JSON 报告”禁止 AI 堆砌解释性废话上下文分层项目级AGENTS.md→ 模块级api-spec.md→ 任务级当前 Prompt按需注入不全量塞进上下文复用是真正的省钱把高频流程生成压测脚本、评审测试代码、对比性能基线固化为 Skill复用次数越多单次边际成本越低七、AI 测试工程的红线这些坑必须人工把关AI 能提效但测试工程师的判断力不可替代。这几条红线建议写进你的AGENTS.md红线风险对策AI 编造接口字段脚本跑通但测的是空气提供真实 Swagger/HAR做事实核查只断言 HTTP 200业务失败被误判成功强制校验业务 code 关键字段测试 mock 过多改坏实现也能绿灯故意改错一行实现验证测试会变红测试与实现一起飘双双偏离 spec每次改代码后 diff 检查测试文件是否被偷偷改了硬编码密钥/Token凭证泄露.env.example模板化CI 检查真实密钥过度测试维护成本爆炸删掉同行为不同写法的重复用例压测打生产事故脚本内硬编码host必须为测试域名CI 门禁特别重要的一条单元测试可以让 AI 写 90%但端到端 / 集成测试要坚持人工写 90%——因为 E2E 反映的是你们公司的真实业务流AI 不知道。八、可落地的五步实施清单如果你今天就想动手按这个顺序走建统一入口写AGENTS.md说清项目背景、目录、规则、AI 默认读取顺序整理 prompts/config把角色约束、技术栈、输出格式、模型配置放到固定位置沉淀高频 Skill选你最重复的 2~3 个流程生成压测脚本 / 生成接口测试 / 评审测试代码固化目标、步骤、禁区、交付格式拆分复杂任务按设计 → 实现 → 验证 → 沉淀切成小节点逐步交付记录效果并迭代跟踪 Token 消耗、返工次数、缺陷定位时间、复用次数用数据驱动优化九、总结回到开头那句话AI 效率的关键不是把提示词写得更长而是把上下文、流程和经验工程化。对测试开发来说这件事尤其划算——我们的工作本来就是规格驱动的。把接口契约、验收标准、测试策略、历史基线整理成 AI 能读的工程文件再配合 TDD 三色循环和 Skill 沉淀同样的模型产出质量会有质的区别。最后送一句给同样在写 pytest / Locust 的你AI 接管的是机械劳动留给你的是判断——哪些断言真正保护业务、哪些场景值得压测、哪些红线绝不能碰。这些判断全是经验性工作新人做不来AI 也替代不了。注意点用好AI工具可以大大缩短压测流程提高压测执行效率也可以快速提升自动化测试能力而非从0-1去学习某个技术栈AI时代你需要的是某一块领域的知识并且用好AI去执行一边用AI设计、执行落地一边跟着AI去学习去了解相干的技术栈或者领域知识最终成为自己的一个技能和工作流。互动话题你用 AI 写测试脚本时踩过最离谱的幻觉坑是什么欢迎评论区交流我可以帮你把常见坑整理成一份可复用的review_checklist.mdSkill。 
