缺陷库专题|缺陷的优先级别

优先级是表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。

确定软件缺陷优先级，更多的是站在软件研发人员的角度，该级别建议由研发人员自己定义。因为缺陷的修正顺序是个复杂的过程，有些不是纯粹技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修正缺陷的难度和风险。

优先级别划分指缺陷必须被修复的紧急程度，由研发负责人在分配新建缺陷时指定，产品（项目）负责人或经理可参与定夺。由于软件行业不同，还需根据每个行业的特点来定义缺陷优先级。通常优先级的定义参考该缺陷的严重程度，如：

l 紧急级别缺陷应阻止相关研发人员的进一步开发活动，立即进行本缺陷的修复工作。例如，软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷。

l 高级别缺陷应在本次迭代周期内修改完成。例如，影响软件功能和性能的一般缺陷；

l 中级别缺陷需要在本次迭代周期内修改完成，但不排除放到下一周期内解决，但需要项目组讨论决定。例如，本地化软件的某些字符没有翻译或者翻译不准确的缺陷。

l 低级别缺陷是项目完成前修改完成，或根据实际项目情况，择时修改。例如，对软件的质量影响非常轻微或出现几率很低的缺陷。

缺陷生命历程中，操作人员职责确定之后，还要制定缺陷库的相关配置规范，具体规范如下：

1）根据现有项目，配置管理员创建缺陷库，并设置项目用户和权限。

2）设置缺陷库的相关属性。根据现有缺陷库工具，设定出合理的缺陷属性。

3）规定测试人员提交缺陷的书写格式。Bug的详细描述要达到让研发人员清晰这是一个什么问题，看了能够自己复现的程度，所以要详细但要避免冗余。缺陷的编写规范要包含以下几点：

l 测试配置：主要是产品或相关测试要件的配置。

l 测试环境：测试所搭建的软件、硬件、数据环境。

l 测试步骤：这是比较关键的，目的是帮助研发重现缺陷，需要组号列出1、2、3等步骤项。或者指明对应的测试用例。

l 预期结果和实际结果：写到描述中，不但能够做对比，而且能够有效的证明这确实是一个bug。

除了上述描述外还应注意如下：

l 一个缺陷记录只能描述一个bug。

l Bug的唯一性：在提交bug之前，要确认这个bug是否已经被其他人发现并报告（搜索功能）

l 重现：有些bug很容易就重现，有些就很难。如果你能重现一个bug，应该准确的解释必须的条件。应该列出所有的步骤，包括精确的组合，文件名以及你碰到或重现这个问题的操作顺序。如果你能够确认这个问题在任何文件，任何的操作顺序等条件下都会发生，那也做好能够给出一个明确的示例来帮助开发重现。如果发现一个不能重新的bug，就尽可能多的提供有效的信息给开发人员。截图、日志，抓包等对捕获这个bug有帮助的信息可以包含在你的bug报告中

l 定位：对于一个测试人员来说，应该做一些有效的事情来帮助定位问题。要多想会不会是外部的什么特殊原因引起的这个问题？会不会是因为网络的问题导致的问题？或者是应用软件配置错误导致的问题？如果实在不能定位问题原因，是否可以想办法缩小出错的范围？尽量避免是由于测试人员的问题导致误报了bug。测试人员定位bug的能力，一定程度上是测试人员附加值的体现，能够节省项目组相关人员的时间，缩短了回归bug的时间

l 报告bug时要使用中性语言，不要带有感情色彩。不要带有幽默也不要带有任何不满情绪。

4）为了防止缺陷库遭到未经授权的访问和操作，可以将缺陷库成员分配到指定的用户组，用户组权限设置如表2-1所示。

表2-1用户组权限设置

最后，下面是我整理出来的一份软件测试工程师发展方向知识架构体系图。

希望大家能在这个成长过程中收益良多。可以说，这个过程会让你痛不欲生，但只要你熬过去了。以后的生活就轻松很多。正所谓万事开头难，只要迈出了第一步，你就已经成功了一半，古人说的好“不积跬步，无以至千里。”等到完成之后再回顾这一段路程的时候，你肯定会感慨良多。

由于CSDN上传图片大小有限，有需要的朋友可以关注我的公众号：程序员二黑，回复1，即可获取原图。

下面是一份配套的软件测试资源包：

上面是一些配套资源，对于软件测试的的朋友来说应该是最全面最完整的备战仓库，为了更好地整理每个模块，我也参考了很多网上的优质博文和项目，力求不漏掉每一个知识点，很多朋友靠着这些内容进行复习，拿到了BATJ等大厂的offer，这个仓库也已经帮助了很多的软件测试的学习者，希望也能帮助到你。

关注我的微信公众号：程序员二黑，即可免费获取！

最困难的时候，也就是我们离成功不远的时候！如果你不想再体验一次自学时找不到资料，没人解答问题，坚持几天便放弃的感受的话，可以加入我们的群：785128166 大家一起讨论交流学习。