学习软件测试软件缺陷
Posted 一只小阿大:)
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了学习软件测试软件缺陷相关的知识，希望对你有一定的参考价值。
目录
软件缺陷
定义：软件或程序中存在的各种问题及错误
软件缺陷的存在会导致软件产品在某种程度上不能满足用户的需求
判定标准
- 软件未达到需求规格说明书标明的功能
- 软件出现了需求规格说明书指明不会出现错误的地方
- 软件的功能超出了需求规格说明书指明的范围
- 软件出现了需求规格说明书虽未指明，而应该达到的目标
- 软件测试人员认为软件难以理解，不易使用，运行速度慢，或者最终用户体验不好。
产生的原因
软件缺陷产生是不可避免的，造成软件缺陷产生的原因主要归纳如下：
- 需求解释、记录或者定义错误
- 设计文档说明存在错误或者拼写错误
- 编码说明、程序代码有误
- 硬件或者软件系统上存在错误
软件缺陷产生的根源
- 需求的变更
- 交流不充分
- 软件的复杂性
- 进度压力
软件缺陷的信息
| 编号 | 属性名称 | 描述 |
|---|---|---|
| 1 | 缺陷ID | 唯一的缺陷ID，可以根据该ID追踪缺陷 |
| 2 | 缺陷状态 | 缺陷状态指缺陷通过一个跟踪修复过程的进展情况 |
| 3 | 缺陷标题 | 描述缺陷的标题 |
| 4 | 缺陷的严重程度 | 对软件产品的影响程度，分致命、较严重、严重、一般、低 |
| 5 | 缺陷的优先级 | 缺陷修复的先后顺序，即哪些缺陷优先修正，哪些稍后修正 |
| 6 | 缺陷所属模块 | 缺陷所属的项目和模块，要能较精确的定位至模块 |
| 7 | 缺陷记录者 | 提交缺陷的人员姓名 |
| 8 | 缺陷提交时间 | 缺陷提交的时间 |
| 9 | 缺陷处理人 | 处理缺陷的处理人 |
| 10 | 处理结果描述 | 对处理结果的描述，描述处理情况和代码修改说明 |
| 11 | 缺陷处理时间 | 缺陷处理的时间 |
| 12 | 缺陷验证人 | 对被处理缺陷验证的验证人（回测者） |
| 13 | 验证结果描述 | 对验证结果的描述（通过、不通过） |
| 14 | 缺陷详细描述 | 缺陷的重现步骤 |
| 15 | 缺陷环境说明 | 对测试环境的描述 |
| 16 | 必要的附件 | 如涉及到附件的或错误现象的图片等。 |
缺陷的基本内容
缺陷标题，缺陷的预置条件，缺陷的重现步骤，缺陷的实际结果，缺陷的期望结果
缺陷的状态
- new：“新建状态”
- open：“打开状态”
- fixed：“修复状态” 指研发更改了
- closed：“关闭状态” bug被修复了，由测试人员关闭
- rejected：“拒绝状态” 测试提交了，拒绝修改
- postpone：“拖延状态” 研发现在时间管这个bug
缺陷的严重程度
| 严重等级 | 描述 |
|---|---|
| 5-Critical | 系统瘫痪、异常退出、死循环、严重的计算错误等 |
| 4-VeryHigh | 频繁的死机，系统大部分功能不可用 |
| 3-High | a.功能点没有实现，或不符合用户需求 b.数据丢失 |
| 2-Medium | a.影响一个相对独立的功能 b.仅仅在特定条件上发生 c.与产品需求定义不一致 d.断断续续的出现问题 |
| 1-Low | 表面性错误（如错别字） |
缺陷的优先级
| 优先级别 | 描述 |
|---|---|
| 5-Urgent | 最高优先级。在这个错误影响下，系统几乎不可用。 |
| 4-VeryHigh | 高优先级。错误对这套系统的能力产生严重的影响。 |
| 3-High | 中优先级。如果这个错误存在与系统中，会制约开发和活动的进行，如果先前没有修复它，那么需要在发布前修复它 |
| 2-Medium | 低优先级。不会延迟发布，但是会在以后修正这个错误。 |
| 1-Low | 最低优先级。时间和资源允许时修正。 |
缺陷报告
模板：
缺陷报告的重要性
- 错误的缺陷报告会误导开发人员，影响开发人员的效率
- 错误的缺陷报告会影响测试人员自身的荣誉。
缺陷报告的注意事项
- 尽量确保缺陷可以重现
- 简洁、准确、完整
- 一个缺陷一个报告
缺陷书写规范
- 标题：应保持简短、准确，提供缺陷的本质信息
尽量按缺陷发生的原因与结果的方式书写：
避免使用模糊不清的词语，例如：“功能中断，功能不正确，行为不起作用”等。应该使用具体文字说明缺陷的症状。
- 复现步骤：应包含如何使别人能够很容易的复现该缺陷的完整步骤。
简单地一步步引导复现该缺陷，一个步骤包含的操作不要多
每个步骤前使用数字对步骤编号
尽量使用短语或短句，避免复杂句型句式
根据实际需要，提供测试的环境信息
避免包含多余的步骤，避免丢失必要的步骤
- 实际结果：是执行复现步骤后软件的现象和产生的行为。
实际结果的描述应向标题信息那样，要列出具体的缺陷症状，而不是简单地指出“不正确”或“不起作用”
- 期望结果：描述应与实际结果的描述方式相同。通常需要列出期望的结果是什么。
- 附件：对缺陷描述的补充说明，可以是以下类型：
缺陷症状的截图
测试使用的数据文件
- 其他常见错误
避免使用我、你等人称代词，可以直接使用动词或必要时使用”用户“代替
避免使用情绪化的语言和强调符号
避免使用诸如“似乎”、“看上去可能”等含义模糊的词汇，而需要报告确定的缺陷结果
避免提交不确定的测试问题，自己至少需要重现一次再提交
缺陷处理流程
缺陷跟踪流程
测试报告
一般公司会有模板
缺陷统计
一个项目全做完了，测试需要做一个报告。
缺陷数据分析关注的问题
- 正在测试的软件哪个模块的问题最多
- 测试人员中谁报告的软件缺陷最多
- 各类缺陷所占的数量百分比是多少
- 开发人员能及时修复软件缺陷吗
- 开发人员一次正确修复缺陷的百分比是多少
- 正在开发的软件能否在计划的时间内正常发布
禅道软件（未使用）
有兴趣的可以看下面这篇文章
禅道项目管理软件配置及使用教程
以上是关于学习软件测试软件缺陷的主要内容，如果未能解决你的问题，请参考以下文章
软件测试体系学习及构建（12）-测试基础之软件测试的原则概述