07 · 测试 · 早高峰
三十家店同时下单，最慢的那撮和压完后的膨胀都要看见
性能测试工程师按早高峰验证变慢发生在哪、最慢的一小撮有多慢、压完会不会留下膨胀。账会不会记两笔，交给后端用证据证明。
性能测试工程师用业务高峰，不用空转的数字
他要的场景来自现场：周一早高峰三十家店在十分钟内提交订货。岗位特点是同时看响应时间、错误率和最慢的一小撮请求。只看平均耗时，会把高峰里那批连点的人藏掉。数据量要接近上线后三个月，而不是十张单据的空库。空库上的索引一切都快。他和数据库工程师确认慢的语句是哪一条，是锁等待还是缺索引。测试报告写出瓶颈、并发数、p99 和压完之后同样查询是否恢复。
怎样加压才像人
脚本按真实比例混合：大部分是查询待提交订货，小部分是提交，偶尔有重复提交。全部做成提交，会得到一个现场不会出现的数字，也会把队列打满后误判系统不行。思考时间和点按间隔写进场景。他把超时后的客户端一次重试也算进模型，因为手机真的会重试。重试密度按真实客户端写明，过密结论偏悲观，完全不重试结论偏乐观。
三十店同时下单
订货截单前的十分钟，历史峰值大约三十家店。性能测试在预发按这个峰值的两倍跑。平均时间可接受，p99 到了三秒。报告把最慢那撮请求单独列出，并写清是锁等待。若压测中出现同一门店两张草稿，他记一行「正确性嫌疑」，交给后端用请求号证明，不把「没有双草稿」写成性能测试自己的通过条件。本岗通过条件是：高峰形状、最慢一撮、压完后空载是否恢复。只写每秒事务数的报告，他不签名。
压测前他把单据量补到上线后三个月的水平，再清掉本次产生的订单。不清理会把下一次压测建立在更脏的数据上。高峰之后他把系统恢复到空载，再看一次同样的查询。恢复后仍慢，说明压测留下了膨胀的表或索引问题，不是现场并发。把膨胀当成并发，会错误地要求加机器；把并发当成膨胀，会在下个高峰再被同一条语句拖死。报告里两种结论不能写在一起混用。
一次压测后平均耗时仍漂亮，空载查询却比压前慢了四倍。原因是订货表上的统计信息没更新，优化器选了全表。他在报告里把这行写成膨胀，并要求发布窗口带上收集统计的步骤。如果当时写成「需要加机器」，下一周会买来用不上的容量，高峰仍被同一条语句拖死。脚本的思考时间按店长真实点按间隔写，不按压测工具默认值。默认值过密，会把一个从不会发生的队列打满，然后误判系统不行。压测账号不得拥有生产权限。预发的门店主数据按峰值店复制，不拿演示店的十张单去代表三十家店。报告附件给出最慢那撮的语句和锁等待图，没有图的 p99 他当没测过。压测窗口不得和发布窗口重叠。重叠时变慢分不清是候选还是数据量。他要求发布经理把这两个窗口写在同一张日历上，错开至少一天。