软件测试 印象比较深的项目,面试题：你工作中碰到的印象比较深的 bug，你怎么处理的？...

我没太弄清楚面试官想得到什么答案，他的意思是你没起到多少作用，但是你不是说把问题原因定位到了么。 难道他想你直接改 bug 么哈哈哈。 可能你这个问题比较简单吧，所以面试官不以为然。 一般回答这种问题都是往高逼格上回答。 就找你印象里最有技术含量的 bug 说就行了。 回答方向上主要经清楚测试过程，排查过程和验证过程，中间多讲讲怎么帮助研发排查问题的。 如果能知名的开源软件的 bug 就更好，比如我一般会说 k8s 的 bug。 因为这个显逼格哈哈哈。 比如：

我们在测试环境中发现服务不稳定，总是很卡。甚至请求失败。通过监控 k8s 集群上发现有 2 个节点的 cpu load 高达 200，但是在这两个点上启动的服务其实很少，而且 CPU 使用率也很低。通过 ps 命令发现当前节点的进程数量有好几千个，所以初步判断是由于进程过多导致的进程上下文切换造成的 cpu load 变高。 找到若干个进程查看其 stack 发现都是 fork from xxx 的进程，怀疑都是由某个进程 fork 出来执行 shell 命令的。 查看 kubelet 的日志发现有很多的报错信息显示 du 命令运行出错。 不知道跟这个有没有关系，所以到 github 上查找是否有相关问题。 最终找个有人提过相关的 issue。原因是 k8s 1.8 版本中 kubelet 对外暴露的 metric 接口是给普罗米修斯对接监控用的。他会周期的执行收集监控数据的命令。 其中会执行 du 命令来收集磁盘信息数据， kublet 1.8 使用的是老版本的收集功能，有一个偶发的缺陷是调用 du 命令会出错。所以 kubelet 中会一直抛出这个异常，而因为一直出错所以一直重试，所以才会有那么多 fork 出来的进程执行 du 命令导致 CPU load 变高。 所以按照 github 上提供的 workaournd 我们把 du 命令直接删除。 这样找不到 du 命令只会抛一次错但是不会导致不停的重试。 后面我们找到了不少这样的低版本 k8s 的 bug 导致的产品不稳定问题，甚至直接影响到了生产环境。所以在 19 年的时候升级到 k8s 1.16 版本后就彻底解决了这个问题。

这个 bug 是不是听起来就很有逼格了。 引申下去可以跟面试官探讨一下这种开源产品的 bug 你们怎么处理的问题。

ps：面试这玩意都是吹着唠的， 有些 bug 可能不是你处理的，但是只要你知道细节，不怕面试官深问，你就拿来说是自己处理的就成