大家好,又见面了,我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。
Jetbrains全系列IDE使用 1年只要46元 售后保障 童叟无欺
引言
软件缺陷定义
软件缺陷(Defect):又叫做Bug。即为计算机软件、程序、web应用中存在的某种不符合正常运行的功能问题。也是错误、隐藏,让用户不满意的功能缺陷。
从产品内部看,缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题;
从产品外部看,缺陷是系统所需要实现的某种功能的失效或违背。
缺陷报告定义
缺陷报告把测试的过程和结果写成文档,并对发现的问题和缺陷进行分析,为纠正软件存在的质量问题提供依据,同时为软件验收和交付打下基础。
协同公司在项目中采用的缺陷处理过程如下
在软件测试过程中,缺陷报告起到了一个交接单的作用,它帮助开发人员和测试人员之间更有效的交流,提高了缺陷的解决速度和质量。同时也可以通过统计bug数来对被测的软件进行质量评估,比如根据以往项目中每千行bug数的平均值来制定测试计划,同类的产品,尤其是同一个开发流程的产品,这些数值不应该相差太多,如果相差一个数量级以上,我们几乎可以说,要么是QA出问题了,要么是开发出问题了。另外,降级bug的多少对于软件质量评估也是一个重要参考标准,降级bug也就是由于修正一个bug,又产生了一个新bug,降级bug数目过多意味着现在的产品在越修越坏。
缺陷报告是测试过程中可以提交的最重要的东西。编写缺陷报告的目的是为了方便程序员找到程序出现的问题,从而有利于分析错误产生的原因,定位错误,修改问题。它的重要性丝毫不亚于测试计划,并且比其他的在测试过程中的产出文档对产品的质量的影响更大。因此,缺陷报告编写的基本要求是简洁、准确、完整、规范。有效的缺陷报告将能够:减少开发部门的二次缺陷率、提高开发修改缺陷的速度、提高测试部门的信用度、增强测试和开发部门的协作。那么在提交缺陷报告时,我们需要提交的就是一份简单明了、便于理解和查找问题的缺陷报告。
各个测试阶段中的测试点
单元测试: 针对每个单元的测试,以确保每个模块能正常工作为目标。
集成测试: 对已测试过的模块进行组装,进行集成测试。目的在于检验与软件设计相关的程序结构问题。
系统测试: 检验软件产品能否与系统的其他部分(比如,硬件、数据库及操作人员)协调工作。
验收测试: 检验软件产品质量的最后一道工序。主要突出用户的作用,同时软件开发人员也应有一定程度的参与,验收测试可以分成Alpha测试和Beta测试。
Alpha测试: 由用户在开发环境下完成的测试
Beta测试: 由用户在用户环境下完成的测试。
缺陷报告的组成
报告信息
编号 | 信息 | 描述 |
---|---|---|
1 | 软件名称 | 缺陷报告属于哪个软件。 |
2 | 编号 | 执行那条用例时出现的缺陷,用例编号等于缺陷编号。 |
3 | 版本号 | 此缺陷是否被修改过。新建为1.0 。 |
4 | 测试人员 | 报告编写人。 |
5 | 日期 | 编写日期。 |
6 | 指定处理人 | 此缺陷由哪个开发者修复。 |
7 | 浏览器 | 针对web应用需要填写浏览器。 |
8 | 操作系统 | 测试此项目时使用的操作系统。 |
9 | 严重程度 | 缺陷严重程度[S0,S1,S2,S3] 最高S0→S1→S2→S3最低。 |
10 | 优先级 | 修复缺陷的优先级 [P0,P1,P2] 最高P0→P1→P2最低。 |
缺陷信息
编号 | 信息 | 描述 |
---|---|---|
1 | 缺陷概述 | 针对缺陷简短的描述。 |
2 | 所属模块 | 缺陷属于哪个模块。 |
3 | 预置条件 | 复现缺陷需要哪些前置条件。 |
4 | 复现步骤 | 复现缺陷需要具体的操作步骤。(给出实际输入数据) |
5 | 预期结果 | 按照“预制条件”和“复现步骤”执行后正常运行结果。 |
6 | 实际结果 | 按照“预制条件”和“复现步骤”执行后实际运行结果。 |
7 | 缺陷网址 | web应用需要填写缺陷网址;客户端程序填写路径。 |
8 | 缺陷截图 | 软件中出现缺陷,如条件允许,需要截图,方便开发人员发现问题。 |
修复信息
编号 | 信息 | 描述 |
---|---|---|
1 | 处理结果 | 缺陷的修复结果:成功、延缓、无法修复。 |
2 | 处理人 | 处理人姓名。 |
3 | 处理日期 | 处理日期。 |
4 | 修改记录 | 对反侧人的留言,对缺陷修复评价。 |
5 | 反测结果 | 反测结果:通过,不通过。 |
6 | 返测人 | 返测人姓名 |
7 | 返测日期 | 返测日期 |
8 | 返测记录 | 对缺陷修复评价。 |
缺陷生命周期
图解
备注:
粉红色:测试人员操作周期;
浅绿色:部门主管或测试人员操作周期;
浅蓝色:系统开发人员操作周期;
详解:
编号 | 英文 | 中文 | 介绍 |
---|---|---|---|
1 | NEW | 新建 | 当缺陷被第一次递交的时候,它的状态即为“新建”。这也就是说缺陷未被确认其是否真正是一个缺陷。 |
2 | OPEN | 打开 | 在测试者提交一个缺陷后,部门主管确认其确实为一个缺陷的时候他会把状态置为“打开”。 |
3 | ASSIGN | 指派 | 一旦缺陷被部门主管置为“打开”,他会把缺陷交给相应的开发人员或者开发组。这时缺陷状态变更为“分配”。 |
4 | REPAIR | 修复 | 当开发人员修复缺陷后,他会吧缺陷提交给测试组进行新一轮的测试。在开发人员公布已修复缺陷的程序之前,他会把缺陷状态置为“修复”。这时表明缺陷已经修复并且已经交给了测试组。 |
5 | VERIFIED | 确认 | 一但缺陷被修复它就会被置为“修复”,测试员会执行测试。如果缺陷不再出现,这就证明缺陷被修复了同时其状态被置为“关闭” |
6 | DEFERRED | 延期 | 缺陷状态被置为“延期”意味着缺陷将会在下一个版本中被修复。将缺陷置为“延期”原因有许多种。有些由于缺陷优先级不高,有些由于时间紧,有些是因为缺陷对软件不会造成太大影响。 |
7 | REOPENED | 重开 | 如果缺陷被开发人员修复后仍然存在,测试人员会把缺陷状态置为“重开”。缺陷即将再次穿越其生命周期。 |
8 | DUPLICATE | 重复 | 如果同一个缺陷被重复提交或者两个缺陷表明的意思相同,那么这个缺陷状态会被置为“重复”。 |
9 | REJECTED | 拒绝 | 如果开发人员不认为其是一个缺陷,他会不接受。他会吧缺陷状态置为“拒绝”。 |
10 | CLOSED | 关闭 | 一但缺陷被修复,测试人员会对其进行确认。如果测试人员认为缺陷不存在了,他会把缺陷状态置为“关闭”,并记录此缺陷。这个状态意味着缺陷被修复,通过了测试并且核实确实如此。 |
风险分析
-
问题:编写报告时对缺陷描述不彻底;
- 解决方案:编写报告时,出具体操作步骤,操作数据,与缺陷截图。
-
问题:缺陷仅仅出现一次,但引发了重大问题,无法详细描述。
- 解决方案:记录缺陷,并通知其他测试人员协助寻找引发缺陷原因。
-
问题:缺陷提交后开发人员无法重现。
- 解决方案:协助开发人员复现缺陷。
-
问题:缺陷重复提交
- 解决方案:使用缺陷管理工具。组内缺陷由一人提交。发现重复,对比后在提交。
附件:缺陷报告模板
Ha ha ha ~~ 不能上传表格,给你们一个截图 !
发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/192075.html原文链接:https://javaforall.cn
【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛
【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...