文章目录

一、软件项目的测试流程（重点）
二、缺陷报告（Defect-bug）
- 1.简介缺陷报告
- 2.如何编写缺陷报告[^缺陷报告示例]
- - 缺陷报告的主要组成：
  - - 1.缺陷编号（Defect ID）
    - 2.缺陷标题（summary）
    - 3.缺陷发现者/创建者（detected by）
    - 4.提交缺陷的日期（detected on date
    - 5.缺陷指派给谁处理（assigned to）
    - 6. 缺陷所属的功能模块（subject）
    - 7. 发现缺陷的版本（detected in release/version）
    - 8. 状态（status）
    - - 1. 常用状态
      - 2. 缺陷报告的跟踪处理流程（步骤、生命周期）？【重点】
    - 9.缺陷的严重程度（severity）
    - 10.缺陷的优先级（priority）
    - 11.缺陷描述（description）
    - - 随机缺陷

一、软件项目的测试流程（重点）

需求分析（阅读、分析、整理业务）
制定测试计划
由测试组长或测试经理完成测试计划的制定，测试人员阅读并按要求执行。
拓展：
Q1：是否能够编写测试计划？
Q2：测试计划的主要组成部分（在测试项目时，会阅读测试计划，要注意将测试计划组成部分整理出来）
设计测试
分析、设计《测试用例》的过程，需要掌握测试方法（7种）
执行测试，记录测试结果
记录缺陷（通过缺陷报告记录），并对缺陷进行跟踪和管理。
测试总结（测试报告/测试总结报告）

二、缺陷报告（Defect-bug）

1.简介缺陷报告

测试人员发现缺陷后将缺陷记录在《缺陷报告》中。
测试方通过缺陷报告将缺陷告知给开发方（提bug）。
通过缺陷报告对缺陷进行跟踪和管理。
缺陷报告是开发人员和测试人员之间重要的沟通方式。

2.如何编写缺陷报告¹

^{在企业中通过工具对缺陷进行管理，例如：禅道（中文、免费）、QC（HP,英文，付费）、bugzilla、bugfree、自制的管理工具等。

注意：缺陷报告的管理工具不同，模板可能会有差异，但是核心部分大同小异。}

^{缺陷报告的主要组成：}

^{1.缺陷编号（Defect ID）}

^{编号可以唯一标识这条缺陷。

按照发现缺陷的顺序记录编号（通常是由工具自动生成的编号）

注意：缺陷编号是项目中的缺陷统一管理。而不是只记录你自己的。}

^{2.缺陷标题（summary）}

^{简明扼要的将缺陷概括出来。

注意：标题没有标准答案，能够将缺陷概括准确即可。}

^{3.缺陷发现者/创建者（detected by）}

^{由测试人员发现缺陷，创建缺陷报告

填测试人员的账号/真实姓名}

^{4.提交缺陷的日期（detected on date}

^{注意：缺陷报告应及时提交。

缺陷报告既不应该人为延误，也不应该立即提交，而是应该“确认”，确定不是由于测试人员人为失误造成的假缺陷，再提交。}

^{5.缺陷指派给谁处理（assigned to）}

^{首先：测试人员将bug指派给开发方负责人

接下来：再由开发方负责人将缺陷指派给具体负责的开发人员。}

^{6. 缺陷所属的功能模块（subject）}

^{说明：可以实现对bug的基本定位。

开发方负责人可以通过功能模块，快速确定负责解决该bug 的开发人员。}

^{7. 发现缺陷的版本（detected in release/version）}

^{说明：这里所指的版本，不仅指最终发布的版本，也包括在研发过程中出现过的临时版本。

拓展：

回归测试：

在当前版本中，对上一个版本的所有功能要重新再测试一遍，叫回归测试。

为什么做回归测试：

1. 新增加的功能可能会对原有功能造成影响。

2. 解决的bug，有可能会对原有功能造成影响。

在企业中，对于回归测试，可以采用自动化测试的方式进行，这样可以提高回归测试效率。}

^{8. 状态（status）}

^{缺陷处于怎样的处理情况}

^{1. 常用状态}

^{新的–new

激活的–open

已解决的–fixed

关闭的 --closed

被拒绝的–rejected

重新激活的–reopen}

^{2. 缺陷报告的跟踪处理流程（步骤、生命周期）？【重点】}

^{测试人员提交新的缺陷报告给开发方负责人。}
^{开发方负责人验证（确认）缺陷：}
^{如果验证为缺陷，开发负责人激活该缺陷，并指派给相应的开发人员。}
^{如果验证未通过，开发负责人将拒绝该缺陷。步骤3：被指派的开发人员解决该缺陷，解决完成后将缺陷设置为“已解决”状态。（理解为：待返测的缺陷）步骤4：测试人员返测已解决的缺陷，}
^{如果返测通过，测试人员将缺陷关闭。}
^{如果返测没有通过，测试人员将缺陷重新激活，指派回该开发人员继续解决，直到返测通过，缺陷关闭为止。}

^{Q1：如果提交的bug被拒绝了，测试人员应如何处理？(思路）}

^{测试人员首先自己确认，是否由于自己失误造成假缺陷。}
^{如果确认自己没有失误，接下来：分析被拒原因，与相关人员进行沟通，讨论，最终确认是否是假缺陷。

如果是假缺陷，测试方负责关闭该假缺陷。如果是缺陷，谁拒绝的，谁负责将缺陷激活，纳入回缺陷处理流程。

最后：如果在沟通，讨论过程中遇到问题，可以向直属上级领导汇报，并请求帮助。}

^{Q2：用状态的变化来表示缺陷报告的跟踪处理过程：}

^{常规处理过程 new→open→fixed→closed}
^{带有返测失败的处理过程（失败1次） new→open→fixed→reopen→fixed→closed}

^{9.缺陷的严重程度（severity）}

^{表明该缺陷有多糟糕，对程序的影响有多坏。

严重程度常规级别：}

^{1--致命的--urgent2--严重的--high3--一般的（中等的）--medium （比例相对较高）4--建议性的小问题--low}

^{说明：个别的缺陷管理工具中，在致命和严重之间增加了“非常严重–very high”这个级别。（不常用）

问题：严重级别的定义过于笼统，在实际工作中容易产生争论，所以企业通常会制定更为详细的严重级别说明。

注意：}

^{不同企业，不同项目组，严重级别的详细说明都可能不同，要注意参考。}
^{测试人员应该严格判定严重级别，不应受个人情绪影响，或为了引起开发方重视而擅自更改级别。}

^{10.缺陷的优先级（priority）}

^{希望或建议开发方在什么时间或什么版本，解决该bug。

优先级的常规级别：}

^{1--立即解决--urgent
2--下一个版本解决--high （常用）
3--在软件产品发布之前解决--medium
4--尽量在软件产品发布之前解决--low有可能有发现的bug没有解决，软件产品就发布了。}

^说明：

^{个别的管理工具中，在1-urgent 和2-high 级别之间增加一个 very high-在当前版本解决的级别。}
^{优先级的定义不同企业，不同项目组可能有不同，要具体参考。}

^{11.缺陷描述（description）}

^{就是将发现缺陷的过程（步骤、数据）记录下来，使开发人员能够重现该缺陷。

目的：让开发人员看明白，能重现缺陷

要求：逻辑清晰，用语专业准确，易懂，不要出现评价性的语言。（如实记录）}

^随机缺陷

^{也叫不可重现缺陷，按照相同的操作过程，时有时无的缺陷。

注意事项：}

^{随机缺陷应该要提交，并且提交时应说明该缺陷为随机缺陷。}
^{对于随机缺陷，测试人员应尽量详细描述，最好能够提供证迹（截图、视频）。

提示：测试人员应养成随手截证迹的习惯。}
^{测试人员应尽量配合开发方关于随机缺陷的调查，例如：短时间保留测试环境，提供随机缺陷出现的频率等。}
^{测试方可以提供白盒测试手段，配合随机bug的调查。}

^{Q1：影响优先级的因素有哪些？

Q2：严重程度和优先级是严格的正比关系吗？

Q3：严重程度和优先级确定之后能改吗？

Q4：在发布的软件产品中，是否可能有发现但没有解决的bug？（适当介绍）}

缺陷报告
编号	1
标题	xxx
发现者	yn
日期	2020-4-27 20:36:51
指派	Jh
功能模块	登录模块
版本	1.0
状态	新的（new）
严重级别	2-严重
优先级	2-下一个版本

^{缺陷报告示例 ↩︎}

软件测试总结--02缺陷报告相关推荐

软件测试--缺陷和缺陷报告
缺陷的基本概述定义:软件未实现产品说明书要求的功能软件出现了产品说明书指明不应该出现的功能软件实现了产品说明书未提及的功能软件未实现产品说明书虽未说明单应该实现的目标软件难以理解.不易使用. ...
软件测试梳理第九节缺陷和缺陷报告
缺陷的基本概述缺陷的定义软件未实现产品说明书要求的功能软件出现了产品说明书指明不应该出现的功能软件实现了产品说明书未提到的功能软件未实现产品说明书虽未明确提及但应该实现的目标软件难以理解. ...
❤️熬夜7天肝出5万字【禅道/缺陷报告/测试报告/接口测试及用例/Fildder】超详细总结❤️
目录一.禅道一.测试工具背景二.测试管理工具三.测试工具介绍四.禅道介绍五.禅道操作 7. 创建发布 8. 测试团队二.缺陷报告三.测试报告一.概要二.测试过程三.缺陷分析四. ...
禅道/缺陷报告/测试报告/接口测试及用例/Fildder
一.测试工具背景当测试环境搭建完成后,测试人员将在自己搭建的环境上执行测试用例,开展测试工作.测试人员在执行测试用例的过程中,如发现实际结果与预期结果不一致, 则意味着出现Bug (缺陷.错误.问题 ...
软件测试通用技术04 缺陷基本概述缺陷的生命周期缺陷的识别缺陷报告缺陷报告模板测试需求、测试用例、缺陷报告的关系
1 缺陷基本概述 1.1 缺陷的定义(重要!) 软件未实现产品说明书要求的功能: 软件出现了产品说明书指明不应该出现的功能: 软件实现了产品说明书未提到的功能: 软件未实现产品说明书虽未明确提及但应该 ...
信息检索报告_iFixR：缺陷报告驱动程序修复
引用 Koyuncu A , Liu K , Tegawendé F. Bissyandé, et al. iFixR: Bug Report driven Program Repair[C]// t ...
第四次博客作业：bookstore缺陷报告
Bookstore系统集成测试缺陷报告 -------------------------------------------------------------------------------- ...
软件测试工程师-缺陷报告
缺陷报告 1.缺陷报告注意事项 (1)尽量保证缺陷可以重现 (2)简洁.准确.完整 (3)一个缺陷报告只写一个缺陷 2.缺陷书写规范 (1)标题简洁.提供缺陷的本质信息即可 (2)复现的步骤要详细,用 ...
软件测试--缺陷报告
缺陷报告是描述软件缺陷现象和重现步骤地集合.软件缺陷报告Software Bug Report(SBR)或软件问题报告Software Problem Report(SPR) 作用:缺陷报告是软件测试 ...
测试开发之缺陷报告下篇
三. 缺陷的分类 1 缺陷的分类标准 2 根据缺陷类型对缺陷分类  功能缺陷  界面缺陷  文档缺陷  代码缺陷  算法错误  性能缺陷 3 根据缺陷的等级对缺陷分类 A 类-致命缺陷,包 ...

软件测试总结--02缺陷报告

文章目录

一、软件项目的测试流程（重点）

二、缺陷报告（Defect-bug）

1.简介缺陷报告

2.如何编写缺陷报告¹

^{缺陷报告的主要组成：}

^{1.缺陷编号（Defect ID）}

^{2.缺陷标题（summary）}

^{3.缺陷发现者/创建者（detected by）}

^{4.提交缺陷的日期（detected on date}

^{5.缺陷指派给谁处理（assigned to）}

^{6. 缺陷所属的功能模块（subject）}

^{7. 发现缺陷的版本（detected in release/version）}

^{8. 状态（status）}

^{1. 常用状态}

^{2. 缺陷报告的跟踪处理流程（步骤、生命周期）？【重点】}

^{9.缺陷的严重程度（severity）}

^{10.缺陷的优先级（priority）}

^{11.缺陷描述（description）}

^随机缺陷

软件测试总结--02缺陷报告相关推荐

最新文章

热门文章

软件测试总结--02缺陷报告

文章目录

一、软件项目的测试流程（重点）

二、缺陷报告（Defect-bug）

1.简介缺陷报告

2.如何编写缺陷报告1

缺陷报告的主要组成：

1.缺陷编号（Defect ID）

2.缺陷标题（summary）

3.缺陷发现者/创建者（detected by）

4.提交缺陷的日期（detected on date

5.缺陷指派给谁处理（assigned to）

6. 缺陷所属的功能模块（subject）

7. 发现缺陷的版本（detected in release/version）

8. 状态 （status）

1. 常用状态

2. 缺陷报告的跟踪处理流程（步骤、生命周期）？【重点】

9.缺陷的严重程度（severity）

10.缺陷的优先级（priority）

11.缺陷描述（description）

随机缺陷

软件测试总结--02缺陷报告相关推荐

最新文章

热门文章

2.如何编写缺陷报告¹

^{缺陷报告的主要组成：}

^{1.缺陷编号（Defect ID）}

^{2.缺陷标题（summary）}

^{3.缺陷发现者/创建者（detected by）}

^{4.提交缺陷的日期（detected on date}

^{5.缺陷指派给谁处理（assigned to）}

^{6. 缺陷所属的功能模块（subject）}

^{7. 发现缺陷的版本（detected in release/version）}

^{8. 状态（status）}

^{1. 常用状态}

^{2. 缺陷报告的跟踪处理流程（步骤、生命周期）？【重点】}

^{9.缺陷的严重程度（severity）}

^{10.缺陷的优先级（priority）}

^{11.缺陷描述（description）}

^随机缺陷