bug的概念和分类

前面篇我们都在讲测试用例设计的案例、设计方法、工具。本篇呢我们来聊聊bug，程序里的小虫子。

所谓“（Bug）”，是指程序中隐藏的错误或者缺陷。

早在 软件测试的工作周期 一文附录中我们就已经对bug来源做了解释，感兴趣的点击链接回顾。

一条Bug记录最基本应包含：

※bug编号：bug的唯一id，以方便尽快找到此bug。

※bug标题：bug摘要，阐述bug大体内世蚂容。

※bug严重级别，优先级：作为缺陷是否修复以及缺陷修复优先级的决定性因素。

※bug产生的模块：记录bug所属模块，方便开发定位问题。

※bug对应的版本：bug对应的软件版本，方便后续的统计归档以及开发定位问题。

※bug描述：bug的产生环境、详细步骤，期望结果、实际结果。

※附件：包括但不仅限于截图、日志、录像、所用到的示例文件以及应用；同样是方便复现解决缺陷的。

以上是上报bug（创建）bug必须的，在后续我们还会对bug进行修复、复测等工作，那在为了记录后续工作，bug还应该包含：

※bug状态：开始、修复中、修复完成、提测、搜肆埋测试中、测试通过/失败、关闭等，后续bug周期中会讲到。

※bug修订人：bug修订人员。

※bug复测人：通常是谁报的bug最后返回给谁测试，但是在某些情况下比如bug报告人任务积累太多/不在的情况下也会分给其他人，所以通常会记录bug复测责任人。

※bug修订说明：由bug修订人来写，说明bug产生原因，修改思路等。

※bug复测说明：由复测人员来写，说明复测过程，复测结果等。

※bug备注：备注，以便记录一些额外信息。

俗话说，事有轻重缓急。生活如此，工作亦如此。软件缺陷也并不是平等的，根据当前环境我们将不同的缺陷按照严重程度以及优先级进行分类，开发通过这个分类来决定bug是否修改以及bug修改的先后顺序（“缺陷的轻重缓急”）。

具体划分方法各个公司不尽相同，但是通用原则大体一样：

※ 严重性 ：表示软件缺陷的恶劣程度，当用户碰到该缺陷时影响的可能性和程度。

※ 优先级 ：表示修复缺陷的重要程度和紧迫程度。

下面我们给出严重性和优先级的常用划分方法，需要注意的是，我们这个只是示例，每个公司划分方法也都不尽相同，多多少少有些改变，大家作为参考即可。

严重性：

    a.系统崩溃、数据丢失、数据毁坏、安全性被破坏、核心功能未实现（比如QQ 没有做聊天功能）、主体功能实现与需求不符（比如QQ聊天功能只能发消息不能收消息）

    b. *** 作性错误、结果错误、功能模块的某个点未实现（比如QQ没有做消息提醒）,兼容性错误

    c.小问题、拼写错误，UI布局不美观、特定情况下的罕见bug

    d.一些易用性的建议（也可以归为3）

优先级：

    a.立即修复，阻止了进一步测试

    b.在产品发布之前必须修复

    c.如果时间允许应该修复

    d.可能会修复，不影响发布。

再次重申，上述清单只是范例，具体的缺陷划分规则还要依据实际项目、应用场景来制定。比如：通常我们认为毁坏用户数据的缺陷比简单的拼写错误缺陷严重。但是如果数据毁坏仅在用户几乎用不到的罕见特例中出现，而拼写错误导致所有用户安装软件产生问题呢？此时数据毁坏与拼写错误的优先级和严重性就不言而喻了，必然是拼写错误的严重性和优先级高于数据毁坏的。

严重性和优先级对于审查缺陷报告并决定哪些软件缺陷应该修复，以何种顺序修复的人员极为重要。如果一个程序员受命修复10个缺陷，他就应该先从严重性为1 、优先级为1这样的缺陷着手，而不是优先修复简单的，有简到难。

同样，两个项目经理--一个管理广告门户网站/游戏软件，一个管理医院检测仪/性能检测类软件，对待同样的问题就会做出两种选择，比如同样都是页面美观问题，在前者那优先级可能就是2，在后者那可能就是3或者4了。

好了，今天到此结束。如有任何问题请留言及时与我沟雹首通，我会尽快回复大家！谢谢大家~我们下次再见！

所以看到你这个问题，我被雷倒了。。。。缺陷的易用性？难道你是想利用漏雹雹洞干什么吗？

BUG分类一般可以从严重程度，和修复优先级分。

严重程度顾名思义就是BUG 对软件造成的问题大小 比如是普通的功能缺陷 还是重大的凳肆伍 会死机等

修复的优先级就是 要马上修的，和可以不修的，或以后修的。

而优先级和严重程度并不成枣或正比。并不是严重的就要马上修，也不是不重的，就以后修。

如有不明白的，自己再行百度一下吧。