佛教的信徒表示抵制 ant design

内部平台用的 ant design 旧版 没影响 路过

vue 信徒飘过~

线上最好是用指定版本，而不是最新版本，你永不知道下个版本会发生什么坑爹的事情。。。

好精彩好精彩，我就看到了远离阿里开源这一句话，哈哈哈

你想埋我一个彩蛋给我，我踩到的是一颗炸弹。。。

这次虽然是彩蛋，其实也带来了一个对测试和 QA 很严重的挑战，“开发者往代码里下毒如何办？”

问题描述

无论是处于好心的彩蛋，还是恶意的留后门，或者是无意间留下的 bug，都会给人类埋下一枚巨大的地雷。这类的问题其实在质量的历史上曾经出现过很多次类似的问题，千年虫、int 类型溢出、md5 碰撞等问题，基本上阿里、腾讯、百度、京东等大大小小的公司的公司都经历过。这类 bug 的特征就是，在时间、环境、数据量变化的前提下会一定概率发生错乱，与其上考验的是测试能力，还不如说考验的是开发者架构能力。

我先抛出几个类似的历史上的严重质量威胁给大家做个参考，因为一时找不到对应的新闻和源代码分析了，所以就简单记录下大概的事情。后面再补充完善细节。

常见的类似问题

• 千年虫问题（暴露年龄了。。。）
• Linux 源代码后门提交问题，有不明身份的人伪装开发者提交一段暗藏后门的代码给 linux，结果被发现。
• mac 后门问题，开发者写错了一个符号， 把==写成了=，或者 if else 里少写了{}导致分支走向错误。
• vue 依赖的组件后门事件，不明组织社工开源开发者，窃取帐号后故意在升级中加入挖矿或窃取比特币的逻辑
• int 类型溢出，当公司的业务量上升后，会超过 int 类型可以表达的范围出错，这个问题几乎 BAT 都被坑过
• MD5 碰撞问题，因为 hash 算法设计问题导致会有一定概率重复，导致账号和订单可能会存在串号和信息读取错误等。

解决思路

我提几个预防这类问题的方法

对 changelog 和 diff 做 code review

这是个常规的办法，不过考虑到全世界人类使用的开源项目和 lib 数量已经超百万级别，我觉得靠人已经没办法做到了。只能挑重点的项目，以及依赖开源项目自己完善的管理。当年就有黑客伪装开发者提 merge request 给 linux 项目想暴露一个后门，幸好被 linux 开源项目组的人发现并禁止了。如果没有 review 机制，大家可以想象有多可怕，全世界的服务器都可能会被不明组织入侵。而 vue 依赖的组件后门事件则没这么幸运了，导致了爆发

关注未被覆盖的代码覆盖率和特性

这个是更有效的发现方法，为什么这么说那。大家知道每家公司的工程师都喜欢在自己的 app 里保留一个调试的后门页面。如果有的时候配置错了就会暴露，比如淘宝和微博就暴露过。这说明了什么那，在正常的功能之外还故意隐藏了一些后门，这些后门的代码其实就隐藏在 app 中，只是大家常规情况下看不到，只要触发了特定的条件就会出现。这既可能是特型开关，也可能是无意留下的开启地狱之门的钥匙。借助于对代码做模型分析和代码路径统计，其实就可以找出来所有隐藏的功能。

源代码智能分析

学术界和黑客界也有一些不错的工具在批量分析开源项目的各种代码分支和数据流走向，尝试发现一些异常问题，我在百度的时候也遇到有项目组在研究这个。大概的做法就是分析所有的代码可能走向，可以是静态代码分析也可能是动态调试技术。尝试分析所有的可能路径，然后判断什么样的输入会带来什么样的问题。这个比较学术，难度挺高。工业界还没有大规模应用，sonarqube 只是一个通用的规则列表，发现的问题还达不到这个深度。不过的确也是一个方向，可能自动发现很多代码问题。也许 sonarqube 可能会越来越能接近这个目标。

人类社会的发展是要重度依赖计算机的，而计算的正确性如何保证是一个任重道远的事情。如何提前发现这类的问题那，欢迎测试行业的同学们多积极的思考。

“” 这是个常规的办法，不过考虑到全世界人类使用的开眼项目” boss，有个错别字，开源项目

对做政企的公司来说，领导估计把引进这个开源的开发宰了的心都有了。。。

以前也遇到过只有特定时间才出发的 bug，天可怜见，我竟然测试出来了

现在洗地的太多了，看着就恶心，什么没人逼着你用呀，用开源项目你不看源代码的吗等等

严格的需求管理和代码审查是必要的。之前工作中听过一个真实的事情，之前同事的同学做过的一个事。他在项目代码中的一个正常逻辑不可能执行到的判定逻辑写了行：“如果看到这行内容就说明你见鬼了”。之后很久也没什么事，偶然一天半夜雷雨跳闸重启，显示屏跳出了这行文本，结果把保安吓得不轻。

开发人员头脑一热写的无厘头彩蛋还是得代码提交审查来控制。还有一类之前见过的就是往 debug 版本 app 中加开发人员名单/合照的菜单，见过三次。