大家好，又见面了，我是你们的朋友全栈君。
文章目录
一、缺陷的基本概述
1、缺陷的定义（重要）：
2、缺陷属性
二、缺陷的生命周期（重要）
三、缺陷的识别
四、缺陷报告
五、测试需求、测试用例、缺陷报告的关系？
一、缺陷的基本概述
1、缺陷的定义（重要）：
①软件未实现产品说明书要求的功能 ②软件出现了产品说明书指明不该出现的功能 ③软件实现了产品说明书未提到的功能 ④软件未实现产品说明书虽未明确提及但应该实现的目标 ⑤软件难以理解、不易使用、运行缓慢或者（从测试角度看）最终用户会认为不好
2、缺陷属性
1、缺陷的类型： 功能、用户界面、文档、软件包、性能、系统/模块接口
注意：需求分析、设计阶段，文档类型缺陷多； 集成测试阶段，一般接口类型的缺陷多一些； 系统测试阶段，功能、界面类型的缺陷多一些； 验收测试阶段，更多地关注性能缺陷； 实施过程，可能会遇到一些软件包的缺陷。 2、缺陷的严重程度：缺陷的故障对软件的影响，每个公司和团队的分类标准略有不同。
①致命：系统任何一个主要功能完全丧失，用户数据收到破坏，系统崩溃、悬挂、死机，或者危及人身安全。
②严重：系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的的功能或服务收到明显的影响。
③一般：系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题。
④较小：是操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等小问题。
注意：结合缺陷的影响，结合软件的具体功能（业务或者流程）
3、缺陷的修复优先级：很大程度上取决于缺陷对测试工作的影响程度。有以下等级：立即解决、高优先级、正常排队、低优先级。 例如：电商系统的用户注册功能无法使用（导致无法登录、购买、结算、支付、下单、物流跟踪、收获、评论等功能无法进行），就必须立即修复。但是电商系统中关于用户购买流程帮助说明的网页链接点击404页面，就比较次要。
注意：优先级的衡量，一般可以根据测试的软件系统的全业务流程划分，软件的基本功能的缺陷，优先级高，甚至需要立即解决。软件的备选流、基本功能测试中的反向测试的内容，优先级较低，甚至有些可改可不改。
缺陷的严重程度和优先级有什么关系？ 1、没有任何直接的关系，严重程度是指缺陷对软件的影响，而优先级是指缺陷对测试的影响。 2、不要认为严重的缺陷，修复优先级就高； 3、如果碰到，优先级和严重程度都高的缺陷，也只是偶然。例如，QQ的帮助按钮，会有经常闪退的现象。严重程度很高，但是优先级就很低。又例如企业logo错误，不影响任何功能，但是必须优先修复。
提交缺陷时能不能夸大或降低缺陷的严重程度或者优先级？ 不能，不能搞“狼来了”，也不能搞私人关系，”帮”好朋友减少不良影响。要公正、客观。
4、缺陷的状态： 缺陷状态指缺陷的处理进度。 发现缺陷时缺陷处理的前提，但是还没有进入缺陷的处理流程。
①激活/打开（新建）：由测试人员进行标注。 ②确认：确认新提交的缺陷是一个真实有效的缺陷。一般由测试主管或者质量保证、产品经理进行确认。经确认后，有效的缺陷会指派给相关人员进行处理。 ③已修复/修正。缺陷修复，一般由开发人员进行。 ④关闭/非激活。缺陷被修复完成后，经过测试人员的验证后，没有问题。 ⑤重新打开。经过测试人员的验证后，缺陷没有修复成功，需要重新打开进行再次处理和修复。 ⑥推迟。缺陷现在不修复，推迟到下一个版本或阶段。测试要跟开发或者其他相关管理人员进行确认。 ⑦保留。缺陷暂时修复不了，一般也是由开发人员去设定。也需要测试人员进行确认。 ⑧不能重现。开发按照缺陷的复现步骤不能再次发现缺陷。一般闪退、崩溃类型的缺陷具有类似的特征。或者由于操作系统的差异，浏览器的缓存等信息，出现的问题。所以作为测试人员，提交bug之前，要再三确认bug。 ⑨需要更多信息。作为测试人员，提交bug的时候，要尽可能把所有相关的文件一起提交（图片、视频）。 ⑩重复。测试中，一定要避免这种情况的出现。尤其在软件的某个功能频繁被多个模块（由不同的测试人员测试）调用的情况下。 ⑪不是缺陷。一定不要在测试工程师的工作生涯中被开发标注缺陷状态为不是bug。 ⑫需要修改软件规格说明书。缺陷不是技术原因造成的，而是由于需求不明确或设计不明确。
5、缺陷的起源：
缺陷起源是指缺陷引起的故障或事件第一次被检测到的阶段。
缺陷起源有：需求、构架、设计、编码、测试、用户。
6、缺陷的来源：
缺陷来源指缺陷的起因。缺陷被发现的阶段，直接原因。
缺陷来源有：需求说明书、设计文档、系统集成接口、数据流（库）、程序代码。
7、缺陷的根源：
缺陷根源指发生错误的根本因素。一般发生在总结阶段。
缺陷根源有：测试策略、过程/工具和方法、团队/人、缺乏组织和通讯、硬件、软件、工作环境。
二、缺陷的生命周期（重要）
类似于面试官提问：针对你工作中发现的一个bug，说说这个bug的处理过程。其实就是要说明缺陷的生命周期中，每一个环节由谁做什么。
1、发现缺陷。由测试人员发现。开发人员也能知道自己哪里写错了，但是不会广而告之。
2、提交缺陷。由测试人员提交。
3、确认缺陷。一般由测试主管、质量保证、产品经理进行确认。
4、分配缺陷。经确认后，有效的缺陷会指派给相关人员进行处理。一般由谁确认的缺陷，就由谁分配。分配的对象可能是开发，也可能是UI、产品经理。
5、修复缺陷。主要由开发修复，也有可能产品经理、UI修复问题。
6、验证缺陷。测试去验证缺陷有没有修复成功。
7、关闭缺陷。只能是测试人员进行，否则出现了问题，测试人员一律不背锅。
三、缺陷的识别
依据：需求文档、设计文档、产品原型、测试用例，都是客观的依据。
同行业类似的成熟软件，和开发人员沟通，和有经验的测试人员沟通，同行业隐式需求。这些都是带有主观色彩的依据。
测试人员在识别缺陷的时候，要很灵活地对待。
四、缺陷报告
1、缺陷报告模板：
- 缺陷编号。Bug_项目名称_模块名称_功能名称_0001
- 所属模块。一级模块/二级模块/三级模块
- 优先级。缺陷的修复紧急程度。P1>P2>P3>P4
- 严重程度。S1>S2>S3>S4。
- 缺陷概述。用一句话描述缺陷的基本情况（时间、地点、人物、事件）。
- 缺陷描述。将缺陷的复现步骤、预期结果和实际结果列出来。缺陷描述的准则：可再现，除了类似闪退、崩溃等不可再现的缺陷。不做评价，不对缺陷出现的严重程度和缺陷表现出来的效果进行主观臆断。
- 提交人。
- 备注。一般写产生该缺陷的特殊情况。将Bug的截图作为备注信息。
2、缺陷报告编写目的：
- 展现缺陷的详细信息
- 展现缺陷的影响程度和方式
3、预期读者：开发人员、质量管理、市场人员、运维人员。
所以缺陷报告要写得很直白、清晰明了。
4、缺陷报告编写准则：准确、清晰、简洁、完整、一致。
缺陷报告本身要保证没有任何表述性的错误。
5、缺陷跟踪系统：禅道、ALM、JIRA等
五、测试需求、测试用例、缺陷报告的关系？
测试的基本流程：获取测试需求–编写测试计划–制订测试方案–设计和开发测试用例–执行测试–提交缺陷–测试分析和评审–测试总结–准备下一版本的测试
获取测试需求是测试工作的重点，也是第一步。通过需求的分析，了解和掌握测试的方向和内容。例如：
1）分析出系统的模块和组织结构
2）分析出软件的基本功能和运行流程。（业务分析）包括可能会有哪些人或者哪些角色要用。
3）识别出软件的重要功能和次要功能。
获取测试需求的过程中，测试人员就要有相应的分析成果，一般用xmind这样的思维导图工具进行分析，或者使用需求跟踪矩阵来完成测试需求的获取和分析。
设定测试需求的正、反向和优先级。
当有了测试需求之后，就开始针对每一个需求点进行测试用例的设计。也就是，每一个需求点，都要被测试。
因此测试的过程中，衡量需求的覆盖程度，就非常重要。使用公式进行计算和说明：需求的覆盖程度=被测试时用例覆盖的需求数/需求点总数。
如果需求覆盖度<100%，那一定说明了测试的覆盖度不够。
测试中，最能体现测试人员工作量的指标就是缺陷的数量和用例的数量。
1）设计的测试用例总量 TC。
2）执行的测试用例数量 EC。
3）未执行的测试用例数量 WC。
4）执行通过的测试用例总量 SC。
5）执行失败的测试用例总量 FC。
6）提交的缺陷的总量 BC。
以上几个数据，它们要符合以下的数量关系：
1)TC>=EC
2)TC=EC WC
3)EC=SC FC
4)BC>=FC。提交的Bug数量，多于执行未通过的用例数。一条用例的预期结果数量是固定的（甚至是唯一的）。说明了，测试过程中发现的缺陷，除一部分是用例执行失败带来的，还有一部分是测试人员自身的经验和直觉带来的。
5）通过 SC/EC 可以表现出系统的质量是否合格。
6）通过 EC/TC 可以表现出系统的需求是否得到满足。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/192198.html原文链接：https://javaforall.cn
