1 缺陷基本概述
1.1 缺陷的定义（重要！）
软件未实现产品说明书要求的功能；
软件出现了产品说明书指明不应该出现的功能；
软件实现了产品说明书未提到的功能；
软件未实现产品说明书虽未明确提及但应该实现的目标；
软件难以理解、不易使用、运行缓慢或者（从测试的角度看)最终用户会认为不好。
1.2 缺陷的属性
缺陷的优先级：正向的测试用例永远高于反向的测试。正向的测试是测试软件功能是否能使用，若不能使用，就是缺陷，此时去进行反向的测试没有意义。
1.2.1 缺陷的类型
功能（Function）缺陷：常出在系统测试阶段。
用户界面（UI）缺陷：常出在系统测试阶段。
文档（Doumentation）缺陷：常出现在需求分析、设计阶段。
软件包（Package）缺陷：常出在实施过程。
性能（Performance）缺陷：常出在验收测试阶段。
接口（Interface）缺陷：常出在集成测试阶段。
1.2.2 缺陷的严重程度
缺陷的故障对软件的影响。
一般有分类，每一个公司和团队的分类标准都不太一样。
在学习过程中，以下描述的严重等级进行缺陷严重程度划分为标准。
结合缺陷的影响，结合软件的具体功能（业务或流程）。
1.2.3 缺陷的修复优先级
缺陷的修复优先级取决于缺陷对测试工作的影响程度。
例如：电商系统用户注册功能无法使用，带来的影响有：无法登录、购买、结算、支付、下订单、物流跟踪、收货、评论等功能都无法进行，就必须立即修复；电商系统系统中关于用户购买流程帮助说明的网页链接弹出404页面。
优先级的衡量，可以根据测试的软件系统的全业务流程划分，软件的基本功能的缺陷，优先级高，甚至需要立即解决。软件的备选流和基本功能中的反向测试的内容，优先级较低。
问：缺陷的严重程度和优先级有什么关系？
答：两者之间没有任何直接的关系；
不要认为严重的缺陷，修复优先级就高；
如果碰到优先级和严重程度都高的缺陷只是偶然。例如：微信帮助按钮，会有闪退的现象，严重程度很高，但优先级很低。企业logo错误不影响任何功能，但是必须优先修复。
问：提交缺陷时能不能夸大或降低缺陷的严重程度或优先级？
答：坚决不能！作为一名测试人员，必须做到公正和客观。不能搞“狼来了”，也不能私人关系“帮”好友减少不良影响。
1.2.4 缺陷的状态
缺陷状态表示缺陷的处理进度。
发现缺陷是所有缺陷的前提，但是还没有进入缺陷的处理流程。
缺陷的状态阶段：
激活/打开（新建）。由测试人员进行标注。
确认。确认提交的缺陷是一个真实有效的缺陷。由测试主管、质量保证或产品经理进行确认。经确认之后，有效缺陷会指派给相关人员进行处理。
已修复/修正。在缺陷修复后，一般由开发人员进行。
关闭/非激活。缺陷被修复完成后，经过测试人员的验证后，没有问题。
重新打开。经过测试人员的验证后，缺陷没有修复成功，需要重新打开进行再次处理和修复。
推迟。缺陷现在不修复，推迟到下一个版本。测试要跟开发或其他相关的管理人员进行确认。
保留。缺陷暂时修复不了。由开发人员去设定。也需要测试人员确认。
不能重现。开发按照缺陷复现步骤不能再次发现缺陷。一般是闪退、崩溃类型的缺陷。或者由于操作系统的差异、浏览器的缓存等信息出现的问题。所以作为测试人员提交bug之前，要再三确认bug。
需要更多信息。作为测试人员提交bug的时候，要尽可能把所有相关的文件一起提交。（图片、视频）
重复。测试中，一定要避免这种情况的出现。尤其在软件某一个功能频繁被多个模块（由不同的测试人员测试）调用的情况下。
不是缺陷。一定不要在测试工程师的工作生涯中被开发标注缺陷状态为不是bug。
需要修改需求说明书。缺陷不是技术原因造成的，而是由需求不明确或设计不明确造成的。
1.2.5 缺陷的起源
1.2.6 缺陷的来源
1.2.7 缺陷的根源
缺陷的起源关注较多；在测试总结的时候，关注缺陷的根源。
2 缺陷的生命周期（重要）
发现缺陷：由测试人员负责。开发也能知道自己哪里写错了，但是不会广而告之。
提交缺陷：由测试人员负责。开发更不可能提交bug。
确认缺陷：由测试主管或质量保证（QA）或产品经理确认。
分配缺陷：经确认之后，有效缺陷会指派给相关人员进行处理。由谁确认的缺陷，就由谁分配。分配的对象可能是开发、也可能是UI、也可能是产品经理。
修复缺陷：主要由开发修复，也可能是产品经理修复问题，也可能是UI修复问题。
验证缺陷：测试人员去验证缺陷有没有修复成功。
关闭缺陷：只能是测试人员进行。否则出了问题，测试人员一律不背锅。
问：针对你工作中发现的一个bug，说说bug的处理过程。（缺陷的生命周期中，每一个环节由谁做什么）
3 缺陷的识别
客观依据：需求文档、设计文档、产品原型、测试用例
主观依据：同行业相类似成熟的商业软件、和开发人员沟通、和有经验的测试人员沟通、同行业隐式需求
测试人员在识别缺陷的时候，要很灵活对待。
4 缺陷报告模板
缺陷编号。Bug_项目名称_模块名称_功能名称_0001
所属模块。一级模块/二级模块/三级模块。
例如：直播软件，如果项要查看签到的历史记录，需要进入直播主界面——互动应用（一级模块）——签到（二级模块）——签到历史记录（三级模块）。
优先级。缺陷的修复紧急程度。P1>P2>P3>P4（参考缺陷的修复优先级 1.2.3）
严重程度。S1>S2>S3>S4（缺陷的严重程度 1.2.2）
缺陷概述。用一句话描述缺陷的基本情况。
例如：在多边形判断程序首页点击三边形按钮，应该出现三边形的实例图片，但是实际出现的是五边形的图案。
缺陷的描述。将缺陷的重现步骤、预期结果和实际结果列出来。
例如：
1 使用chrone浏览器打开多边形判断程序的页面
2 点击三边形按钮
实际结果:
示例图片为五边形的图案
预期结果:
示例图片为三边形的图案
提交人。
备注。写产出该缺陷的特殊情况（在断网的情况下），将bug的截图作为备注信息，如下图：
缺陷报告的编写目的：
展现缺陷的详细信息；
展现缺陷的影响程度和方式；
缺陷报告的读者有：开发人员、质量管理人员、市场人员、运维人员…，所以缺陷报告要写得很直白。
缺陷报告编写的准则：准确、清晰、一致、简洁、完整。
缺陷描述的规则：
可以再现。针对绝大数的缺陷都是如此，但是有一些小部分的缺陷是难以做到（类似闪退、崩溃这种不可再现的缺陷无须做到。针对一些可重复出现的闪退缺陷，也要进行步骤的详细描述）
不做评价。不对缺陷的出现的严重程度和缺陷表现出来的效果进行主观臆断。
缺陷报告本身要保证没有任何表述性的错误！！
缺陷跟踪系统
禅道特点：开源 免费 中文 国产 项目 产品 测试 齐全 组织机构 人员
QC特点： (ALM)外国英文功能齐全
5 测试需求、测试用例、缺陷报告的关系
软件测试的流程：
获取测试需求——编写测试计划——制定测试方案——开发与设计测试用例——执行测试——提交缺陷报告——测试分析与评审——提交测试总结——准备下一版的测试
获取测试需求是测试工作的重点，也是第一步。通过需求的分析，了解和掌握测试的方向和内容。例如：分析出系统的模块和组织结构；分析出软件的基本功能和运行流程（业务分析），包括可能会有哪些人或者哪些角色要用；识别出软件的重要功能和次要功能。
获取测试需求的过程中，测试人员就要有相应的分析成果。一般用xmind的思维导图工具进行分析，或者使用需求跟踪矩阵来完成测试需求的获取和分析。
设定测试中需求的正、反向和优先级。
当有了测试需求之后，就开始针对每一个需求点进行测试用例的设计。也就是，每一个需求点都要被测试。因此测试的过程中，衡量需求的覆盖程度就非常重要。使用：需求的覆盖程度=被测试用例覆盖的需求数/需求点总数
进行计算和说明。
如果需求覆盖度≤100%，那一定说明了测试的覆盖度不够。
测试中，最能体现测试人员工作量的指标就是缺陷的数量和用例的数量。
TC：设计的测试用例总量。
EC：执行的测试用例数量。
WC：未执行的测试用例数量。
SC：执行通过的测试用例总量。
FC：执行失败的测试用例总量。
BC：提交的缺陷的总量（Bug Counts）。
以上6个数据，它们要符合如下的数量关系：
TC>=EC
TC=EC+WC
EC=SC+FC
BC>=FC。测试用例虽然通过了，达到了预期的结果，但是也会出现计划之外的缺陷，测试用例不可能包括现实状况的方方面面，所以提交缺陷的总量大于等于测试用例总量。测试过程中发现的缺陷，一部分是用例执行失败带来的，还有一部分是测试人员自身的经验和直觉（其他知识）带来的。
SC/EC可以表现出系统的质量是否合格。
EC/TC表现出系统的需求是否的得到满足。
小结
缺陷的定义。软件难以理解、不易使用、运行缓慢或者（从测试的角度看)最终用户会认为不好。
缺陷的严重程度。缺陷的故障对软件的影响。
缺陷的修复优先级。缺陷的修复优先级取决于缺陷对测试工作的影响程度。
缺陷的状态主要阶段有：激活/打开（新建）、确认、已修复/修正、关闭/非激活、重新打开。
缺陷的生命周期：发现缺陷——提交缺陷——确认缺陷——分配缺陷——修复缺陷——验证缺陷——关闭缺陷。
缺陷的识别有客观依据和主观依据。
缺陷报告模板包括缺陷编号、所属模板、优先级、严重程度、缺陷概述、缺陷描述、提交人和备注。
软件测试的流程：获取测试需求——编写测试计划——制定测试方案——开发与设计测试用例——执行测试——提交缺陷报告——测试分析与评审——提交测试总结——准备下一版的测试
需求的覆盖程度=被测试用例覆盖的需求数/需求点总数