欢迎光临散文网 会员登陆 & 注册

测试主管必备:软件缺陷Bug管理规范

2023-02-24 11:40 作者:COMEON-Children  | 我要投稿

这里分享一份通用的缺陷管理规范,关于测试准入准出标准、缺陷定性以及缺陷管理流程可以依据实际工作中使用的缺陷管理工具与项目研发模式来灵活变动。
先看本缺陷规范的总体架构:


1    文档目的
为了保证缺陷得到有效的跟踪和解决,并且达到项目质量度量和缺陷分析的目的,为后续工作的改进提供参考价值。

2    准入标准
2.1    冒烟测试准入标准
1)冒烟测试用例已通过评审;
2)冒烟测试环境已搭建完成;
2.2    系统集成测试准入标准
1) 需求规格说明书已通过评审;
2) 测试用例已通过评审;
3) 在测试环境已搭建完成后,根据测试用例执行测试,优先级别高的用例应优先并重点测试。
2.3    回归测试准入标准
1)致命缺陷、严重缺陷修复率达到100%,一般缺陷、轻微缺陷由项目负责人确认可以延后修改;
2)开发组执行内测,确定修改缺陷后没有产生其他模块的问题;
关于系统测试各阶段的准入准出规则详情可以参考《系统测试各阶段准入准出规则》


3    BUG定义
3.1    缺陷严重程度
缺陷严重程度指因缺陷引起的故障对软件产品的影响程度,可分为:致命缺陷、严重缺陷、一般缺陷、轻微缺陷、建议。
1    致命缺陷:不能完全满足系统要求,系统停止运行,系统的重要部件无法运行,系统崩溃或者挂起等导致系统不能正常运行。
2    严重缺陷:严重地影响系统要求或基本功能的实现,且没有更正办法。使系统不稳定、或破坏数据、或产生错误结果,或部分功能无法执行,而且是常规操作中经常发生或非常规操作中不可避免的主要问题,系统无法满足主要的业务要求,性能、功能或可用性严重降低。包括功能问题,业务逻辑问题,数据控制等功能实现的问题
3    一般缺陷:系统可以满足业务要求,系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题。包括性能问题、安全问题、校验问题、乱码等。
4    轻微缺陷:使操作者不方便或操作麻烦,但它不影响执行工作功能或重要功能。包括界面问题、提示信息、易用性、统一性等。
5    建议:希望提出的建议但不强制进行的修改。不会对发布的准确性或可用性带来任何严重影响。

3.2    缺陷类型
缺陷类型分为:功能、逻辑、数据、页面、兼容、环境、性能、文档、变更


3.3    缺陷优先级
缺陷优先级:指缺陷必须被修复的紧急程度。优先级的衡量抓住了在严重性中没有考虑重要程度因素,同时优先级要以对客户的影响程度来衡量。
最高: 缺陷必须立即解决。
高:    缺陷必在当天内被立即解决。
中:    缺陷在测试报告提交前解决。
较低: 可在推迟修改,在时间和资源允许的情况下解决。
低:    可做可不做的修改。

3.4    缺陷状态
缺陷状态:指缺陷通过一个跟踪修复过程的进展情况。
新建:缺陷的初始状态。
已解决:开发人员修改缺陷完成。
关闭:回归测试通过。
重新打开:回归测试失败,缺陷重新打开。
延期解决:不影响主要功能,可以列入下期规划内容。
已拒绝:开发人员驳回问题。
待裁决:需求理解存在歧义、无法修改或遗留问题。
                          
3.5    缺陷原因
缺陷原因:造成上述错误的根本因素,以寻求开发、测试人员可改进的地方。
低级错误:正常的状态下不可能犯的错误
疏忽:因马虎大意导致的缺陷。
考虑欠周全:因考虑不周全导致的缺陷。
理解不到位:对业务、需求、设计等理解不到位导致的缺陷。
其他

3.6    缺陷修改次数
缺陷修改次数:同一个缺陷被重新修复的次数。如下图所示:



4    常规BUG定性
一般包含:致命缺陷、严重缺陷、一般缺陷、轻微缺陷、建议
详细的定性规则如下图:


5    缺陷度量指标        
1测试用例密度 = 测试用例数/需求功能点个数
2测试需求覆盖率  = 被测试的需求点数/总需求点数
3测试案例执行率  = 实际执行的测试用例数/计划执行的测试用例数
4测试案例通过率  = 测试用例通过率=(实际执行的测试用例数-测试执行不通过的测试用例数)/实际执行的测试用例数
5缺陷修正率 = 发布前已修正的缺陷数/发布前已知的缺陷总数

6    缺陷管理
XXX作为缺陷跟踪管理工具,测试人员负责提交缺陷、跟踪缺陷和关闭缺陷,开发人员负责修复缺陷;项目负责人负责缺陷裁决和报备。
缺陷管理流程如下图:


测试人员根据测试用例,发现并创建问题,分配给对应的模块经办人,经办人对问题进行修复,在修复后通过测试人员。测试人员进行回归测试,在测试通过后,直接关闭问题,如不通过,则重新打开,由经办人再进行修复。
当新需求、改进或遗留问题在影响到工期或不涉及主要或关键功能时,开发人员可向项目负责人或产品经理报备,问题可延期处理
当开发人员认为不予解决时,由项目负责人或产品经理进行裁决,决定问题是否需要进行处理或重新指定人员处理。

7    准出标准
1、被测项目满足软件需求规格说明书的要求;
2、所有测试用例已通过评审;
3、所有测试用例都已成功执行;
4、所有发现的缺陷已成功记录到XXX缺陷管理系统中;
5、致命缺陷、严重缺陷的缺陷修正率达到100%,如有无法修改的缺陷,需要由产品经理确认方可关闭;
6、一般缺陷、轻微缺陷如有遗留,需由项目负责人确认缺陷不修改的原因,测试组可以提出质疑,最终双方意见达成一致后可以不用修改;
7、产出系统测试报告。


测试主管必备:软件缺陷Bug管理规范的评论 (共 条)

分享到微博请遵守国家法律