软件测试中的缺陷管理过程
错误是代码错误的结果/后果。
软件测试缺陷
软件缺陷是软件程序与最终用户或原始业务需求的差异或分歧。软件缺陷是一种编码错误，它导致软件程序不满足其预期目的的不准确或意外输出。在执行测试用例的过程中，测试人员可能会偶然发现此类缺陷。
这两个名称在行业中的区别非常细；两者都是必须纠正的缺陷，一些测试团队交替使用它们。
当测试人员运行测试用例时，他们可能会得到与他们预期的不太一样的测试结果。软件缺陷被定义为测试结果的变化。在各种业务中，这些缺陷或偏差被称为问题、问题、错误或事件。
本指南将教您如何
报告错误
管理缺陷的过程
发现
分类
解决
确认
关闭
报告
缺陷的重要指标
软件测试错误报告
在软件测试中，错误报告是描述软件程序中检测到的缺陷的详尽文档。错误报告包含关于错误的所有信息，例如描述、发现问题的日期、发现问题的测试人员的身份、纠正问题的开发人员的姓名等。错误报告有助于在未来检测类似问题，从而避免这些问题。
在向开发人员报告错误时，您的问题报告应包括以下详细信息。
缺陷ID-缺陷的唯一标识号。
缺陷描述-缺陷的详细描述，包括发现它的模块的详细信息。
版本-发现缺陷的程序版本。
步骤-一组带有截图的详细步骤，开发人员可以使用这些截图来复制缺陷。
提出缺陷的日期-提出缺陷的时间
提供对文档的参考，如规范、设计、架构，甚至是错误的图像，以帮助理解错误。
检测者-报告缺陷的测试人员的姓名或ID。
状态-缺陷的当前状态；稍后会详细介绍。
进行维修的开发商的姓名/ID
关闭日期-解决故障的日期。
故障的严重性定义了它对应用程序的影响。
优先级与缺陷纠正的紧迫性有关。根据问题应解决的影响紧迫性，严重性优先级可能是高、中或低。
作为测试经理，请考虑以下事项
在测试电子商务项目时，您的团队发现了问题。当测试人员发现85个问题时，项目经理得到了通知。之后，项目经理将项目交给了开发团队。
开发人员在一周后通过纠正65个问题来回答。测试团队随后检查了该项目，除了需要纠正的65个问题外，还发现了另外10个问题。
如果以口头方式进行故障交流，如上例所示，事情很快就会变得非常困难。需要一个缺陷生命周期来成功控制和管理缺陷。
缺陷管理的流程是什么？
缺陷管理是一种识别和解决缺陷的方法。缺陷管理循环的步骤如下：1)缺陷检测，2)缺陷分类3)开发人员修复缺陷4)测试人员验证5)缺陷修复6)项目结束时的缺陷报告
本文将向您展示如何在电子商务网站项目中使用缺陷管理方法。要处理故障，请按照以下步骤操作。
发现
项目团队必须在最终客户注意到它们之前在发现阶段发现尽可能多的缺陷。当开发者承认并接受一个缺陷时，它被认为是被检测到并改变为被接受的状态。
在上述场景中，测试人员在网站中发现了85个缺陷-
发现缺陷
识别缺陷
制作缺陷报告
接受一个缺陷
在这种情况下，应该使用争议解决方法，您应该作为法官来确定网站问题是否存在缺陷。
分类
软件工程师可以使用缺陷分类来确定他们工作的优先级。也就是说，具有高优先级可以让工程师专注于首先纠正最关键的缺陷。
测试经理通常负责对缺陷进行分类——
让我们像这样进行一些锻炼。
为以下缺陷选择优先级
严重/高/中/低-
该网站的响应时间很长。
该网站的登录机制无法正常工作。
该网站的图形用户界面(GUI)未在移动设备上正确显示。
该网站无法记住用户的登录会话。
许多链接被破坏。
推荐答案
解决缺陷
在软件测试中，缺陷解决是解决问题的逐步过程。缺陷解决过程始于测试经理将缺陷分配给开发人员，然后开发人员根据优先级安排要解决的缺陷。然后修复缺陷，开发人员向测试经理提交解决报告。这种方法使纠正和跟踪问题变得简单。
分配给开发人员或其他技术人员解决，状态更改为“正在响应”。
确定时间表：这是开发人员控制的地方。根据故障优先级，他们将设计一个时间表来解决这些问题。
修复问题：当开发团队正在处理缺陷时，测试经理会跟踪过程并将其与上面的时间表进行比较。
当错误得到解决时，从开发人员那里获得解决方案的报告。
确认
测试团队确保在开发团队纠正并报告故障后已修复故障。
例如，当开发团队报告他们之前已经修复了61个问题时，您的团队将再次测试以确保这些缺陷得到解决。
关闭
在修复和验证缺陷后，缺陷的状态将更改为已关闭。如果不是这种情况，您必须向开发提交通知以再次检查故障。
缺陷报告
在软件测试中，缺陷报告是测试经理生成缺陷报告并将其传输给管理团队以输入缺陷管理过程和问题状态的过程。然后，管理团队会审查问题报告并根据需要发表评论或提供进一步的帮助。缺陷报告有助于改进沟通、跟踪和故障解释。
管理委员会有权知道有多少缺陷。为了帮助你完成这个项目，他们必须掌握缺陷管理过程。因此，您必须将当前的故障场景通知他们以获得反馈。
缺陷的重要指标
支持上述情况。报告的错误已经过开发和测试团队的审查。
如何测量和评估测试执行的质量？
每个测试经理都想知道这个问题的答案。您应该考虑两个参数-
（拒绝的缺陷数/提出的错误总数）*100缺陷拒绝率
（漏缺陷数/软件缺陷总数）*100=缺陷泄漏率
您可以将上述情况下的缺陷拒绝率(DRR)计算为20/84=0.238。(23.8%)。
例如，假设Guru99Bank网站总共有64个故障，但您的测试团队只发现了其中的44个，留下了20个未发现的问题。因此，缺陷泄漏率(DLR)可以计算为20/64=0.312（31.2%）。
最后，使用以下两个参数来评估测试执行的质量
23.8%的缺陷拒绝率
31.2%的缺陷泄漏率
DRR和DLR值越低，测试执行质量就越高。允许的比率范围是多少？这个范围可以根据项目的目标创建和批准，或者可以使用来自可比项目的测量。
本项目中可接受的比例被认为在5%到10%之间。它表明测试执行质量很差。你应该想出一个降低这些比率的计划，比如
成员的测试能力有待提高。
应该在测试执行上花费更多的精力，特别是检查测试执行结果。