《软件测试52讲》读书笔记 —— 如何高效填写软件缺陷报告?
作者:互联网
缺陷标题
通常采用 在什么情况下发生了什么问题 的模式
First
描述 什么问题 的同时还必须清楚地表述发生问题时的上下文,也就是 问题出现的场景
Second
标题应该尽可能描述问题本质,而避免只停留在问题的表面
比如:“商品金额输入框,可以输入英文字母和其他字符”,这个描述就只描述了问题的表面现象;若采用“商品金额输入框,没有对输入内容做校验”,就可以透过标题看到缺陷的本质,这样可以帮助开发人员快速掌握问题的本质
Last
缺陷标题不易过长,对缺陷更详细的描述应该放在“缺陷概述”里
缺陷影响
优先级:开发以此为依据来决定修复该缺陷的优先级
严重程度:以此衡量缺陷的严重程度,并决定是否要等该缺陷被修复后才能发布产品
环境配置
主要是为缺陷的重现提供必要的环境信息,比如: 操作系统的类型与版本 、 被测软件版本 、 浏览器的种类和版本 、 被测软件的配置信息 、 集群的配置参数 、 中间件的版本信息
主要注意的是,环境配置的内容通常是按需描述,也就是说通常只描述那些 重现缺陷的环境敏感信息
比如:“菜单栏上某个条目缺失的问题”只会发生在 Chrome 浏览器,而其他浏览器都没有类似问题。那么, Chrome 浏览器 就是 环境敏感信息 ,必须予以描述,而至于 Chrome 浏览器是运行在什么操作系统上就无关紧要了
前置条件
前置条件是指测试步骤开始前系统应该处在的状态,目的是减少缺陷重现步骤的描述。合理地使用前置条件可以在描述缺陷重现步骤时排除不必要的干扰
比如:
- 某个业务操作需要先完成用户登录,在缺陷重现步骤里就没必要描述登录操作的步骤细节,可以添加“前置条件:用户已完成登录”
- 用户在执行登录操作前,需要事先在被测系统准备好测试用户,在缺陷重新步骤无需添加“生成新的用户”,可以添加“前置条件:用户已完成注册”
重现步骤
从用户角度出发来描述的,每个步骤都应该是可操作并且是连贯的,所以往往会采用步骤列表的表现形式。
- 确保缺陷的可重现性
- 找到最短的重现路径,过滤掉非必要的步骤
期望结果和实际结果
描述期望结果时:需要说明 应该发生什么 ,而不是说明 不应该发生什么
描述实际结果时:需要说明 发生了什么 ,而不是 没有发生什么
优先级和严重程度
严重程度,是缺陷本身的属性,通常确定后不再变化
优先级,则是缺陷的工程属性,会随着项目进度、解决缺陷的成本等因素而变动
优先级和严重程度的关系
- 缺陷越严重,优先级越高
- 缺陷影响范围越大,优先级越高
- 有些缺陷不影响用户使用,但是会妨碍测试的正常执行,这种属于 严重程度低,优先级高
- 有些缺陷虽然严重程度较高,但考虑到修复成本和技术难度,也会有优先级低的情况
变通方案
是指提供一种临时绕开当前缺陷而不影响产品功能的方式
变通方案的有无以及实施的难易程度,是决定缺陷优先级和严重程度的重要依据。
如果某个严重的缺陷无任何变通方案,那么不管修复缺陷代价多大, 优先级一定会是最高的,如果该缺陷存在比较简单的变通方案,那么优先级就不一定是最高的
根原因分析(Root Cause Analysis)
平常说的RCA,如果能在发现缺陷的同时,定位出问题的根本原因,那是最好的
标签:优先级,读书笔记,步骤,52,重现,描述,缺陷,前置条件,软件测试 来源: https://blog.51cto.com/u_12020737/2838314