软件测试Bug相关

目录

一、概念：

二、基本要素

1. 标题（Title）

2. 问题描述（Description）

3. 复现步骤（Steps to Reproduce）

4. 预期结果（Expected Result）

5. 实际结果（Actual Result）

6. 环境（Environment）

7. 严重程度（Severity）

8. 优先级（Priority）

9. 附件（Attachments）

10. 其他可选要素

三、分级：

1. 按严重程度（Severity）分级

等级划分：

2. 按优先级（Priority）分级

等级划分：

四、步骤

五、常见问题

---

一、概念：

        1）当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。

        2）当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户的功能要求时，就是软件错误。

二、基本要素

1. 标题（Title）

        简洁描述Bug的核心问题，便于快速理解。
        示例：“登录页面点击‘忘记密码’按钮后页面崩溃”

2. 问题描述（Description）

• 详细现象：Bug的具体表现（如错误提示、崩溃、功能失效等）。

• 用户场景：在什么操作或条件下出现（如浏览器版本、操作步骤等）。
  示例：“在Chrome 120版本中，用户点击登录页面的‘忘记密码’按钮后，页面白屏并控制台报错‘Uncaught TypeError’。”

3. 复现步骤（Steps to Reproduce）

• 明确的步骤序列，确保开发人员能复现Bug。

4. 预期结果（Expected Result）

• 正常情况下的正确行为。
  示例：“应跳转到密码重置页面。”

5. 实际结果（Actual Result）

• 当前Bug导致的异常行为。
  示例：“页面白屏，控制台报错。”

6. 环境（Environment）

• 发现Bug的软硬件环境，包括：

  • 操作系统（如Windows 11、macOS 14）；

  • 浏览器/设备（如Chrome 120、iPhone 15）；

  • 版本号（如App版本v2.1.0）。

7. 严重程度（Severity）

• Bug对系统的影响等级：

  • 致命（Critical）：系统崩溃、数据丢失；

  • 高（High）：主要功能失效；

  • 中（Medium）：次要功能问题；

  • 低（Low）：界面错位等轻微问题。

8. 优先级（Priority）

• 修复的紧迫性（如P0-P3，需结合业务需求调整）。

9. 附件（Attachments）

• 辅助信息，如：

  • 错误日志（Console Log、Server Log）；

  • 截图/录屏；

  • 网络请求（Har文件）。

10. 其他可选要素

• 发现人/报告人：测试人员或用户；

• 关联需求/任务：如JIRA任务ID；

• 修复状态：Open、In Progress、Resolved等。

三、分级：

1. 按严重程度（Severity）分级

定义：Bug对系统功能或用户体验的破坏程度。

等级划分：

等级	描述	示例
崩溃（Critical）	导致系统崩溃、数据丢失、核心功能完全不可用。	- 服务器崩溃无法启动； - 支付功能失败导致用户资金损失。
严重（High）	主要功能失效，但系统仍可运行。	- 用户无法提交订单； - 登录功能报错。
一般（Medium）	次要功能问题，对核心流程影响较小。	- 页面部分内容显示错位； - 非必填字段验证错误。
次要（Low）	界面瑕疵或建议性改进，不影响功能。	- 字体颜色不统一； - 提示文案拼写错误。

---

2. 按优先级（Priority）分级

定义：修复Bug的紧急程度（需结合业务需求判断）。

等级划分：

等级	描述	示例
P0（紧急）	必须立即修复，否则阻塞核心流程或引发严重风险。	- 线上支付功能失败； - 安全漏洞（如SQL注入）。
P1（高）	需尽快修复，显著影响用户体验或关键功能。	- 主要页面的加载超时； - 注册流程中断。
P2（中）	可安排在后续版本中修复，影响范围有限。	- 次要功能的边界条件错误； - 非主流浏览器的兼容性问题。
P3（低）	优化类问题，可长期规划或忽略。	- 页面动画效果不流畅； - 控制台无关紧要的警告日志。

四、步骤

在工作中，测试人员创建的bug不一定是有效的，也可能是因为误操作导致的无效bug。

五、常见问题

①在软件上线后出现bug时，测试人员可以采取以下措施：

1. 复现问题：

   • 确认并复现bug，记录复现步骤、环境、输入数据等关键信息。

2. 记录与报告：

   • 详细记录bug，包括复现步骤、预期结果、实际结果、截图或日志等，并提交给开发团队。

3. 优先级评估：

   • 协助评估bug的严重性和影响范围，确定修复优先级。

4. 协助修复：

   • 与开发人员合作，提供更多信息或协助定位问题。

5. 回归测试：

   • 在修复后，进行回归测试，确保问题已解决且未引入新问题。

6. 监控与反馈：

   • 监控线上系统，收集用户反馈，及时发现并报告新问题。

7. 总结与改进：

   • 分析bug原因，总结经验，优化测试流程，提升测试覆盖率。

8. 沟通与协调：

   • 与开发、产品、运维等团队保持沟通，确保问题得到及时处理。

9. 用户支持：

   • 协助支持团队，提供临时解决方案或规避措施，减少用户影响。

10. 文档更新：

    • 更新测试用例和文档，确保未来版本能覆盖类似问题。

通过这些措施，测试人员能够有效应对上线后的bug，保障软件质量。

②测试人员因bug与开发人员发生冲突

1）先检查自身，是否bug描述不清楚。反省自己，是不是出现了误操作，bug描述是否清楚。

2）站在用户角度考虑，并抛出问题。功能正常只是测试的一部分，还需考虑用户使用感受。

3）BUG定级要有理有据。依据BUG定级描述文档。

4）提高自身技术和业务水平，做到不仅能提出问题，还需考虑用户使用感受。

一定不要以命令的口吻来要求开发人员按照自己的逻辑来修改。

5）bug评审。三个代表：测试代表、开发代表、产品代表。

主要解决：1）决定如何处理bug        2）分析缺陷产生的原因，找出预防的对策。