软件测试中的缺陷管理流程
什么是缺陷管理流程?
缺陷管理是一个系统化的流程,用于识别和修复错误。缺陷管理周期包含以下阶段:1) 缺陷发现,2) 缺陷分类,3) 开发人员修复缺陷,4) 测试人员验证,5) 缺陷关闭,6) 项目结束时的缺陷报告。
本主题将指导您如何将缺陷管理流程应用于 Guru99 银行网站项目。您可以按照以下步骤管理缺陷。
步骤 1) 发现
在发现阶段,项目团队必须在最终客户发现缺陷之前,尽可能多地发现缺陷。当缺陷被开发人员确认并接受时,该缺陷被视为已发现并更改状态为“**已接受**”。
在上述场景中,测试人员在 Guru99 网站中发现了 84 个缺陷。
让我们看以下场景:您的测试团队在 Guru99 银行网站中发现了一些问题。他们将其视为缺陷并报告给开发团队,但存在冲突 –
在这种情况下,作为测试经理,您会怎么做?
B) 测试经理充当判断者,决定问题是否为缺陷
C) 同意开发团队的看法,认为这不是缺陷
在这种情况下,应应用解决流程来解决冲突,您将充当判断者,决定网站问题是否为缺陷。
步骤 2) 分类
缺陷分类有助于软件开发人员优先处理他们的任务。这意味着这种优先级有助于开发人员首先修复那些至关重要的缺陷。
缺陷通常由测试经理分类 –
我们来做个小练习,如下所示:
拖放下面的缺陷优先级1) 网站性能太慢 |
|
2) 网站登录功能无法正常工作 |
|
3) 网站的图形用户界面在移动设备上显示不正确 |
|
4) 网站无法记住用户登录会话 |
|
5) 一些链接不起作用 |
|
以下是推荐的答案
编号 | 描述 | 优先级 | 解释 |
---|---|---|---|
1 |
网站性能太慢 |
高 |
性能错误会给用户带来巨大的不便。 |
2 |
网站登录功能无法正常工作 |
严重 |
登录是银行网站的主要功能之一,如果此功能不起作用,则为严重错误 |
3 |
网站的图形用户界面在移动设备上显示不正确 |
中等 |
该缺陷影响使用智能手机查看网站的用户。 |
4 |
网站无法记住用户登录会话 |
高 |
这是一个严重问题,因为用户将能够登录,但无法执行任何进一步的交易 |
5 |
一些链接不起作用 |
低 |
这对于开发人员来说是一个简单的修复,并且用户仍然可以访问该网站而无需这些链接 |
步骤 3) 缺陷解决
软件测试中的**缺陷解决**是修复缺陷的循序渐进的过程。缺陷解决过程始于将缺陷分配给开发人员,然后开发人员根据优先级安排缺陷修复,然后缺陷被修复,最后开发人员向测试经理发送解决方案报告。此过程有助于轻松修复和跟踪缺陷。
您可以按照以下步骤修复缺陷。
- **分配**:分配给开发人员或其他技术人员进行修复,并将状态更改为“**响应中**”。
- **安排修复**:开发人员负责此阶段。他们将根据缺陷优先级制定修复这些缺陷的计划。
- **修复缺陷**:当开发团队修复缺陷时,测试经理根据上述计划跟踪缺陷修复过程。
- **报告解决方案**:当缺陷修复后,从开发人员处获取解决方案报告。
步骤 4) 验证
开发团队**修复**并**报告**缺陷后,测试团队**验证**缺陷是否确实已解决。
例如,在上述场景中,当开发团队报告他们已经修复了 61 个缺陷时,您的团队将再次测试以验证这些缺陷是否确实已修复。
步骤 5) 关闭
一旦缺陷被解决并验证,缺陷的状态将更改为“**已关闭**”。如果未解决,您必须向开发人员发送通知以再次检查缺陷。
步骤 6) 缺陷报告
软件测试中的**缺陷报告**是测试经理准备并将缺陷报告发送给管理团队,以获取有关缺陷管理流程和缺陷状态的反馈的过程。然后管理团队检查缺陷报告,并在需要时发送反馈或提供进一步支持。缺陷报告有助于更好地沟通、跟踪和详细解释缺陷。
管理委员会**有权**了解缺陷状态。他们必须了解缺陷管理流程以在此项目中支持您。因此,您必须向他们报告当前的缺陷情况以获取他们的反馈。
为什么需要缺陷管理流程?
您的团队在测试 Guru99 银行项目时发现了错误。
一周后,开发人员回应 –
下周,测试人员回应
如上述情况,如果缺陷沟通是口头进行的,事情很快就会变得非常复杂。要控制和有效管理错误,您需要一个缺陷生命周期。
重要的缺陷指标
回到上面的场景。开发人员和测试团队已经审查了报告的缺陷。这是讨论结果
如何衡量和评估测试执行的质量?
这是每个测试经理都想知道的问题。您可以考虑以下 2 个参数:
在上述场景中,您可以计算**缺陷拒绝率**(DRR)为 **20/84 = 0.238 (23.8 %)**。
另一个例子,假设 Guru99 银行网站总共有 **64** 个缺陷,但您的测试团队只检测到 **44** 个缺陷,即他们遗漏了 **20** 个缺陷。因此,您可以计算缺陷泄漏率(DLR)为 20/64 = **0.312** (31.2 %)。
结论,测试执行的质量通过以下两个参数进行评估
DRR 和 DLR 的值越小,测试执行的质量越好。**可接受**的比率范围是多少?此范围可以根据项目目标定义和接受,或者您可以参考类似项目的指标。
在此项目中,可接受比率的建议值为 **5 ~ 10%**。这意味着测试执行的质量较低。您应该采取对策来降低这些比率,例如:
- **提高**成员的测试技能。
- **花费更多时间**进行测试执行,特别是审查测试执行结果。
常见问题
如果视频无法访问,请点击此处