企业官网建设流程全解析

AI生成测试脚本的验证方法

AI输出脚本不等于可用脚本，核心目标：语法能跑、逻辑符合需求、边界场景不漏、没有隐性bug、可维护、符合工程规范，不能只看“运行不报错”。下面分静态审查→单步调试→功能验证→异常&边界→工程质量→落地集成→回归复核7个环节，每一步给出可落地检查点，可直接做成Checklist用于团队审核AI产出脚本。

适用范围：Python+pytest/Playwright/JMeter接口脚本、HAR转脚本、自动化用例、SSE流式脚本等AI生成产物

一、静态代码审查（不运行，先读代码，最快筛掉低级错误）

1.需求与用例对齐（最容易被AI幻觉带偏）

1. 核对脚本业务逻辑是否和原始需求/测试用例完全匹配：有没有AI脑补额外步骤、遗漏前置后置、篡改参数、私自修改断言条件
2. 检查用例覆盖：主流程、分支场景是否齐全；AI经常只写正向流程，跳过异常、边界、反向场景
3. 断言校验（AI高频坑）
   • ❌坏例子：只判断接口返回码200，不校验业务字段；assert response.status_code ==200就结束
   • ✅好例子：状态码+业务返回码+关键字段值+数据一致性校验
   • 禁止硬写死动态变化值（时间戳、id、token、随机字段）直接断言相等
4. 前置/后置条件：环境准备、数据构造、数据清理是否齐全；AI经常忘记清理测试数据，造成脏数据污染环境

2.语法与依赖检查

1. 导入包：是否存在未安装的库、导入不存在函数、废弃API（Playwright旧接口、pytest废弃方法）
2. 变量命名：变量名是否合理，有无魔法数字、硬编码域名、账号密码直接写死在脚本里
3. 硬编码风险：账号、token、数据库地址、密钥写死代码，必须抽配置/环境变量
4. 语法缺陷：缩进错误、括号不匹配、函数参数数量不对，复制直接跑直接报错

3.逻辑漏洞静态排查

1. 等待逻辑：UI自动化是否存在硬编码time.sleep()滥用；有没有使用智能等待；AI特别喜欢大量sleep，脚本不稳定
2. 循环/分支：if/else逻辑是否写反，循环终止条件会不会死循环
3. 异常捕获：try‑except是否吞掉异常（裸except，捕获所有异常不抛出，脚本显示pass实际业务失败）

AI常见坑：try:... except: pass，报错直接静默，测试结果完全失真。

二、最小可运行单元调试（单脚本隔离执行）

不要一次性跑全套，优先单用例执行

1. 环境对齐：脚本依赖的环境、数据库、测试账号、网络代理是否和脚本预期一致，排除环境问题干扰脚本正确性
2. 分步执行：断点调试，逐行跑，打印关键入参、出参
   • 请求的真实request payload、header是不是和预期一致
   • 拿到的response原始报文和AI注释写的是否一致（AI幻觉：注释写A，实际代码传B）
3. 区分两类失败：
   • 脚本本身bug：语法、调用错误 → 修改脚本
   • 业务系统bug：脚本逻辑正确，被测系统返回错误 → 提缺陷

重点警惕：脚本跑通，但请求参数就传错了，只是接口返回200，业务逻辑完全没测到，这是AI脚本最高发问题。

三、业务功能正确性验证

1. 正向场景：执行脚本后，核对系统实际状态，不能只看脚本断言

例：创建订单接口脚本返回成功，要登录后台确认订单真实生成，而不是仅看response返回成功。AI只校验返回报文，忽略数据库/页面真实状态。

2. 参数校验：把脚本中入参手动修改，验证脚本是否按预期校验；确认传参顺序、json字段key大小写、数组格式是否正确。
3. 流程连贯性：多步骤脚本，步骤之间数据传递是否正确；上一步输出的id/token能否正确传给下一步；AI经常写死中间变量，步骤之间没有数据传递。

四、异常、边界、稳定性校验（AI最容易缺失）

1. 异常用例：AI大多只生成正向脚本，需要手动构造异常输入跑脚本，看脚本是否能正确捕获失败
2. 容错性：网络抖动、接口超时，脚本是否有合理超时配置，会不会无限阻塞
3. 重复执行：同一脚本连续跑3‑5次
   • 是否出现偶现失败；是否产生重复脏数据；是否缺少清理逻辑
   • UI脚本：元素动态id、弹窗、浮层是否导致偶现失败
4. 并发：如果是接口脚本，简单多线程运行，观察变量是否存在全局变量污染问题。

五、工程质量&可维护性校验（决定脚本能不能进CI流水线）

1. 可读性：注释是否和代码一致，AI经常写虚假注释；函数职责单一，不要一个函数干十件事
2. 可配置：环境地址、账号、超时时间抽离配置文件，不写死代码内
3. 日志输出：关键步骤打印日志，失败时输出请求/响应详情，方便排查；AI脚本普遍日志缺失
4. 清理机制：测试完成后数据回滚、删除测试数据；不能在测试环境遗留大量垃圾数据
5. 兼容CI：脚本是否支持无界面运行，不依赖本地浏览器窗口；是否支持pytest参数化，可接入流水线；不依赖本地人工操作。
6. 错误报告：失败后，报错信息是否能定位问题，而不是只抛出笼统异常。

六、集成验证：放到真实流水线场景测试

1. 本地验证通过后，放到CI/CD环境执行，隔离本地环境差异
2. 校验执行结果：脚本pass/fail结果是否和实际业务表现完全匹配

高危现象：业务实际失败，脚本报告pass（假阳性，AI脚本头号杀手）；
业务成功，脚本报fail（假阴性，断言写死）

3. 参数化场景：多组测试数据传入，验证脚本对不同输入的处理。

七、复核AI特有风险：幻觉专项检查

AI脚本独有的问题，普通代码审查容易漏掉：

1. 调用不存在接口、不存在字段、错误的接口路径；AI会编造接口
2. 参考旧版本API文档，使用已经下线的接口字段
3. 复制粘贴逻辑：A用例的逻辑直接复制到B用例，忘记修改参数，逻辑完全错位
4. 注释和代码行为不一致，注释写一套，代码写另一套

快速判别AI脚本是否“有毒”的几个信号

• 大量time.sleep硬等待
• 只有status_code==200断言，没有业务断言
• 裸except: pass吞异常
• 密钥、账号明文硬编码
• 注释描述和实际代码行为不一样
• 多步骤脚本，中间id全部硬编码
• 只能跑一次，第二次运行直接报错

可直接落地的简短Checklist模板

补充：如果脚本校验发现问题，怎么反向给AI提示词修正

不要直接说“脚本不对”，把发现的问题具体化丢回AI：

脚本问题：
1.只校验200状态码，缺少业务返回码断言；
2.大量time.sleep硬等待；
3.没有测试数据清理逻辑；
4.步骤2直接硬编码order_id，没有复用步骤1返回值。
请基于原始用例修复以上问题，输出最终脚本。