【软件缺陷】

定义

软件或者程序中存在的问题及错误

软件缺陷的判定标准

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：打开状态
  • reopen：关闭的缺陷，再次打开
• fixed：修复状态
• closed：关闭状态
• rejected：拒绝状态
• postpone：拖延状态

缺陷的严重程度

• 5-Critical
  • 系统瘫痪、异常退出、死循环、严重的计算错误等
• 4-VeryHigh
  • 频繁的死机，系统大部分功能不可用
• 3-High
  • 功能点没有实现，或不符合用户需求
  • 数据丢失
• 2-Medium
  • 影响一个相对独立的功能
  • 仅仅在特定条件上发生
  • 与 产品需求定义不一致
  • 断断续续的出现问题
• 1-Low
  • 表面性的错误（如错别字）

缺陷的优先级

• 5-Urgent
  • 最高优先级。在这个错误影响下，系统几乎不可用
• 4-VeryHigh
  • 高优先级。错误对这套系统的能力产生严重的影响
• 3-High
  • 中优先级。如果这个错误存在于系统中，会制约开发喝测试活动的进行，如果先前没有修复它，那么需要在发布前修复他
• 2-Medium
  • 低优先级。不会延迟发布，但是会在以后修正这个错误
• 1-Low
  • 最低优先级。时间和资源允许时修正

缺陷类型

• 功能错误
• 界面错误
• 兼容性缺陷

缺陷管理

认识缺陷报告

缺陷报告的重要性

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

缺陷报告的注意事项

• 缺陷报告不能有缺陷
• 尽量确保缺陷可以重现
• 简洁、准确、完整
• 一个缺陷一个报告
• 避免出现模糊的词汇
• 不能有感情色彩
• 出现bug过程一定要详细

缺陷书写规范

• 标题：简洁、准确，提供缺陷的本质信息

尽量按缺陷发生的原因和结果的方式书写 避免使用模糊不清的词语

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

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

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

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

• 期望结果：描述应与实际结果的描述方式相同。通过需要列出期望的结果是什么

• 附件：对缺陷描述的补充说明，可以是以下类型：

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

其他常见错误

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

缺陷处理流程

缺陷跟踪流程

• new新建状态
• 要提交一个缺陷，首先是新建状态
• open打开状态
  • 确认缺陷有效后，为打开状态
• fixed修复状态
  • 由缺陷的处理人，把缺陷处理完成之后设置为修复状态
• closed关闭状态
  • 验证缺陷确实修复成功后，一般由缺陷的发起人设置状态为关闭状态
• reopen重新打开状态
  • 一个已经关闭的缺陷再次出现，就要设置为重新打开状态

缺陷统计

• 按严重程度统计
• 按缺陷提交人分布
• 按缺陷类型分布

缺陷分析需要注意的点

• 哪个模块问题最多
• 哪个测试工程师测试的缺陷最多
• 各类缺陷数量占比
• 开发是否可以及时修复缺陷
• 开发人员一次修复缺陷占比
• 软件是否可以正常发布

项目管理工具——禅道

禅道介绍

• 由青岛易软天创工资开发的一款项目管理软件
• 开源，免费
• 产品管理，项目管理，质量管理三个核心流程融合在一套工具里面，是一款软件生命周期管理工具
• 轻量级实现，部署简单

禅道中的三权分立思想

禅道管理软件中，核心的三种角色：产品经理、研发团队和测试团队，相对独立

禅道使用流程

基本流程如下：

1. 产品经理创建产品
2. 产品经理创建需求
3. 项目经理创建项目
4. 项目经理确定项目要做的需求
5. 项目经理分解任务，指派到人
6. 测试人员测试，提交bug

使用centOS中禅道的步骤

• 需要在vmware中加载centOS6的虚拟操作系统

• 在vmware中启动centOS6

• 登录centOS

• 进入命令行终端

  • ifconfig - 查看centOS的IP地址

• 回到windows下，用ping来验证是否可以与centOS网络联通

• 打开浏览器

  • http://centOS的ip:81/www

经过以上操作就可以看到禅道的登录页面

测试管理工具——JIRA

JIRA介绍

• 由澳大利亚Atlassian公司开发的一款有优秀的软件问题跟踪管理软件工具。它可以对各种问题进行管理和跟踪。
• jira产品非常的完善，且功能强大
• 特点是支持多语言，干净和强大的用户界面，企业级的权限和控制，可以在几乎所有硬件和操作系统和数据库平台运行

JIRA系统中所涉及到的角色

• 企业管理人员
• 项目管理者
• 开发人员
• 测试人员
• 其他人员

内容来源b站黑马程序员软件测试基础教程视频