软件测试流程-----＞提交缺陷，缺陷报告的编写

软件测试流程----->提交缺陷

缺陷的基本描述

缺陷的定义

软件未实现产品说明书提及的内容

软件实现了产品说明书未提及，不该出现的功能

软件未实现产品说明书虽没明确提及但应该实现的目标。

软件难以理解，不易使用，运行缓慢，用户体验差

从结果看：实际结果和预期结果是否一致

从需求，就是不满足需求，或者超出需求都是缺陷

缺陷的属性

概述：指执行用例后，一旦发现缺陷，可以从哪些方面描述

缺陷的相关属性

缺陷的类型：根据缺陷的自然属性划分类别有 功能缺陷 ui缺陷 文档缺陷 代码缺陷 性能缺陷

缺陷的严重程度

概述：因趣味性那引起的故障对软件产品的影响

缺陷分类等级：

致命（s1）：主要功能完全丧失，用户数据破坏，死机，崩溃，闪退不嗯呢该恢复

严重（s2）：主要功能部分丧失，次要功能完全丧失，软件闪退，重启恢复，数据不能保存。

一般（s3）：系统的次要功能部分丧失，不影响用户使用，提示信息不准确，响应时间长，交互界面差，

较小（s4）：使用不方便，错别字，排版重合不合理

p1到p5 分别为致命 严重 一般 较小 建议

缺陷的优先级

概述：缺陷被修复的紧急程度

p1到p4 高 中 低

p1：立即解决 导致系统主要流程无法正常运行，测试无法进行

p2：高优先级 缺陷严重，影响测试需要优先考虑修复

p3：正常顺序 提交的缺陷按照顺序等待开发修复

p4：低优先级 有时间修复就行

缺陷的严重级别越高，修复优先级越高

缺陷的状态

概述：缺陷的生命周期中，缺陷在不同阶段处于不同状态，体现的是一个缺陷被跟踪修复的过程。

缺陷的生命周期：

缺陷状态：

激活或者打开：缺陷提交给开发

已修复或者已修改：开发人员修复好的软件缺陷

关闭：测试验证完成后，通过后就可关闭

重新打开 ：修复后，测试验证不通过

推迟修复：下个版本修复，得相关负责人确认

保留：缺陷是第三方造成的，得一只保留

不能复现：按照步骤，不能重现步骤，原因为测试提交的缺陷描述或者复现步骤不清楚，条件不完善

可多提交缺陷截图等证据避免。

重复：同一个缺陷提交多次。

缺陷的起源

概述：缺陷第一次发现的阶段

需求

架构设计

编码测试

用户

缺陷的来源（起因）

需求说明书 概要设计 详细设计 接口文档 数据库 代码

缺陷的根源

发生缺陷的根本原因

测试计划安排不合理

缺陷的识别

1.预期结果与实际结果对比识别

2.参考用户手册相关文档

3.同行业类似 成熟软件

4.同行业又经验测试人员

缺陷报告

概述：纪录执行测试过程中发现的缺陷，对缺陷进行相关的描述

缺陷报告包含的模块：

1.缺陷编号：给纪录的每一个缺陷生成唯一编号

例：bug_项目名称_模块名称_0001

2.所属的模块

例:商品模块/添加商品

3.严重程度：

s1----s4

4.优先级

p1---p4

5.缺陷概述

简洁的语言描述，把问题现象说清楚

例：刷新验证码出现三个字符

6.缺陷描述

三个方向来进行缺陷的阐述

a，复现步骤：把缺陷产生的操作步骤写清楚

b，实际结果：按照复现步骤产生的结果

c，预期结果：按照操作步骤应该出现的结果

7.提交人

8，备注

可以添加图片视频复现印证bug

缺陷报告编写的目的

1.易于管理和检索测试中发现的缺陷

2.发现的缺陷进行了必要的隔离，报告的缺陷更为具体，准确

3.开发人员希望能够获取到缺陷本质特性和复现步骤

4.开发和技术人员等想要获取到缺陷类型的分布以及对市场和用户的影响程度。

预期读者：开发 运维 市场 质量管理人员

缺陷报告的编写准则

clear：清晰（易于理解的，清晰完整）

correct：准确（描述准确）

concise：简洁（只包含必不可少内容）

complete：完整（只包含复现步骤和其他的本质信息）

consistent：一致（按照格式书写缺陷报告）