测试活动之缺陷管理

简介: 测试活动之缺陷管理

以下为简单概述或者通用型描述,不同的项目或者业务会有所不同。

1 bug定义

BUG是一个英文单词,本意是指昆虫、小虫、损坏、犯贫、缺陷、窃听器等意思。现在一般是指在电脑系统或程序中,隐藏着的一些未被发现的缺陷或问题,简称程序漏洞。

2 bug关键信息

关键信息 说明
所属产品 产生缺陷的对应的产品
所属模块 缺陷产生的具体功能模块
所属项目 缺陷产生的具体项目
影响版本 发现缺陷的测试版本
当前指派 缺陷提交给对应的开发,缺陷的解决人
Bug类型 比如代码错误、环境配置错误等,见文章后文描述
操作系统浏览器 测试环境
严重程度 缺陷的严重等级
优先级 修复bug的先后以及对系统的影响
Bug标题 简单明了阐述bug发生的现象
重现步骤 测试步骤,很重要
附件 发现bug的依据(截图、视频、log等等)

3 bug书写注意事项

  • BUG必须标注:严重等级、优先级别并准确表述出问题内容及所在模块等,方便研发等人员快速定位问题并有序解决问题;
  • BUG标题:要以一个准确简练的句子描述某个模块存在的问题,或者某个操作导致了什么问题;
  • BUG内容:针对不同的原因导致的问题要包含对应的原因,例如手机的品牌、操作系统或者是浏览器名称、版本等;
  • BUG内容:常规BUG内容中要包含:操作步骤、实际结果、预期结果,语言要清晰准确;
  • BUG内容:若为特殊数据造成的问题,需提供具体测试数据;
  • 兼容性问题需在两个以上环境中确认BUG再进行提交;
  • 非必现BUG需进行10次以上测试,标注问题出现概率;
  • BUG的所有描述中,不要带有个人情绪或诽谤性词汇,要用专业名词、准确、客观的描述问题、实际结果及期望结果。

4 bug类型说明

简单概括,不同的业务和项目有所不同,不代表全部bug类型。

bug类型 说明
代码错误 程序bug
环境配置错误 由于测试环境配置文件没有配置正确引起的bug
转测程序/脚本错误 由于转测程序打包、遗漏数据库脚本引起的bug
系统性能问题 内存溢出、死机、程序卡死等问题
对需求理解有误 由于需求理解错误实现的与产品需求不一致
需求变更/未说明 需求未明确说明或变更后研发还未实现
测试与研发对需求理解不一致 同字面意思

5 bug严重程度

比如:致命、严重、一般、提示、建议。(详细根据项目情况定义,比如还有A、B、C、D;Ⅰ、Ⅱ、Ⅲ、Ⅳ等等)

6 bug生命周期

一般BUG的生命周期为:创建(激活)–确认(已确认)–解决(已解决)–关闭(已关闭)。
以禅道为例说明如下:

  • 测试人员在测试过程中,发现并创建BUG(创建完成后状态为:激活状态),记录产品缺陷,分析并跟踪BUG直至问题解决;
  • BUG创建后会指派给对应人员,若存在中间分析/分配BUG人员,则指派给该人员,分析/分配BUG的人员查看BUG并进行分析,确定为BUG则确认BUG(状态变为:已确认)并将问题指派给对应解决人员(一般为研发人员);
  • 研发人员及时分析处理问题,问题解决后修改BUG状态为:已解决,并填写解决方案、解决版本,然后指派给测试人员(一般为创建BUG的人员),若有特殊说明,则在备注中说明;
  • 测试人员对已解决状态的问题及时进行回归,若问题解决则关闭BUG,若问题未解决则激活。

7 bug解决方案说明

以禅道为例,BUG解决方案有:设计如此、重复BUG、外部原因、已解决、无法重现、延期处理、 不予解决。

  • 【设计如此】:若BUG所述内容与产品或设计图是一致的,则研发人员在将BUG置为已解决 状态时,可选择:设计如此 解决方案,但建议在备注内进行说明;
  • 【重复BUG】:若BUG为重复BUG,即已经存在与此相同的BUG,则研发人员在将BUG置为已 解决状态时,可选择:重复BUG 解决方案,并填写重复BUG的ID,若有特殊说明可在备 注内进行说明;
  • 【外部原因】:若BUG的出现原因为外部原因(例如硬件、第三方软件等导致的问题),则 研发人员在将BUG置为已解决时,可选择:外部原因 解决方案并在备注内进行说明;
  • 【已解决】:若BUG中描述的问题已解决,则研发人员在将BUG置为已解决状态时选择:已 解决 解决方案;
  • 【无法重现】:若BUG为无法重现的BUG,则研发人员在将BUG置为已解决状态时,可选择: 无法重现 解决方案,并在备注内进行说明,建议研发人员遇到此类问题联系测试人员进 行复现;
  • 【延期处理】:若研发人员考虑到时间等原因,觉得BUG需要延期进行处理,则在将BUG置 为已解决时,选择:延期处理 解决方案,并填写计划在哪个版本进行修复,在备注内进 行原因说明;
  • 【不予解决】:若研发人员在分析问题后觉得不是问题或者无需修改,则选择:不予解决 解 决方案 并在备注内写明不予解决的原因。

8 bug处理流程

8.1 简单流程

在这里插入图片描述

8.2 某工具复杂流程

在这里插入图片描述

9 bug管理工具

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述
有很多缺陷管理工具,这里简单罗列几个,可自行选择。

目录
相关文章
|
7月前
|
监控 测试技术
当测试发现300个缺陷时
当测试发现300个缺陷时
53 0
|
2月前
|
机器学习/深度学习 测试技术
ACL杰出论文奖:GPT-4V暴露致命缺陷?JHU等发布首个多模态ToM 测试集,全面提升大模型心智能力
【10月更文挑战第6天】约翰斯·霍普金斯大学等机构提出了一项荣获ACL杰出论文奖的研究,旨在解决大模型在心智理论(ToM)上的不足。他们发布了首个MMToM-QA多模态ToM测试集,并提出BIP-ALM方法,从多模态数据中提取统一表示,结合语言模型进行贝叶斯逆规划,显著提升了模型的ToM能力。这一成果为机器与人类自然交互提供了新思路,尽管仍面临一些局限性和技术挑战。论文详情见:https://arxiv.org/abs/2401.08743。
51 6
|
7月前
|
机器学习/深度学习 数据采集 人工智能
【专栏】AI在软件测试中的应用,如自动执行测试用例、识别缺陷和优化测试设计
【4月更文挑战第27天】本文探讨了AI在软件测试中的应用,如自动执行测试用例、识别缺陷和优化测试设计。AI辅助工具利用机器学习、自然语言处理和图像识别提高效率,但面临数据质量、模型解释性、维护更新及安全性挑战。未来,AI将更注重用户体验,提升透明度,并在保护隐私的同时,通过联邦学习等技术共享知识。AI在软件测试领域的前景广阔,但需解决现有挑战。
1018 6
|
3月前
|
机器学习/深度学习 人工智能 安全
软件测试中的探索性测试:一种高效发现软件缺陷的方法
本文将深入探讨软件测试中的一种关键方法——探索性测试。探索性测试是一种动态的、探索性的软件测试方法,它依赖于测试人员的直觉和经验,通过实际操作软件来发现潜在的问题和缺陷。与传统的基于预定义用例的测试方法相比,探索性测试更加灵活,能够更全面地覆盖软件的各个方面,从而更有效地发现难以预见的错误和漏洞。
42 2
|
4月前
|
监控 测试技术
软件测试中的风险管理:如何避免潜在缺陷
【8月更文挑战第5天】在软件开发的生命周期中,测试阶段扮演着至关重要的角色。本文将深入探讨软件测试中的风险管理,包括风险识别、评估和缓解策略。我们将通过具体案例分析,揭示如何在早期阶段预防和减少潜在的软件缺陷,以及如何通过有效的测试计划和执行来保障产品质量。文章旨在为读者提供一套系统的风险管理框架,帮助他们在软件开发过程中识别和应对各种测试风险。
204 3
|
7月前
|
前端开发 测试技术 数据安全/隐私保护
软件测试 —— 案例系统缺陷报告
软件测试 —— 案例系统缺陷报告
|
7月前
|
缓存 C语言 C++
【项目日记(九)】项目整体测试,优化以及缺陷分析
【项目日记(九)】项目整体测试,优化以及缺陷分析
|
7月前
|
测试技术
有了测试标准流程后缺陷就不会遗漏到线上吗?
有了测试标准流程后缺陷就不会遗漏到线上吗?
|
7月前
|
测试技术
『测试基础』| 如何理解测试用例管理和缺陷管理?
『测试基础』| 如何理解测试用例管理和缺陷管理?
221 1
|
监控 测试技术
测试思想-流程规范 软件测试缺陷管理流程
测试思想-流程规范 软件测试缺陷管理流程
185 0
下一篇
DataWorks