软件测试通用技术04 缺陷基本概述缺陷的生命周期缺陷的识别缺陷报告缺陷报告模板测试需求、测试用例、缺陷报告的关系

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表现出系统的需求是否的得到满足。

小结

缺陷的定义。软件难以理解、不易使用、运行缓慢或者（从测试的角度看)最终用户会认为不好。
缺陷的严重程度。缺陷的故障对软件的影响。
缺陷的修复优先级。缺陷的修复优先级取决于缺陷对测试工作的影响程度。
缺陷的状态主要阶段有：激活/打开（新建）、确认、已修复/修正、关闭/非激活、重新打开。
缺陷的生命周期：发现缺陷——提交缺陷——确认缺陷——分配缺陷——修复缺陷——验证缺陷——关闭缺陷。
缺陷的识别有客观依据和主观依据。
缺陷报告模板包括缺陷编号、所属模板、优先级、严重程度、缺陷概述、缺陷描述、提交人和备注。
软件测试的流程：获取测试需求——编写测试计划——制定测试方案——开发与设计测试用例——执行测试——提交缺陷报告——测试分析与评审——提交测试总结——准备下一版的测试
需求的覆盖程度=被测试用例覆盖的需求数/需求点总数