软件缺陷基础概念
定义
从内部看,软件确认是产品开发或者维护过程中存在的错误、毛病等各种问题
从外部看,软件缺陷是系统所需要实现的某种功能的失效或者违背
总的来说,缺陷就是问题,最终表现为所需要的功能没有完全实现,没有满足用户的需求
具体包含(程序、数据、文档)
未达到需求规格说明书中的功能
出现了需求规格说明书中指明不会出现的错误
功能超出了需求规格说明书的范围
未达到需求规格说明书中虽然没有指明,但应该到达的目标
测试人员或者用户认为软件难以理解、不易使用、运行速度慢或最终用户认为不好
表现形式
功能、特性没有实现或者部分实现
设计不合理、功能特性不明确、逻辑不清楚或者存在矛盾
产品实际结果和所期望的结果不一致
没有达到需求规格说明书所规定的性能指标
运行出错、中断、崩溃、界面混乱
数据不正确、精度不够、不完整、格式不统一
用户不能接受的其他问题,超时、界面丑陋
硬件或者系统软件上存在的其他问题
缺陷产生的原因
缺陷不可避免,主要原因如下:
需求解释或者记录错误,用户需求定义错误,需求说明存在错误,编码说明、程序代码有误,硬件或者系统存在错误,文档错误、内容不正确、拼写错误
缺陷产生的根源
交流不充分、软件的复杂性、开发任务的错误、需求的变化、进度压力
缺陷的修复费用
说明测试应该尽早介入
缺陷报告介绍
在测试后,如果发现缺陷,则应该进行缺陷报告
缺陷报告的一些字段及说明
缺陷ID:唯一的缺陷ID,可以根据该ID追踪缺陷
缺陷状态:缺陷状态指缺陷通过一个跟踪修复过程的进展情况
缺陷标题:描述缺陷的标题
缺陷的严重程度:对软件产品的影响程度,分致命、较严重、严重、一般、低
缺陷的优先级:缺陷修复的先后顺序,即那些缺陷优先修正,哪些稍后
缺陷的所属模块:缺陷所属的项目和模块,要能较精确的定位至模块
缺陷记录着:提交缺陷的人员姓名
缺陷提交时间:缺陷提交的时间
缺陷处理人:处理缺陷的处理人
处理结果描述:对处理结果的描述,描述处理情况和代码修改说明
缺陷处理时间:缺陷处理的时间
缺陷验证人:对被处理缺陷验证的验证人(回测者)
验证结果描述:对验证结果的描述(通过、不通过)
缺陷详细描述:缺陷的复现步骤
缺陷环境说明:对测试环境的描述
必要的附件:如涉及到附件的或错误现象的图片等
缺陷报告有如下作用
记录测试结果、方便开发人员进行缺陷的定位、为后期统计缺陷提供依据
缺陷报告内容
缺陷的状态
状态变化
new:测试人员发现缺陷
assigned:由开发经理或者其他人员,将修复职责指定为某位开发人员
开发人员阅读缺陷报告,可能得到如下结果
open:测试人员是正确的,准备修复
dupllcate:与其他bug为同一原因,修正好一个后,这个也就修复了
reject:测试人员理解错误,其实这不是bug
flxed:经过一段时间开发人员修复了bug,就会标记为此状态
postpone:小问题,目前没有时间修复
4. 测试人员检验缺陷状态
closed:再次测试,发现错误已经修复
closedreject的错误,经过沟通核实后,确认无需修复
reopen:原来修复后的缺陷,经过回归测试后又出现了,标记原先的缺陷为此状态
缺陷的跟踪
要点:缺陷从测试人员开始,也应该由测试人员结束
严重程度
严重程度分为五个等级:
fatal致命的缺陷:造成系统或应用程序崩溃、死机、系统挂起,或造成数据丢失,主要功能完全丧失,导致本模块以及相关模块异常等问题
critical严重错误的软件缺陷:系统的主要功能部分丧失,数据不能保存,系统的次要功能完全丧失,问题局限在本模块,导致模块功能失效或异常退出。如系统自愿占用过大,功能没有做完
majoe一般的软件缺陷:次要功能没有完全实现但是不影响使用。如:提示信息不太准确,或用户界面差,操作时间长,模块功能部分失效等
minor较小的软件缺陷:较小错误的软件缺陷,使操作者不方便或遇到麻烦,但它不影响功能性的操作和执行,例如:对话框弹出位置,步骤较多,输入项太麻烦
enhancemental建议问题:由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑。例如:错别字、颜色、按钮大小
说明:严重程度的分级并不统一,有的公司分为三个或者四个等级都是可以的
优先级
表现形式
缺陷报告书写规范
标题
简短,尽量能够体现原因和结果;准确,避免使用模糊不清的词语;便于他人理解,不要使用俚语、方言词汇
原则
完整,他人按照此步骤,即可复现问题
简明,不包含夸张、啰嗦的内容
内容
测试环境描述
步骤(加上编号,一个步骤不要包含太多步骤,可能将多个步骤合而为一,可以包含该步骤后的一个中间结果,可使用短语或短句不需要复杂句式)
实际结果清楚,不笼统
期望结果根据需求文档,应该出现的结果
附件截图、录屏、测试中需要的数据
解决方案、可能的原因(非必填),如果测试人员能够给出解决方案则更好了
常见错误
人称代词不明确;情绪化语言,强调符号;不确定词汇;幽默、梗;不确定:对于缺陷,测试人员至少需要再次操作,来重现缺陷
缺陷统计
通过缺陷统计,我们可能得出以下信息
缺陷分布:找出系统的薄弱环境
缺陷状态:根据变化,检查测试和开发的工作情况
人员水平:开发人员出错的数量,测试人员出错的数量
比较历史:对人员水平有所把握
模块难度:较难的模块出问题的可能较大
修复时间:平均修复缺陷需要的时间,越短越好
未修复的缺陷数目
作用
风险评估:能否在计划内的时间发布
缺陷原因:避免反复出现同类型的缺陷
员工技能提升:根据开发和测试人员表现出来的问题,可有针对性提升
团队配置:根据缺陷修复时间,可知道团队配合强弱
指标
单位时间(天/周)内报告的缺陷数目
单位时间(天/周)内修复的缺陷数目
累计缺陷报告数量
累计缺陷修复数量
不同严重性的缺陷数
模块与缺陷的对应关系
缺陷密度
单位缺陷数量/kloc(kilo ines of code)计算 千行代码缺陷数量
总缺陷数量/总代码行数/1000
缺陷报告的原则和重要性
重要性
节省开发和测试人员的沟通时间、提高缺陷修复速度、提高测试人员的声誉、加强协同工作
原则
5C准则
准确:每个组成部分的描述准确不会引起误解
简洁:只包含必不可少的信息,不包含任何多余的内容
清晰:每个组成部分的描述清晰,易于理解
完整:包含复现该缺陷的完整步骤和其他本质信息
一致:按照一致的格式书写全部缺陷报告
2. 一个缺陷一个报告
便于分配、便于验证
常见缺陷的查找方法
UI(非重点)
色彩,大小,布局,图片,字体
时间
网络传输,数据未压缩,解析困难
文字内容
描述不清楚不正确,有语病、错别字,太复杂,乱码
容错处理
性能缺陷
花费时间长,资源占用多,卡顿,开发差,延迟高
缺陷的修复
不是所有的“缺陷”都是缺陷
无法重现或者难以捕捉;缺陷报告中没有复现步骤;缺陷报告无法理解;极少使用的功能,或者不符合用户习惯、惯例;由不受信任的测试人员提出
不是所有的缺陷都会修改
上线时间有限制;不正确的操作;涉及模块太多,可能导致按下葫芦浮起瓢的情况;性价比太低;极难重现
缺陷的管理过程(了解)
如果觉得《软件测试---缺陷 缺陷报告》对你有帮助,请点赞、收藏,并留下你的观点哦!