大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新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 ~~ 不能上传表格，给你们一个截图 !
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/192075.html原文链接：https://javaforall.net
