软件测试管理快速入门11-BUG管理

什么是Bug？

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

什么是缺陷(Defect)？缺陷是与原始业务要求的变化或偏差。

这两个术语的差异很小，在行业中都是需要修复的故障，因此一些测试团队可以互换使用。

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

错误报告

在向开发人员报告错误时，您的错误报告应包含以下信息

• Defect_ID - 缺陷的唯一标识号。
• 缺陷描述 - 缺陷的详细描述，包括有关发现缺陷的模块的信息。
• 版本 - 发现缺陷的应用程序版本。
• 步骤 - 详细步骤以及开发人员可以重现缺陷的屏幕截图。
• 发现日期 - 提出缺陷的日期
• 参考 - 你在哪里提供像这样的文件的参考。 要求，设计，架构或甚至错误的屏幕截图，以帮助理解缺陷
• 发现者 - 引发缺陷的测试人员的姓名/ ID
• 状态 - 缺陷的状态，稍后将详细介绍
• Fixed by - 修复它的开发人员的名称/ ID
• Closed日期 - 缺陷关闭的日期
• 严重性 ，描述缺陷对应用程序的影响
• 优先级与缺陷修复紧迫性有关。 根据应分别修复缺陷的影响紧急程度，严重性优先级可以是高/中/低
• 
  

缺陷管理流程

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

• 发现

在发现阶段，项目团队必须在最终客户发现之前发现尽可能多的缺陷。 据说开发人员承认并接受了一个缺陷并将其更改为已接受的状态。

我们来看看下面的场景; 您的测试团队在Guru99银行网站上发现了一些问题。 他们认为它们是缺陷并向开发团队报告，但存在冲突 -

分类

缺陷分类有助于软件开发人员确定其任务的优先级。 这意味着这种优先级有助于开发人员首先解决这些非常重要的缺陷。

序号 描述 优先 说明 1 网站性能太慢 高 性能错误会给用户带来极大的不便。 2 网站的登录功能无法正常运行 危急 如果此功能不起作用，登录是银行网站的主要功能之一，这是严重的错误 3 网站的GUI无法在移动设备上正确显示 中 该缺陷影响使用Smartphone查看网站的用户。 4 该网站无法记住用户登录会话 高 这是一个严重的问题，因为用户将能够登录但无法执行任何进一步的交易 5 有些链接不起作用 低 对于开发人员来说，这是一个简单的解决方案，用户仍然可以访问没有这些链接的网站 解决

一旦接受并分类缺陷，您可以按照以下步骤修复缺陷。

• 分配 ：分配给开发人员或其他技术人员进行修复，并将状态更改为“ 响应” 。
• 时间表修复 ：开发者方在此阶段负责。 他们将根据缺陷优先级创建修复这些缺陷的计划。
• 修复缺陷 ：当开发团队正在修复缺陷时，测试管理器会跟踪修复缺陷的过程，与上述计划相比较。
• 报告解决方案 ：在修复缺陷时获取开发人员的决议报告。

验证

在开发团队修复并报告缺陷后，测试团队会验证缺陷是否已实际解决。

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

关闭

一旦缺陷得到解决和验证，缺陷就会变为已关闭状态。 如果没有，您已向开发人员发送通知以再次检查缺陷。

报告

管理委员会有权知道缺陷状态。 他们必须了解缺陷管理流程，以便在此项目中为您提供支持。 因此，您必须向他们报告当前的缺陷情况，以便从他们那里获得反馈。

重要的缺陷指标

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

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

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

在上述场景中，您可以计算出缺陷抑制比 （DRR）为20/84 = 0.238（23.8％）。

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

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

DRR和DLR的值越小，测试执行的质量越好。 什么是可接受的比例范围？ 可以在项目目标中定义和接受此范围，也可以参考类似项目的指标。

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

• 提高会员的测试技能。
• 花更多时间来测试执行，尤其是审查测试执行结果。