(四)Bug的生命周期
Bug的属性
Bug重现环境
这个应该是我们重现bug的一个前提,如果没有这个前提,我们可能会无法重现问题,或者跟本就无从下手。
- 操作系统
这个是一般软件运行的一大前提,基本上所有的软件都依赖于操作系统之上的,对于一个软件来说,要想在某个操作系统上运行,必须要对这个操作系统支持,这就需要有真对性的设计与开发。对于不同的操作系统,其可能存在差异(如:win xp 与 win 7)或本质的区别(如 win 7 与 CentOS linux ),所以,操作系统环境是重现问题的一个重要前提。
- 浏览器
对于B/S系统,或面向大众的互联网产品(网站,邮箱等),浏览器的兼容性也是必须测试的一个重点,对于现在的浏览器市场,各式的浏览器都有其用户群,要想使产品大众化,必须考虑这些产品的兼容性问题。
不同的浏览器之间(IE、 firefox、chrome、opera 等),甚至同一系列不同版本(ie6/ie7/ie8/ie9等)都可能存在兼容性问题,所以,对于这类应用,浏览器环境重现bug前提条件之一。
- 其它(这个“其它”非常重要)
对于不同的系统发现重现问题,都会有其特定的前提,拿我测试的邮箱来说,必须要描述其是在测试线还是现网环境,而且还要附带一重现问题的帐号等。
对于c/s软件,可能还要考虑与其它常用软的兼容等,例如,是在安装的某款软件后,对本软件的安装和使用造成影响。这些都是重现问题的必须描述的环境。
问题类型
根据JIRA的管理系统的划分,bug 只是问题的一种,它可以用于跟踪多种不同类型的问题(其实,他只是将bug做为一子类而已)。
JIRA系统缺省提供的问题类型(大部分的系统都可以自定义类型的,这样就增加了灵活性。)
- Bug : 测试过程、维护过程发现影响系统运行的缺陷。(这就是一般测试人员所提交的bug)
- New Feature : 对系统提出的新功能。(单个的小需求可以,如果大的话,就相当于一个需求,放到这里是不合理的。)
- Task : 需要完成的一任务。(开发或测试任务指派。)
- Improvement : 对现有系统功能的改进。(一般产品经理或产品体验师做的事)
当然,不同的公司,他们的人员定位与职责是不太相同的,按照上面的分类,JIRA就不是简单的缺陷管理系统了,它涵盖一项目(或产品)所需要处理的任务、需求与缺陷。
Bug 类型
这里缩小范围,单指我们测试人员在测试过程中发现的缺陷,发现产品缺陷其实就是测试人员工作的主要目的。当然,你要确定一个问题的类型,也需要对项目(或产品)有比较深的理解。是代码缺陷还是设计缺陷有时候就不太容易区分,当然,这个划分,对于开发定位问题影响很小,但对于问题类型的统计就比较重要了。
下面看一些常见的分类:
划分方式一: ``` * 代码错误
* 设计缺陷
* 界面优化
* 配置相关
* 安装部署
* 性能问题
* 标准规范
* 测试代码
* 其它 划分方式二:
* 功能类(function)
* 性能类(performance)
* 界面类(UI)
* 易用性类(usability)
* 兼容性类(compatibility)
* 其它(else) ```这个分类当然是可以自定义的,具我接触的缺陷管理都是可以自定义的,既然是对问题的管理,那么你当然可以拿来做特定环境下的系统来使用,或我就想用这个系统来指派任务,那么我的自定义类型为前端任务、后端任务、测试任务、配置部署…
缺陷等级
缺陷等级,这个划分也比较灵活,有分三级或四级,也有分五级的。
- 致命
一招毙命的缺陷,使你的系统无法运行,有造成数据泄漏的安全性问题。
- 严重
可以引起易于纠正的异常情况、可能引起易于修复的故障或对产品外观难以接受的缺陷。
- 一般
指不影响产品的运转和运行、不会成为故障起因,但对产品外观和下道工序影响较大的缺陷
- 轻微
轻微缺陷是指对产品外观和下道工序可能会有轻微影响的缺陷
- 建议
增加用户使用体验的建议性问题。(一般情况下,建议也为做为缺陷的一种。这个跟系统的类型与需求有关)
缺陷优先级(priority)
当问题处理人员在面对许多问题需要处理进,就需要问题进行优先级排序。我们做事情的安排,操作系统有处理进程等都在使用着优先级。
优先级的划分: ```低——>中——>高——>紧急
延迟处理——>正常排队——>优先处理——>紧急处理 ```Bug的严重程度和优先级是含义不同但相互联系密切的两个概念,它们从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程序和处理方式。
一般地,严重程序高的软件缺陷具有较高的优先级。严重程度高说明缺陷对软件造成的危害性大,需要优先处理,而来严重程序低的缺陷可能只是软件不太尽善尽美,可以稍后处理。
- 严重程度高优先级不一定高:
如果某个严重的软件缺陷只在非常极端的条件下产生,则没有必要马上处理。
如果某一个软件缺陷,需要重新修改软件的整体架构,可能会产生更多的潜在缺陷,而且软件由于市场的压力必须尽快发布,此时即使缺陷的严重性很高,是否需要修正,需要全盘考虑。
- 严重程度优先级不一定低
如果是软件名称或公司名称的拼写错误,虽然说其属于界面错误,严重程度不高,但其关系到软件和公司的市场开解,必须尽快修正。
缺陷状态
对于一个问题,其处理过程是一个周期,周期的不同阶段,其所处的状态也是不一样的。不同状态所对应的处理人也是不一样的。
- 打开: 表示问题被提交等待有人处理。
- 重新指派 : 问题被重新指派给某人处理。
- 处理 : 问题在处理中,尚未完成。
- 固定 : 确认此问题存在,但暂时不进行处理。
- 回归 : 对已经修复的问题进行回归确认。
- 关闭 : 问题的最后一个状态。
一个bug的生命周期
下面通过一个比较完整的bug的处理流程图,更深刻的理解bug的状态以一个bug的生命周期。
提交(打开)缺陷
在提交一个缺陷的缺陷,首先尽量描述这个缺陷的属性。Bug重现环境,bug类型,bug等级,bug的优先级以及详细的重现步骤,结果与期望等。
当然,我们在提交一个问题之前首先应该保证,这个缺陷是没有被提过的,以免造成重复缺陷单。
如果是回归不通过的缺陷,其状态又会变为打开状态。
分配(转交)缺陷
这一步不是必须的,跟项目模式有关,有些公司测试部门与开发部门独立,那么测试人员就不确定自己测试的模块是由哪位开发人员负责的,在这种情况下,测试人员统一把问题指派给项目组长或经理,由项目组长(或经理)对问题进行确认后再次分配给相应的开发人员。
有些测试人员是穿插到不同研发团队中的,所以对不同的开人发员负责的开发模块非常清楚,这个时候就可以将问题直接指派给相应的开发人员。
也有一种情况,本来此问题应该由A开发人员负责,但由于A开发人员的调离或辞职,些问题为转交给其它人员处理。“分配”强调是上级对下级;“转交”强调的是平级之间。
确认缺陷
当开发人员接到一个缺陷时,首先是对其进行分析与重现,如果对其进行分析发现不是缺陷(可能由于测试人员不了解需求)或无法对此问题进行重现,那么就需要将此问题反回给测试人员,并注明原因。如果确认为缺陷则需要对其进行处理。
推迟处理
在处理问题之后,还需要进行一次判断,是否需要推迟处理,有些需求已经确认了是问题,由于其可能在极端情况下才会出现,或需要对系统架构进行改动,或其优先级非常低,所以暂时不需要对此问题进行处理(或到下个版本进再进行修复)。
固定
对于推迟处理的问题可以暂时进行固定(“固定”为QC中的叫法。)一般固定的问题需要经过项目经理与测试经理协商后才能固定。
处理缺陷
开发人员在确认完一个问题需要处理时,那么就对其进行处理工作。(例如,redmine 是支持处理人时时更新问题处理进度的,如 已处理30% ,已处理80% 等,当然,对于短时间内可以修复的问题就没必要时时的去更新处理进度。)
回归缺陷
回归缺陷对于测试人员来说是非常重要的工作,其有三个入口两个出口。
确认非缺陷问题:对于提交的一个缺陷,开人员处理为非问题或无法重现,然后直接转交给测试人员回归。测试人员再次确认,如果真如开发人员所说,则将问题关闭。如果非开发人员所说,是由于问题描述模糊或其它原因喂重现问题,则再次注明原因转给开发人员。
确认修复问题:对开发人员修复的问题再次进行确认,确认能过,则关闭问题。确认不通过,将问题再次打开并转给开发人员。
确认固定问题:有计划的对固定问题进行确认,有些固定问题随着时间的推移,版本的更新或已经不存在了,对这类问题应该及时关闭。有些固定问题依然存在且变得紧急,对于这类问题应该及时打开交给开发人员处理。
关闭缺陷
对于已经修复的缺陷进行关闭,这也是一个缺陷的最后一个状态。
最后,“状态”和“指派人”的对应关系如果更加细化,对项目而言是有益的: ```已关闭—>指派给修复这个bug的开发工程师。
无需解决,不是bug—>指派给提交这个bug的测试人员。
无需解决,迭代待解决—>指派给项目的产品经理。 ```
(四)Bug的生命周期相关推荐
- 测试:bug的生命周期、bug的等级、如何描述一个bug
一.Bug 的生命周期 new - open - fixing - verify - close 发现bug–>提交bug–>指派bug–>研发确认bug–>研发去修复bug– ...
- 测试篇(二): 如何合理的创建bug、bug的级别、bug的生命周期、跟开发产生争执怎么办
目录 一.如何合理的创建bug 二.bug的等级 三.bug的生命周期 四.和开发产生争执怎么办 一.如何合理的创建bug 创建Bug的目的就是为了能够让其他人可以尝试复现 一个合格的bug应该包含以 ...
- 软件测试(基础)· 软件测试的生命周期 · 如何描述一个 Bug · Bug 的级别 · Bug 的生命周期 · 争执 · Bug 评审
一.软件测试的生命周期 软件测试的生命周期 & 软件开发的生命周期 二.如何描述一个 Bug 三.如何定义 Bug 的级别 四.Bug 的生命周期 五.发生争执了怎么办? Bug 评审 一.软 ...
- Angular 个人深究(四)【生命周期钩子】
Angular 个人深究(四)[生命周期钩子] 定义: 每个组件都有一个被 Angular 管理的生命周期. Angular 创建它,渲染它,创建并渲染它的子组件,在它被绑定的属性发生变化时检查它,并 ...
- Bug的生命周期_Sinno_Song_新浪博客
1.Bug的属性: .Bug出现的环境:指这个Bug是在什么系统环境下出现的,如:国内几大安卓手机的不同型号不同版本,Ios不同型号不同系统版本.B/S架构下,用户使用不同浏览器.内核.版本不同等等不 ...
- 详解BUG(又名:BUG的生命周期)
测试人员最本质的工作就是寻找bug,提交bug.验证bug.推进bug的解决,直至软件达到发布的标准,提高软件的质量,及研发的工作效率和质量. 一.什么是bug 软件的BUG,狭义概念是指软件程序的漏 ...
- bug的生命周期你知道吗?一张图带你看懂它!
目录 1.什么是bug 2.bug的生命周期 3.如何描述一个bug 4.bug的级别 1.什么是bug 软件的bug狭义方面可以理解为是指软件程序的漏洞或缺陷,广义方面除找到程序漏洞之外,还包括测试 ...
- 软件测试---BUG的生命周期
测试人员最本质的工作就是寻找bug,提交bug.验证bug.推进bug的解决,直至软件达到发布的标准,提高软件的质量,及研发的工作效率和质量. 一.什么是bug 软件的BUG,狭义概念是指软件程序的漏 ...
- 软件测试中Bug的生命周期以及Bug的严重等级
Bug的生命周期中有很多个状态,下面我就为大家比较细致的罗列出一个Bug从它被创建到关闭的过程: 1.首先当测试人员接到一个项目或产品准备测试的时候,测试人员会根据测试用例一步步的来执行用例进行简单的 ...
最新文章
- const函数和const对象
- 极限与连续知识点总结_高数上知识点期末复习 极限、连续、间断点(一)
- [mybatis]映射文件_参数处理_#取值时指定参数相关规则
- 加密解密概述及openssl应用及其创建CA和签发证书的实现
- SAP License:SAP的公司间销售
- python大文件排序_Python如何实现大文件排序?Python大文件排序的实现方法
- 马斯克又一个宏伟蓝图即将启动:卫星高速上网,没有中间商赚差价
- java 使用 lamba 表达式处理二维数组
- java访问权限的控制
- FIO压测-SSDvsHDD
- sl400升级win10_联想SL400全安装WIN7(官方最完美教程).doc
- (已解决)ubuntu16.04蓝牙耳机与电脑配对成功,但不出现在声音输出设备里
- 基于FPGA的光口通信开发案例|基于Kintex-7 FPGA SFP+光口的10G UDP网络通信开发案例
- matlab 读取mdf文件路径,访问 MDF 文件
- MATLAB Simulink Example
- MathWorks 中国
- Unity 事件中心
- 我的母校照片~~``
- Oracle11g pl-sql developer安装包及教程
- linux测试读写的工具,Linux 下的硬盘读写速度测试工具
- 如何正确关闭MongoDB
- mac使用u盘安装系统
热门文章
- 分式计算机,计算机网络与分式系统.ppt
- 汇编SHR、SHL、SAR、SAL、ROL、ROR、RCL、RCR指令
- 神探夏洛克 Sherlock: The Abominable Bride (2016)
- 港科夜闻|香港科大新研究显示预期接种疫苗和加强针后产生的T细胞免疫屏障将能继续保护人体并减少被Omicron等病毒变异的感染机率...
- 学习表——受任于败军之际,奉命于危难之间(2.20--2.26)
- 如何在 Vue 中使用 Chart.js - 手把手教你搭可视化数据图表
- 改进YOLOv5、YOLOv8系列:29.YOLOv5 结合 极简又强大的RepVGG 重参数化模型结构
- 微信小程序集成实时音视频通话功能
- Android系统打不开,如何修复它:Android手机无法启动
- 【安卓笔记】android申请储存权限,读写文件