上线前要过的测试不用多，三组。三组分别对应三类事故：答错、接不住、断线。每组都要有写死的通过标准，否则测完只是跑了一遍流程，谁也不敢说可以放量。[外链图片转存中…(img-jscSpNRn-1791594241511)]## 三组测试各防什么**边界测试防答错。**不确定的问题被硬答，比不答更伤——买家会把机器编的内容当成店铺承诺。边界测试专门喂那些「词表答不了」的问题，看它会不会硬撑。**压力测试防接不住。**消息一多就重复、就漏、就排队，是自动回复上线后最常见的翻车方式。压力测试要测的不是极限值，而是「日常峰值的三倍进来时，它还稳不稳」。**异常测试防断线。网络断、进程停、员工权限被撤、额度用完，这些都不常发生，一旦发生就是静默失效：没人知道自动回复已经停了，买家等了一整天。三组测试可以在一到两天内跑完，顺序按上面的排：先保证答得对，再看接不接得住，最后看摔了之后能不能爬起来。## 头一组，边界测试：问不确定的问题测哪几种问法。**库外的问题（「个人能不能开专票」）、不能承诺的（「吃了能调理好吗」）、模糊的（「那个多少钱」）、带情绪的（「你们就是骗人的」）、一次连问好几件的。**用例从哪来。**从现有条目的边缘挑，每条准备五种绕开词表的问法；再从前一个月转人工最多的咨询里抄五个。用例不用多，二三十条就够，但要覆盖「词表答不上」这一类。**通过标准。**不确定就说不确定，不许硬答；每种情况都有下一步动作，追问、给入口或者转人工；话术里不出现承诺、功效、把话说满的表述；连问多条时按顺序回应，不丢问题。**跑完做两件事。把不合格的用例记回词表，改完重跑一遍；把用例、预期、实际、判定、责任人填成一张五列的表，留档。## 第二组，压力测试：连发与并发测哪几种场景。**同一个买家连发五条；十个客户在同一分钟内进线；客户群里短时间多人提问；活动开始后的集中进线。**怎么造压力。**用内部号模拟，分三档加量：单人连发、十人同时、群内连续提问。每档跑十分钟，记录触发次数、发送次数、转人工数、平均响应时长四项。**通过标准。**不重复发送，一条事件对应一条回复；不漏答，连发的每条消息都有回应或明确的合并说明；响应时长不随人数线性拉长到不可用；转人工不出现排长队；进程与账号状态保持在线。任何一项不达标，先降规则复杂度或加限流，别靠「再跑一遍试试」。**测完对账。触发日志、发送日志、排队记录三者要能对上；对不上的地方，就是上线后查不到问题的原因。## 第三组，异常测试：网络断与权限撤断网重连。**断开十分钟再恢复：恢复后不重复发、不补发一串过期的回复，未送达的消息有交代。**进程重启。**中途重启一次：规则配置还在、去重状态不清空、正在处理的消息有结果，而不是凭空消失。**权限撤销。**把员工从企业微信里移除、把第三方应用的权限收回：自动回复要么干净停下，要么转给接手人，不能继续以离职人员的身份发消息。**额度与服务到期。**把额度调到只剩一点，看有没有提醒；订阅快到期时，提前几天该有人收到通知。**通过标准。**每种异常都能触发告警，至少有一个通知渠道真的收到；恢复后状态一致，不重复、不静默丢失；三类异常各跑一遍，记下处理人和处理时长。三组都过了再放量，头一天先灰度：只对一小部分新客户生效，盯住命中率、转人工率、重复与漏答四条，稳定之后再全量开。测试花的是一两天，换回来的是异常发生时手里有数、心里不慌。## 参考文章- 自动回复上线前的验收测试清单- 自动回复漏答消息怎么补救