先测任务正确性
按业务动作拆分用例：抽取、分类、生成、多轮追问。每类给出期望输出与可接受差异，用双人盲评减少主观偏差。正确率之外还要记录错误类型分布，才能判断是提示词问题还是模型能力不足，避免一有问题就换模型。
再测结构化稳定性
需要写库的场景，必须统计字段齐全率、类型合法率与解析失败数。建议连续跑上千次同一批用例，观察波动区间，而不是只看一次是否通过，否则上线后偶发失败很难向业务解释，也难以判断是否需要加固。
压测看并发与延迟
按预估峰值的半数、峰值与一倍半做三级梯度，记录吞吐、首字延迟与 P95 完成时间。队列积压与超时重试要单独统计，它们决定高峰期用户的实际感受，也决定是否需要限流与排队策略，不能只看平均延迟。
安全与兜底不可省
用例应包含提示注入、越权索取、敏感信息泄露与超长输入。同时验证模型不可用时的降级路径：是否有兜底话术、是否转人工、是否留痕，这些在真故障时决定业务能否继续运转，而不只是应付合规材料。
报告要能复现
测试报告要附原始数据、脚本版本与用例清单，注明测试环境与模型版本。性能结论以客户环境实测并由双方签认为准，我方不承诺固定性能数值，避免验收标准与实测脱节后产生争议，也便于后续复测对比。
适用与不适用
适合谁
- 准备上线、需要向业务方证明可用性的团队
- 多家供应商对比、要求同口径测试的采购方
- 已有系统要接入模型、需评估承载能力的企业
不适合谁
- 没有真实样本、只能用公开数据测试的项目
- 要求供应商承诺固定性能数字的招标场景
典型场景
某银行运营部门在智能工单分类上线前组织验收。技术组准备八百条历史工单作为评测集，先测分类准确率与字段解析率，再按峰值三级梯度压测，最后注入越权与超长输入用例。测试报告由运营、技术与合规三方签认后才进入灰度，未通过项另附整改计划与复测时间。
可执行步骤
- 与业务方确认验收指标、可接受区间与判定责任人，并把口径写入验收方案
- 抽取真实样本组成评测集，完成标注后冻结版本号与样本清单，全程留档
- 跑正确性与结构化稳定性测试，按错误类型归类统计并保留原始输入输出
- 按三级并发梯度压测，记录延迟、超时、队列积压与重试次数随时间的变化
- 完成安全用例与降级演练，出具报告并组织业务、技术、合规三方签认归档
常见坑
- 用演示数据代替真实样本，准确率虚高，上线后落差明显，返工压力全部集中在项目后期，上线后才集中暴露。
- 只压单轮短请求，长上下文与多轮场景下延迟成倍上升，容量规划随之失真，整改往往来不及，问题集中爆发。
- 没测降级路径，模型限流时业务无提示、无转人工入口，用户在高峰时段直接流失，用户等待成本很高。
- 报告只写结论不附原始数据，出现争议时无法复现，也无法定位到具体责任环节，整改就缺少依据。
- 压测在业务高峰进行，既影响正常服务又污染测试结果，数据事后无法采用，结论也缺乏可信度，难以复盘。
自检与验收清单
- 验收指标是否与业务方书面确认并写明判定人
- 评测集是否覆盖真实样本与边界样本并冻结版本
- 是否记录结构化解析失败明细与典型样例，是否有记录
- 压测是否覆盖长上下文、多轮与高峰时段，是否覆盖多轮
- 降级与转人工路径是否实际演练并记录耗时，是否计时
常见问题
压测要用生产流量吗？
优先用脱敏后的生产样本回放，更接近真实分布；没有条件时用构造样本，但要说明局限。在生产环境压测需选业务低峰并获批准，避免影响正常服务，也避免测试结果被限流干扰。
准确率达到多少算通过？
没有通用阈值，应由业务方按错误代价确定。对外服务类场景通常要求更高，内部辅助类可以放宽，但都要配合人工接管机制，不必照搬同行标准，关键是错误发生时有人能兜住。
供应商提供的测试报告能直接用吗？
可以作为参考，但不能替代客户环境验收。硬件、网络、模型版本与并发模型都会影响结果，建议在目标环境复测关键项后再签认，差异部分要求供应商书面说明原因，作为后续整改与付款的依据。