听到小伙伴在定位处理一个外部故障时，我会习惯性的去打听是什么故障？是啥原因出去了？啥场景下的？啥操作触发的？以分析原因并复盘。今天也不例外，只是情绪有点波动，质疑-紧张-平和-反思。一开始小伙伴跟我提到这个故障时，我不相信，因为算是需求中的基本场景，而且很肯定的有相关的测试用例，而且好几个分支都测试过。怎么会犯这种低级错误，不允许自己这样。迅速的找到CI环境进行校验，没有问题，又找开发伙伴看抛出的异常是在代码中的位置，想从代码层出发确认场景。怀疑是前转的协议不一样，立马又确认应用的前转配置和我们的环境配置是否一致。答案：一致。下一步又去确认前转的邮箱和电话号码跟我们的一致吗？不一致，把出问题配置的邮箱和电话输入到我们自己的环境中，问题复现了。开发伙伴赶紧看电话号码判断的代码，终于找到原因了：因为应用同学输入的电话号码长度超过了最大长度限制，则触发了另外一个异常处理流程，这个异常处理抛出的日志没有进行个人信息的加密处理。
我问伙伴：这个场景能发现吗？玄，除非代码走查。但是我不甘心，我在反思怎么样才能发现这个场景？重新梳理：告警前转后，在日志中个人相关信息需要加密。前转可以是成功也可以失败；成功的场景只有一种，邮箱和电话前转成功；失败呢？邮箱服务没有配置引起的失败；邮箱链接不通的失败；电话号码正确而因信号不好前转的失败；邮箱和电话号码不存在的失败；邮箱和电话号码不符合标准的失败（即不符合国际标准）。再针对种失败进行实例化，例如邮箱和电话号码不符合标准的失败，那就配置不符合标准的邮箱和电话号码，那标准的格式，长度限制是多少？这样通过等价类设计出测试条件。或者从另外一个角度出发：涉及前转，前转需要输入前转的邮箱和电话号码，它作为入参，输入参数可以作为一个单功能进行测试分析和设计，采用等价类和边界进行分析和设计，识别有效等价类和无效等价类，这样也会挖出这个场景。
多问，多沟通，锻炼逻辑听力，提取信息和组织信息的能力，多探索。不要惧怕紧张自己未测试出的故障，因为它会是个礼物，需要我去拆，去探索。
