测试结论从什么结果开始
数据量翻倍后，性能验收需要重做吗？首先需要把“新规模下指标和资源预算明确”写成可判定的结果。这里讨论的是企业客户与订单增长，一个需要验证的风险是仅在小样本上形成性能结论。仅看到页面操作顺利还不够，测试记录必须能说明业务结果是否真实发生，以及失败时是否留下了不该产生的影响。
性能问题要把等待拆成网络、处理、排队和外部依赖。平均耗时会掩盖少量非常慢的请求，样本还应覆盖忙时和较大数据量。
复现时保留哪些证据
本题需要保存数据规模、索引及主要查询分布。把一次正常操作和一次异常操作放在相同版本、相同环境下比较，记录输入、操作时点及实际结果；敏感值可以替换，但触发问题的字段关系不能删掉。若无法重新出现“仅在小样本上形成性能结论”对应的差异，先补足样本，暂不把猜测写成已确认根因。
先在可控环境记录基线，再只改变一个条件；比较相同操作的耗时分布、错误数量和资源使用，不只比较首页打开速度。
执行三个针对性检查
第一项是准备代表性规模，将判定口径写清楚后执行。第二项是复测核心操作，同时保存数据规模、索引及主要查询分布中的相关记录。第三项是约定扩容触发点，对照“新规模下指标和资源预算明确”逐条确认。三个检查应分别记录结果，这样失败时可以知道问题出在输入、处理中还是结果核对，避免一次修改多个环节后失去判断依据。
用边界例子发现遗漏
数据规模样本要保留真实分布。全部订单都一样会遗漏复杂筛选、热点数据与长期历史查询问题。
例如：半年后订单量翻倍查询超时。这个例子不是客户项目事实，而是用于测试企业客户与订单增长的样本设计。先写下按业务规则应该发生什么，再执行并比较；不能用程序当前表现反过来定义正确结果。修复后还要重跑原样本，并检查附近的合法操作仍然可用。
压测需要限定并发和停止条件。生产系统没有授权或恢复准备时，先使用隔离环境和脱敏数据复现。
怎样算验收通过
验收应能够证明：新规模下指标和资源预算明确。结果附上环境、版本、样本和记录位置；异常提示、持久化结果与相关后续动作应互相一致。若“半年后订单量翻倍查询超时”仍能触发错误，就应列为未解决事项，并说明影响范围。测试通过不代表以后永不出错，后续变更至少保留这一问题的回归样本。
执行与验收清单
- 明确企业客户与订单增长的正确结果：新规模下指标和资源预算明确。
- 准备并脱敏核对资料：数据规模、索引及主要查询分布。
- 执行准备代表性规模，保留对应结果。
- 完成复测核心操作与约定扩容触发点，核对实际产物。
- 使用“半年后订单量翻倍查询超时”复查问题，并记录未解决事项。