缺陷
一、缺陷的基本概述
1、缺陷的定义
- 软件未实现产品说明书要求的功能
- 软件出现了产品说明书指明不应该出现的功能
- 软件实现了产品说明书未提到的功能
- 软件未实现产品说明书虽未明确提及但应该实现的目标
- 软件难以理解、不易使用、运行缓慢或者(从测试的角度看)最终用户会认为不好
一、缺陷的定义和属性:
- XXXXXXXXXX缺陷的定义:
2、缺陷的属性
缺陷的属性
属性名称 | 描述 |
---|---|
缺陷类型(type) | 缺陷类型是根据缺陷的自然属性划分的缺陷种类 |
缺陷严重程度(Severity) | 缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度 |
缺陷优先级(Priority) | 缺陷的优先级指缺陷必须被修复的紧急程度 |
缺陷状态(Status) | 缺陷状态指缺陷通过一个跟踪修复过程的进展情况 |
缺陷起源(Origin) | 缺陷起源指缺陷引起的故障或事件第一次呗检测到的阶段 |
缺陷来源(Source) | 缺陷来源指缺陷的起因 |
缺陷根源(Root Cause) | 缺陷根源指发生错误的根本因素 |
缺陷的严重程度
-
缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。
缺陷严重等级 描述 致命(Fatal) 系统任何一个主要功能完全丧失,用户数据受到破坏,系统崩溃、悬挂、死机,或者危及人身安全 严重(Critical) 系统的主要功能部分丧失,数据不能保存,系统的次要功能完全丧失,系统所提供的功能或服务受到明显的影响 一般(Major) 系统的次要功能没有完全实现,但不影响用户的正常使用。例如:提示信息不太准确或用户界面差、操作时间长等一些问题 较小(Minor) 是操作者不方便或遇到麻烦,但它不影响功能的操作和执行,如个别不影响产品理解的错别字、文字排列不整齐等一些小问题
缺陷的状态
-
缺陷状态指缺陷通过一个跟踪修复过程的进展情况。
缺陷状态 描述 激活或打开 问题还没有解决,存在源代码中,确认“提交的缺陷”,等待处理,如新报的缺陷 已修复或修复 已被开发人员检查、修复过的缺陷,通过单元测试,认为已解决但还没有被测试人员验证 关闭或非激活 测试人员验证后,确认缺陷不存在之后的状态 重新打开 测试人员验证后,还依然存在的缺陷,等待开发人员进一步修复 推迟 这个软件缺陷可以在下一个版本中解决 保留 由于技术原因或第三者软件的缺陷,开发人员不能修复的缺陷 不能重现 开发不能再现这个软件缺陷,需要测试人员检查缺陷复现的步骤 需要更多信息 开发能再现这个软件缺陷,但开发人员需要一些信息,例如缺陷的日志文件、图片等 重复 这个软件缺陷已经被其他的软件测试人员发现 不是缺陷 这个问题不是软件缺陷 需要修改软件规格说明书 由于软件规格说明书对软件设计的要求,必须要修改软件规格说明书
缺陷的起源
-
缺陷起源指缺陷引起的故障或事件第一次被检测到的阶段。
缺陷起源 描述 需求 在需求阶段发现的缺陷 构架 在系统架构设计阶段发现的缺陷 设计 在程序设计阶段发现的缺陷 编码 在编码阶段发现的缺陷 测试 在测试阶段发现的缺陷 用户 在用户使用阶段发现的缺陷
缺陷的根源
-
缺陷根源指发生错误的根本因素。
缺陷根源 描述 测试策略 错误的测试范围,误解了测试目标,超越测试能力等 过程,工具和方法 无效的需求收集过程,过时的风险管理过程,不适用的项目管理方法,没有估算规程,无效的变更控制过程等 团队/人 项目团队职责交叉,缺乏培训。没有经验的项目团队,缺乏士气和动机不纯等 缺乏组织和通讯 缺乏用户参与,职责不明确,管理失败等 硬件 硬件配置不对、缺乏,或处理器导致算术精度丢失,内存溢出 软件 硬件设置不对、缺乏,或操作系统错误导致无法释放资源,工具软件的错误,编译器的错误,千年虫的问题等 工作环境 组织机构调整,预算改变,工作环境恶劣,如噪音过大
缺陷的属性:
缺陷的类型:功能(Function)、界面(UI)、文档(Docemendation)、软件包(Package)、性能(Performance)、接口(Interface)
注意:需求分析、设计阶段,文档类型的缺陷多;集成测试阶段,一般接口类型的缺陷多一些;系统测试阶段,功能、界面类型的缺陷多一些。验收测试阶段,更多的关注性能缺陷;实施过程,可能会遇到一些软件包的缺陷。
缺陷的严重程度。缺陷的故障对软件的影响。一般有分类,每个公司和团队的分类标准或略有不同。
注意:结合缺陷的影响,结合软件的具体功能(业务或者流程)。
缺陷的修复优先级。很大程度上取决于缺陷对测试工作的影响程度。例如:电商系统的用户注册功能无法使用(无法登陆、购买、结算、支付、下订单、物流跟踪、收货、评论等功能都无法进行),就必须立即修复;电商系统中关于用户购买流程帮助说明的网页链接点击404页面。
注意:优先级的衡量,一般可以根据测试的软件系统的全业务流程划分,软件的基本功能的缺陷,优先级高,甚至需要立即解决。软件的备选流、基本功能测试中的反向测试的内容,优先级较低,甚至有些可改可不改。
面试提问:缺陷的严重程度和优先级有什么关系?
- 没有任何直接的关系。
- 不要认为严重的缺陷,修复优先级就高;
- 如果碰到优先级和严重程度都搞的缺陷,也只是偶然。例如,QQ的帮助按钮,会经常闪退的现象。严重程度很高,但是优先级就很低。
面试提问:提交缺陷时能不能夸大或降低缺陷的严重程度或者优先级?
- 不能搞“狼来了”
- 也不能私人关系“帮”好朋友减少不良影响。
缺陷的优先级
缺陷的状态。表现缺陷的处理进度。
- 激活/打开(新建)。由测试人员进行标注。
- 确认。确认提交的缺陷是一个真实有效的缺陷。一般由测试主管、或者质量保证(OA)、由产品经理进行确认。经确认后,有效的缺陷会指派给相关人员进行处理。
- 已修复/修正。在缺陷被修复后,一般由开发人员进行。
- 关闭/非激活。缺陷被修复完成后,经过测试人员的验证后,没有问题。
- 重新打开。经过测试人员的验证后,缺陷没有修复成功,需要重新打开进行再次处理和修复。
- 推迟。缺陷现在不修复,推迟到下一个版本或者阶段。测试要跟开发或者其他相关的管理人员进行确认。
- 保留。缺陷暂时修复不了。一般也是由开发人员去设定。也需要测试人员进行确认。
- 不能重现。开发按照缺陷的复现步骤不能再次发现缺陷。一般闪退、崩溃类型的缺陷具有类似的特征。或者由于操作系统的差异、浏览器的缓存等信息,出现的问题。所以作为测试人员,提交bug之前,要再三的确认bug。
- 需要更多信息。作为测试人员,提交bug的时候,要尽可能的把所有相关的文件一起提交。(图片、视频)
- 重复。测试中,一定要避免这种情况的出现。尤其在软件的某一个功能频繁呗多个模块(由不同的测试人员测试)调用的情况下。
- 不是缺陷。一定不要在测试工程师的工作生涯中被开发标注缺陷状态为不会缺陷。
- 需要修改需求说明书。缺陷不是技术原因造成的,而是由于需求不明确或者设计不明确造成。
缺陷的起源、来源、根源。一般关注较多的是缺陷的来源(直接原因);在测试总结的时候,关注缺陷的根源。
二、缺陷的生命周期
1、缺陷的生命周期
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FKNYw06B-1625815979063)(/Users/acetian/Library/Application Support/typora-user-images/image-20210706103941129.png)]
二、缺陷的生命周期
- 发现缺陷。由测试人员。开发也能知道自己哪里写错了,但是不会广而告之。
- 提交缺陷。由测试人员。开发更不可能提交bug。
- 确认缺陷。一般由测试主管、或者质量保证(QA)、由产品经理进行确认。
- 分配缺陷。经确认后,有效的缺陷会指派给相关人员进行处理。一般由谁确认的缺陷,就由谁分配。分配的对象可能是开发、也可能是UI、也可能是产品经理。
- 修复缺陷。主要由开发修复,也有可能是产品经理修复问题,也有可能是UI修复问题。
- 验证缺陷。测试去验证缺陷有没有修复成功。
- 关闭缺陷。只能是测试人员进行。否则出了问题,测试人员一律不背锅。
面试提问:针对你工作中发现的一个bug,说说这个bug的处理过程。(缺陷的生命周期中,每一个环节由谁做什么)
三、缺陷的识别
1、缺陷的识别
- 通过测试用例中的预期结果进行识别
- 通过需求规格说明书进行识别
- 通过用户手册及其他文档进行识别
- 通过同行业相类似成熟的商业软件来识别
- 通过和开发人员的沟通进行识别
- 通过和有经验的测试人员沟通进行识别
- 参照同行业隐式需求进行识别
三、缺陷的识别
依据:需求文档、设计文档、产品原型、测试用例,都是客观的依据。
同行业的类似成熟软件,和开发人员沟通,跟有经验的测试人员沟通,同行业隐形需求,都是带有主观色彩的依据。
测试人员在识别缺陷的时候,要很灵活的对待。
四、缺陷报告
1、编写目的和预期读者
缺陷报告编写目的
- 易于搜索软件测试报告的缺陷
- 报告的软件缺陷进行了必要的隔离,报告的缺陷信息更具体、准确
- 软件开发人员希望获得缺陷的本质特征和复现步骤
- 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度
预期读者
- 开发人员、质量管理人员、市场人员、运维人员·······
2、报告编写准则
缺陷报告编写准则
- Correct(准确):每个组成部分的描述准确,不会引起误解
- Clear(清晰):每个组成部分的描述清晰,易于理解
- Concise(简洁):只包含必不可少的信息,不包括任何多余的内容
- Complete(完整):包含复现该缺陷的完整步骤和其他本质信息
- Consistent(一致):按照一致的格式书写全部缺陷报告
3、缺陷描述准则
缺陷描述准则
- 单一准确
- 可以再现
- 完整统一
- 短小简练
- 特定条件
- 补充完善
- 不做评价
4、缺陷管理方式和模版
缺陷报告模版
缺陷编号 | 所属模块 | 优先级 | 严重程度 | 缺陷概述 | 缺陷描述 | 提交人 | 备注 |
---|---|---|---|---|---|---|---|
Bug_OA_CJGL_ZZJG_0001 | 一级模块/二级模块 | P1/P2/P3/P4 | S1/S2/S3/S4 | 一句话描述(时间、地点、人物、事件) | 复现步骤、实际结果、预期结果 | XXX | 特殊条件、产生该缺陷的测试用例编号 |
缺陷跟踪系统
- Bugzilla(英文),安装比较繁琐
- Bugfree(中文) 安装简单 用例 缺陷的跟踪 功能单一
- 禅道(中文) 国产 项目 产品 测试 齐全 组织机构 人员 开源 免费
- QC(ALM) 外国 英文 功能全
- JIRA 外国 Java环境 主流(商业)
- 企业自己开发
四、缺陷报告
- 缺陷编号。Bug_项目名称 _功能名称 _0001。
- 所属模块。一级模块/二级模块/三级模块。例如:上课所用的直播软件,如果想要查看签到历史记录,需要进入直播界面——互动应用——签到——签到历史记录。
- 优先级。缺陷的修复紧急程度。P1>P2>P3>P4。
- 严重程度。S1>S2>S3>S4。
- 缺陷概述。用一句话描述缺陷的基本情况。
- 缺陷的描述。缺陷的复现步骤、预期结果和实际结果列出来。
- 提交人。是谁就写谁的名
- 备注。一般写产生该缺陷的特殊情况。将bug的截图作为备注信息。
缺陷报告的编写目的
1)展现缺陷的详细信息
2)展现缺陷的影响程度和方式
由于缺陷报告的读者很多:开发、质量管理、市场人员、运维人员,所以缺陷报告要写的很直白、清晰、明了。
报告编写的准则:准确、清晰、一致、简洁、完整。
缺陷描述的规则:
- 可以再现。针对绝大多数的缺陷都是如此。但是有一些小部分的缺陷是难以做到(类似闪退、崩溃这种不可再现缺陷,无需做的。针对一些可以重复出现的闪退缺陷,也要进行步骤的详细描述)
- 不做评价。不对缺陷的出现的严重程度和缺陷表现出来的效果进行主观臆断。
缺陷报告本身要保证没有任何表述性的错误。
测试需求和测试用例、缺陷报告的关系?
测试的基本流程:获取测试需求——编写测试计划——制定测试方案——设计和开发测试用例——执行测试——提交缺陷——测试分析和评审——测试总结——准备下一版本的测试。
获取测试需求是测试工作的重点,也是第一步。通过需求的分析,了解和掌握测试的方向和内容。例如:
1)分析出系统的模块和组织结构
2)分析出软件的基本功能和运行流程。(业务分析)包括可能会有哪些人或者哪些角色要用。
3)识别出软件的重要功能和次要功能。获取测试需求的过程中,测试人员就要有相应的分析成果。一般用Xmind这样的思维导图工具进行分析,或者使用需求跟踪矩阵来完成测试需求的获取和分析。
设定测试中需求的正、反向,和优先级。
当有了测试需求之后,就开始针对每一个需求点进行测试用例的设计。也就是,每一个需求点,都要被测试。
因此测试的过程中,衡量需求的覆盖程度,就非常的重要。使用: 需求的覆盖程度=被测试用例覆盖的需求数/需求点总数 进行计算和说明。
如果需求覆盖度<100%,那一定说明了测试的覆盖度不够。
测试中,最能体现测试人员工作量的指标就是缺陷的数量和用例的数量。
1)设计的测试用例总量 TC。
2)自信的测试用例数量 EC。
3)为执行的测试用例数量 WC。
4)执行通过的测试用例总量 SC。
5)执行失败的测试用例总量 FC。
6)提交的缺陷的总量 BC(Bug Counts)。
以上几个数据,他们要符合如下的数量关系。
1)TC大于等于EC。
2)TC=EC+WC。
3)EC=SC+FC。
4)BC大于等于FC。提交的bug数量,多于执行未通过的用例数。一条用例的预期结果数量是固定(甚至是唯一的)。说明了,测试过程中发现的缺陷,除一部分是用例执行失败带来的,还有一部分应该是测试人员自身经验和直觉(其他知识)带来的。
5)通过 SC/EC 可以表现出系统的质量是否合格。
6)通过 EC/TC 可以表现出系统的需求是否得到满足。