缺陷
1.缺陷:软件在使用过程中存在的任何问题都叫软件的缺陷,简称bug
2.缺陷的判定标准:
a.软件未实现需求(规格)说明书中明确要求的功能(少功能)
b.软件实现的功能超出需求(规格)说明书指明的范围(多功能)
c.软件出现了需求(规格)说明书中指明不应该出现的错误(功能错误)
d.软件未实现需求(规格)说明书中虽未明确指明但应该实现的要求(隐性功能错误)
e.软件难以理解,不易使用,运行缓慢,用户体验不好(不易使⽤)
用例执行:用例的执⾏结果与⽤例的期望结果不⼀致(含义),为缺陷(⽤例执⾏不通过为缺陷,需要进⾏缺陷管理)
3.缺陷产生的原因:
a.需求:
1.需求不明确:软件需求不清晰或者开发人员对需求理解不明确,导致软件在设计时偏离客户的需求目标,
造成软件功能或特征上的缺陷
2.在开发过程中,客户频繁变更需求也会影响软件最终的质量
b.架构设计:
1.如果软件系统结构比较复杂,很难设计出一个具有很好层次结构或组件结构的框架,
这就会导致软件在开发、扩充、系统维护上的困难
2.即使能够设计出一个很好的架构,复杂的系统在实现时也会隐藏着相互作用的难题,而导致隐藏的软件缺陷
c.编码问题:
在软件开发过程中,程序员水平参差不齐,再加上开发过程中缺乏有效的沟通和监督,问题累积越来越多,
如果不能逐一解决这些问题,会导致最终软件中存在很多缺陷
d.项目期限短:
现在大部分软件产品开发周期都很短,开发团队要在有限的时间内完成软件产品的开发,压力非常大,
因此开发人员往往是在疲劳、压力大、受到干扰的状态下开发软件,这样的状态下,
开发人员对待软件问题的态度是 “不严重就不解决
e.使用新技术:
现代社会,每种技术发展都日新月异。使用新技术进行软件开发时,如果新技术本身存在不足或开发人员对新技术
掌握不精,也会影响软件产品的开发过程,导致软件存在缺陷
f.环境(硬件、软件):
4.软件缺陷的生命周期:
生命周期:是一个物种从诞生到消亡经历了不同的生命阶段
软件缺陷生命周期:是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程
生命周期中缺陷状态:新建-->指派-->已解决-->待验-->关闭
在整个软件缺陷生命周期中,通常是以改变软件缺陷的状态来体现不同的生命周期的状态的变化,
来跟踪项目进展的软件质量
如果待验的BUG在验证时没有解决好,我们需要重新打开--指派—已解决—待验,循环这个过程
中间其他状态:拒绝、延期等
简化版:
发现-打开:测试人员找到软件缺陷并将软件缺陷提交给开发人员。
打开-修复:开发人员再现、修复缺陷、 然后提交给测试人员去验证。
修复-关闭:测试人员验证修复过的软件,关闭已不存在的缺陷
详细版:
1.发现bug:
a.按照测试用例进行操作,发现和测试用例的预期结果不一致的
b.还有就是成本问题,比如没有充足的时间去编写测试用例
c.测试用例不可能穷尽,总有超出你预料之外的因素,或者是神操作出现的bug
2.提交bug:
在提交一个缺陷的时候,首先尽量描述这个缺陷的属性、Bug重现环境,bug类型,bug等级,
bug的优先级以及详细的重现步骤,结果与期望等
当然,我们在提交一个缺陷之前首先应该保证,这个缺陷是没有被提过的,以免造成重复缺陷单
3.指派bug:
a.这一步不是必须的,跟项目模式有关,有些公司测试部门与开发部门独立,那么测试人员就不确定
自己测试的模块是由哪位开发人员负责的,在这种情况下,测试人员统一把问题指派给项目组长或经理
由项目组长(或经理)对问题进行确认后再次分配给相应的开发人员
b.有些测试是穿插到不同研发团队中的,所以对不同的开发负责的开发模块非常清楚,
这个时候就可以将问题直接指派给相应的开发人员
c.也有一种情况,本来此问题应该由A开发人员负责,但由于A开发人员的调离或辞职,
这些问题为转交给其它人员处理
“分配”强调是上级对下级;“转交”强调的是平级之间
4.确认缺陷:
当开发人员接到一个缺陷时,首先是对其进行分析与重现,如果对其进行分析发现不是缺陷
(可能由于测试人员不了解需求),或无法对此问题进行重现,那么就需要将此问题反回给测试人员
并注明原因,如果确认为缺陷则需要对其进行处理
5.修复BUG:
a.推迟处理
在处理问题之前,还需要进行一次判断,是否需要推迟处理,有些需求已经确认了是问题,
由于其可能在极端情况下才会出现,或需要对系统架构进行改动,或其优先级非常低,
所以暂时不需要对此问题进行处理(或到下个版本进再进行修复)
b.固定:
对于推迟处理的问题可以暂时进行固定(“固定”为QC中的叫法。)
一般固定的问题需要经过项目经理与测试经理协商后才能固定。
处理缺陷:
开发人员在确认完一个问题需要处理时,那么就对其进行处理工作。
(例如,redmine 是支持处理人时时更新问题处理进度的,如 已处理30% ,已处理80% 等,
当然,对于短时间内可以修复的问题就没必要时时的去更新处理进度。)
6.回归验证BUG:
回归缺陷对于测试人员来说是非常重要的工作,其有三个入口两个出口
a.确认非缺陷问题:对于提交的一个缺陷,开发人员处理为非问题或无法重现,
然后直接转交给测试人员回归,测试人员再次确认,如果真如开发人员所说,
则将问题关闭。如果非开发人员所说,是由于问题描述模糊或其它原因未重现问题,
则再次注明原因转给开发人员
b.确认修复问题:对开发人员修复的问题再次进行确认,确认能过,则关闭问题。
确认不通过,将问题再次打开并转给开发人员
c.确认固定问题:有计划的对固定问题进行确认,有些固定问题随着时间的推移,版本的更新或已经不存在了,
对这类问题应该及时关闭,有些固定问题依然存在且变得紧急,
对于这类问题应该及时打开交给开发人员处理
7、关闭缺陷:
对于已经修复的缺陷进行关闭,这也是一个缺陷的最后一个状态
注!!!
1、回归测试:
①常规项⽬回归:项⽬本次发布新增2个模块,最基本要测新增模块功能及新增模块关联的旧模块
②⾮常规项⽬(银⾏、部队、航天):新增功能,必须全部复测
2、回归bug:上⼀个版本发现的缺陷,开发修复完毕,在下个版本进⾏重新验证
5.缺陷六大核心要素:缺陷标题、前置条件、复现步骤、预期结果、实际结果、附件备注
⾯试题:发现缺陷后,⾸先会怎么办?
确定Bug可复现、确定是Bug,提交时,要检查缺陷是否已存在
标签:软测,开发人员,测试人员,问题,笔记,软件,缺陷,bug From: https://www.cnblogs.com/noproblems/p/17500518.html