在之前的系列，我们分享过Bug的由来，和Bug相似的一些近亲概念，还分享过一个有意思的经典Bug，本篇再分享一个也很典型，同时也是笔者亲身经历过的典型Bug。

奇怪的页面崩溃

笔者曾经测试过一个有关进出口贸易Web应用，有一个页面是显示贸易对象信息，类似下图

然后有一个辅助功能，是可以根据对方的贸易国不同将交易信息导出为符合对应国别要求的标准格式文档（当然大部分国家的格式其实是一样的）。

这个功能在测试阶段未发现问题。

但是在交付给用户使用后，在某个用户那里，一旦触发这个导出操作，则间或会出现页面崩溃的严重问题。

问题定位

在收到数次这个反馈后，发现这个用户在出现崩溃的情况时，无一例外，都是对方的交易国家是挪威，而对应这个国家其实导出的文档也是标准文档。所以并不是导出的文档格式问题

在分析这个功能的实现逻辑后，终于发现了问题的症结所在。

这个导出功能，对于文档格式的匹配是定义在一个YAML配置文件中的，而国别的识别，在YAML中是通过国家码来进行配置的。而挪威的国家码对应的是NO

类似：

1
2
3
4
config:
 - filetype: pdf
 - profile: standard
 - country: NO

根据YAML V1.1标准配置中的定义（https://yaml.org/type/bool.html）：

NO在经过代码转义后，会被处理为bool型值False，而程序在这里缺乏配置校验和处理异常保护，导致在读取国家码时出现异常，引发页面崩溃。

所以原因总结起来包括：

YAML配置文件：国家码配置，默认当作字符型处理，未考虑到NO这种特殊情况，没有添加字符引号标记。
程序处理，缺乏对YAML配置值正确性的校验
异常保护不足，发生异常时直接导致页面崩溃

问题修正

找到原因，那么修复其实很简单，对于国家码，强制转换为字符型后在处理，并添加有效性校验和异常保护代码即可。当然对于容易引起歧义的YAML配置，也增加了字符串引号引用。

1
2
3
4
config:
 - filetype: pdf
 - profile: standard
 - country: "NO"

思考

其实不止国家码，在字符类型的字段中，如果使用其他一些有特殊含义的字符，比如“Yes”, “null"等，也同样会造成类似问题。

因此，对于我们测试来说，测试时的数据处理验证，特别是类似的特殊字符处理，一定要考虑到相关场景，否则就很容易造成类似严重问题的遗漏。

趣谈Bug - 500英里邮件

继续和大家分享历史上的经典Bug。

这个Bug也比较离奇：

故事发生在2002年，这天，麻省理工（MIT）统计系的主任找到校园邮件系统的负责人Trey Harris，跟他抱怨一个比较离奇的问题：“咱们的邮件发不到500英里以外的地方，其实，是520英里更准确点”。管理员内心：^&^(&………&))(&^% 但不管怎么不相信，但还是亲自用自己的邮箱进行了测试。结果居然是真的！确实如报告一样，邮件只能发送到520英里以内的地方，范围之外的邮件一律发送失败。

经过一番排查，终于搞清了原委。

原来不久之前，邮件服务器的操作系统刚刚进行了版本更新（当年还是SunOS），而当时的操作系统发行版，通常会附带一些附件软件，但这些软件的版本往往比较旧（好比更新Linux，自带的Python版本一般都不是最新的）。因此更新完系统后，他们使用的邮件软件 SendMail 版本被降级了（SendMail 8 -> SendMail 5）

而更新系统，还同时保留了SendMail的配置文件sendmail.cfg，因此就出现了下面的情况：SendMail 5 会解析SendMail 8 的配置文件。

因为 sendmail.cfg中存在一个 SendMail 5不支持的配置项 timeout to connect to the remote SMTP server，即连接远端SMTP Server的超时时间, 对于这个不支持的配置，在 SendMail 5 中被直接忽略，并按默认值0处理。而后来经过试验，0秒的timeout会导致Sendmail在3毫秒后中断连接。

所以为什么是 500 英里呢？

当年，MIT的校园网络中还没有那么多路由，因此网络延时很少，也就是连接一个远端主机的时间，大概接近光速。于是，3毫秒就意味着：

0.003 * 3 * 10 ^ 8 * 0.001 * 0.621 = 558.9

考虑到很少的网络延迟，因此就出现了这个 500 英里的问题。