缺陷和缺陷报告

一、缺陷的基本概述

 1、缺陷的定义

软件未实现产品说明书要求的功能
软件出现了产品说明书指明不应该出现的功能
软件实现了产品说明书未提到的功能
软件未实现产品说明书虽未明确提及在应该实现的目标
软件难以理解、不易使用、运行缓慢或者（从测试的角度看）最终用户会认为不好

2、缺陷的属性

后三个了解就行

 缺陷优先级：在正常的软件测试过程中，所有的测试用例都是正向的缺陷优先进行，正向的测试用例产生的缺陷，它的修复的紧急程度要比反向的要高而且高不少。

1）缺陷的类型：功能（Function）、用户界面（UI）、文档（Documentation）、软件包（Package）、性能（Performance）、系统/模块接口（Interface）

注意：需求分析、设计阶段，文档类型的缺陷多一些；系统测试阶段，功能、界面类型的缺陷多一些。验收测试阶段，更多的关注性能缺陷；实施过程中可能会遇到一些软件包的缺陷。

2）缺陷严重程度：因缺陷的故障对软件的影响。一般有分类，每个公司和团队的分类标准或略有不同

致命（系统任何一个主要功能完全丧失）、严重（主要功能部分丧失）、一般（次功能没有完全实现，不影响用户使用）、较小（如有错别字等）

注意：结合缺陷的影响，结合软件的具体功能（业务或者流程）。

3）缺陷优先级：很大程度上取决于缺陷对测试工作的影响程度

例如：电商系统的用户注册功能无法使用（无法登录、购买、结算、支付、下订单、物流跟踪、收货、评论等功能都无法进行），就必须立即修复电商系统中关于用户购买流程帮助说的网页链接点击404页面。

P1级立即解决：缺陷导致系统几乎不能使用或测试不能继续、P2级高优先级：缺陷严重，影响测试，需要有限考虑、P3级正常排队：新版本发布之前改完、P4级低价优先：有时间再改

注意：优先级的衡量，一般可以根据测试软件系统的全业务流程划分，软件的基本功能的缺陷，优先级高，甚至需要立即解决。软件的备选流、基本功能测试中的反向测试的内容，优先级较低，甚至有些可以不改。

面试提问：缺陷的严重程度和优先级有什么关系？

a.没有任何直接关系

b.不要认为严重的缺陷，修复优先级就越高

c.如果碰到，优先级和严重程度都高的缺陷，也只是偶然。列如：QQ的帮助按钮，会有经常闪退的现象。严重程度很高，但是优先级就很低。企业logo错误，不影响任何功能，但是必须优先修复

4）缺陷状态：表示缺陷的处理进度

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

①激活或打开（新建）。由测试人员进行标注。

②确认。确认新提交的缺陷是一个真实有效的缺陷，一般由测试主管或者质量保证（QA）、由产品经理进行确认，经确认后有效的缺陷会指派给相关人员进行处理

③已修复/修正。在缺陷被修复后，一般由开发人员进行
④关闭/非激活。缺陷被修复完成后，经过测试人员的验证后，没有问题。
⑤重新打开。经过测试人员的验证后，缺陷没有修复成功，需要重新打开进行再次处理和修复。
⑥推迟。缺陷现在不修复，推迟到下一个版本或者阶段。测试要跟开发或者其他相关的管理人员进行确认。
⑦保留。缺陷暂时修复不了，一般也由开发人员去设定，也需要测试人员进行确认。
⑧不能重现。开发按照缺陷的复现步骤不能再次发现缺陷，一般闪退、崩溃类型的缺陷具有类似的特征，或者由于操作系统的差异，浏览器的缓存等信息，出现的问题。所以作为测试人员提交bug之前要再三确认bug。
⑨需要更多信息。作为测试人员提交bug的时候，要尽可能的把所有相关的文件一起提交（图片、视频）。
⑩重复。测试中一定要避免这种情况的出现，尤其在软件的的某一个功能频繁被多个模板（由不同的测试人员测试）调用的情况下。
⑪不是缺陷，一定不要在测试工程师的工作生涯中被开发标注缺陷状态为不是Bug。
⑫需要修改需求说明书，。缺陷不是技术原因造成的，而是由于需求不明确或者设计不明确造成。

5)缺陷起源：缺陷引起的故障或事件第一次被检测到的阶段。

需求、构架、设计、编码、测试、用户

6)缺陷来源：缺陷的起因，一般是缺陷的直接因素

需求说明书（的错误或不清楚引起的问题）、设计文档（描述不准确，和需求说明书不一致）、系统集成接口（系统各模块不匹配，开发组之间缺乏协调）、数据流/库（数据字典、数据库中的错误）、程序代码（编程中的问题）

7）缺陷根源：发生错误的根本因素

测试策略、过程，工具和方法、团队/人、缺乏组织和通讯、硬件、软件、工作环境

缺陷的起源、来源、根源。一般关注较多的是缺陷的来源（直接原因）；在测试总结的时候，关注缺陷的根源。

二、缺陷的生命周期

缺陷的生命周期

发现缺陷、提交缺陷、确认缺陷、分配缺陷、修复缺陷、验证缺陷（若缺陷未修复则再次提交）、关闭缺陷

1. 发现缺陷：由测试人员

2. 提交缺陷：由测试人员

3. 确认缺陷：一般由测试主管、或者质量保证（QA）、由产品经理进行确认

4. 分配缺陷：经确认后，有效的缺陷会指派给相关人员进行处理。一般谁确认的缺陷，就由谁分配。

5. 修复缺陷：主要由开发修复，也有可能是产品经理修复问题，也有可能是UI修复问题

6. 验证缺陷：测试去验证缺陷有没有修复成功

7.关闭缺陷。只能是测试人员进行，否则出了问题，测试人员一律不背锅。

三、缺陷的识别

依据：需求文档、设计文档、产品原型、测试用例，都是客观依据。同行业的类似成熟软件，和开发人员沟通，跟有经验的测试人员沟通。同行业隐形需求，都是带有主观色彩的依据。

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

1. 通过测试用例中的预期结果进行识别

2. 通过需求规格说明书进行识别

3. 通过用户手册及其他文档进行识别

4. 通过同行业相类似成熟的商业软件来识别

5. 通过和开发人员的沟通进行识别

6. 通过和有经验的测试人员沟通进行识别

7. 参照同行业隐式需求进行识别

四、缺陷报告

1、缺陷报告的编写目的：1）展现缺陷的详细信息2）展现缺陷的影响程度和方式

1. 易于搜索软件测试报告的缺陷

2. 报告的软件缺陷进行了必要的隔离，报告的缺陷信息更具体、准确

3. 软件开发人员希望获得缺陷的本质特征和复现步骤

4. 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度

缺陷报告的读者很多：开发人员、产品经理、质量管理、市场人员、运维人员。

所以缺陷报告要写的很直白、清晰、明了

2、缺陷报告编写的准则：准确、清晰、一致、简洁、完整。

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

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

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

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

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

3、缺陷描述的规则

1)单一准确

2)可以再现。针对绝大多数的缺陷都是如此，但是有一些小部分的缺陷是难以做到的。类似闪退、崩溃这种不可能再现的缺陷，无需做到。针对一些可以重复出现的闪退缺陷，也要进行步骤的详细概述）

3)完整统一

4)短小简练

5)特定条件

6)补充完善

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

4、缺陷报告模版

1）缺陷编号。Bug_项目名称_模块名称_功能名称_0001

2）所属模块。一级模块/二级模块/三级模块。例如，上课用的直播软件，如果想要查看签到的历史记录，需要进入直播主界面---互动应用---签到---签到历史记录。

3) 优先级。 缺陷的修复紧急程度 P1>P2>P3>P4

4)  严重程度。S1>S2>S3>S4

5)  缺陷概述：用一句话描述缺陷的基本情况

6)  缺陷的描述。将缺陷的复现步骤、预期结果和实际结果列出来

7)  提交人：是谁就写谁的名字

8)  备注：一般写产生该缺陷的特殊情况。将Bug的截图作为备注信息

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