软件测试基础—-缺陷

软件测试基础—-缺陷

• • 缺陷的定义：★★★★
  • 产生缺陷的原因：
  • 缺陷的类型：
  • 缺陷的严重程度：★★★★★
  • 缺陷的修复优先级：★★★★★
  • 缺陷的状态：
  • 缺陷的根源：
  • 缺陷的识别：
  • 缺陷的 告：
  • 缺陷编写准则：
  • 缺陷描述规则：
  • 缺陷的严重程度和优先级与什么关系★★★

缺陷的定义：★★★★

1. 软件未实现产品说明书要求的功能
2. 软件出现了产品说明书指明不应该出现的问题
3. 软件实现产品说明书未提及的功能
4. 软件未实现产品说明书虽明确提及但应该实现的目标
5. 软件难以理解，不易使用，运行缓慢或者（从测试角度）最终用户认为不好

软件实现了产品规格说明所要求等功能但因受性能限制而未考虑可移植性问题不属于软件缺陷。

产生缺陷的原因：

1. 需求的不完善定义
2. 客户—开发者通信失败
3. 对软件需求的故意偏离
4. 逻辑设计错误
5. 编码错误
6. 不符合文档编制与编码规定
7. 测试过程不足
8. 规程错误
9. 文档编制错误

缺陷的类型：

（常见的有）功能、 界面 、 文档、 软件包、 性能、接口 等等

缺陷的严重程度：★★★★★

（不同公司采用的专业名词可能不同 基本原理相同
根据《软件测试》第二版 分为）

致命
严重
一般
较小

缺陷的修复优先级：★★★★★

不同企业采用的名词可能不同

立即解决
高优先级
正常排队
低优先级

缺陷的状态：

1. 激活/打开
2. 确认
3. 已修复/修正
4. 关闭/非激活
5. 重新打开
6. 推迟
7. 保留
8. 不能重现
9. 需要更多信息
10. 重复
11. 不是缺陷
12. 需要修改软件规格说明书吧

缺陷状态是通过跟踪缺陷修复过程的进展情况而定义的，开发人员修复Bug后，会将状态改为已修复，也就是待验证状态。

• 需求说明书
• 设计文档
• 系统集成接口
• 数据库（流）
• 程序代码

缺陷的根源：

• 测试策略
• 过程、工具和方法
• 团体/人
• 缺乏组织和通讯
• 硬件
• 软件
• 工作环境

缺陷的识别：

依据：需求分析、设计文档、产品原型、测试用例都为客观的依据 同行业的类似成熟软件

缺陷的 告：

1. 缺陷编 例: Bug_项目名称_模块名称_功能名称_0001
2. 所属模块
3. 优先级
4. 严重程度
5. 缺陷概述：一句话描述缺陷的情况
6. 缺陷的描述：缺陷的复现步骤 预期结果 和实际结果
7. 提交人
8. 备注：一般写产生该缺陷的特殊情况或bug的截图作为备注信息

缺陷 告的基本信息包括：缺陷标题、测试环境、复现环境（操作步骤）、实际结果、预期结果、注释。
缺陷处理优先级，属于软件缺陷 告的属性。

缺陷编写准则：

准确
清晰
简洁
完整
一致

缺陷描述规则：

可以在现
不做评价

缺陷的严重程度和优先级与什么关系★★★

答：没有任何直接关系
不要认为严重的缺陷 修复优先级就高
如果碰到优先级和严重程度都高的缺陷 也只是偶然

常用缺陷管理工具：
如开源（Bugzilla、jira、matins、Excel等）商业（QC/ALM、禅道等）。

软件中的缺陷不一定都会导致程序崩溃。

严重缺陷，指功能模块或特性没有实现，主要功能部分丧失，次要功能全部丧失，或致命的错误声明。

文字、界面错误属于严重程度较低的缺陷。

实施缺陷跟踪的原因是软件质量无法控制、问题无法量化、重复问题接连产生、解决问题的知识无法保留。

良好的复现步骤应该包含本质的信息，按照下列方式书写：
提供测试的前提条件和测试环境；
如果有多种方法触发该缺陷，请在步骤中包含；
简单地一步一步地引导复现该缺陷，每个步骤尽量只记录一个操作；
尽量使用短语和短句，避免复杂句型和句式；
复现的操作步骤要完整、准确、简短；
只记录各个操作步骤是什么，不要包含每个操作步骤执行后的结果；
将常见的步骤合并为较少的步骤。