BUG等级与状态
以下是一些前辈的个人见解，仅供参考！
BUG等级的划分(Severity)Feature ——
新特性&&一般用来指系统缺乏一个所需要的特性
——&&微不足道&&比较小的问题,例如用户界面中Button位置等
Text ——& &
文字错误&&文字上的拼写错误
——&&不合理/别扭&&如:
Minor ——&
&次要错误&&不能用上述分类界定的,报告人认为是严重程度比较轻的问题
Major ——&
&严重错误&&不属于系统崩溃和死锁类的,但报告人认为比较严重的错误
Crash ——&
&系统崩溃&&引起系统崩溃的错误
Block ——&
&系统死锁&&引起系统死锁的错误
Mantis中的BUG可重现性的说明(Reproducibility)
Always ——&&总是出现,每次尝试都会出现
——&&有时出现,相对于下面的“随机”频率要高一些
Random&&——&
Have not tried
——&&还没有尝试&&即发现bug的操作只进行了一次
Unable to reproduce ——
不可重现&&只发现一次,之后的尝试都无法再现
N/A&&——&&Not
Applicable/Acceptable&&不可/适用
即再次尝试的时候出现bug的功能不能用了
Mantis中的BUG优先级的说明:
None —— 相关的bug已经resolve不存在了或者觉得优先级没有必要体现
Low —— 低优先级,留到最后解决,如果项目的进度很紧张可以在产品发布以前不解决
Normal —— 中等优先级
High —— 高优先级,将处于Immediate和Urgent优先级的bug修改完毕后要进行修改
Urgent —— 紧急,一到两天之内必须进行修改
Immediate —— 需要立即进行修改
优先级与BUG自身的等级并不是完全一致的例如有些bug属于严重级别的错误,但是却只是偶尔的出现一次,不影响软件的正常使用,这样的bug的优先级可以适当的降低.
而有些bug虽然是不严重的错误,但是却是一直出现的,对软件的使用者造成比较大的困扰,这样的bug就要根据情况适当的提高优先级了.即bug的优先级可以认为是上面的Severity(严重等级)和Reproducibility(出现频率)的综合考虑.
当然,优先级的选择问题是与reporter本身的理解关系很大的.不同的reporter对于同样的一个bug可能会选择不相同的优先级.这个也很难有一个统一的标准来衡量的,还是要根据自己的经验和理解来做出比较合适的选择.经验越丰富,这个选择就会相应的越合适越有说服力了!
BUG状态(Status)和解决状态(Resolution)的说明
Status:New ——
当reporter新提交一个bug,不给其指派所有者的时候,bug的状态会自动的成为new的状态.(我们的权限设置,默认的reporter并没有指派的权利,所以reporter提交的一定是new状态的bug.)
Feedback —— 要求reporter再次对bug进行说明
Acknowledged —— 开发人员解决了bug以后QA已经了解但是还没有来得及确认
Confirmed ——
bug的解决方案得到了QA的确认（如果你们的mantis是挂在网上同时用于customer的issue反馈的话，confirmed可以理解成客户反&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
馈的bug得到了QA的确认,确实是个bug，而acknowledged这个时候的理解就可以变成是开发人员
的解决方案得到了QA的公认了）
Assigned —— 当将bug指派给他所属的开发人员之后,bug的status会自动的并成为assigned
Resolved —— bug已经被解决但是还没有得到QA的验证
Closed —— 当bug已经确认被解决或者确认不是bug的时候将bug的状态改为closed
Resolution:
Open —— bug没有被解决Fixed ——
bug的修改已经登记并经过测试
Reopen —— bug曾经被解决,但是解决方案被认为不正确
Unable to reproduce ——
不可重现,被指派的开发人员想要再现bug进行修改的时候发现bug始终不能再现的时候将bug的resolution设置为此项
Not fixable —— 不能修改这个bug
Duplicate —— 与某个已经存在的bug重复
No change required —— 经理和相关开发人员经过需求和设计的核实后决定不需要修改
Suspended —— 延期,一般是指当前版本不进行修改,下个版本再提供解决方案
Won’t fix —— 不准备修改这个bug
NOTE: 个人的理解,
status主要是QA来设置修改,而resolution则是相关的开发人员和项目经理来进行修改的.但是也并不完全如此,中间还是有交叉的几项,例如status中的”feedback”是当开发人员或者项目经理没有看明白bug的描述的时候将bug设置成为的状态;而resolution中的”reopen”则应该是QA在测试相关的解决方案后发现其不正确后将resolution修改为reopen.如果将reopen和feedback交换一下位置的话就不会有这样的交叉了!^_^
status有如下的选项:
&报告一个bug时,没有指派给具体的开发人员修改时,就是new状态
Feedback& &&
反馈,当开发人员修改不正确时,把该bug反馈给他,重新修改
Acknowledged&
&bug问题是公共的,所多页面,都在这样的情况,设为Acknowledged&
Confirmed& &&
&& & 开发人员改完一个
bug后,就把该bug的状态,变成已确认,测试人员看bug状态变成确认时,就来再次检查
Assigned& &&
&已指派,当新建一个bug时,已经知道这个bug将由who修改了,就直接修改该bug
Resolved& &&
&&&bug已经确认,认定是bug但因为技术的问题,暂时不解决
Closed& &&
&确认bug已解决,关闭
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
&&&测试人员报告一个新bug并且没有指派给具体的开发人员修改时的状态
Feedback& &&
开发人员认为此bug不需要修改，就将其反馈。测试人员和开发人员讨论评估&&
&&&后，决定是否将其关闭。
Acknowledged&
&该bug在大部分模块中或页面中都会出现，将其设为Acknowledged（由开发人员
Confirmed& &&
开发人员确认存在此bug，并准备修改，将其设为confirmed
Assigned& &&
&将新建bug指派给某个指定的开发人员后，状态变为Assigned（一般由项目经理
Resolved& &&
&&&开发人员确认bug已经解决，测试人员可以进行验证测试了
Closed& &&
&&&确认bug已解决,关闭
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。　开发应用程序是一项压力很大的，人无完人，工作中遇到bug是很正常的事，有些程序员会生气，沮丧，郁闷，甚至泄气，也有一些程序员则会比较淡定。如何进行修复bug的过程，是值得我们好好推敲的。
　　我想分享一些有关程序员在努力修复bug时常说的话和冒出的想法。当氛围变得紧张的时候，这些话就会显得轻松幽默。最终，bug也会修复成功，你将会继续下一个任务。
　　我相信许多开发人员和软件工程师在编程中都会遇到困难，而事后回想起来，还会觉得很好笑。
　　1、我不知道该删掉还是重写
　　回归曾经写的源代码，总有一种想要重新返工的冲动，逻辑性差，冗余代码多，让人难以理解。但是，如果功能没出现问题，千万不要去修改。这是我经常要面对的困扰，相信也困扰了其他不少的者。
　　2、一开始架构时就该查Github
　　相信绝大多数开发人员都知道Github，它上面每天都会发布的一些神奇的开源项目。涉足所有计算机语言的程序员，会利用网络对现有项目进行分叉，在维基论坛谈论或者回购他们自己的源代码，这些都为各种各样的项目的插件和模板提供了很多丰富的资源。
　　3、为什么这个脚本要依赖这么多库
　　说到一些越来越被广泛使用的计算机语言，像Java和Objective-C，库文件的数量也不断增加。很明显可以看出，构建一个框架就需要许多的基础 库，甚至一些JavaScript的插件也需要很多大量的附加文件。有时候这些乱七八糟的东西会很让人心烦，但是至少它能运行。
　　4、网上一定有解决办法
　　遇到困难时，我的第一反应就是上网查资料，很多程序员会在论坛上发布他们的问题，最终这些问题都会被解决并存档。会很神奇地选择一些跟你的问 题相关的关键字，你就能够轻而易举地得到一些对你有帮助的讨论信息。不幸的是，有时候对于一些特定的问题，相关的信息还不是很多。
　　5、有这个功能的插件吗
　　何必要多此一举插件是扩展任何程序或者网站用户接口的很好的资源。另外它们还为开发者提供了一些定制以及独特的选项。如果没有可用的插件，那你为什么不自己创建一个呢？
　　6、对于网站项目，我好担心坑爹的InternetExplorer
　　使用IE渲染网页遇到的各种困难，我就不提了，从5。5版本到IE9-IE10，对于的支持问题的争议就一直不断。Web开发人员会很害怕网页调试，使用IE6进行渲染更是噩梦。，幸好那些日子已经慢慢成为历史了。
　　7、有些逻辑语句，并不符合逻辑
　　有一些逻辑语句，像if/else循环，for循环，while循环，do循环&等等，还有很多。在回顾一些源代码时，我总是尽力想弄明白我的逻辑是怎么回事。我经常会回头更新代码，让逻辑更清晰。
　　8、我花30分钟写个函数，运行它却要花2个小时
　　这不是十年前的一个有关编程的故事吗？当一切都在按照你所所期待的顺利进行着，突然某个函数输出了一个致命的错误，所以你不得不回头删除代码块，试图定位出错的代码行。尽管这会让你筋疲力尽，但是一旦找到错误的原因，问题解决之后，你又会立马感到浑身轻松。
　　9、读了几篇博客后，我才意识到我之前所做的全是错的
　　我总是喜欢根据自己的编程思想直入主题，但是如果事情没有按照我原本的计划进行时，会导致很多麻烦。有很多次，我在做项目时，途中都遇到了麻烦，最后只得 查找博客和相关去寻求帮助。然后又发现我的整个方法完全错了，还不如从头开始更容易点。所以从长远来看，在项目开始时多做点研究反而会节省时间。
　　10、StackOverflow上有好心人或许能帮助我
　　我已经数不清有多少次，遇到问题都是通过StackOverflow得到解决的。只要你提出问题，社区里就会有很多聪明，友好的热心人愿意帮助你。所有的在线论坛里，它绝对是支持软件编程和前后端web开发的最全面的网站。
　　11、这个问题竟然就因为少了个右括号
　　调试是我们经常要用的方法，向前两步，回退一步，再向前两步，如此反复。为了查找函数命名或者变量作用域等错误，盯着代码看了数个小时，结果发现只是缺少 了一个括号，你会有种哭笑不得的感觉。所有的时间都浪费在了一个小小的语法错误上，那一刻，你会觉得自己既是天才，又是傻子。
　　12、喝杯咖啡，休息一下
　　有的时候你需要起身离开显示器，连续敲了几个小时的键盘，如果中间休息一下，会对你的身体有益。大多数健康指南都建议每30-60分钟休息一次。但是还是要取决于你的需要，如果你感觉中间暂停去休息会打断你的思维，让你很不爽，那就最好不要了。
　　13、我应该先把这个项目放一放，稍后在处理它
　　休息的另一种方式就会暂停你手中的项目，而不是离开你的电脑桌。或许你还有其他的工作要做，那就继续下一项任务。比起试图在一个花了5个小时还没解决的问题上继续挣扎，这会是一种更合理地分配时间和资源的方式。
　　14、我在想或许古典音乐能够激发我的编程潜能呢
　　有一种说法认为古典音乐能促进植物的早期生长，我个人更偏爱古典音乐错综复杂的注解和音乐理论。爵士，钢琴，大型乐队，优雅的音乐在全球各地的人类文化都占有一席之地。所以编程的时候听点美妙的音乐会让你调试起来更得心应手呢。当然也有可能，会让你更加心烦意乱。
　　15、或许现在是验证鲍尔默峰值理论的好时机
　　我相信很多读者都知道鲍尔默峰值，它是根据一个特殊的XKCD漫画得来的。简单来说，这个理论认为程序员的编码能力在喝了定量的酒后，会达到一个峰值。这 个起源于SteveBallmer的些古怪滑稽的姿态被认为是像一个醉汉在说胡话。尽管这有点讽刺，因为鲍尔默在从来算不上一个真正的程序员，猜想我 们只有等其他人来实践这个理论了。
　　16、是谁动了我的代码？
　　这个听起来有点像妄想症，但是有时候你很想知道是谁趁你补觉的时候写的这些东西。回顾过去几周或者几个月的项目，会给你一种晕乎乎的感觉。有时候你会不记得你写过这些东西&尽管上周你还在参与这个项目。好像是我很疯狂地写的代码，你却从来不知道&
　　17、完全不知道这是神马东东
　　你遇到的最糟糕的情况应该是在研究源代码时，完全不知道它是在干什么，可能是来自你自己的项目，也可能是其他人的项目，但是问题都一样。这个时候，你必须确定是否值得花费更多的时间去寻找其它解决方案或者仔细剖析代码，研究它到底是干什么的。
　　18、直接google下错误提示
　　鉴于多年的PHP经验，我不得不说Google真的是调试问题的最好的小伙伴。这对于Objective-C，C++，Java和其他的主流语言的境况一 定是相同的。错误提示信息对我们很有用，但是你必须记住不同的错误代码代表什么意思。它读起来更像是被翻译过的计算机语言。幸好有这么多在线支持，让我们 确定这些错误信息代表的真正意思。
　　19、今天应该到此为止了，可我真的想把这个问题解决了
　　我们都知道想要退出时的那种极度沮丧的感觉，但是同时又觉得放弃不是正确的选择。你很想继续前进，找出新的解决方案来。但是如果到最后还是浪费了一个小时，那该怎么办？我对这种情况并不陌生，它会让人特别沮丧。
20、哦买糕的，为什么我都没写注释呢
　　如果涉及到最基本的前端代码HTML/CSS/JS时，并不需要总是写注释。但是如果是比较复杂的脚本和程序时，就需要写一些标准的注释以便你几个月，甚 至几年后来重温这些代码。有时候你会忘记给函数，参数，输出格式以及其他重要的数据写注释，这无疑会导致发生bug时你不得不调试整个脚本去寻求解决方 案，感到非常困惑，到那个时候你会觉得要是有一些有用的注释该多好啊。
　　21、这个20分钟之前还好好的呢
　　或许构建程序时最让人沮丧的是，明明刚才还好好的东西，没有改过任何代码，这会儿却运行不起来了。我发誓这种情况绝对有发生，而且它没有任何意义&也许其 它程序运行的是缓存版本呢然后也有一些时候我们只更新了一丁点代码，结果整个程序都崩溃并且完全停止运行。那就会回退到最新的备份版本，从那儿继续吧。
　　22、忘了一个该死的分号，整个程序都崩了
　　几乎我用过的所有的编程语言都要求每行结束时都要有结束符，但并不是所有的语言都这样，不过C/C++系列语言绝对是这样。当你忘记添加分号结束符时，这 是多明显的错误！但是解析器并不不理解，便抛出一个致命的错误。接下来就得再花费20分钟时间去研究代码，查找技术错误。最终发现只是少了一个分号。哈， 这就是软件调试的乐趣。
　　23、我想要招人来帮我修复bug，得花多少钱哪
　　雇佣程序员的想法听起来很诱人，但显然在经济上是不可行的。另外，如果你连自己的的错误都没解决，你又怎么能从这些错误中学到东西呢？经历多次失败，最后当你真正理解了编程的概念后，你会很有成就感。但有时候脑子里难免还是会闪过这种想法。
　　24、快速浏览下HackerNews，肯定能提高我的效率
　　很多程序员对于浏览软件和创业等社会新闻的偏爱选择都是HackerNews首页。它有大量的关于自由职业，时间管理，软件开发，创业发布和筹资资金等方 面很棒的信息。尽管HN能够模拟出通过自我教育更加高效的感觉，但其实是在浪费你的时间。每隔几小时去快速浏览下新闻也没那么糟糕。
　　25、这个API怎么没有说明文档啊？
　　最让人沮丧的事情就是使用插件或者框架时，自带的文档很糟糕，你只好自己去深入阅读源代码。我更喜欢让开发人员花时间专门为项目设计一个文档页，对所有的 参数和选项都给予解释，有可能的话，给出一些示例代码。但是很遗憾，这种情况几乎不可能。所以最简单的办法就是远离那些附带文档很糟的工作，以免给自己带 来麻烦。
　　26、我真希望我已经对数据库进行备份了
　　在编写和调试代码的时候，我有时候会想不到备份。然而，数据备份能够帮助我们回退到做出某个特定的改变之前的版本，这对一个即时的服务器环境是特别有用 的，有些变化瞬间就会发生。切记在本地保留对网站文件和数据库的拷贝，以备急需。你可能会觉得这样太麻烦了，但是总比你重建一个SQL数据库强多了。
　　27、怎样才能快速解决这个问题？
　　如果花费了数小时后，仍然未找到一个解决办法，很明显你需要一个新的方案了。程序员总是想要先实现功能，然后再去设计和美化界面。先确定一个最快的，最准确的解决方案，并尽力去实现和完成，然后再去考虑美化界面的问题就会很轻松了。
　　28、我敢打赌，你更新下我的代码，这个问题就解决了
　　那些为编程语言提供依赖包和插件的团队并不需要频繁地发布产品。有时候从本地传送文件到服务器的时候，更新PHP/Ruby/Python/SQL版本可能会解决一些调试问题。除非你的版本实在太旧了，否则本地更新很少能够帮助你修复源代码中的bug，不过还是值得一试！
　　29、我真的该好好学习Git了，&还是下周吧
　　开源的版本控制控制软件Git在程序员中广受欢迎。跟其他竞争对手相比，它提供了一条更简单的学习曲线，被应用在了许多在线仓库像Github和 Bitbucket中。可能对初学者来说，会有点难度，但是一旦你掌握了基本命令，你会发现使用GIt就是小菜一碟。它还让版本控制更加清晰。
　　30、算了，我还是从头开始吧
　　有时候尝试了数小时的解决方案后，你可能需要将你的工作文件归档(或者删掉它们)，重新开始。这个决定的最大难点就是你会考虑到前面数小时的工作会毫无收获。但是如果你保留之前的想法，项目却毫无进展时。重新开始，才有可能让项目顺利完成。
阅读(...) 评论()}