缺陷及缺陷管理
今日目标
能够说出缺陷的判定标准
能够说出描述缺陷的6大核心内容
能够描述缺陷状态、严重程度、优先级的作用
能够按照提供的缺陷模版完成一个缺陷的提交
能够说出缺陷的跟踪流程
能够在禅道中提交测试用例
能够在禅道中提交缺陷
1. 缺陷
1.1 缺陷的定义（重点）
- 产品实现不满足用户需求
- 测试执行时，实际结果和预期结果不一致
1.2 缺陷的判定标准（重点）
- 未达到需求说明书指明的功能
- 出现了需求说明书指明不应该出现的错误
- 实现了需求说明书之外的功能
- 未达到需求说明书虽未明确提及但是应该实现的目标（如：性能要求等）
- 用户角度发现的各种问题与错误
1.3 缺陷产生的原因及根本原因
1.3.1 缺陷产生的原因
- 需求文档存在错误
- 需求变更
1.3.2 设计存在错误
- 代码错误
1.3.3 缺陷产生的根本原因
需求变更
当需求变化太多，就一个功能反复变化很多次，在管理很混乱的情况下，就很容易导致一些错误，产生缺陷。
沟通不畅、信息不同步
如项目经理只是口头或微信通知开发需要修改某个功能，但并未更新相应的需求文档，开发人员还是按照旧的需求文档进行开发新的功能，必然产生缺陷。
软件复杂
在大型项目中，像支付宝、医疗系统中分非常多的功能模块，子系统，这些可能是直接是由不同的公司来开发的，不同公司之间的想法不同，沟通问题等就很容易造成缺陷。
进度压力
活多钱少时间紧的情况下，按照正常进度需要10天，但被压缩为了1天，在这种高强度的压力下必然会犯错，产生缺陷。
1.4 软件缺陷的核心内容（重点）
- 标题：描述缺陷的基本信息，如（输入密码长度为5时，注册成功。）
- 前置条件：描述缺陷出现依赖的相关基础条件，如（未注册手机号）
- 复现步骤：测试用例里面的执行步骤
- 实际结果：执行被测试软件过程中，系统给出的结果
- 预期结果：参照需求说明书，在测试用例中设计的预期结果
- 附件：方便开发定位bug的关键信息，包含图片、日志log等
1.5 缺陷基本要素（重点）
ID（编号）：唯一
模块：根据产品进行具体的划分，如登录、注册
缺陷状态：表明缺陷处理进度
严重程度：从技术维度来衡量，bug的破坏力
优先级：从业务的角度，决定bug修改的先后顺序
缺陷类别（bug类型）：用于分类整理缺陷
1.6 缺陷的状态（重点）
- new：新建，表示缺陷刚创建
- open：打开，表示已经指派或者开发认领了bug
- inprogress：进行中，表示开发正在修改中
- fixed：已修复，表示测试可以使用回归测试验证了
- closed：关闭，表示测试验证通过
- reopen：重新打开，回归测试没通过，需要开发重新修改该bug，或者在当前版本测试没问题，但到下一个版本后又出现了该问题，也可以提reopen
- rejected：已拒绝，表示开发拒绝了当前bug
- postpone/delay：延期，表示开发延迟修复该bug
1.7 缺陷严重程度（重点）
5-致命的：直接导致金融数据丢失，如漏费情况
4-非常高：可能是主要影响核心业务流程的bug，如购物加入不了购物车，用户无法完成下单流程
3-高：单个模块上的流程有问题，如注册不了
2-中：异常的、不符合的一些情况，如密码要求6位以上，5位也能注册，有影响，但影响不大
1-低：一些界面上或者很少影响的问题，如需要中文冒号，用的英文的，可以作为一些改进意见提给开发
1.8 缺陷优先级（重点）
表示解决缺陷的紧急程度，有的需要马上解决，有的可以等一段时间解决，有的不严重的可以在下个版本再解决
- 5-紧急的：必须马上解决的
- 4-非常高：能稍微等一会儿，但是也不能等待太久的
- 3-高：
- 2-中
- 1-低
### 思考题：优先级和严重程度的区别（了解）
+ Priority is Business【优先级是从公司运营角度（人力配置，资金投入等）】
+ Severity is Technical【严重级别是从技术角度】
- 优先级还要考虑团队的工作进度，阻塞工作的缺陷，要优先解决
- 考虑解决缺陷的能力，难度，风险
+ 最终优先级
+ 确定权：产品经理、项目经理等
+ 建议权：测试
1.9 缺陷类别（了解）
功能错误：需求没实现，有错误
UI界面错误：界面设计有错误（按钮、标点符号、对齐、文字检查）
兼容性：不同浏览器，不同平台的使用
易用性：是否好用
改进建议：比如UI界面红配绿这种搭配不好看，可以提，参照一些同行的设计
其他：没办法归类的，放到其他
2. 缺陷管理
2.1 缺陷信息（重点）
核心要素
- 标题：描述缺陷的基本信息，如（输入密码长度为5时，注册成功。）
- 前置条件：描述缺陷出现依赖的相关基础条件，如（未注册手机号）
- 复现步骤：测试用例里面的执行步骤
- 实际结果：执行被测试软件过程中，系统给出的结果
- 预期结果：参照需求说明书，在测试用例中设计的预期结果
- 附件：方便开发定位bug的关键信息，包含图片、日志log等
基本要素
- ID编号：唯一
- 模块：根据产品进行具体的划分，如登录、注册
- 缺陷状态：表明缺陷处理进度
- 严重程度：从技术维度来衡量，bug的破坏力
- 优先级：从业务的角度，决定bug修改的先后顺序
- 缺陷类别：用于分类整理缺陷
2.2 缺陷报告的重要性（了解）
体现测试的一个专业性
多站在开发的角度去思考问题（换位思考）
2.3 编写缺陷报告注意事项（理解）
- 可复现：缺陷可以复现
- 唯一性：一个问题只提交一个bug记录
- 规范性：符合公司或者项目要求
- 准确：描述的信息是正确的
- 具体：有细节且是真实特定的
- 简洁易懂：描述简单容易理解
- 次序清晰：描述缺陷过程有条件，有先后顺序
避免使用模糊不清的词语，例如：“功能中断，功能不正确，行为不起作用”等。应该使用具体文字说明缺陷的症状；
2.4 缺陷书写规范（理解）
- 标题：应保持简短、准确，提供缺陷的本质信息
- 复现步骤：应包含如何使别人能够很容易的复现该缺陷的完整步骤
- 实际结果：是执行复现步骤后软件的现象和产生的行为
- 预期结果：通常需要列出期望的结果是什么
- 附件：对缺陷描述的补充说明
2.5 缺陷跟踪流程(重点)
场景1：确认BUG解决
- 测试【new】》开发【open】》开发【fix】==》测试【close】
场景2：验证未通过，缺陷仍存在
- 测试【new】》开发【open】》开发【fix】==》测试【reopen】
场景3：开发延期处理
- 测试【new】》开发【open】》开发【postpone】
场景4：拒绝处理
- 测试【new】》开发【open】》开发【reject】
2.6 缺陷的统计（了解）
- 严重程度
- 提交人
- 缺陷类型
- ......