Bug是什么？
Bug是编码错误的后果/结果。
软件测试中的缺陷
软件测试中的缺陷是软件应用程序偏离最终用户要求或原始业务要求的偏差。测试人员在执行测试用例时可能会遇到这样的缺陷。
这两个术语有非常细微的区别，在行业中，两者都是需要修复的故障。 当测试人员执行测试用例时，可能会遇到与预期相矛盾的测试结果。
在本教程中，将了解-
- 缺陷报告
- 缺陷管理流程
- 发现
- 分类
- 验证
- 闭合
- 报道
- 重要缺陷度量标准
软件测试中的缺陷报告
软件测试中的缺陷报告是关于软件应用程序中发现的缺陷的详细文档。缺陷报告包含有关Bug的每个细节，有助于在将来识别类似的Bug。
向开发人员报告缺陷时，缺陷报告应包含以下信息
- Defect_ID-缺陷的唯一标识号。
- 缺陷描述-缺陷的详细描述，包括关于发现缺陷的模块的信息。
- Version-发现缺陷的应用程序的版本。
- 步骤-详细的步骤以及开发人员可以用来再现缺陷的屏幕截图。
- 日期-缺陷被提的日期
- 参考(Reference)-在中提供对文档的参考，如。需求、设计、体系结构，甚至错误的屏幕截图，以帮助理解缺陷
- 检测依据-提出缺陷的测试员的名称/ID
- 状态-缺陷的状态，稍后将详细介绍
- 修复依据-修复该问题的开发人员的名称/ID
- 关闭日期-缺陷关闭的日期
- 严重程度，描述缺陷对应用程序的影响
- 与缺陷修复紧迫性相关的优先级。根据缺陷应修复的影响紧急程度，严重性优先级可以分别为高/中/低
作为一名测试经理，考虑以下事项
团队在测试项目时发现了错误
一周后，开发团队回应说-
下周测试员会做出回应
与上面的情况一样，如果缺陷通信是口头进行的，很快事情就会变得非常复杂。为了控制和有效地管理错误，需要一个缺陷生命周期。
什么是缺陷管理流程？
缺陷管理是识别和修复缺陷的系统过程。缺陷管理周期包含以下阶段：1) 发现缺陷，2) 缺陷分类，3) 开发人员修复缺陷，4) 测试人员验证，5) 缺陷关闭， 6) 项目结束时的缺陷报告
可以按照以下步骤管理缺陷：
发现缺陷
在发现阶段，项目团队必须在最终客户发现缺陷之前发现尽可能多的缺陷。当开发人员确认并接受缺陷时，就称发现了缺陷并将其更改为已接受状态
在上述场景中，测试人员在网站中发现了84个缺陷。
让我们看一下下面的场景；测试团队发现他们认为它们是缺陷，并报告给开发团队，但存在冲突-
在这种情况下，作为一名测试经理，会做什么？
-
同意测试团队的意见，认为这是一个缺陷
-
测试经理扮演决策的角色，决定问题是否有缺陷
-
同意开发团队认为不是缺陷
对，是这样，但不正确
在这种情况下，应该用一个解决的准则来解决冲突，作为一个决策者来决定这个网站问题是不是一个缺陷。
分类
缺陷分类帮助软件开发人员确定其任务的优先级。这意味着这种优先级帮助开发人员首先修复那些非常关键的缺陷。
缺陷通常由测试经理进行分类- 将缺陷优先级拖放到下面
- 严重紧急的
- 高风险的
- 中等风险
- 低风险
| 序号 | 描述 | 优先级 | 解释 |
|---|---|---|---|
| 1 | 网站性能太慢 | 高 | 性能缺陷会给用户带来极大的不便。 |
| 2 | 该网站的登录功能无法正常工作 | 紧急 | 登录是银行网站的主要功能之一，如果这个功能不起作用，就是严重的漏洞 |
| 3 | 网站的GUI在移动设备上显示不正确 | 中等 | 该缺陷影响了使用智能手机浏览网站的用户。 |
| 4 | 网站无法记住用户登录会话 | 高 | 这是一个严重的问题，因为用户将能够登录，但不能执行任何进一步的交易 |
| 5 | 某些链接不起作用 | 低 | 对于开发人员来说，这是一个简单的修复，用户仍然可以在没有这些链接的情况下访问网站 |
缺陷解决方案
软件测试中的缺陷解决是一个逐步修复缺陷的过程。缺陷解决过程从将缺陷分配给开发人员开始，然后开发人员按照优先级安排缺陷被修复，然后定义该过程有助于轻松地修复和跟踪缺陷。
可以按照以下步骤修复缺陷。
- 分配：分配给开发人员或其他技术人员进行修复，并将状态更改为响应。
- 进度安排：此阶段由开发方负责。他们将根据缺陷优先级创建修复这些缺陷的计划。
- 修复缺陷：当开发团队修复缺陷时，测试经理根据上面的时间表跟踪修复缺陷的过程。
- 报告解决方案：修复缺陷后，从开发人员那里获取解决方案的报告。
验证
在开发团队修复并报告缺陷之后，测试团队验证缺陷是否已实际解决。 例如，在上面的场景中，当开发团队报告他们已经修复了61个缺陷时，团队将再次测试以验证这些缺陷是否实际已修复。
闭合
一旦缺陷得到解决和验证，缺陷的状态将更改为关闭。如果没有，必须向开发人员发送通知，再次检查缺陷。
缺陷报告
软件测试中的缺陷报告是测试经理准备缺陷报告并将其发送给管理团队以反馈缺陷管理过程和缺陷状态的过程。缺陷报告有助于更好地沟通、跟踪和详细解释缺陷。
管理委员会有权了解缺陷状态。他们必须了解，因此，必须向他们报告当前的缺陷情况，以便从他们那里获得反馈。
重要缺陷度量标准
回到上面的场景。如何衡量和评估测试执行的质量？ 这是每个测试管理器都想知道的问题。可以考虑以下两个参数
在上述银行场景中，可以计算出缺陷拒绝率为20/84=0.238(23.8%）另一个例子，假设银行网站总共有64个缺陷，但测试团队只检测到44个缺陷，因此，可以计算出缺陷泄漏率为20/64=0.312(31.2%)。
结论，通过以下两个参数来评估测试执行的质量
DRR和DLR的值越小，测试执行的质量越好。可以接受的比例范围是多少？这个范围可以在项目目标中定义和接受，也可以参考类似项目的指标。
在本工程中，可接受比的推荐值为5~10%。应该找到对策来降低这些比率，例如
- 提高测试人员的测试技能。
- 花更多的时间，特别是检查测试执行结果。
