作为一个软件开发工程师，经常会遇到各种bug需要修复。
一般来说，自己写的的代码，测试工程师描述一下问题的现象（比如网站某个页面打不开了），开发工程师就知道大概是什么地方出了问题（这种情况很有可能就是已知的缺陷）。
但随着软件系统的不断扩大，代码复杂度会越来越高，这时候单单靠描述问题现象是很难解决问题的了，即使是自己写的代码，这时候也需要测试工程师给出具体的复现步骤，开发工程师通过复现步骤，能大概知道出错代码的位置，修复完，扔给测试检查有没问题即可。
遇到更复杂的bug，测试工程师给出了复现步骤，开发工程师就只能定位到代码的大概位置，但还是很疑惑——究竟什么地方出错了？这时候，一般是开发工程师的技术缺陷。比如说：有一段给字符串去除空格的代码。测试工程师反馈代码有问题，输入一串字符之后，输出的字符里头还有空白占位符。遇到这种情况，就需要将具体的报错呈现在开发工程师的开发机器上，让开发工程师知道具体是哪一行出的错误，错误的上下文（即相关变量的值）是什么。达到这一步，问题开发工程师就恍然大悟：哦哦，原来空白字符出了“空格”还有“TAB键”等等乱七八糟的玩意。
遇到更复杂的情况，比如说是大型分布式数据库环境，开发工程师无法复现问题，这时候就需要有具体的报错日志里的报错信息（报错信息中一般会有报错提示、报错堆栈）（其实上一段里头，开发工程师想知道的也是报错堆栈，只不过这一段里描述的是报错堆栈难以获取的情况）。这时候依赖于bug报告人员的日志分析能力了，从各个服务的日志文件中，定位出错误，并提取错误堆栈给开发工程师，这里就考验bug报告人员的 linux 命令的功底了。
网友评论