缺陷

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：上⼀个版本发现的缺陷，开发修复完毕，在下个版本进⾏重新验证