BUG就像议论文

来源：互联网发布：2016中国网络视听大会编辑：程序博客网时间：2024/04/29 07:10

先抛出一个观点——“发现bug—理解bug—通常占了工作的90%”。

在SQA上报的bug中，有许多缺陷可能只需要改几行代码或者一个变量就可以被修复。每个Bug都有它们自己的性格特征，有些可能很容易被发现，而有些可能会跟你玩“捉迷藏”并且容易发现的Bug不一定就很好修复，当然，那些擅长玩“隐藏”的Bug有可能很容易被修复。

查找和修复（这里参考了其他文章）

如何发现并修复Bug。当debug时，经验丰富的程序员会很熟悉这种结构化和纪律性的步骤要领：

确定查找的目标，审查Bug报告，看看该Bug描述是否合理并且提供了足够的信息去发现和重现，重新是很重要的。程序员回忆一下该bug以前是否遇到过，如果是，可以检查以前的处理记录。
搭建测试环境，有时测试环境往往对bug的复现有一定的意义，如果你不能重现这个错误，那么就无法去修复。
定位原因即bug的可能原因，就像是先提出一个论点，你去验证这个论点一样。
调试，重现并且诊断错误。
进行修复——思考修复是否会有‘后遗症’。这可能包括，在修复之前对代码进行重构使代码更容易被理解，并且使整个修复更安全。在后面的回归测试中确保没有引入任何新的bug。
努力让代码更安全，更清洁，耦合度底，尽量独立，做一些循序渐进的重构确保代码更健壮并且易于维护的。
修复完成后，让他人进行审查，确保你没有做一些愚蠢的事情。
再次检查。
结束并且进行思考和总结。明白是哪里出错了？为什么？是否真正理解自己的修复？在别的地方还会发现这个错误吗？“如果你花了很长时间去修复这个Bug，问问自己，到底是为什么？”在将来，如何让该Bug更容易被发现和修复？如何提高修复方法或许是使用工具？思考的是否深入，要看这个Bug影响和所花的时间有多长？

发现和修复需要多久

设置测试环境所需的时间，重现一个Bug或者修复可能远远超过在代码中查找和修复的时间。但是对于那种小缺陷，在发现时即可修复。

在发现一个Bug（理解并重现Bug）比多久去修复更难。研究发现，大多数Bug（几乎3/4）很容易被发现和理解，并且不会花多少时间去修复：5天或更少（这是在大型实时系统与一个重量级的SDLC中，经过大量检查和测试发现的）。这里有一个长期隐藏型Bug，可能需要花更长的时间修复，即使这个Bug微不足道：

发现/修复工作小于5天修复大于5天缺陷可以重现72.5%18.4%很难或者不能重现5.9%3.2%

所以在你发现Bug的时候，可以和自己打赌，它很快就会被修复，这个命中率会很高。但是当打赌失败时，你可能会错很多，或者彻底来个大错特错。