软件测试基础-缺陷管理

      一、缺陷管理流程总览

        当涉及到软件测试时，缺陷（bug）管理是一个至关重要的流程。它涉及发现、报告、跟踪和解决软件中的缺陷。

下面是一个常见的软件测试缺陷管理流程的概述：

1. 缺陷报告：在软件测试过程中，测试人员会发现各种缺陷。一旦发现缺陷，测试人员需要准确地记录缺陷的详细信息。这些信息通常包括缺陷的描述、重现步骤、缺陷的严重程度和优先级等。

2. 缺陷分类和分级：测试团队通常会对每个缺陷进行分类和分级。这有助于确定缺陷的类型和严重程度，并确定解决缺陷的优先级。常见的分类包括功能性缺陷、性能问题、用户界面问题等。

3. 缺陷分配：一旦缺陷被报告，测试团队需要将其分配给相应的开发人员或团队进行修复。分配缺陷时，通常会考虑开发人员的专业领域、负责的模块或功能等因素。

4. 缺陷跟踪：跟踪缺陷是确保缺陷得到及时解决的关键步骤。测试团队会使用缺陷跟踪系统或工具来记录缺陷的状态、解决进度和相关讨论等信息。这有助于团队成员之间的沟通和协作，并确保缺陷得到适时处理。

5. 缺陷解决和验证：开发人员接收到分配的缺陷后，他们会进行相应的修复工作。修复完成后，测试团队会重新测试相关功能或模块，以确认缺陷是否已经得到解决。

6. 缺陷关闭：一旦缺陷被修复并且经过验证，测试团队会将其标记为已关闭。此时，缺陷报告中的状态将被更新为已解决，并且相关的文档和记录也会进行更新。

7. 缺陷统计和分析：缺陷管理流程的最后一步是对缺陷进行统计和分析。测试团队可以根据缺陷报告和缺陷跟踪系统中的数据生成报告，以便评估软件质量、发现潜在的趋势和改进测试过程。

        需要注意的是，实际的缺陷管理流程可能因组织和项目而有所不同。一些组织可能使用专门的缺陷管理工具来支持缺陷管理流程，而另一些组织可能使用通用的项目管理工具来跟踪和管理缺陷。流程的具体细节和工具的选择应根据实际需求和组织的约定进行确定。

二、缺陷(bug)的等级

        软件测试中，缺陷等级用于划分和分类不同严重程度的软件缺陷

2.1 、P0（紧急缺陷）：

• 系统崩溃或无法启动。
• 严重影响核心功能的错误。
• 数据丢失或损坏。
• 安全漏洞或数据泄露。
• 严重影响用户体验的问题。
• 其他紧急修复需要的问题[1]。

2.2、P1（严重缺陷）：

• 应用系统崩溃或系统资源使用严重不足。
• 系统停机或非法退出，无法通过重启恢复。
• 系统出现死循环。
• 数据库发生死锁或程序原因导致数据库断连。
• 系统关键性能不达标。
• 数据通讯错误或接口不通。
• 错误操作导致程序中断。
• 其他严重影响系统正常运行的问题[1]。

2.2、P2（较严重缺陷）：

• 系统因软件严重缺陷导致重要交易无法正常使用、功能不符合用户需求。
• 重要计算错误。
• 业务流程错误或不完整。
• 使用某交易导致业务数据紊乱或丢失。
• 业务数据保存不完整或无法保存到数据库。
• 周边接口出现故障。
• 服务程序频繁需要重启。
• 批处理报错中断导致业务无法正常开展。
• 前端未合理控制并发或连续点击动作，导致后台服务无法及时响应。
• 在产品声明支持的不同平台下，出现部分重要交易无法使用或错误[1]。
• 偶尔出现的致命性bug

2.3、P3（一般缺陷）：

• 功能缺陷，但不会导致系统崩溃或重大故障。
• 非关键功能的错误。
• 用户界面不符合设计规范。
• 非关键性能问题。
• 非关键数据显示错误。
• 简单的输入限制未放在前段进行控制
• 其他一般性问题[1]。

2.4、P4（次要缺陷）：

• 不影响系统功能的小问题。
• 界面样式问题。
• 文字拼写错误或语法错误。
• 非关键性能优化建议。
• 其他次要问题[1]。

        需要注意的是，不同的组织或项目可能会有自己的缺陷等级定义和划分标准，尤其是不同业务之间有差别，因此以上定义仅供参考。

        在实际测试中，根据缺陷的严重程度和影响范围，将缺陷分配到相应的等级，有助于开发团队优先处理严重的缺陷，确保软件质量和用户体验。

三、缺陷的生命周期

        缺陷的生命周期是指在软件开发和测试过程中，缺陷从被发现到被解决的整个过程。在这个过程中，缺陷会经历不同的状态和处理流程。下面是软件缺陷的一般生命周期流程：

新建 - 可能出现的缺陷，但尚未得到验证，未新建状态

分配 - 分配创建的缺陷给开发团队，此时缺陷还未解决

激活 - 缺陷处于开发团队排查或解决中，可能会出现两种结果：一为拒绝打回（非缺陷），二为延迟解决

测试 - 缺陷已被开发团队标记为已解决，软件测试人员进行测试，可能出现两种结果：一是缺陷依旧未修复，重新打开分配给开发团队，二是测试通过

验证 - 缺陷已由软件测试人员进行回归验证，标记为已验证

关闭 - 关闭已验证通过的缺陷

重新激活 - 即缺陷未修复好，软件测试人员标记为重新激活或重新打开分配给开发团队以进行修复

延迟 - 因某些因素需要，暂缓该缺陷的修复

拒绝 - 开发团队拒绝修复该缺陷，可能是因为：1、重复的缺陷 2、不是缺陷 3、不可重现

以下是缺陷生命周期流程：

1. 发现缺陷：当发现缺陷时，建议测试人员不要着急提交缺陷，而是先记录下来。记录可以包括详细的描述、复现步骤和截图等，这有助于提供更准确的信息给开发人员。

2. 确认缺陷：在确认缺陷之前，测试人员应该排除外部因素对缺陷的影响。他们需要确保缺陷是可重现的，并确定该缺陷对系统功能或用户体验的实际影响。这样可以更准确地评估缺陷的优先级和重要性。

3. 提交缺陷：当缺陷被确认后，测试人员需要将其提交到指定的缺陷跟踪系统或工具中。在提交时，他们应该明确指定缺陷的必现或偶现情况，并将其提交给相应的团队成员或开发人员。同时，提供清晰的描述和相关附件，以便更好地理解和复现缺陷。

4. 指派缺陷：一旦缺陷被提交，应该及时将其指派给适当的开发人员。确保有一个明确的指派流程，以便缺陷能够得到及时处理和跟进。同时，跟进缺陷的处理进度，并确保开发人员能够妥善处理和解决缺陷。

5. 研发确认缺陷：开发人员在接收到缺陷后，应该仔细审查缺陷报告中的信息，并与测试人员进行进一步的沟通和确认。他们需要从测试人员提交的描述中判断是否真的存在缺陷，并共同讨论解决方案。

6. 重复缺陷：如果开发人员发现某个缺陷已经被其他人提交过了，他们应该在相关的缺陷报告中标注该缺陷的重复性，并解释原因。如果确认是重复缺陷，可以关闭该缺陷报告并说明原因，这样可以避免重复工作和混淆。

7. 不是缺陷：有时候，测试人员可能会误将一些外部因素或设计如此的情况认为是缺陷。在遇到这种情况时，他们应该先确认外部因素或与设计意图一致，然后与相关人员进行沟通和确认。根据确认结果，如果是无效的缺陷，可以关闭该缺陷报告并添加相应的备注；如果是有效的缺陷，应该重激活该缺陷并指派给相应的开发人员。

8. 无法重现：有时候，某些缺陷可能只是偶尔出现，或者在特定的环境下才能复现。对于这种情况，测试人员需要记录相关的信息，并尝试找到稳定复现该缺陷的步骤。如果在测试环境中无法复现该缺陷，可以尝试在开发环境中进行复现，并与开发人员一同协作解决缺陷。

9. 不予解决：对于某些缺陷，根据一些因素（如修复风险、影响范围等），可能决定不对其进行修复。在这种情况下，应该明确记录和解释不予解决该缺陷的原因，并及时通知相关人员。

10. 延期缺陷：对某些缺陷，根据团队的优先级和资源分配，可能决定将其延期处理。在这种情况下，应该明确记录并解释延期处理该缺陷的原因，并在适当的时候重新评估和调整优先级。

11. 回归验证缺陷：在开发人员修复缺陷后，进行回归测试以验证修复的有效性。这样可以确保修复的缺陷不会对其他功能产生负面影响，并且相关的功能点得到充分测试。

12. 解决和关闭缺陷：在确认缺陷已经被修复并通过回归测试后，及时关闭缺陷报告。在关闭时，提供必要的备注和记录，包括修复的版本号、修复日期等信息。

        通过优化以上步骤，可以提高缺陷管理过程的效率和准确性。测试人员和开发人员之间的沟通和协作将更加顺畅，缺陷可以更快地得到解决，从而提高软件质量和团队的工作效率。这些优化建议应根据具体情况和团队需求进行调整和实施。

参考

软件测试缺陷等级划分标准_软件故障等级划分标准表格-CSDN博客文章浏览阅读1.5w次，点赞13次，收藏83次。严重级别子项概述具体描述1级：致命问题A-1操作系统崩溃运行软件系统后会导致操作系统崩溃（内存漏留严重或CPU占用100%）A-2导致软件系统崩溃..._软件故障等级划分标准表格https://blog.csdn.net/w13632910369/article/details/84957758

【软件测试系列二】《软件测试流程规范》-腾讯云开发者社区-腾讯云

拆分软件测试流程，一张图秒杀所有面试-腾讯云开发者社区-腾讯云