软件缺陷,缺陷报告怎么写_缺陷报告通常包括哪些内容

大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。

Jetbrains全系列IDE使用 1年只要46元 售后保障 童叟无欺

软件缺陷
软件缺陷： 常常又被叫做Bug。所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。
从软件测试观点出发，软件缺陷有以下五大类：
功能缺陷、系统缺陷、加工缺陷、数据缺陷、代码缺陷

软件类别：
缺陷的表现形式不仅体现在功能的失效方面，还体现在其他方面。主要类型有：
软件没有实现产品规格说明所要求的功能模块；
软件中出现了产品规格说明指明不应该出现的错误；
软件实现了产品规格说明没有提到的功能模块；
软件没有实现虽然产品规格说明没有明确提及但应该实现的目标；
软件难以理解，不容易使用，运行缓慢，或从测试员的角度看，最终用户会认为不好

缺陷属性：
1、缺陷标识：缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识；
2、缺陷类型：缺陷类型是根据缺陷的自然属性划分的缺陷种类；
3、缺陷严重程度：缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度；
4、缺陷优先级：缺陷的优先级指缺陷必须修复的紧急程度；
5、缺陷起源：缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段；
6、缺陷状态：缺陷状态指缺陷通过一个跟踪修复过程的进展情况；
7、缺陷来源：缺陷来源指引起缺陷的起因；
8、缺陷根源：缺陷根源指发生错误的根本因素。

缺陷严重程度：
1级（Critical）：不能执行正常工作功能或重要功能，或者危及人身安全。
2级（Major）：严重的影响系统要求或基本功能的实现，且没有办法更正。（重新安装或重新启动该软件不属于更正办法）
3级（Minjor）：严重的影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法）
4级（Cosmetic）：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能
5级（Other）：其他错误

Major：主要的，较大的缺陷 Minor：次要的，小的缺陷

缺陷优先级：
1级：缺陷必须被立即解决
2级：缺陷需要正常排队等待修复或列入软件发布清单
3级：缺陷可以在方便时被纠正

缺陷状态：
1级：已提交的缺陷
2级：确认“提交的缺陷”，等待处理
3级：拒绝“提交的缺陷”，不需要修复或不是缺陷
4级：缺陷被修复
5级：确认被修复的缺陷，将其关闭

缺陷起源：
1.Requirement：在需求阶段发现的缺陷
2.Architecture：在架构阶段发现的缺陷
3.Design：在设计阶段发现的缺陷
4.Code：在编码阶段发现的缺陷
5.Test：在测试阶段发现的缺陷

缺陷报告
当测试时人员发现一个缺陷，需要填写一份“缺陷报告”来记录这个缺陷，并通过这个缺陷报告告知开发人员所发生的问题–缺陷报告实测实人员和开发人员交流沟通的重要工具
案例1：张三在测试案例1-2-1程序时，发现除数为0时程序异常退出，向开发组提交一份缺陷报告。


一、缺陷报告的组成：
1、缺陷编号（Defect ID）：提交缺陷的顺序
2、缺陷的标题（summary）：简明扼要的描述缺陷
3、缺陷的发现者（Defected By）：测试人员
4、缺陷发现的日期（date）：一般为当天
5、缺陷所属的模块（subject）：在测试那个功能模块时发现的bug
6、发现缺陷的版本（Defected in release）：开发的软件的版本
7、指派给谁处理（Assigned to）：测试人员指派给开发经理，开发经理根据缺陷所在的模块，需要再次指派具体的开发人员
8、缺陷的状态（status）：缺陷此时所处的处理阶段或处理情况
（1）测试人员发现缺陷，提交缺陷报告，把缺陷的状态置为new（新）
（2）开发经理验证提交的bug，如果是bug，把状态改为open（打开的bug，开发组承认的bug），指派给具体的开发人员解决；如果不是bug，把状态改为rejected（拒绝的bug）
（3）开发人员看到指派给自己解决的bug，进行缺陷修复，修改完后，把缺陷状态fixed（已经修复的bug，可以返测的bug）
（4）测试人员对修复的bug进行反测，若返测成功，将状态改为closed（关闭的缺陷，归档的bug）；如果返测不成功，把状态改为reopen（重新打开的bug）
缺陷报告的处理流程

说明：
（1）以上过程就是缺陷的处理流程
（2）一个缺陷的生命周期：new->open->fixed->closed
返测：针对程序员修复的缺陷进行测试，验证该缺陷是否真正解决
9、缺陷的严重程度（severity）：bug对软件的影响有多大
urgent：造成系统死机、重启、崩溃的缺陷
very high：非常严重的缺陷
high：大的缺陷
medium：中等程度的缺陷
low：小的缺陷
bug level（等级、级别）每一个等级到底包含哪些缺陷，最好在专门的文档中进行详细说明，这样可以使开发人员和测试人员达成共识
性能：performance 功能：function
10、缺陷的优先级（priority）：测试人员希望该缺陷程序员在什么时间或者在那个版本中解决
urgent：立刻修改（影响开发或测试的进度）
veryhigh：本版本修改（一个软件开发过程可能就含有多个版本，比如一个星期就是一个版本）
high：下版本修改
low：允许在产品发布后存在的软件缺陷
11、缺陷描述（description）：把发现bug的步骤、使用的数据等记录下来，使程序员通过描述就能清楚所发生的事情
二、加深理解
1、缺陷的严重程度和优先级是不是成正比关系？
界面问题的严重程度一般比较低，担优先级可能很高————立即修复
某些重大的功能问题可能暂时解决不了，但不影响其他功能的使用，这时优先级可能定义的比较低————在发布之前修复
2、缺陷的严重程度和优先级确定好后，还能修改吗？
严重成度不允许改，优先级可能修复。
测试人员确定一个缺陷“立即修复”，但开发组认为这个缺陷不好解决，而这个缺陷又不影响其他功能，这时可能要求在“下一个版本修改”或“发布之前修改”
3、是不是所有一发现的缺陷都会被修复？
有些缺陷修复的成本太高或者由于进度压力可能在发布前得不到修复，这样的缺陷一定要经过项目组的讨论，权衡成本和风险，要确保不会对用户在成重大的影响及法律纠纷。后面再通过升级软件或者打补丁的方式修复缺陷或弥补漏洞
三、缺陷报告的用途
1、记录bug 2、对bug进行分类（模块、bug状态、严重程度、版本）
3、跟踪bug 4、对bug进行分析、统计
四、如何识别bug
1、通过测试用例的预期结果判断——实际结果与预期结果不一致，就是bug
2、看需求（通过缺陷的5定义识别）
3、沟通（开发、需求、用户）
五、些缺陷报告时注意的问题
1、一个报告只提交一个缺陷
2、缺陷描述清晰、准确、易读、使用最少、必须的步骤、确保缺陷可以在现
3、对缺陷的严重性、优先级的划分准确、客观
4、在提交缺陷报告之前一定要认真审核，确保提交的缺陷是有效的，而不是因为自己的疏忽或操作不正确造成的”假缺陷“
5、不要为了引起开发人员的重视而夸大缺陷
6、小的缺陷也要报告
7、及时报告缺陷
8、对于不可重现的缺陷也要报告
9、不做任何评价
一些公司是不允许在电脑上安装截图的工具的，可以使用Windows自带的画图软件，步骤：
1）：截

测试流程 如何描述

黑盒测试白盒测试优缺点