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

什么是缺陷管理流程?

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

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

Defect Management Process

步骤 1) 发现

在发现阶段,项目团队必须在最终客户发现缺陷之前,尽可能多地发现缺陷。当缺陷被开发人员确认并接受时,该缺陷被视为已发现并更改状态为“**已接受**”。

在上述场景中,测试人员在 Guru99 网站中发现了 84 个缺陷。

Discovery

让我们看以下场景:您的测试团队在 Guru99 银行网站中发现了一些问题。他们将其视为缺陷并报告给开发团队,但存在冲突 –

在这种情况下,作为测试经理,您会怎么做?

A) 同意测试团队的看法,认为这是一个缺陷

B) 测试经理充当判断者,决定问题是否为缺陷

C) 同意开发团队的看法,认为这不是缺陷

正确
不正确

在这种情况下,应应用解决流程来解决冲突,您将充当判断者,决定网站问题是否为缺陷。

步骤 2) 分类

缺陷分类有助于软件开发人员优先处理他们的任务。这意味着这种优先级有助于开发人员首先修复那些至关重要的缺陷。

Categorization

缺陷通常由测试经理分类 –

我们来做个小练习,如下所示:

拖放下面的缺陷优先级
1) 网站性能太慢
2) 网站登录功能无法正常工作
3) 网站的图形用户界面在移动设备上显示不正确
4) 网站无法记住用户登录会话
5) 一些链接不起作用

以下是推荐的答案

编号 描述 优先级 解释

1

网站性能太慢

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

2

网站登录功能无法正常工作

严重

登录是银行网站的主要功能之一,如果此功能不起作用,则为严重错误

3

网站的图形用户界面在移动设备上显示不正确

中等

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

4

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

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

5

一些链接不起作用

这对于开发人员来说是一个简单的修复,并且用户仍然可以访问该网站而无需这些链接

步骤 3) 缺陷解决

软件测试中的**缺陷解决**是修复缺陷的循序渐进的过程。缺陷解决过程始于将缺陷分配给开发人员,然后开发人员根据优先级安排缺陷修复,然后缺陷被修复,最后开发人员向测试经理发送解决方案报告。此过程有助于轻松修复和跟踪缺陷。

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

Defect Resolution

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

步骤 4) 验证

开发团队**修复**并**报告**缺陷后,测试团队**验证**缺陷是否确实已解决。

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

步骤 5) 关闭

一旦缺陷被解决并验证,缺陷的状态将更改为“**已关闭**”。如果未解决,您必须向开发人员发送通知以再次检查缺陷。

步骤 6) 缺陷报告

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

管理委员会**有权**了解缺陷状态。他们必须了解缺陷管理流程以在此项目中支持您。因此,您必须向他们报告当前的缺陷情况以获取他们的反馈。

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

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

Defect Management Process

一周后,开发人员回应 –

Defect Management Process

下周,测试人员回应

Defect Management Process

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

重要的缺陷指标

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

Important Defect Metrics

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

这是每个测试经理都想知道的问题。您可以考虑以下 2 个参数:

Important Defect Metrics

在上述场景中,您可以计算**缺陷拒绝率**(DRR)为 **20/84 = 0.238 (23.8 %)**。

另一个例子,假设 Guru99 银行网站总共有 **64** 个缺陷,但您的测试团队只检测到 **44** 个缺陷,即他们遗漏了 **20** 个缺陷。因此,您可以计算缺陷泄漏率(DLR)为 20/64 = **0.312** (31.2 %)。

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

Important Defect Metrics

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

在此项目中,可接受比率的建议值为 **5 ~ 10%**。这意味着测试执行的质量较低。您应该采取对策来降低这些比率,例如:

  • **提高**成员的测试技能。
  • **花费更多时间**进行测试执行,特别是审查测试执行结果。

常见问题

Bug 是编码错误的后果/结果。

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

这两个术语之间存在非常细微的差异,在行业中,两者都是需要修复的故障,因此一些测试团队会交替使用。

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

软件测试中的 Bug 报告是关于在软件应用程序中发现的 Bug 的详细文档。Bug 报告包含 Bug 的每个细节,如描述、发现 Bug 的日期、发现 Bug 的测试人员姓名、修复 Bug 的开发人员姓名等。Bug 报告有助于在将来识别类似的 Bug,从而可以避免它们。

  • **Defect_ID –** 缺陷的唯一标识号。
  • **缺陷描述** – 缺陷的详细描述,包括发现缺陷的模块信息。
  • **版本 –** 发现缺陷的应用程序版本。
  • **步骤 –** 详细步骤以及开发人员可以重现缺陷的屏幕截图。
  • **提出日期 –** 缺陷提出的日期
  • **参考 –** 您可以在其中提供对文档的引用,如需求、设计、架构,甚至错误截图,以帮助理解缺陷
  • **检测者 –** 提出缺陷的测试人员姓名/ID
  • **状态 –** 缺陷的状态,稍后详细介绍
  • **修复者 –** 修复缺陷的开发人员姓名/ID
  • **关闭日期 –** 缺陷关闭的日期
  • **严重性** 描述缺陷对应用程序的影响
  • **优先级** 与缺陷修复的紧急程度有关。严重性优先级可根据缺陷应修复的影响紧急程度分为高/中/低

如果视频无法访问,请点击此处

资源

下载缺陷报告模板示例