今天和大家一起聊一聊缺陷分级的重要性以及分级标准,良好的缺陷等级标准可以给我们带来哪些好处呢?

  1. 明确的缺陷分级标准可以在项目不同角色间对齐问题的严重程度,开发在解决问题时也会优先解决问题等级高的缺陷。

  2. 我们通常使用千行代码缺陷量来衡量开发质量,但千行代码缺陷率统计并不方便,通常我们可以通缺陷量和严重问题占比来简化开发质量度量。

  3. 我们可以通过单位时间内(例如1月内)测试人员发现缺陷的数量和质量来评估测试人员的能力和工作饱和度。

    缺陷分级的重要性以及分级标准

既然缺陷等级这么重要,那么我们应该如何对缺陷分级呢?通常我们对缺陷进行5个等级划分:

致命

这一等级问题包含程序异常崩溃,死循环和死锁,软件整体或部分核心功能不可用等。

这一级别问题出现时系统处于不可用状态,应立即进行修复或回滚操作。

严重

系统不稳定,一般功能未实现或不正确,接口错误,数据库慢查询或消息队列堆积等性能问题。

这一级别问题出现时系统处于不稳定状态,系统服务异常但未完全宕机,若不及时处理则会造成更恶略的后果。

一般

兼容性问题以及数据异常或操作没有达到预期效果,参数未充分校验等。

这一级别问题通常不会对系统造成致命影响,但会影响用户使用或需要手动修复后系统才能正常运行。

轻微

界面展示错误或提示不友好,一些概率性复现问题等。

这一级别问题通常会和产品一起评估是否需要修复以及修复方案。

建议

外观和体验性问题

这一级别问题可以同UI、UE一起评估,确定是否修复以及修复方案。

通常致命和严重缺陷未修复软件系统不能发布,一般问题应在发布前全部修复完毕。轻微和建议性问题需要确认是否修或,明确修复的问题若未在发布前修复完毕需要给出明确的修复时间点或转为线上问题,或转为需求。