学习软件测试（四）软件缺陷

软件缺陷

定义：软件或程序中存在的各种问题及错误

软件缺陷的存在会导致软件产品在某种程度上不能满足用户的需求

判定标准

1. 软件未达到需求规格说明书标明的功能
2. 软件出现了需求规格说明书指明不会出现错误的地方
3. 软件的功能超出了需求规格说明书指明的范围
4. 软件出现了需求规格说明书虽未指明，而应该达到的目标
5. 软件测试人员认为软件难以理解，不易使用，运行速度慢，或者最终用户体验不好。

产生的原因

软件缺陷产生是不可避免的，造成软件缺陷产生的原因主要归纳如下：

1. 需求解释、记录或者定义错误
2. 设计文档说明存在错误或者拼写错误
3. 编码说明、程序代码有误
4. 硬件或者软件系统上存在错误

软件缺陷产生的根源

• 需求的变更
• 交流不充分
• 软件的复杂性
• 进度压力

软件缺陷的信息

编号	属性名称	描述
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	最低优先级。时间和资源允许时修正。

缺陷报告

模板：

缺陷报告的重要性

• 错误的缺陷报告会误导开发人员，影响开发人员的效率
• 错误的缺陷报告会影响测试人员自身的荣誉。

缺陷报告的注意事项

• 尽量确保缺陷可以重现
• 简洁、准确、完整
• 一个缺陷一个报告

缺陷书写规范

• 标题：应保持简短、准确，提供缺陷的本质信息

尽量按缺陷发生的原因与结果的方式书写：
避免使用模糊不清的词语，例如：“功能中断，功能不正确，行为不起作用”等。应该使用具体文字说明缺陷的症状。

• 复现步骤：应包含如何使别人能够很容易的复现该缺陷的完整步骤。

简单地一步步引导复现该缺陷，一个步骤包含的操作不要多
每个步骤前使用数字对步骤编号
尽量使用短语或短句，避免复杂句型句式
根据实际需要，提供测试的环境信息
避免包含多余的步骤，避免丢失必要的步骤

• 实际结果：是执行复现步骤后软件的现象和产生的行为。

实际结果的描述应向标题信息那样，要列出具体的缺陷症状，而不是简单地指出“不正确”或“不起作用”

• 期望结果：描述应与实际结果的描述方式相同。通常需要列出期望的结果是什么。
• 附件：对缺陷描述的补充说明，可以是以下类型：

缺陷症状的截图
测试使用的数据文件

• 其他常见错误

避免使用我、你等人称代词，可以直接使用动词或必要时使用”用户“代替
避免使用情绪化的语言和强调符号
避免使用诸如“似乎”、“看上去可能”等含义模糊的词汇，而需要报告确定的缺陷结果
避免提交不确定的测试问题，自己至少需要重现一次再提交

缺陷处理流程

缺陷跟踪流程

测试报告

一般公司会有模板

缺陷统计

一个项目全做完了，测试需要做一个报告。

缺陷数据分析关注的问题

1. 正在测试的软件哪个模块的问题最多
2. 测试人员中谁报告的软件缺陷最多
3. 各类缺陷所占的数量百分比是多少
4. 开发人员能及时修复软件缺陷吗
5. 开发人员一次正确修复缺陷的百分比是多少
6. 正在开发的软件能否在计划的时间内正常发布

禅道软件（未使用）

有兴趣的可以看下面这篇文章
禅道项目管理软件配置及使用教程