/catalog/2416e7f1c515497f98c8b7cb9874d41d//catalog/821d36aa8dfd499ca4af14ac5eb2b6b3//Document/282631823061061.html/Document/264572214259781.html/Document/264193141411909.html/Document/263120166727749.html/Document/262780577878085.html/Document/262434321498181.html/Document/261700928712773.html/Document/260317655674949.html/Document/259254117072965.html/Document/257842584657989.html/Document/257479171993669.html/Document/255707511132229.html/Document/255351757029445.html/Document/250725636485189.html/Document/249686534438981.html/Document/248257145659461.html

功能测试中缺陷的划分标准有哪些纬度?

我们缺陷的分类可以按严重程度分类、按优先级划分、按测试种类划分、按功能模块划分、按缺陷生命周期划分。

按严重程度划分(Severity),这个是我们最常用的一个分类。


致命级
系统崩溃,数据丢失,由于程序所引起的死机、非法退出,死循环,数据库发生死锁,错误操作导致的程序中断 ,严重的计算错误,与数据库连接错误,数据通讯错误。

严重级
系统功能错误或遗漏;程序接口错误 、数据流错误 、轻微数据计算错误。

主要级(一般级)
错误操作提示,界面错误,打印内容、格式错误,简单的输入限制未放在前台进行控制,删除操作未给出提示,数据输入没有边界值限定或不合理。

次要级
不影响系统功能,更好的操作方式,罕见的错误,辅助说明描述不清楚,显示格式不规范,系统处理未优化,时间操作未给用户进度提示,提示窗口文字未采用行业术语。

建议级
不影响系统功能,影响界面美观等。

image.png

(缺陷模板中缺陷的定义)



按优先级划分(Priority)

最高优先级:指的是一些关键性错误,必须立即修复。

高优先级:在产品发布之前必须修复。

中优先级:如果时间允许应该修复。

低优先级:可能会修复,但是也能发布软件。

需要注意的是严重程度高的Bug其优先级就高吗?Bug的严重程度和优先级一定成正比吗?不一定。 严重程度高优先级不一定高:


如果某个严重的软件缺陷只在非常极端的条件下产生,没有必要马上解决。


如果修正一个软件缺陷,需要重新修改软件的整体架构,可能会产生潜在的缺陷,而软件又必须尽快发布,是否需要修正,需要全盘考虑。


按Bug生命周期划分


我们可以把Bug看作一个有生命的小虫子,每一个Bug都有其生存和死亡的生命周期。可以这样划分: 新建(New),确认(Confirmed),解决(Fixed),关闭(Closed),重新打开(Reopen)。
新建(New):一个Bug由测试人员发现并提交,我们将状态标注为新建;

确认(Confirmed):项目经理分配Bug ,开发人员接收了该Bug, 将Bug的状态修改为已分配表示已经认可(Confirmed);

解决(Fixed):开发人员解决了该Bug后,就将Bug的状态修改为解决(Fixed),并发给测试人员回归测试;

关闭(Closed):测试人员对Bug进行回归测试,如果确实已经解决,就将Bug的状态修改为关闭(Closed),否则的话则发给开发人员重新修改,直到关闭为止。

重新打开(Reopen) :Bug是可以“死而复生”的,以前版本已经关闭的Bug,如果新版本中重新出现,我们就需要将其状态修改为重新打开(Reopen)。