软件测试 - 缺陷管理篇

基础理论篇

一、软件缺陷
- 1.1. 缺陷的定义
- 1.2. 缺陷的判定标准
- 1.3. 缺陷的产生原因
- 1.4. 缺陷的生命周期
- 1.5. 缺陷的核心内容
- 1.6. 缺陷的提交要素
二、项目中缺陷的管理流程
- 2.1.缺陷跟踪流程及注意事项
- 2.2.缺陷报告编写规则
- 2.3.使用excel管理缺陷报告示例
- 2.4.使用禅道管理用例和缺陷报告示例

一、软件缺陷

1.1. 缺陷的定义

软件在所有过程中存在的任何问题都叫软件的缺陷，简称bug

1.2. 缺陷的判定标准

软件未实现需求规格说明书中明确要求的功能 - - 少功能
软件出现了需求规格说明书中指明不应该出现的错误 - - 功能错误
软件超出需求规格说明书指明的范围（比如每个员工都可以查看某公司的工资流水） - - 多功能
软件出现了需求规格说明书中虽然未明确按应该实现的要求（登录成功没有跳转到首页，删除敏感信息时没有进行二次确认） - - 隐形功能错误
软件难理解，不易使用，运用缓慢，用户体验不好（如春运买票提示系统繁忙） - - 不易使用

如何区分前端和后端错误
1.界面错误和兼容性错误一般是前端的bug
2.功能错误可以使用抓包（查看请求和响应，检测后端返回数据和前端显示数据）的方法来区分前后端错误

1.3. 缺陷的产生原因

是软件就有缺陷
需求阶段（产品）：需求描述不易理解，有歧义，错误
设计阶段（架构师）：设计文档存在错误或缺陷，数据库及前后端架构
编码阶段（前端和后端）：代码出现错误
运行阶段（兼容性）：软硬件系统本身故障导致软件缺陷

1.4. 缺陷的生命周期

（需求。设计和编码阶段）注入bug – （测试阶段）发现bug – （开发修复）解决bug – 回归测试 – 上线运行阶段（软硬件系统兼容性等）

1.5. 缺陷的核心内容

缺陷的标题：（操作数据描述+预期+实际）
缺陷的描述：（前置+步骤+预期+实际）
缺陷的预制条件
缺陷的复现步骤
缺陷的预期结果
缺陷的实际结果
缺陷的必要附件

1.6. 缺陷的提交要素

1.缺陷Id：可以使用用例Id，要求唯一
2.缺陷标题：操作数据描述+预期+实际（或者：测试步骤描述+实际+需求）
例1：输入4位自然数qq号；期望结果：不通过（提示：必须为6-10位自然数）；实际结果：通过
例2：密码为空；期望结果：不通过（提示：密码不能为空）；实际结果：登录成功
3.所属模块
4.缺陷严重程度：S1（严重：主功能）、S2（一般：次要功能）、S3（优化：易用性、界面）、S4（建议性问题）
5.缺陷优先级：
业务+单功能
业务正向错误P0（登录搜索添加到购物车下单支付其中一项失败）（24h内解决）
业务逆向错误P1（因为未登录导致添加购物车失败）（发布前修复）
单功能正向错误P2（正确用户名+正确密码登录失败）（下个版本中修复）
单功能逆向错误P3（正确用户名+错误密码登录成功）
6.缺陷状态：新建new，激活reopen，已关闭closed，已解决fixed（可以进行回归测试），in progress（进行中），延期delay/postpone，拒绝rejected，过期
7.缺陷的类型：代码错误、兼容性问题、设计缺陷、性能问题
功能错误、界面（UI）错误、兼容性、数据、易用性、改进建议、架构
8.缺陷描述：前置条件+复现步骤+预期结果+实际结果，操作步骤中必须给出测的数据（自己验证的用例）（预期结果一定与世界结果相反）
例1：
[前置] 1.打开qq界面
[步骤] 1.输入qq：1234 ，2.点击验证
[预期] 不通过，提示必须为6-10位自然数
[实际] 通过
9.附件：包括日志和错误界面
10.创建人、指派人、修复日期…

二、项目中缺陷的管理流程

当你发现bug后怎么办：确认bug是否可复现，如果可复现再提交bug
缺陷编写规范：准确、具体、次序清晰、简洁易懂
缺陷管理工具：禅道：三管融合（产品管理、项目管理、质量管理）、jira
禅道的特点：三权分立（产品部门 - 构象者，研发部门 - 执行者，测试部门 - 保证者）、四角协同（产品经理，项目经理，研发团队，测试团队）

实际测试中bug不可复现怎么办？
1.多次重复测试，不出现先记录
2.回顾bug出现的操作流程和测试环境的配置，是否由于误操作或环境临时故障引起
3.请开发协助自己查找当前测试模块是否有对应的日志信息（日志位置可以问开发）
4.考虑更换一套环境查看是否能复现上述问题
5.后续的版本测试，要关注刚说测试该功能时是否还出现上述问题
6.后续帮办还出现，需要开发协助打印日志进行分析定位

2.1.缺陷跟踪流程及注意事项

提交缺陷 – 分配缺陷 – 处理缺陷 – 回归测试 – 关闭缺陷
权限跟踪作用：描述开发和测试如何协同配合处理bug

测试处理状态：新建new，激活reopen，已关闭closed
开发处理状态：已解决fixed（可以进行回归测试），in progress（进行中），延期delay/postpone，拒绝rejected，过期

注意：
1.确保bug准确性、可复现
2.描述简单易懂具体
3.不能用感情色彩，和模棱两可的词汇（是否，可能），不要用人称代词（你应该怎么修改）

2.2.缺陷报告编写规则

可复现，唯一性，规范性（遵循公司要求）

2.3.使用excel管理缺陷报告示例

2.4.使用禅道管理用例和缺陷报告示例

创建用例 – 评审用例 – 执行用例（选择测试结果） – 失败转bug – 提交bug（输入缺陷核心要素） – 开发确认bug – 解决bug – 关闭bug

创建用例（单条，多条（导出导入模板））

评审用例

执行用例

提交缺陷（转bug或提bug）

可以进行缺陷管理和用例管理，但用例管理使用的不多（可以直接使用excel，使用禅道进行用例管理的优点是可以记录执行结果，测试不通过可以直接转bug）

跟踪缺陷（指派bug给开发 - 开发确认bug - 开发解决bug ）

验证缺陷（回归测试 - 成功关闭，失败重新打开）

软件测试 - 缺陷管理篇相关推荐

常见的软件测试缺陷分类：遇到测试缺陷怎么处理？
什么是软件测试缺陷呢?通俗来说,就是bug管理.在软件系统或者程序研发过程中,程序员编码.系统设计架构不合理都可能产生错误,影响程序的正常运行.而软件测试的目的之一,就是通过软件测试工具执行操作,找到 ...
软件测试--缺陷报告
缺陷报告是描述软件缺陷现象和重现步骤地集合.软件缺陷报告Software Bug Report(SBR)或软件问题报告Software Problem Report(SPR) 作用:缺陷报告是软件测试 ...
8.0、软件测试——缺陷（定义和标准）
8.0.软件测试--缺陷(定义和标准) 1.缺陷的定义软件在使用过程中存在的任何问题都叫软件缺陷,简称 bug: 缺陷介绍: 2.缺陷的判定标准 1. 软件未实现需求(规格)说明书中明确要求的功能 ...
软件测试缺陷报告英文版,软件测试缺陷报告书.doc
软件测试缺陷报告书.doc (1页) 本资源提供全文预览,点击全文预览即可全文预览,如果喜欢文档就下载吧,查找使用更方便哦! 19.90 积分缺陷记录编号:00001软件名称:163邮箱模块名:收 ...
软件测试缺陷发生方法,软件测试缺陷分析方法简介
DRE/DRM分析法 DRE/DRM分析法是通过已有项目历史数据,得到软件生命周期各阶段缺陷注入和排除的模型,用于设定各阶段质量目标,评估测试活动. 缺陷排除效果分析DRE矩阵: DRE主要针对历史数 ...
软件测试缺陷定义和管理
我们需要知道的是软件BUG其实就是软件设计没有达到预期设计目标,导致在软件内存在的一种缺陷. 可以一句话概括:一切不符合需求规格说明书要求的,都可以视作软件缺陷. 定义:(1)软件未达到产品说明书标明 ...
软件测试缺陷指标,如何对缺陷进行分析，都分析哪些指标？
5:Defect Injected and Defect Reason 看名字就应该很清楚这个图表的目的是为了查看缺陷引进的原因,根据这些数据可以我们提出改善方案. 最后还有一个叫做Delivered ...
软件测试缺陷分析方法简介
ODC分析法 ODC(正交缺陷分类)分析方法最早由IBM的waston中心推出,是将一个缺陷在生命周期的各环节的属性组织起来,从单维度.多维度来对缺陷进行分析,从不同角度得到各类缺陷的缺陷密度和缺陷比 ...
软件测试怎么跟踪缺陷,也谈软件测试缺陷跟踪管理
缺陷跟踪管理是软件测试工作的一个重要部分,软件测试的目的是为了尽早发现软件系统中的缺陷,因此,对缺陷进行跟踪管理,确保每个被发现的缺陷都能够及时得到处理是测试工作的一项重要内容. 1. 缺陷跟踪管理的 ...

软件测试 - 缺陷管理篇

基础理论篇

一、软件缺陷

1.1. 缺陷的定义

1.2. 缺陷的判定标准

1.3. 缺陷的产生原因

1.4. 缺陷的生命周期

1.5. 缺陷的核心内容

1.6. 缺陷的提交要素

二、项目中缺陷的管理流程

2.1.缺陷跟踪流程及注意事项

2.2.缺陷报告编写规则

2.3.使用excel管理缺陷报告示例

2.4.使用禅道管理用例和缺陷报告示例

软件测试 - 缺陷管理篇相关推荐

最新文章

热门文章