缺陷的概念、优先级、生命周期等
文章目录
- 一、缺陷的基本概述
- 1.1缺陷的定义
- 1.2缺陷的属性
- 1.2.1缺陷的类型
- 1.2.2缺陷的严重程度
- 1.2.3缺陷的修复优先级
- 1.2.4缺陷的状态
- 1.2.5缺陷的起源、来源、根源
- 二、缺陷的生命周期(重点)
- 三、缺陷的识别
- 四、缺陷报告
- 4.1编写目的和预期读者
- 4.2报告编写准则
- 4.3缺陷描述准则
- 4.3缺陷报告模板和缺陷跟踪系统
一、缺陷的基本概述
1.1缺陷的定义
- 软件未实现产品说明书要求的功能
- 软件出现了产品说明书指明不应该出现的功能
- 软件实现了产品说明书未提到的功能
- 软件未实现产品说明书虽未明确提及但应该实现的目标
- 软件难以理解、不易使用、运行缓慢或者(从测试角度看)最终用户会认为不好
1.2缺陷的属性
属性名称 | 描述 |
---|---|
缺陷类型(type) | 缺陷类型是根据缺陷的自然属性划分的缺陷种类 |
缺陷严重程度(Severity) | 缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度 |
缺陷优先级(Priority) | 缺陷的优先级是指缺陷必须被修复的紧急程度 |
缺陷状态(Status) | 缺陷状态指缺陷通过一个跟踪修复过程的进展情况 |
缺陷起源(Origin) | 缺陷起源指缺陷引起的故障或事件第一次被检测到的阶段 |
缺陷来源(Source) | 缺陷来源指缺陷的起因 |
缺陷根源(Root Cause) | 缺陷根源指发生错误的根本因素 |
1.2.1缺陷的类型
缺陷类型 | 描述 |
---|---|
功能(Function) | 影响了各种系统功能、逻辑的缺陷 |
用户界面(UI) | 影响用户界面、人机交互特性,包括屏幕格式、用户输入灵活性、结果输出格式等方面的缺陷 |
文档(Document) | 影响发布和维护,包括注释、用户手册、设计文档 |
软件包(Package) | 由于软件配置库、变更管理或版本控制引起的错误 |
性能(Performance) | 不满足系统可测量的属性值,如执行时间、事务处理速率等 |
系统/模块接口(Interface) | 与其他组件、模块或设备驱动程序、调用函数、控制块或参数列表等不匹配、冲突 |
注意:需求分析、设计阶段,文档类型的缺陷多;集成测试阶段,一般接口类的缺陷多一些;系统测试阶段,功能、界面类型的缺陷多一些;验收测试阶段,更多的关注性能缺陷;实施过程,可能会遇到一些软件包的缺陷
1.2.2缺陷的严重程度
缺陷的严重程度是指因缺陷引起的故障对软件产品的影响程度
缺陷严重等级 | 描述 |
---|---|
致命(Fatal) | 系统任何一个主要功能完全丧失,用户数据受到破坏,系统崩溃、悬挂、死机。或者危及人身安全 |
严重(Critical) | 系统的主要功能部分丧失,数据不能保存,系统的次要功能完全丧失,系统所提供的功能或服务收到明显的影响 |
一般(Major) | 系统的次要功能没有完全实现,但不影响用户的正常使用。例如:提示信息不太准确或用户界面差、操作时间长等一些问题 |
较小(Minor) | 是操作者不方便或遇到麻烦,但它不影响功能的操作和执行,如个别不影响产品理解的错别字、文字排列不整齐等一些小问题 |
1.2.3缺陷的修复优先级
缺陷的优先级指缺陷必须被修复的紧急程度。例如:电商系统的用户注册功能无法使用(无法登录、购买、结算、支付、下订单、物流跟踪、收货、评价等功能都无法进行),就必须立即修复;电商系统中关于用户购买流程帮助说明的网页链接点击404页面
缺陷优先级 | 描述 |
---|---|
立即解决(P1级) | 缺陷导致系统几乎不能使用或测试不能继续,需立即修复 |
高优先级(P2级) | 缺陷严重,影响测试,需要优先考虑 |
正常排队(P3级) | 缺陷需要正常排队等待修复 |
低优先级(P4级) | 缺陷可以在开发人员有时间的时候被纠正 |
注意:优先级的衡量,一般可以根据测试的软件系统的全业务流程划分,软件的基本功能的缺陷,优先级高,甚至需要立即解决。软件的备选流程、基本功能测试中的反向测试的内容,优先级较低,甚至有些可改可不改。
面试提问:缺陷的严重程度和优先级有什么关系?
①二者之间没有任何直接的关系
②不要认为严重的缺陷,修复优先级就高
③如果碰到,优先级和严重程度都高的缺陷,也只是偶然。例如QQ的帮助按钮,会有经常闪退的现象。严重程度很高,但是优先级就很低。例如企业logo错误不影响任何功能,但是必须优先修复。
面试提问:提交缺陷时能不能夸大或降低缺陷的严重程度或者优先级?
不能
①不能搞“狼来了”
②也不能私人关系“帮”好朋友减少不良影响
1.2.4缺陷的状态
缺陷状态是指缺陷通过一个跟踪修复过程的进展情况。(处理进度)
发现缺陷时缺陷处理的前提,但是还没有进入缺陷的处理流程。
缺陷状态 | 描述 |
---|---|
激活或打开 | (测试人员)问题还没有解决,存在源代码中,确认“提交的缺陷”,等待处理,如新报的缺陷 |
确认 | 确认信提交的缺陷是一个真实有效的缺陷(测试主管或者质量保证(QA)、产品经理进行确认),经确认后,有效的缺陷会指派给相关人员进行处理 |
已修正或修复 | 已被开发人员检查、修复过的缺陷,通过单元测试,认为已解决但还没有被测试人员验证 |
关闭或非激活 | 测试人员验证后,确认缺陷不存在之后的状态 |
重新打开 | 测试人员验证后,还依然存在的缺陷,等待开发人员进一步修复 |
推迟 | 这个软件缺陷可以在下一个版本中解决(测试要跟开发或者其他相关的管理人员进行确认) |
保留 | 缺陷暂时修复不了(一般由开发人员设定,需要测试人员进行确认) |
不能重现 | 开发不能再现这个软件缺陷。一般闪退、崩溃类型的缺陷具有类似的特征,或者由于操作系统的差异、浏览器的缓存等信息,出现的问题。所以作为测试人员,提交bug之前,要再三地确认bug |
需要更多信息 | 作为测试人员,提交bug的时候,要尽可能的把所有相关的文件一起提交(文件、图片、视频) |
重复 | 这个软件缺陷已经被其他的软件测试人员发现 |
不是缺陷 | 一定不要在测试工程师的工作生涯中被开发标注缺陷状态为不是bug |
需要修改软件规格说明书 | 缺陷不是技术原因造成的,而是由于需求不明确或者设计不明确造成; |
1.2.5缺陷的起源、来源、根源
一般关注较多的是缺陷的来源(直接原因),在测试总结的时候,关注缺陷的根源。
(1)缺陷起源指缺陷引起的故障或事件第一次被检测到的阶段。
缺陷起源 | 描述 |
---|---|
需求 | 在需求阶段发现的缺陷 |
构架 | 在系统构架设计阶段发现的缺陷 |
设计 | 在程序设计阶段发现的缺陷 |
编码 | 在编码阶段发现的缺陷 |
测试 | 在测试阶段发现的缺陷 |
用户 | 在用户使用阶段发现的缺陷 |
(2)缺陷来源指缺陷的起因
缺陷来源 | 描述 |
---|---|
需求说明书 | 需求说明书的错误或不清楚引起的问题 |
设计文档 | 设计文档描述不准确,和需求说明书不一致的问题 |
系统集成接口 | 系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷 |
数据流(库) | 由于数据字典、数据库中的错误引起的缺陷 |
程序代码 | 是编码中的问题所引起的缺陷 |
(3)缺陷根源指发生错误的根本因素
缺陷根源 | 描述 |
---|---|
测试策略 | 错误的测试范围,误解了测试目标,超越测试能力等 |
过程、工具和方法 | 无效的需求收集过程,过时的风险管理过程,不适用的项目管理方法,没有估算规程,无效的变更控制过程等 |
团队/人 | 项目团队职责交叉,缺乏培训。没有经验的项目团队,缺乏士气和动机不纯等 |
缺乏组织和通讯 | 缺乏用户参与,职责不明确,管理失败等 |
硬件 | 硬件配置不对、缺乏,或处理器导致算术精度丢失,内存溢出 |
软件 | 软件设置不对、缺乏,或操作系统错误导致无法释放资源,工具软件的错误,编译器的错误,千年虫的问题等 |
工作环境 | 组织机构协调 ,预算改变,工作环境恶劣,如噪音过大 |
二、缺陷的生命周期(重点)
发现缺陷:由测试人员
提交缺陷:由测试人员
确认缺陷:一般由测试主管、或者质量保证(QA)、由产品经理进行确认
分配缺陷:一般由谁确认的缺陷,就由谁分配。分配的对象可能是开发、也可能时UI、也可能是产品经理
修复缺陷:主要由开发修复,也有可能是产品经理修复问题,也有可能是UI修复问题
验证缺陷:测试去验证缺陷有没有修复成功
关闭缺陷:只能是测试人员进行。否则出了问题,测试人员一律不背锅
面试提问:针对你工作中发现的一个bug,说说这个bug的处理过程(缺陷的生命周期中,每个环节由谁做什么)
三、缺陷的识别
依据:需求文档、设计文档、产品原型、测试用例,都是客观的依据
- 通过测试用例中的预期结果进行识别
- 通过需求规格说明书进行识别
- 通过用户手册及其他文档进行识别
- 通过同行业相类似成熟的商业软件来识别
- 通过和开发人员的沟通进行识别
- 通过和有经验的测试人员沟通进行识别
- 参照同行业隐式需求进行识别
测试人员在识别缺陷的时候,要很灵活的对待
四、缺陷报告
1、缺陷编号:Bug_项目名称_模块名称_功能名称_0001
2、所属模块:一级模块/二级模块/三级模块。例如:上课所用的直播软件,如果想要查看签到的历史记录,需要进入直播主界面—互动应用—签到—签到历史记录
3、优先级:缺陷的修复紧急程度。p1>p2>p3>p4
4、严重程度:s1>s2>s3>s4
5、缺陷概述:用一句话描述缺陷的基本情况
6、缺陷的描述:将缺陷的复现步骤、预期结果和实际结果列出来
7、提交人:XXX
8、备注:一般写产生缺陷的特殊情况,将bug的截图作为备注信息
缺陷编号 | 所属模块 | 优先级 | 严重程度 | 缺陷概述 | 缺陷描述 | 提交人 | 备注 |
---|---|---|---|---|---|---|---|
P1/P2/P3/P4 | S1/S2/S3/S4 | 一句话描述(时间、地点、人物、事件) | 复现步骤、实际结果、预期结果 | XXX | 特殊条件、产生该缺陷的测试用例 | ||
Bug_项目名称_模块名称_功能名称_0001 | 用户管理/二级模块 | P3 | S3 | 在多边形判断程序首页点击三边形按钮,应当出现三边形的示例图片,但是实际出现的是五边形的图案 | 复现步骤:1、使用chrome浏览器打开多边形判断程序的页面;2、点击三边形按钮。实际结果:示例图片为五边形的图案。预期结果:示例图片为三边形的图案 | 杨凯凯 |
4.1编写目的和预期读者
(1)缺陷报告编写目的:
- 易于搜索软件测试报告的缺陷
- 报告的软件缺陷进行了必要的隔离,报告的缺陷信息更具体、准确
- 软件开发人员希望获得缺陷的本质特征和复现步骤
- 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度
(2)预期读者:
- 开发人员、质量管理人员、市场人员、运维人员……
4.2报告编写准则
- Correct(准确):每个组成部分的描述准确,不会引起误解
- Clear(清晰):每个组成部分的描述清晰,易于理解
- Concise(简洁):只包含必不可少的信息,不包括任何多余的内容
- Complete(完整):包含复现改缺陷的完整步骤和其他本质信息
- Consistent(一致):按照一致的格式书写全部缺陷报告
4.3缺陷描述准则
- 单一准确
- 可以再现(针对大多数的缺陷都是如此。但是有一些小部分的缺陷是难以做到,类似闪退、崩溃这种不可再现的缺陷,无须做到。针对一些可以重复出现的闪退缺陷,也要进行步骤的详细描述)
- 完整统一
- 短小简练
- 特定条件
- 补充完善
- 不做评价(不对缺陷出现的严重程度和缺陷表现出来的效果进行主观臆断)
- 缺陷报告本身要保证没有任何表属性的错误
4.3缺陷报告模板和缺陷跟踪系统
缺陷报告模板
缺陷编号 | 所属模块 | 优先级 | 严重程度 | 缺陷概述 | 缺陷描述 | 提交人 | 备注 |
---|---|---|---|---|---|---|---|
Bug_OA_CJGL_ZZJG_0001 | 一级模块/二级模块 | P1/P2/P3/P4 | S1/S2/S3/S4 | 一句话描述(时间、地点、人物、事件) | 复现步骤、实际结果、预期结果 | XXX | 特殊条件、产生该缺陷的测试用例编号 |
缺陷跟踪系统
- Bugzilla(英文):安装比较繁琐
- Bugfree:中文 安装简单 用例 缺陷的跟踪 功能单一
- 禅道:中文 国产 项目 产品 测试 安全 组织机构 人员 开源 免费
- QC(ALM):外国 英文 功能齐全
- JIRA:国外的软件 Java环境 主流 (商业)
- 企业自己开发
缺陷的概念、优先级、生命周期等相关推荐
- 软件测试基础知识(二)------------等价类划分法、边界值分析法、场景法、错误推测法、bug定义/类型/优先级/生命周期/跟踪管理
等价类划分法 是把程序的输入域划分成若干个子集合(等价类),然后从每个子集合(等价类)中选取少数具有代表性的数据作为测试的输入数据. 在该子集合中,所有的输入数据对于揭露软件中的错误都是等效的.--- ...
- Fragment系列总结(一)Fragment概念与生命周期
写在前面 Fragment是Google在Android3.0新加的东西,它的功能和作用如同名字一样,代表着一块块碎片,而这些碎片则可以灵活地嵌入到各Activity之中. 其他关于Fragment的 ...
- Linux 进程信号:信号的概念、生命周期、产生流程、阻塞
信号的概念 信号的生命周期 信号的阻塞 信号的概念 信号 信号是一个软中断.操作系统通过信号通知某个进程发生了某件事件,然后中断这个进程当前操作,让它优先去处理这个事件. 我们在linux下常用的ki ...
- Servlet→对象监听器、事件监听器、Session钝化活化、@WebListener标注、过滤器概念原理生命周期、过滤器链、@WebFilter标注、定时器Timer、cancel()、purge
监听器ServletContextListener HttpSessionListener ServletRequestListener 事件监听器 Session钝化活化 @WebListener标 ...
- java线程池的概念_Java线程池的基本概念以及生命周期
一.为什么要实现线程池? 线程的创建与销毁对于CPU而言开销较大,通过池化技术可避免重复的创建与销毁线程. 方便与线程资源统一管理. 二.几种常见的线程池以及核心参数 不推荐使用Executor创建线 ...
- maven(7)生命周期和插件
[0]README 1)本文部分文字转自 "maven实战",旨在 review "maven(7)生命周期和插件" 的相关知识: 2)maven 另外两个核 ...
- spring生命周期七个过程_Spring杂文(三)Spring循环引用
众所周知spring在默认单例的情况下是支持循环引用的 Appconfig.java类的代码 @Configurable @ComponentScan("com.sadow") p ...
- 罗格数据:生命周期动态模拟技术及其在税收领域应用初探 | 会员专栏
本篇发表于:<税务研究>2018.10 总第 405 期 由罗格研究院"互联网+税务"课题组(北京罗格数据科技有限公司 北京 100080)提供 在2018年<税 ...
- 从全生命周期管理角度看大数据安全技术研究
从全生命周期管理角度看大数据安全技术研究 李树栋1,2, 贾焰2, 吴晓波3, 李爱平2, 杨小东4, 赵大伟5 1. 广州大学网络空间先进技术研究院,广东 广州 510006 2. 国防科技大学计算 ...
- 微信小程序开发:微信小程序生命周期总结
前言 在微信小程序开发中,关于微信小程序API的使用是必备技能,但是关于微信小程序的生命周期也是首先要了解和掌握的知识点.尤其是现在的前端开发领域,关于前端的各种框架和技术都要会,而且微信小程序的语法 ...
最新文章
- 中文停用词文档_使用Python中的NLTK和spaCy删除停用词与文本标准化
- .NET MYSQL数据库操作基类( C#源码)
- SQL 异常处理 Begin try end try begin catch end catch--转
- 循环服务器,并发服务器模型以及I/O多路转接模型
- php 双向队列,PHP实现一个双向队列
- KMP算法 --- 深入理解next数组
- [转载] Java异常处理中Try-Catch-Finally中常见的笔试题
- 可能是国内最火的开源项目 —— C/C++ 篇
- Android-LayoutParams的那些事
- LINUX SHELL能不能调用桌面刷新命令,或者模拟键盘输入F5?
- qq空间音乐外链,音乐永久地址,连接dj,连接音乐,背景音乐,舞曲背景0sm.com
- WPS中添加页眉和页脚
- linux 编译libvlc,libvlc源码编译
- 个人计算机键盘上的按键击键声音小,按键盘每个键出现嘟嘟的声音也打不出字是什么...
- 页面加载数学公式,mathjax转html
- python 折线图标签_如何使用python绘制折线图?
- 数据校验之Checksum算法
- 2022年软件测试人员必读的经典书籍推荐(附电子版)
- Akm函数递归与非递归解法
- 狼的故事17:大结局
热门文章
- 冯·诺依曼体系结构 -- 理解
- 数据结构 | 顺序表
- 设f(x)=∑x^n/n^2,证明f(x)+f(1-x)+lnxln(1-x)=∑1/n^2
- html-2-禁止手机页面放大缩小
- navicat 16安装 注册机path报错
- [Vue warn]: Unknown custom element: <helptext> - did you register the component correctly? For recu
- 13.不抱怨的世界--美,威尔.鲍温,陈敬旻译,2017-12-10
- 软件的生命周期SDLC
- 白兵机器人怎样连接_“玩具之家”的新宠——星战白兵冲锋队员机器人体验
- dz程序上传服务器的位置,dz手机端上传到远程服务器