目录
软件的缺陷
缺陷的定义
判断的依据：用户需求说明书 ----> 编写测试用例
- 软件在使用（运行）过程中存在的任何问题（如：错误、异常、失效等），都叫软件的缺陷，简称bug
缺陷的判定标准🏴
如何确定一个问题是不是缺陷？
- 软件未实现需求（规格）说明书中明确要求的功能 —— 没有做
eg : 手机是否支持5G功能
- 软件出现了需求（规格）说明书中指明不应该出现的错误 —— 做错了
eg : 登录失败应该有错误提示，但是没有提示
- 软件实现的功能超出需求（规格）说明书指明的范围 —— 做多了
eg : 实现计算的软件出现聊天互动等功能
- 软件未实现需求（规格）说明书中虽未明确指明但应该实现的要求 —— 没做完
eg ：软件的产品对于金额默认保留两位有效数据，但是没有保留（需求中未写）
- 软件难以理解，不易使用，运行缓慢，用户体验不好 —— 不完美
eg ：使用过卡顿，响应速度慢、界面不好看等
【扩展】缺陷的级别
- 违反上述标准的1、2、3条件，基本上属于高严重级的bug
- 违反上述标准的4、5条件，基本属于中低级别的bug
缺陷产生原因阶段
为什么需要分析缺陷的原因？
- 能帮助测试领导确定产品出现质量问题的具体阶段，方便后续软件产品质量的优化
- 能够帮助测试人员积累经验
- 需求阶段：需求描述不易理解，有歧义、错误等
- 设计阶段： 设计文档存在错误或者缺陷
- 编码阶段：代码出现错误（语法、单词、标点符号等）
- 运行系统：软硬件系统本身故障导致软件缺陷
- 故障解决阶段：对于系统不熟悉修复问题时引入新bug
缺陷的生命周期
缺陷报告的核心内容🏴
缺陷报告的其他要素
- 缺陷的编号：能够唯一的表示一个缺陷
- 缺陷的状态：描述缺陷生命周期的过程
- 新建（new）: 表示缺陷的产生
- 打开（open）：表示开发确认通过
- 拒绝（rejected）：表示开发确认不通过
- 进行中（inprogress）：表示开发正在修复缺陷
- 已修复（fixed）：表示开发已经修复完成
- 延迟修复（delay/postpone）：表示开发延迟修复
- 测试通过（closed）：表示测试通过，已关闭
- 测试不通过（reopen/open）：表示测试不通过，重新打开
- 缺陷的所属模块：类似于用例的所属项目，描述缺陷产生的模块范围
- 缺陷的优先级：告诉开发当前缺陷修改的先后次序 （ P1）priority
- urgent priority : 最高优先级
- veryhigh priority : 次高优先级
- high priority : 高优先级
- medium priority ： 中优先级
- low priority：低优先级
- 缺陷的严重级：告诉产品当前缺陷对于整个产品的破坏程度（和优先级一一对应） （S1）serious
- critical ：致命的破坏
- major ：高的破坏性
- medium ： 中等破坏
- minor：低等破坏
- tiny ： 微小的破坏
- 缺陷的类型：描述缺陷主要产生问题的原因
- 功能问题
- UI问题
- 兼容性问题
- 易用性问题
- 架构问题
- 安全问题
缺陷的管理
缺陷的跟踪流程🏴
作用：描述开发和测试在公司中对于缺陷的跟踪管理过程
编写缺陷报告规范
- 可复现：确保当前发现的bug能够复现
- 唯一性：确保一个缺陷报告中上报一个问题
eg：登录测试失败了，在数据库对应表中发现当前的账号密码信息是明文的
此时描述的是两个问题，可以分开报bug
- 规范性：遵循公司规定的报bug的要求
eg : 客服人员发现的bug，需要在标题中单独标记
【客服】正确的账号登录过程中出现的失败的结果
注意事项
- 确保上报的bug是准确的
- 描述尽可能简洁易懂具体
- 不能使用感情色彩的词语
- 不能使用模棱两可的词汇
- 不能使用人称代词
442
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
