什么是Bug？
Bug是编码错误的后果/结果。什么是缺陷(Defect)？缺陷是与原始业务要求的变化或偏差。
这两个术语的差异很小，在行业中都是需要修复的故障，因此一些测试团队可以互换使用。
当测试人员执行测试用例时，他可能会遇到与预期结果相矛盾的测试结果。测试结果的这种变化称为软件缺陷。这些缺陷或变体在不同的组织中由不同的名称引用，例如问题，问题，错误或事件。
错误报告
在向开发人员报告错误时，您的错误报告应包含以下信息
Defect_ID-缺陷的唯一标识号。缺陷描述-缺陷的详细描述，包括有关发现缺陷的模块的信息。版本-发现缺陷的应用程序版本。步骤-详细步骤以及开发人员可以重现缺陷的屏幕截图。发现日期-提出缺陷的日期参考-你在哪里提供像这样的文件的参考。要求，设计，架构或甚至错误的屏幕截图，以帮助理解缺陷发现者-引发缺陷的测试人员的姓名/ID状态-缺陷的状态，稍后将详细介绍Fixedby-修复它的开发人员的名称/IDClosed日期-缺陷关闭的日期严重性，描述缺陷对应用程序的影响优先级与缺陷修复紧迫性有关。根据应分别修复缺陷的影响紧急程度，严重性优先级可以是高/中/低缺陷管理流程
本主题将指导您如何将缺陷管理过程应用于项目Guru99Bank网站。您可以按照以下步骤管理缺陷。
发现在发现阶段，项目团队必须在最终客户发现之前发现尽可能多的缺陷。据说开发人员承认并接受了一个缺陷并将其更改为已接受的状态。
我们来看看下面的场景;您的测试团队在Guru99银行网站上发现了一些问题。他们认为它们是缺陷并向开发团队报告，但存在冲突-
分类
缺陷分类有助于软件开发人员确定其任务的优先级。这意味着这种优先级有助于开发人员首先解决这些非常重要的缺陷。
解决
一旦接受并分类缺陷，您可以按照以下步骤修复缺陷。
分配：分配给开发人员或其他技术人员进行修复，并将状态更改为“响应”。时间表修复：开发者方在此阶段负责。他们将根据缺陷优先级创建修复这些缺陷的计划。修复缺陷：当开发团队正在修复缺陷时，测试管理器会跟踪修复缺陷的过程，与上述计划相比较。报告解决方案：在修复缺陷时获取开发人员的决议报告。验证
在开发团队修复并报告缺陷后，测试团队会验证缺陷是否已实际解决。
例如，在上面的场景中，当开发团队报告他们已经修复了61个缺陷时，您的团队将再次测试以验证这些缺陷是否已实际修复。
关闭
一旦缺陷得到解决和验证，缺陷就会变为已关闭状态。如果没有，您已向开发人员发送通知以再次检查缺陷。
报告
管理委员会有权知道缺陷状态。他们必须了解缺陷管理流程，以便在此项目中为您提供支持。因此，您必须向他们报告当前的缺陷情况，以便从他们那里获得反馈。
重要的缺陷指标
回到上面的场景。开发人员和测试团队对已报告的缺陷进行审核。这是讨论的结果
如何衡量和评估测试执行的质量？
这是每个测试经理都想知道的问题。您可以考虑以下两个参数
在上述场景中，您可以计算出缺陷抑制比（DRR）为20/84=0.（23.8％）。
另一个例子，假设Guru99银行网站共有64个缺陷，但您的测试团队只检测到44个缺陷，即他们错过了20个缺陷。因此，可以计算出缺陷泄漏率（DLR）为20/64=0.（31.2％）。
结论，通过以下两个参数评估测试执行的质量
DRR和DLR的值越小，测试执行的质量越好。什么是可接受的比例范围？可以在项目目标中定义和接受此范围，也可以参考类似项目的指标。
在该项目中，可接受比率的推荐值为5~10％。这意味着测试执行的质量很低。您应该找到降低这些比率的对策，例如
提高会员的测试技能。花更多时间来测试执行，尤其是审查测试执行结果。
转载请注明：http://www.0431gb208.com/sjszlff/3600.html
