缺陷的基本概述

定义：软件未实现产品说明书要求的功能

软件出现了产品说明书指明不应该出现的功能

软件实现了产品说明书未提及的功能

软件未实现产品说明书虽未说明单应该实现的目标

软件难以理解、不易使用、运行缓慢或者（从测试的角度看）最终用户会认为不好

缺陷的定义和属性

1、缺陷的定义

2、缺陷的属性

缺陷类型：缺陷类型是根据缺陷的自然属性划分的缺陷种类

缺陷严重程度：缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度

缺陷优先级：缺陷的优先级是指缺陷必须被修复的紧急程度

缺陷状态：缺陷状态是指缺陷通过一个追踪修复过程的进展情况

缺陷起源

缺陷根源

缺陷类型：

功能Function、用户界面UI、文档Documentation、

软件包Package、性能Performance、系统/模块接口Interface

注意：

需求分析、设计阶段，文档类型的缺陷较多；

集成测试阶段，一般接口类型的缺陷较多；

系统测试阶段，功能和界面类型的缺陷较多；

验收测试阶段，更多的关注性能缺陷；

软件实施过程中，可能会遇到一些软件包的缺陷

缺陷的严重程度：

致命：系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机，或者危及人身安全

严重：系统主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或者服务受到明显影响

一般：系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不正确或用户界面差、操作时间长等问题

结合缺陷的影响程度、结合软件的具体功能（业务或者流程）。

缺陷修复的优先级：

立即解决：缺陷导致系统几乎不能使用或测试不能继续，需立即修复（很大程度取决于缺陷对测试工作的影响）

例如：电商系统的用户注册无法使用

（登陆功能、购买、结算、支付、下订单、物流跟踪、收货）都无法使用，就必须立即修复；

电商系统中关于用户购买流程帮助说明的 页链接点击后404页面。

高优先级：缺陷严重，影响测试，需要优先考虑

正常排队：

低优先级：

衡量优先级的技巧：一般可以根据测试软件系统的全业务流程划分，在划分的过程中，软件的基本功能的缺陷，优先级高，甚至需要立即解决；

软件的备选流程和基本功能测试中反向测试的内容，优先级较低，甚至可改可不改；

面试提问：

缺陷的严重程度和缺陷的修复优先级有什么关系/p>

1、二者之间没有任何直接的关系。

2、不要认为严重的缺陷优先级就高！！！

3、如果碰到优先级和严重程度都高的缺陷，也只是偶然。

例如：QQ的帮助按钮会引起软件闪退，说明严重程度很高、但是优先级很低。

站的logo被篡改，说明严重程度很低，但是优先级很高！！！

提交缺陷时，能不能夸大或者降低缺陷的严重程度、或者优先级能

缺陷的状态：

发现缺陷是缺陷处理的前提条件，但是还没有缺陷的处理流程。

1. 激活或者打开（新建）：由测试人员进行标注；
2. 确认状态：确认新提交的缺陷是一个真实有效的缺陷，一般由测试主管或者质量保障人员（QA）、产品经理进行。经确认后，有效的缺陷会指派给相关人员进行处理。
3. 已修复：在缺陷被修复后，一般由开发人员进行。
4. 关闭/非激活：缺陷被修复完成后，经过测试人员的验证后，没有问题。
5. 重新打开：经过测试人员验证后，缺陷没有修复成功，就需要重新打开，再次处理。
6. 推迟状态：缺陷现在不能修复，推迟到下一个版本或者状态。测试要和开发或者其他管理人员进行确认。
7. 保留缺陷：缺陷暂时修复不了，一般也是开发人员去设定。测试要和开发或者其他管理人员进行确认。
8. 不能重现：开发按照缺陷的复现步骤不能再次发现缺陷。一般闪退、崩溃的缺陷具有类似的特征。或者由于操作系统的差异或者浏览器缓存等问题，出现的问题。所以作为测试人员，提交bug之前要再三的确认bug。
9. 需要更多信息：作为测试人员，提交bug的时候，要尽可能把相关的文件一起提交（图片、视频）。
10. 重复：测试中，一定要避免这种情况的出现。尤其在软件的某一个功能频繁被多个模块调用、多个模块被不同人员测试的情况下。
11. 不是缺陷：一定不要在测试工程师的工作生涯中被开发标注缺陷状态为不是bug。
12. 需要修改软件规格说明书：缺陷不是技术造成的，而是由于需求不明确或者设计不明造成的。

缺陷的起源：

缺陷的根源：

缺陷的生命周期

发现缺陷—-提交缺陷—-确认缺陷—-分配缺陷—-修复缺陷—-验证缺陷—-关闭缺陷

或者从验证缺陷再次到提交缺陷，适用于缺陷未修复的状态

1. 发现缺陷。由测试人员，开发也能知道自己哪里写错了，但是不会广而告之；
2. 提交缺陷。由测试人员，开发更不可能提交bug；
3. 确认缺陷。一般由测试主管或者质量保证人员、产品经理进行确认；
4. 分配缺陷。一般由谁确认的就由谁分配，分配的对象可能是开发、也可能是UI，产品经理；
5. 修复缺陷。一般主要是开发修复，也有可能是产品经理修复需求问题、文档问题等；也有可能是UI去修复问题；
6. 验证缺陷。测试去验证缺陷是否修复成功。
7. 关闭缺陷。只能是测试人员进行。否则出了问题，测试人员一律不背锅。

面试提问：

你工作中发现的bug，说说这个bug的处理过程的就是生命周期中，每个环节都是做什么…..

缺陷的识别

• • 通过测试用例中的预期结果进行识别
  • 通过需求规格说明书进行识别
  • 通过用户手册以及其他文档进行识别
  • 通过同行业相类似的商业软件进行识别
  • 通过和开发人员的沟通进行识别
  • 通过和有经验的测试人员进行识别
  • 参考同行业隐式需求进行识别

依据：

需求文档、用户手册、设计文档、产品原型、测试用例，都是客观的依据；

同行业类似的成熟软件、和开发人员沟通（下下策）、跟有经验的测试人员沟通、同行业隐形需求进行分析，这些都是带有主观色彩的依据

测试人员在识别缺陷的时候，要很灵活的对待。

缺陷 告

1. 缺陷编 ：Bug_项目名称_模块名称_功能名称_0001
2. 所属模块：一级模块/二级模块/三级模块
3. 优先级：缺陷的修复紧急程度；P1>P2>P3（参考PPT中优先级）
4. 严重程度：S1>S2>S3>S4（参考PPT中严重程度）
5. 缺陷概述：用一句话去描述缺陷的基本情况
6. 缺陷描述：将缺陷的复现步骤、预期结果和实际结果描述出来
7. 提交人：测试人员
8. 备注：产生该缺陷的特殊情况，将bug的截图作为备注信息。

编写目的：

• 易于搜索软件测试 告的缺陷
• 告的软件缺陷进行了必要的隔离， 告的缺陷信息更具体准确
• 软件开发人员希望获得缺陷的本质特性和复现步骤
• 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度。

展现缺陷的详细信息、展现缺陷的影响程度和方式

预期读者：

开发人员、质量管理人员、市场人员、运维人员

编写准则：

Correct（准确）：每个组成部分的描述准确，不会引起误解

Clear（清晰）：每个组成部分的描述清晰，易于理解

Concise（简洁）：只包含必不可少的信息，不包含任何多余的内容

Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息

Consistent（一致）：按照一致的格式书写全部缺陷 告

缺陷描述的准则：

单一准确、可以再现、完整统一、短小简练、特定条件、补充完善、不做评价

可以再现：针对大多数的缺陷都是如此。但是一些小的缺陷是难以做的（类似闪退、崩溃这种不可再现的缺陷，无法做到。针对可以重复重新的闪退缺陷，也要进行步骤的详细描述）

不做评价。不对缺陷出现的严重程度和缺陷表现出来的效果进行主观测断。

缺陷 告本身保证没有任何表述性的错误。

禅道