软件测试 - 缺陷管理篇

一、软件缺陷

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 ）


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