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