速查表：AI 辅助测试与压测清单
六组清单，覆盖从单测到容量结论的全流程。每条一句话，压测前逐项打勾；任何一项没做到，后面的结论都要打折。
单测与用例
| 检查项 | 要点 |
|---|
| 明确 AI 的能力边界 | 让它写用例与桩很快，让它判断「测什么」需要你先给出验收标准；不可验证的需求交不出可验证的用例 |
| 用例写成表驱动 | 输入、期望输出、期望错误写成数据表，AI 补齐边界值、空值、超长值与错误路径比补正常路径更有价值 |
| 桩与假实现要能失败 | 替身（stub/fake）必须支持返回错误、超时与延迟，只返回成功值的桩会制造假绿灯 |
| 依赖隔离到接口 | 用接口替身隔离数据库、缓存与下游，替身行为要与真实实现的关键语义一致 |
| 从需求生成用例 | 把需求与接口文档交给 AI 后，逐条对照验收标准，检查是否覆盖异常分支与并发场景 |
| 断言而非调用 | 覆盖率（coverage）不等于有效性，识别「调用了但没断言」的无效测试 |
| 复现缺陷先要最小输入 | 把完整异常栈、版本与最小输入一起给 AI，从报错推到最小复现，而不是直接让它猜修复方案 |
| 回归用例固化 | 每个已修缺陷都补一条能复现的用例，防止同一处二次回归 |
集成与数据
| 检查项 | 要点 |
|---|
| 数据与夹具可复现 | 测试数据用脚本或夹具（fixture）生成，禁止手工在库里改数据后跑测试 |
| 集成范围有取舍 | 数据库与核心中间件用真实实例跑，第三方服务用契约测试或录播，避免全真导致的脆弱与缓慢 |
| 数据分布贴近生产 | 造数要覆盖冷热数据、稀疏与密集键、超长字段，而不是清一色理想值 |
| 清理与幂等 | 每个用例自己负责数据清理，用例可重复执行且并行安全 |
| 时间与随机源可控 | 时间、随机数、自增 ID 注入可替换实现，否则用例会随机失败 |
| 外部依赖有超时与降级路径 | 集成测试里也要覆盖下游超时、重试与降级，这类分支线上最容易出问题 |
| 环境用容器编排 | 用容器或 Compose 一键起依赖，版本写入配置，避免「我这能跑」 |
| 集成测试分层标记 | 慢的集成测试与快单测分开标记，保证日常反馈速度 |
压测准备
| 检查项 | 要点 |
|---|
| 指标口径先对齐 | 明确 QPS 统计位置（网关/应用）、延迟起点终点、错误率分母，口径不同数字不可比 |
| 验收标准可判定 | 写成「峰值 6000 QPS 下 P99 ≤ 100ms、错误率 < 0.1%」这类可判真假的句子 |
| 工具按协议选 | HTTP 短连接用 wrk/wrk2，脚本化场景用 k6，gRPC 用 ghz，长连接自研或专用工具 |
| 核对生成脚本的参数 | AI 给出的参数一律用 <工具> --help 核对，幻觉参数（hallucinated flag）必须先排除 |
| 环境对齐清单 | 实例规格、启动参数、日志级别、鉴权开关、超时重试、连接池、中间件拓扑逐项对齐生产 |
| 数据量与分布 | 数据量按生产规模准备，参数按生产分布随机化，避免全打同一行造成人为热点 |
| 压测机不能成为瓶颈 | 压测机核数与网卡不低于被测服务，检查客户端 CPU、软中断与端口耗尽 |
| 预热与缓存状态固定 | 预热时长、缓存命中率、冷热两轮策略写进方案，预热数据不计入统计 |
| 限流熔断阈值确认 | 记录网关限流阈值与熔断配置，必要时临时放宽并注明改动 |
| 采集清单就位 | 压测期间要采的应用、系统、中间件指标与剖析入口提前列好并验证可用 |
压测执行
| 检查项 | 要点 |
|---|
| 场景类型分开跑 | 基准、负载、压力、稳定性、尖峰五类场景目的不同，不要混在一次压测里 |
| 档位至少三档 | 单档看不出趋势，档位要覆盖拐点前后，才能定位拐点位置 |
| 单档时长足够 | 每档稳定运行 300s 以上，短压容易把噪声当拐点 |
| 一次只改一个变量 | 同时改连接池与序列化实现，结果无法归因 |
| 长连接单独测 | 连接数与消息吞吐（throughput）分开压，连接建立与保活的开销要单独观察 |
| 稳定性测试拉长时长 | 至少 2 小时，重点看内存、句柄、goroutine 数是否单调上涨 |
| 错误码分布全程采集 | 每档都记录错误码与占比，非零错误率的档位不能作为容量依据 |
| 压测机水位同步监控 | 每档记录压测机 CPU、网卡与连接数，客户端饱和即结果作废 |
| 观察熔断与限流状态 | 压测期间记录熔断器状态与限流命中数，快速失败会伪装成低延迟 |
| 保留原始输出 | 工具的完整输出、监控截图与采集命令一并归档，便于复盘与对比 |
结果分析
| 检查项 | 要点 |
|---|
| 找吞吐延迟曲线的拐点 | 再增负载吞吐不涨而延迟抬头即为拐点（knee），拐点左侧才是可用区间 |
| 平均值与分位一起看 | 平均值正常而 P99 异常说明长尾；两者相差超过 3 倍必须单独解释 |
| 识别队列堆积指纹 | 吞吐停滞而延迟随并发近似线性上升，按利特尔法则（Little's Law）算在途请求是否数量级跳变 |
| 用系统指标做旁证 | GC 占用、上下文切换（context switch）、系统态 CPU、load 用来区分「算力不足」与「排队」 |
| 三条证据链交叉验证 | 指标定层级、日志定环节、剖析（pprof）定代码行，三者对齐才算定位完成 |
| 先写预期再采集 | 产出「假设 → 证据 → 采集命令 → 预期观测」表，先写下预期才不会顺着结论找数据 |
| 用剖析落到代码行 | go tool pprof 的 top -cum 找调用链上游，再 list <函数> 定位到行 |
| 结论按三段式写 | 每条结论都写「结论 / 证据 / 反例」，写不出反例说明只是在复述数字 |
| 排查顺序先便宜后昂贵 | 先看指标与日志抽样，再上剖析；剖析有开销，压测中控制采样时长 |
报告与容量
| 检查项 | 要点 |
|---|
| 报告按八节骨架写 | 结论摘要、环境、场景与参数、结果数据、瓶颈定位、容量结论、风险与建议、附录 |
| 区分观测与推断 | 观测事实引用原始数据行，推断标注依据，缺数据的地方写「未采集」 |
| 容量结论五步算 | 延迟约束 → 拐点位置 → 安全水位（拐点左侧下浮）→ 实例数 → 冗余比例 |
| 容量与约束成对出现 | 写成「单实例 1200 QPS（P99 ≤ 100ms）、峰值 6000 QPS 需 7 台并留 30% 冗余」，不出现孤立 QPS |
| 峰值不等于容量 | 伴随错误率与长尾的峰值吞吐不能当容量依据，安全容量要留抖动空间 |
| 不确定性写成条件 | 写「数据量超过 2000 万行需重压」，而不是「结论仅供参考」 |
| 附录可复现 | 附原始输出文件、采集时间与命令，环境参数完整到别人能照抄 |
| 优化建议分两类 | 分开写扩容能解决的与改代码能解决的，避免用加机器掩盖代码缺陷 |
| 让 AI 反向校验 | 把报告交回 AI，要求列出缺乏数据支撑的结论，再补齐数据 |
| 横向对比留基线 | 保存历史压测数据与本次对比，判断优化是否让拐点右移而不只是峰值变高 |
小结：单测与用例保证「测的是真东西」，集成与数据保证「环境像生产」，压测准备保证「口径与条件对齐」，压测执行保证「过程可控且证据完整」，结果分析用拐点、分位与三条证据链得出可证伪的结论，报告与容量把结论落到延迟约束、实例数与冗余比例上。