随笔 - 53, 文章 - 0, 评论 - 3, 引用 - 0
数据加载中……

如何减少软件的BUG?

每次项目结束,都会发现有一堆的Bug。如何分析这些Bug,避免重蹈覆辙。

有两种分析方法, 根据Developer在修复Bug时选择的CommonCause,选择比重最大的CommonCause,

然后从各个方面分析RootcCause。总结出可以改进的地方。

我很难理解这种方法,主要是觉得每次都是泛泛而谈,对减少BUG没有真正的帮助。


(我确信这种分析方法没有太大的意义,因为缺乏对底层原因的了解. 而且Developer在选择common Cause的时候完全可能没有合适的而任选一个.经常看到的一个例子是缺乏UT. 这个就不一定是真正的原因,事实往往是做了UT却没有发现出Bug.这种分析方法是典型的不深入实际的浮夸作风, 依赖统计的数据而没有看到统计数据事实上可能存在问题. 这样的工作肯定效率不高. )


下面是我的一些思考。
分析的基础应该是Bug,而不是commonCause。直接从CommonCause开始分析,至少可能遗漏一下重要有价值的发现。
有些Bug是有可能避免的。而有些bug可以说没有什么好的对策。我们应该集中分析有可能避免的Bug。
至于如何分析具体Bug是否能避免,首先应该是造成该Bug的Developer自己分析,让大家知道Bug是如何形成的,然后由大家集体决定。(这样做的风险是大家能否接受。)
其次根据Bug引入的时间,和最终测试出的时间,总结有没有可以改进的大方。
能够由developer改进而消除的Bug。是最有希望避免再次发生的。
比如,有些bug是打字错误造成界面上显示的内容有瑕疵,一个可行的改进是每次都从需求文档拷贝。
注意必须要有措施能保证该经验能被所有Developer知道。
另一个例子是,我有一次,是的,我有一次再修正bug是没有清除彻底。在总结的时候我掌握了全局查找、替换的技巧。有效地避免了类似的错误再次发生。

并非所有错误都能由devloper来消除,有一些只能由Tester来消除。比如,一般来说,Tester总是比Developer对界面敏感,更能发现界面bug。
我觉得随着单元测试的进步,现在对Developer的测试水平的要求也提高了。这也许不尽合理。developer对实现花了很多精力,他不可能在测试上达到同样的水准。

posted on 2006-02-19 18:01 InPractice 阅读(605) 评论(0)  编辑  收藏 所属分类: Java


只有注册用户登录后才能发表评论。


网站导航: