第62章 空降(第3/3 页)

bug，不影响用户体验使用，不过修改了最好，一般如果要修改且时间来不及可以

在后面的版本更新中再进行修改即可。

备注：严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷，优先级不

一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优

先级，视具体情况而定。

BUG等级分类参考

一．ＢＵＧ等级分类

1.崩溃：阻碍开发、测试工作；造成系统崩溃、死机、数据丢失；主要功能、基本模块丢失、一级菜单不能使用；

2.严重：功能设计与需求严重不符；数据数值计算出错；程序接口调用出错；

3.一般：功能未实现但不影响使用；操作时间较长；数据库表字段过多；页面样式（如错别字、界面格式不规范、页面显示重叠、不该显示未隐藏、描述不清楚、提示语丢失、文字排列不整齐、光标位置不正确）

4.次要：页面建议性问题不影响正常使用；用户体验感觉不好；

(注：对应禅道类型严重程度1.2.3.4)

二．ＢＵＧ状态

1.待处理：测试人员与网站使用人员发现问题提交的状态。

2.已确认：由开发人员确认。（此步可省略）

3.已处理：经测试人员与开发人员讨论确认ＢＵＧ，修改后未验证。由开发人员来设置。

4.已修改：测试人员验证ＢＵＧ已修改。由测试人员来设置。（在禅道关闭ＢＵＧ）

5.仍存在：测试人员验证ＢＵＧ修改不通过。由测试人员来设置。（在禅道激活ＢＵＧ）

6.暂不处理：当前版本不作修改，后续版本再作处理。由测试人员与开发人员讨论后设置。

对于外包或其他按照缺陷类型与缺陷等级来评估软件质量的企业，提交缺陷报告时，准确定义缺陷类型显得尤为重要。这里列出了常见的几种缺陷类型，分别为功能缺陷、逻辑缺陷、数据问题、界面问题、兼容性问题、环境问题、性能类缺陷、需求缺陷以及变更问题。提交缺陷报告时，依据不同类型的缺陷提交，再辅以完整附件与初步定位问题的结果分析，更有助于提高开发人员修复缺陷的效率与质量。（提升开发人员的效率，也正是测试人员展现自身附加价值的一种能力~~）

1 功能

本章未完，请点击下一章继续阅读！若浏览器显示没有新章节了，请尝试点击右上角↗️或右下角↘️的菜单，退出阅读模式即可，谢谢！