当前位置：首页 > news >正文

Bug管理规范

news 2025/6/16 17:48:59

1BUG定义

1.1Bug状态

BUG状态标记BUG当前所处的状态，是用来处理BUG流程的主要参数，JIRA缺陷管理平台有以下一些状态：

新增（New）：测试人员新发现的系统Bug；

打开（Open）：测试人员通知开发人员需要修改的BUG；

修改（Modify）：开发人员正在修改的BUG；

固定（Fixed）：开发人员通知测试人员已修复的BUG；

跟踪（Trace）：测试人员短时间内很难确定是否已经修复的BUG；

已关闭（Close）：测试人员经回归测试后确定已修复的BUG；

已否决（Rejected）：被开发人员否决了的BUG；

重新打开（Reopen）：Bug未被修复，重新出现在新的测试版本中；

延迟修改（Wait）：因为种种原因需要等待延期修复的Bug。

无效bug：现在及以后都不需要改代码的bug;

无效bug处理流程：

1 测试理解错误，不需要改代码解决的问题，开发直接选择解决方式是无效bug，算无效bug；

2 测试理解正确，PRD没有明确说的，但是经过产品确认现在以后都不需要解决的问题；研发或者产品增加备注，然后解决方式为无效bug，算无效bug;

3 Prd修改但是测试没有得到通知，根据旧prd报的bug，开发选择解决结果是无效bug，解决方式选择 “需求理解偏差”，算无效bug；

4 PRD没有写，但产品确认需要改，bug提给产品/经办人改成产品，bug引入阶段改成需求，研发改完，产品修改bug状态为已完成/已修改，不算无效bug；

5 体验类优化的问题，前端组件不支持，算已解决-未解决, 产生原因外部原因，不算无效bug；

1.2Bug优先级

紧急

导致产品无法正常运行或需要优先处理的任务

重要

系统崩溃、丢失数据或内存溢出等严重错误

一般

一般性错误

次要

程序功能出现错误，但可通过其他手段解决

无关紧要

不影响程序运行的错误，如拼写错误等

1.3BUG自测是否应发现

否：该缺陷不属于研发自测应发现范畴

是，在开发自测用例中：在本次所给自测用例可发现范围内，属于自测应发现情况

是，不在开发自测用例中：在冒烟用例集中，并未在本次项目/需求所给自测用例内，但属于自测应发现范围；

1.4缺陷严重程度

（1）致命错误

致命错误通常有如下情况：

1、需求书中的重要功能未实现；

2、造成系统崩溃、死机，并且不能通过其它方法实现功能；

3、常规操作造成程序非法退出、死循环、通讯中断或异常，数据破坏丢失或数据库异常、且不能通过其它方法实现功能的。

（2）严重错误

严重错误通常使系统不稳定、不安全、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的主要问题，通常有如下情况：

1、重要功能基本能实现，但系统不稳定、一些边界条件下操作会导致run-time error、文件操作异常、通讯异常、数据丢失或破坏等错误；

2、重要功能不能按正常操作实现，但可通过其它方法可实现；

3、错误的波及面广，影响到其它重要功能正常实现；

4、密码明文显示；

5、C/S、B/S模式下，利用客户端某些操作可造成服务端不能继续正常工作的。

（3）一般错误

程序的功能运行基本正常，但是存在一些需求、设计或实现上的缺陷；次要功能运行不正常，通常有如下情况：

1、次要功能不能正常实现；

2、操作界面错误（包括数据窗口内列名定义、含义不一致）；

3、打印内容、格式错误；

4、查询错误，数据错误显示；

5、简单的输入限制未放在前台进行控制；

6、删除操作未给出提示；

7、数据库表中有过多的空字段；

8、因错误操作迫使程序中断；

9、找不到规律的时好时坏；

10、数据库的表、业务规则、缺省值未加完整性等约束条件；

11、经过一段时间运行后，系统性能或响应时间会变慢；

12、重要资料，如密码未加密存放（包括配置文件中的密码），或其它存在安全性隐患的；

13、硬件或通讯异常发生恢复后，系统不能自动正常继续工作（需要过多的人工干预才行）；

14、系统兼容性差，与其它支持系统一起工作时容易出错，而没有充分理由说明是由支持系统引起的；或者由于使用了非常规技术或第三方组件造成不能使用自动化测试工具进行测试的。

（4）优化建议

可以提高产品质量的建议，包括新需求和对需求的改进，以及程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误，通常有如下情况：

1、界面不规范；

2、辅助说明描述不清楚；

3、输入输出不规范；

4、长操作未给用户提示（或长操作结束后提示没有消失）；

5、提示窗口文字未采用行业术语；

6、可输入区域和只读区域没有明显的区分标志；

7、界面存在文字错误；

8、在功能实现方式上如果需求中没有明确定义，而没有按常规实现，并且不比常规方式实现优越的；( 如用户名第一位用数字或特殊字符)

1.5缺陷产生原因

1、产品需求问题：

需求不清晰或错误，导致设计目标偏离客户的需求，从而引起功能或产品特征上的缺陷；

2、编码错误：

程序逻辑问题，包括对程序逻辑路径或数据范围的边界考虑不够周全，漏掉某些边界条件，造成容量或边界错误。

3、需求变更：

4、关联系统/模块影响分析不足

为考到上下游系统的或内部模块间的相互关联及影响造成的缺陷；

5、第三方工具引起的问题

6、新技术不熟悉：

新技术的采用，可能涉及技术或系统兼容的问题，事先没有考虑到。

7、设计错误：

系统结构非常复杂，而又无法设计成一个很好的层次结构或组件结构，结果导致意想不到的问题或系统维护、扩充上的困难；即使设计成良好的面向对象的系统，由于对象、类太多，很难完成对各种对象、类相互作用的组合测试，而隐藏着一些参数传递、方法调用、对象状态变化等方面问题；

8、环境问题：

系统运行环境复杂，包括硬件环境及软件外部依赖环境，依赖接口不稳定等因素造成的缺陷；

1.6缺陷类型

1. 功能遗漏:

未按需求文档实现，功能缺失

2. 程序逻辑错误

需要进行逻辑分析代码修改，如循环条件、计算顺序错误、逻辑顺序错误等；

3. 程序校验错误
4. 界面错误

前端页面排版、显示等交互问题；

5. 兼容问题：

服务端与前端兼容问题、软件间

6. 用户体验问题/优化提升
7. 接口问题

模块接口间调用问题，如参数问题

8.性能问题

不满足系统可测量的属性值，如、执行时间，事务处理速率等缺陷；

9. 安全问题
10.环境问题

由于设计、编译、运行环境引起的问题

2BUG的生命周期

1、测试人员在测试中发现BUG需要将其添加记录到JIRA中，并制定给对应的开发/产品人员进行处理。

2、开发人员修改好BUG后需要在注释框中填写说明信息，并将BUG的状态设为“已修正”状态，同时开发人员如果认为有的缺陷没有必要修改、无法重现、延期修改等，可将其设置为对应的“被拒绝”、“重复的”、“信息不足”、“无法重现”、“延期修改”等状态。

3、开发人员处理完毕BUG后需要测试人员对BUG进行验证，验证通过后就把其状态设置为“已关闭”状态，若验证不通过则把状态设置为“重现开启”状态。

4、对被置为‘被拒绝’状态的BUG，测试人员与开发人员协商后同意关闭，则置为‘已关闭’；若测试人员不同意关闭，则把BUG状态置为“重新开启” ，然后开发人员继续修改；若不用再修改则置为‘已关闭’；若延期处理则置为‘延迟修改’。

5、对被置为“信息不足”状态的BUG需要测试人员补全信息；然后重新开启让开发人员继续修复。

3BUG管理规范

合理的BUG流程管理有助于提高整个项目的效率与质量。BUG管理规范要求在BUG提交、BUG分配、BUG处理、BUG验证、BUG跟踪等环节都要进行规范。以下为各个环节的具体规范要求。

3.1BUG提交规范

BUG 描述的清楚与否，可以很好的帮助开发人员快速定位、解决问题，而且还可以提高测试人员基本测试技能。因此，建立标准的BUG描述规范是十分重要、也是十分必要的。

首先清晰的BUG 描述可以帮助开发人员快速定位、解决问题。软件测试部门中员工的水平各有不一，对于 bug 的认知、描述侧重面也会存在不同。因此，如同一个问题，由不同测试人员描述 bug，就有可能会存在描述不一致的问题。这就会造成让开发人员理解不清晰，从而延误解决问题的周期。

其次标准的BUG描述可以提供测试人员的基本测试技能。如有新入职员工，他可以先从BUG库中查找BUG了解公司产品的整个开发、研制中产生的问题。而标准清晰的BUG描述可方便快速的使其尽早、尽快的融入我测试部门。另外，对于BUG的追踪验证时，由于是不同测试人员进行验证，所以规范的BUG描述，可以提高测试人员验证问题的效率。