软件测试中的缺陷管理流程

由： 托马斯·汉密尔顿 托马斯·汉密尔顿
Hours 更新

什么是缺陷管理流程？

缺陷管理是识别和修复错误的系统过程。缺陷管理周期包含以下阶段：1) 发现缺陷；2) 缺陷分类；3) 开发人员修复缺陷；4) 测试人员验证；5) 缺陷关闭；6) 项目结束时的缺陷报告

本主题将指导您如何将缺陷管理流程应用于项目 Guru99 Bank 网站。您可以按照以下步骤管理缺陷。

缺陷管理流程

步骤 1）发现

在发现阶段，项目团队必须发现 许多 缺陷 可能， 在最终客户发现之前。缺陷被称为被发现并改变状态 公认 当它被开发人员承认并接受时

在上述场景中，测试人员在 Guru84 网站上发现了 99 个缺陷。

探索更多

让我们看看以下场景；您的测试团队在 Guru99 Bank 网站上发现了一些问题。他们认为这是缺陷并报告给了开发团队，但存在冲突 –

那么，作为测试经理，你会怎么做呢？

A）同意测试团队的观点，认为这是一个缺陷

B）测试经理充当裁判的角色来决定问题是否是缺陷

C）同意开发团队的意见，这不是一个缺陷

正确：
不正确

在这种情况下，应该采用解决程序来解决冲突，您扮演法官的角色来决定网站问题是否是缺陷。

步骤2）分类

缺陷分类有助于软件开发人员确定任务的优先级。这意味着这种优先级可以帮助开发人员首先修复那些至关重要的缺陷。

智能分类

缺陷通常由测试经理进行分类 -

让我们做如下一个小练习

将缺陷优先级拖放到下方
1）网站性能太慢
2）网站登录功能无法正常使用
3）网站的 GUI 无法正确显示 联络号码 设备
4）网站无法记住用户登录会话
5）有些链接不起作用

以下是推荐答案

序号 描述 优先 说明

1

网站性能太慢

高

性能错误会给用户带来极大的不便。

2

网站登录功能无法正常使用

危急

登录是银行网站的主要功能之一，如果该功能无法使用，则属于严重错误

3

网站的 GUI 在移动设备上无法正确显示

中等

该缺陷影响使用智能手机浏览该网站的用户。

4

网站无法记住用户登录会话

高

这是一个严重的问题，因为用户将能够登录，但无法执行任何进一步的交易

5

有些链接无效

低

对于开发人员来说，这是一个简单的修复，用户仍然可以在没有这些链接的情况下访问该网站

相关文章

步骤3）缺陷解决

缺陷解决 软件测试是逐步修复缺陷的过程。缺陷解决过程从将缺陷分配给开发人员开始，然后开发人员按优先级安排修复缺陷，然后修复缺陷，最后开发人员向测试经理发送解决报告。此过程有助于轻松修复和跟踪缺陷。

您可以按照以下步骤修复该缺陷。

缺陷解决

  • 转让：已分配给开发人员或其他技术人员进行修复，并将状态更改为 响应.
  • 日程安排：此阶段由开发人员负责。他们将根据缺陷的优先​​级制定修复这些缺陷的计划。
  • 修复缺陷：当开发团队修复缺陷时，测试经理会根据上述计划跟踪修复缺陷的进程。
  • 报告解决方案：缺陷修复后，从开发人员处获取解决方案报告。

步骤4）验证

开发团队 固定 和 报道 缺陷，测试团队 验证 缺陷确实已得到解决。

例如，在上述场景中，当开发团队报告他们已经修复了 61 个缺陷时，您的团队将再次测试以验证这些缺陷是否真正得到修复。

步骤 5）关闭

一旦缺陷得到解决并验证，缺陷状态将更改为 关闭如果没有，你必须向开发人员发送通知，让他们再次检查缺陷。

步骤6）缺陷报告

缺陷报告 软件测试中，缺陷报告是测试经理准备并发送给管理团队以获得有关缺陷管理流程和缺陷状态的反馈的过程。然后，管理团队检查缺陷报告并发送反馈或在需要时提供进一步的支持。缺陷报告有助于更好地沟通、跟踪和详细解释缺陷。

管理委员会有权了解缺陷状况。他们必须了解缺陷管理流程才能支持您完成此项目。因此，您必须向他们报告当前的缺陷情况，以获得他们的反馈。

为什么需要缺陷管理流程？

您的团队在测试 Guru99 Banking 项目时发现了错误。

缺陷管理流程

一周后，开发人员回复道：

缺陷管理流程

下周测试人员将做出回应

缺陷管理流程

就像上面的情况一样，如果缺陷沟通是通过口头进行的，事情很快就会变得非常复杂。为了控制和有效地管理错误，您需要一个缺陷生命周期。

重要的缺陷指标

回到上面的场景。开发人员和测试团队已经审查了所报告的缺陷。以下是讨论的结果

重要的缺陷指标

如何测量和评估测试执行的质量？

这是一个每个人都应该思考的问题 测试经理 想知道。您可以考虑以下两个参数

重要的缺陷指标

在上面的场景中，你可以计算 缺陷拒收率 （DRR）是 20/84 = 0.238（23.8%）。

另一个例子，假设Guru99银行网站总共有 64 缺陷，但你的测试团队只检测 44 缺陷，即他们错过了 20 缺陷。因此，可以计算出缺陷泄漏率 (DLR) 为 20/64 = 0.312 （31.2％）。

结论，测试执行的质量通过以下两个参数来评估

重要的缺陷指标

DRR 和 DLR 的值越小，测试执行的质量越好。比率范围是多少？ 可接受? 此范围可根据项目目标来定义和接受，或可参考类似项目的指标。

本项目中，可接受比例的推荐值为 5～10％。 这意味着测试执行质量低下。你应该找到降低这些比率的对策，例如

  • 提高 成员的测试技能。
  • 花更多时间 用于测试执行，特别是检查测试执行结果。

常见问题

错误是编码错误的结果。

A 软件测试中的缺陷 是软件应用程序与最终用户要求或原始业务要求之间的差异或偏差。软件缺陷是编码错误，导致软件程序产生不正确或意外的结果，不符合实际要求。测试人员在执行测试用例时可能会遇到此类缺陷。

这两个术语的区别非常细微，在行业中，两者都是需要修复的缺陷，因此被一些人交替使用。 测试与验证 队。

当测试人员执行测试用例时，他们可能会遇到与预期结果相矛盾的测试结果。测试结果的这种变化称为软件缺陷。这些缺陷或变化在不同的组织中有不同的名称，如问题、故障、错误或事件。

软件测试中的错误报告是一份关于在软件应用程序中发现的错误的详细信息文档。错误报告包含有关错误的每个详细信息，如描述、发现错误的日期、发现错误的测试人员姓名、修复错误的开发人员姓名等。错误报告有助于识别将来出现的类似错误，从而避免此类错误。

  • 缺陷ID – 缺陷的唯一识别号。
  • 缺陷 Description – 缺陷的详细描述，包括有关发现缺陷的模块的信息。
  • 版本 - 发现缺陷的应用程序版本。
  • 脚步 - 详细步骤以及屏幕截图，开发人员可以使用它们重现缺陷。
  • 募集日期 – 提出缺陷的日期
  • 参考- 在哪里提供参考文档，如需求、设计、架构，甚至可能是错误的屏幕截图，以帮助理解缺陷
  • 检测者 – 提出缺陷的测试人员的姓名/ID
  • 状态 - 缺陷状态，稍后会详细介绍
  • 已修复 – 修复此问题的开发人员的姓名/ID
  • 关闭日期 – 缺陷关闭日期
  • 严谨求真 描述缺陷对应用程序的影响
  • 优先 这与缺陷修复的紧急程度有关。严重性优先级可以分为高/中/低，具体取决于缺陷修复的影响紧急程度

点击 点击这里 如果视频无法访问

资源：

下载缺陷报告模板示例