缺陷报告

缺陷报告

前言

  1. 不做文字的搬运工,多做灵感性记录
  2. 这是平时学习总结的地方,用做知识库
  3. 平时看到其他文章的相关知识,也会增加到这里
  4. 随着学习深入,会进行知识拆分和汇总,所以文章会随时更新
  5. 参考的文章过多,所以参考会写不全,见谅

1.软件缺陷

1.含义

  • 软件缺陷(Defect),又叫bug(臭虫)
  • 软件存在不符合质量需求或违背软件用户、客户、企业意愿的问题

2.判定标准

  • 软件未能达到产品说明书标明的功能
  • 软件出现产品说明书指明不会出现的错误
  • 软件出现产品说明书指明不会出现的错误
  • 软件功能超出产品说明书指明范围
  • 软件未达到产品说明书未指出但应达到的目标
    • 说明书也没必要什么都写,有些相当于公认的,是必须要有的(断电保存数据)
  • 人软件测试人员认为软件难以理解、不易使用、运行速度缓慢、或者最终用户认为不好

3.分类

1.分类标准

分类标准 英文 含义
缺陷类型 Type 根据缺陷的自然属性划分的缺陷种类
缺陷严重程度 severity 是因缺陷引起的故障对软件产品影响程度
缺陷优先级 priority 缺陷必须修复的紧急程度
缺陷状态 status 缺陷通过一个跟踪修复过程的进展请情况

2.分局缺陷类型分类

  • 功能缺陷
  • 界面缺陷
  • 文档缺陷
  • 代码缺陷
  • 算法错误
  • 性能缺陷

3.根据缺陷等级

  • A 类——致命缺陷
  1. 由于程序所引起的死机、非法推出
  2. 死循环
  3. 数据库锁死
  4. 因错误操作导致的程序中断
  5. 功能错误
  6. 与数据库链接错
  7. 数据通讯错误
  • B 类——严重缺陷
    1. 程序错误
    2. 程序接口错误
    3. 数据库的表、业务规则、缺省值未加完整性等约束条件
  • C 类错误——一般错误
    1. 操作界面错误(包括数据窗口内列名、含义是否一致)
    2. 打印内容、格式错误
    3. 简单输入限制未放在前台进行控制
    4. 删除操作未给出提示
    5. 数据库表中有过多的空字段
  • D 类——较小缺陷
    • 界面不规范
    • 辅助说明描述不清楚
    • 输入输出不规范
    • 长操作未给用户提示
    • 提示窗口文字未采用行业术语
    • 可输入区域和制度区域没有明显的区分标志
  • E 类——意见或建议

4.缺陷处理优先级

缺陷优先级 描述
1 必须立即解决
2 需要正常排队等到修复
3 可以在方便的时候被纠正
4 下一个版本修复
5 不修复或列入软件发布清单

5.缺陷状态

缺陷状态 中文 描述
submitted 已提交 已经提交的缺陷(有些叫新建缺陷)
open 打开 确认’提交缺陷‘,等待处理
rejected 已拒绝 拒绝提交的缺陷,不需要修复或者不是缺陷
resolved 已解决 却选被修复
verified 已验证 确认缺陷缺失被修正
closed 已关闭 确认被修复的缺陷,将其关闭

3.表现形式

  • 用户要求的功能、特性没有实现或者部分实现
  • 运行出错,包括运行中断、系统崩溃、界面混乱等
  • 数据结果不正确、精度不够、不完整或者格式不统一
  • 文字显示内容不正确或拼写错误
  • 系统性能低下、资源浪费

4.分离和再现

  • 发现缺陷后,应该做好分离和再现,排查发现的“缺陷”是不是软件本身的问题,然后再提交
  • 重现3次
    • 重现
    • 复现

5.应避免的缺陷

此类缺陷让测试人员遭受职责

1.缺陷的缺陷

  • 含义

    • 测试人员提交的不是缺陷的缺陷

    • 是一种无效的缺陷

  • 处理

    • 正确理解需求
    • 做好复现

2.重复缺陷

  • 含义
    • 同一个缺陷 A测试工程师提交后,B 工程师又提交或者自己提交的缺陷与之前的缺陷相同或类似
    • 是一种无效缺陷
  • 处理
    • 尽量避免两个人同时测同一模块
    • 自己提交的缺陷与自己的重复,提交前查找一下,增强开发知识

3.有争议的缺陷

  • 有关人员进行沟通、讨论
  • 搁置

4.无法再现的缺陷

  • 首先,对于这样的缺陷进行详细的记录,使用不同的方法去重现
  • 其次,要合理安排时间,要考虑测试项目的进度,对一时难以再现的缺陷可以暂时搁置,以保证项目正常进度,并尽快提交给开发人员
  • 最后,在测试过程对未再现缺陷予以关注

2.缺陷报告

1.含义

是对缺陷进行记录、分类和跟踪的文档

2.读者对象

  • 软件开发人员
    • 报告缺陷是为了缺陷得到修复
    • 希望获得缺陷的本质特质和复现步骤
  • 质量管理人员
  • 市场人员
  • 计输支持人员
    • 希望得到缺陷的严重程度和分布情况,以及市场和用户的影响程度

3.写作准则(5C)

  • Correct(准确)
    • 每个组成部分的描述准确,不会引起误解
  • Clear(清晰)
    • 每个组成部分的描述清晰,易于理解
  • Concise(简洁)
    • 只包含必不可少的信息,不包含任何多余的内容
  • Complete(完整)
    • 包含复现该缺陷的完整步骤和其他本质信息
  • Consistent(一致)
    • 按照一致的格式书写全部缺陷报告

4.组织结构

  • 缺陷的标题 / 缺陷的摘要 / 缺陷概述 / 缺陷概述 / 缺陷基本信息
    • 其实就是标题
  • 预处理
    • 相当于预置条件。可要可不要,看情况
  • 复现步骤
    • 就是操作步骤,用例写的好了,可以直接粘贴过来
  • 期望结果
    • 用例的预期结果
  • 实际结果
  • 缺陷的严重程度
  • 缺陷的优先级
  • 测试的软件和硬件环境
  • 测试的软件版本
    • pc、安卓、iso、linux
    • 软件:安装了什么依赖软件
    • 硬件:cpu,内存、(牌子、大小)
  • 缺陷的类型
  • 注释文字和缺陷截图
    • 截图:一般在陈述不清楚时候使用,还有一些开发不认同的

5.写作要求

前言

  • 尽量提前跟开发沟通一下,看他觉得这是不是bug,他确定是了,再提也不晚

1.缺陷标题

  • 尽量按照缺陷发生的原因与结果的方式书写
    • 执行完A后,发生B
    • 在什么地方,做了那些事情,除了什么结果
      • 使用链接词语:
        • 在。。。以后
        • 在。。。时候
        • 在。。。期间
  • 避免使用模糊不清的词语
  • 方便搜索查询,尽量使用关键词
  • 方便他人理解,要避免使用术语、俚语或过分具体的测试细节

2.重现步骤

  • 提供测试的预备步骤和信息
  • 步骤完整、准确、简短,内有缺漏任何操作步骤,没有任何多余的步骤
  • 将常见步骤合并未较少步骤
  • 简单地一步一步地引导复现该缺陷
  • 每一个步骤尽量只记录一个操作
  • 每一个步骤前面使用数字对步骤编号
  • 尽量使用短语和短句,避免复杂句型和句式
  • 只记录各个操作步骤是什么,不要包括每个步骤的执行结果

3.预期结果

  • 软件应该具有的结果,或者说正确的结果是什么样子

4.实际结果

  • 试剂结果的描述要列出具体的表现行为,而不是简单指出“不正确”或“不起作用”

  • 如果一个动作产生彼此不同的多个缺陷结果,或者一个动作将会产生一个结果,而这个结果又产生另一个结果。为了易于阅读,这些结果应该用数字列表分割开来

比如:实际结果:

1.显示“命令代码行。。。错误”

2.显示“并且终止。。。服务”

5.注释/截图

  1. 包含的内容

    • 截取缺陷特征图像文件
    • 测试过程所使用的测试文件
    • 测试附加的打印机驱动程序
    • 再次描述重点,避免开发人员将缺陷退回给测试人员补充更多信息
    • 再次指明该缺陷是否在前一版本中已经存在
    • 多个平台之间是都具有不同的表现
    • 注释包含缺陷的隔离信息没指出缺陷的具体影响范围

    如:

    • 能在win2000和winXP文本框中显示恩本内容,但是不支持Win98
    • 屏幕刷新后,现象会消失‘
    • 使用二进制文件,不存在该错误
    • 参见附加的使用说明书和测试文件

6.避免使用的语言

  • 我(I)你(you) 他/她(He / She)
  • 情绪化的语言和强调符号(!!!)
  • 似乎(Seems) 、看上去可能(Appears)
  • 认为比较幽默的的内容
  • 不确定的测试问题(Issues) / 不确定是否是缺陷

6.提高质量

  • 尽早提交缺陷报告
  • 清楚说明次问题对用户价值的危害
  • 提供尽可能多的技术信息,方便程序员调试
    • 如包含该缺陷需要的环境变量或测试所用的数据文件
  • 报告的软件缺陷进行了必要的隔离,报告的缺陷信息具体、准确
    • 一定要提前排查过不是因为人为的原因导致,就是软件本身得原因
  • 易于搜索软件测试报告的缺陷
  • 一个缺陷报告中只报告了一种缺陷
  • 缺陷报告中不要提问问题

7.缺陷报告处理

1.简单处理流程/缺陷生命周期

在这里插入图片描述

人员 处理 得/传
软件测试人员 提交
测试负责人 分配 相关人员
相关人员 修改记录
测试人员 返测
负责人 关闭
开发人员 返测未通过 处理步骤
  • 关闭或已解决的缺陷报告可能会被阶段性的复审重新打开,应该立即处理

2.缺陷报告的处理流程

  • 缺陷报告的处理流程和缺陷的处理流程是一样的

在这里插入图片描述

  • 正常缺陷
  • 重复缺陷
  • 无效缺陷
  • 推迟修改
  • 验证不通过:返测不通过
  • 描述不清楚

3.缺陷管理工具

1.管理工具的功能

  • 缺陷提交
  • 缺陷跟踪
  • 缺陷分析

2.有效缺陷分析好处

  • 评价软件质量
  • 帮助项目组很好掌握和评估软件的研发过程,进而改进研发过程,
  • 为软件新版本的开发提供宝贵的经验,进而在项目开展之前,指定有效、准确的项目控制计划

3.常见的缺陷管理工具

  • Bugzilla
    • 八个zei了
  • Bugfree
  • Mantis
  • Jira
  • Zen Tao(禅道)
  • Quality Center / Application Lifecycle Management(ALM)

软件说明书

  • 简称说明(spec)或产品说明书(product spec)
  • 是软件开发小组的一个协定。它对开发的产品进行定义,给出产品的细节、如何做、做什么、不能做什么。这种协定从简单的口头说明到正式的书面文档有多种形式

参考

  1. 尚硅谷课件

跳转

知识目录

展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 游动-白 设计师: 上身试试
应支付0元
点击重新获取
扫码支付

支付成功即可阅读