软件测试（七）

软件测试的生命周期

软件测试生命周期的各个阶段

1. 需求阶段

• 任务：测试人员需要了解并理解软件的需求，对需求进行分解，确保对测试目标有清晰的认识。
• 输出：需求规格说明书（如果由测试团队负责编写或审核的话）、测试需求文档等。

2. 计划阶段

• 任务：根据软件需求和测试目标，制定详细的测试计划。这包括确定测试范围、测试策略、测试资源、测试时间表等。
• 输出：测试计划文档，包括测试策略、测试方法、测试资源分配、时间表等。

3. 设计阶段

• 任务：测试人员根据测试计划和需求文档，设计测试用例和测试场景。这包括确定测试数据的输入、预期的输出结果以及测试步骤等。
• 输出：测试用例文档、测试数据准备计划等。

4. 构建/编码阶段（部分参与）

• 任务：虽然测试团队主要不参与编码工作，但在此阶段，测试人员可能会与开发团队紧密合作，确保测试用例的可行性和测试环境的准备。
• 输出：测试环境的搭建、测试工具的集成等。

5. 测试执行阶段

• 任务：按照测试计划和测试用例，执行测试活动，记录测试结果，并跟踪和管理测试中发现的问题。
• 输出：测试报告、缺陷报告等。测试报告应详细记录测试的执行情况、测试结果、问题跟踪情况等；缺陷报告则用于记录和跟踪软件中的缺陷。

6. 评估与总结阶段

• 任务：对测试结果进行分析和评估，确定软件是否满足预定的质量标准和用户需求。同时，对测试过程进行总结和反思，为未来的测试活动提供经验和教训。
• 输出：测试总结报告、改进建议等。测试总结报告应全面总结测试活动的各个方面，包括测试目标达成情况、测试过程中遇到的问题和解决方案、测试资源的利用情况等；改进建议则针对测试过程中发现的问题和不足提出具体的改进方向和措施。

如何描述一个bug

为什么要对一个bug进行描述？

对一个bug进行详细的描述在软件开发过程中至关重要，原因有以下几点：

1. 明确问题：详细描述bug可以确保所有相关人员（包括开发人员、测试人员、产品经理等）对问题有共同且清晰的理解。这有助于避免误解和沟通障碍，确保每个人都对问题的本质有准确的认识。

2. 便于复现：通过提供详细的复现步骤，开发人员可以更容易地在自己的环境中重现bug。这有助于他们更准确地定位问题所在，并找到解决方案。如果bug无法复现，那么修复工作将变得非常困难。

3. 提高修复效率：详细描述bug包括提供环境信息、附加信息等，这些信息可以帮助开发人员更快地了解问题的上下文和可能的原因。有了这些信息，开发人员可以更快地制定修复计划，并有效地实施修复。

4. 跟踪和管理：在软件开发过程中，bug跟踪和管理是必不可少的一环。详细描述bug有助于在bug跟踪系统中创建清晰的记录，方便团队成员随时查看和更新bug的状态。同时，这也为后续的统计分析提供了可靠的数据支持。

5. 确保质量：详细描述bug并跟踪其修复过程，是确保软件质量的重要手段之一。通过及时发现和修复bug，可以避免它们在后续的开发或测试阶段中造成更大的影响。此外，对bug的描述和修复过程进行记录，也有助于在软件发布后快速定位和解决潜在的问题。

如何描述一个bug

        描述一个bug时，需要尽可能详细、准确和清晰地传达问题的本质，以便开发人员能够快速定位并修复它。以下是一个描述bug的通用框架，您可以根据实际情况进行调整：

1. 标题（Summary/Title）

• 简短明确：用一句话概括bug的核心问题，如“登录页面在用户输入正确密码时显示错误”。
• 避免模糊：确保标题能够直接反映问题的本质，避免使用“问题”、“错误”等模糊词汇。

2. 复现步骤（Steps to Reproduce）

• 具体详细：列出重现bug的具体步骤，包括用户操作、输入数据、系统状态等。
• 有序清晰：步骤应该是有序的，并且每个步骤都应该是清晰可执行的。
• 最小化：尽量简化复现步骤，只保留导致bug发生的必要操作。

3. 预期结果（Expected Result）

• 明确描述：说明在正常情况下，按照上述步骤操作后应该得到的结果。

4. 实际结果（Actual Result）

• 详细描述：描述实际发生的情况，包括出现的错误消息、界面异常、功能失效等。
• 对比说明：与预期结果进行对比，明确指出差异所在。

5. 截图/视频（Screenshots/Video）

• 直观展示：如果可能，提供截图或视频来直观展示bug的现象。
• 标注重点：在截图上用箭头、圆圈等工具标注出问题所在，帮助开发人员快速定位。

6. 环境信息（Environment）

• 操作系统：描述发生bug的操作系统及其版本。
• 浏览器/应用版本：如果是Web应用或移动应用，说明使用的浏览器或应用版本。
• 网络条件：如果bug与网络相关，说明当时的网络状况。
• 其他硬件/软件信息：如果特定硬件或软件配置与bug有关，也需要提供相关信息。

7. 附加信息（Additional Information）

• 频率：bug出现的频率，是每次都出现还是偶尔出现？
• 影响范围：bug是否影响所有用户或只是部分用户？
• 相关日志：如果有相关的系统日志、错误日志或堆栈跟踪信息，也应提供。
• 已知类似问题：是否已知有类似的问题或bug报告？

示例

标题：登录页面在用户输入正确密码时显示“密码错误”

复现步骤：

1. 打开浏览器，访问网站登录页面。
2. 在用户名输入框中输入“user123”。
3. 在密码输入框中输入“Password123”（已知为正确密码）。
4. 点击“登录”按钮。

预期结果：用户应被成功登录到系统。

实际结果：页面显示“密码错误”的错误消息，用户无法登录。

截图：附上显示错误消息的登录页面截图，并标注错误消息。

环境信息：

• 操作系统：Windows 10
• 浏览器：Chrome 90
• 网络条件：有线连接，网络稳定

附加信息：

• 频率：每次尝试登录时都会发生。
• 影响范围：所有使用“user123”账户的用户。
• 已知类似问题：无复。

如何定义bug级别

        在软件测试和开发中，bug级别的定义通常基于其对系统或应用程序的影响程度。一般来说，bug的级别可以从多个维度进行划分，但最常见的划分方式是将它们分为四个等级：致命（Blocker/Critical）、严重（Critical/Major）、一般（Normal/Minor）和低（Low/Enhancement）。以下是对这些级别的详细定义：

1. 致命（Blocker/Critical）

• 定义：这类bug通常导致系统或应用程序完全无法运行，或者出现严重的资源不足、崩溃、死机、数据丢失等问题。它们会严重影响用户体验，甚至导致系统或应用程序的不可用。
• 示例：
  • 系统崩溃（如蓝屏、死机）。
  • 功能设计与需求严重不符，导致主要功能模块无法使用。
  • 系统无法登录或注册。
  • 内存泄漏导致系统性能急剧下降。
  • 错误操作导致的程序中断，且无法恢复。

2. 严重（Critical/Major）

• 定义：这类bug影响系统的主要功能或操作，但不会导致系统完全崩溃或无法运行。它们通常表现为功能未实现、功能异常、数据错误等，严重影响用户的使用体验。
• 示例：
  • 主要功能存在严重缺陷，但系统仍然可以运行。
  • 功能实现不正确，导致用户无法完成预期的操作。
  • 数据通讯错误，导致数据传输失败或数据不一致。
  • 轻微的数值计算错误，但影响关键业务结果。

3. 一般（Normal/Minor）

• 定义：这类bug通常表现为界面、性能或兼容性方面的缺陷，它们对系统的主要功能影响较小，但可能会影响用户的操作体验或系统性能。
• 示例：
  • 操作界面错误，如按钮位置不当、界面布局混乱。
  • 提示类错误，如错误信息不准确或误导用户。
  • 边界值错误，如输入边界值导致的程序异常。
  • 大数据操作时，没有提供进度条，导致用户等待时间过长。

4. 低（Low/Enhancement）

• 定义：这类bug通常表现为易用性、建议性或界面美观度等方面的问题，它们对系统的功能性和稳定性影响非常小，但可能从用户体验的角度提出一些改进建议。
• 示例：
  • 产品的易用性不佳，如操作流程复杂、操作不便。
  • 界面的美观度有待提高，如颜色搭配不当、布局不美观。
  • 产品说明不明确或存在错别字。
  • 辅助说明描述不清楚，导致用户难以理解或使用。

        需要注意的是，不同公司和项目可能会根据自身的需求和标准对bug级别进行微调。因此，在实际应用中，建议参考项目或公司的具体规范来定义bug级别。

        此外，除了bug级别外，还有一个与之相关的概念是bug的优先级。优先级通常用于指示修复bug的紧急程度，它可能与bug的级别相关，但并不一定完全对应。例如，一个低级别的bug如果影响了关键业务流程的可用性，可能会被赋予较高的优先级以尽快修复。

bug的生命周期

        Bug的生命周期是指从Bug被发现开始，经过一系列的状态变更，最终被关闭的过程。这个过程涉及多个环节和角色，包括测试人员、开发人员、项目经理等。以下是Bug生命周期的详细步骤：

1. 发现Bug

• 描述：测试人员在执行测试用例或进行软件探索性测试时，发现软件程序中的漏洞或缺陷。
• 关键点：测试人员需要准确地记录Bug的现象、复现步骤、预期结果和实际结果等信息。

2. 提交Bug

• 描述：测试人员将发现的Bug提交给Bug管理系统或开发团队，同时尽量详细描述Bug的属性、重现环境、类型、等级、优先级以及详细的重现步骤、结果与期望等。
• 关键点：确保提交的Bug信息是准确、完整且可复现的，避免重复提交。

3. 指派Bug

• 描述：项目经理或技术负责人根据Bug的优先级和开发人员的工作负荷，将Bug指派给相应的开发人员。
• 关键点：确保Bug被及时、准确地指派给合适的开发人员。

4. 分析并确认为缺陷

• 描述：开发人员接收到Bug后，首先对其进行分析和重现，以确认是否为真正的缺陷。
• 关键点：如果开发人员认为不是缺陷或无法重现，需要将其返回给测试人员并说明原因。

5. 处理并修复Bug

• 描述：一旦确认Bug为缺陷，开发人员将着手进行修复工作。这可能涉及修改代码、调整配置或优化算法等。
• 关键点：开发人员需要确保修复后的软件版本不会引入新的问题，并尽可能减少对其他功能的影响。

6. 回归验证Bug

• 描述：测试人员在开发人员修复Bug后，重新执行相关的测试用例以验证Bug是否已被正确修复。
• 关键点：回归测试是确保软件质量的重要环节，需要仔细、全面地执行。

7. 关闭Bug

• 描述：如果测试人员验证Bug已被正确修复，且未引入新的问题，则可以将Bug关闭。
• 关键点：关闭Bug前需要确保所有相关信息都已记录完毕，并通知相关人员。

Bug生命周期中的其他状态

• 重新打开：如果待验证的Bug在验证过程中发现没有被解决，测试人员需要重新打开Bug，并指派给相应的开发人员继续修复。
• 拒绝：如果开发人员认为Bug不是缺陷或无需修复（如由于设计决策、需求变更等原因），则可以拒绝修复该Bug。
• 延期：由于某些原因（如资源限制、优先级调整等），开发人员可能无法在当前版本中修复Bug，而是将其延期到后续版本中进行处理。

测试的执行和bug的管理

一、测试的执行

测试执行是软件测试的核心活动，它涉及按照预定的测试计划和测试用例对软件进行验证和确认，以发现潜在的问题和缺陷。测试执行的步骤如下：

1. 准备阶段：
   • 制定测试计划：明确测试的目标、范围、方法、资源、时间表等。
   • 设计测试用例：根据需求规格说明书、设计文档等编写测试用例，确保覆盖所有关键功能和路径。
   • 搭建测试环境：配置必要的硬件、软件和网络环境，确保测试环境与实际运行环境尽可能一致。
2. 执行阶段：
   • 执行测试用例：按照测试计划和测试用例逐步执行测试，记录测试结果。
   • 发现并记录问题：在测试过程中，如果发现软件存在问题或不符合预期行为，应详细记录问题的现象、复现步骤、截图或日志等信息。
   • 跟踪问题：将发现的问题提交给开发人员或Bug管理系统，并跟踪问题的处理进度。
3. 评估与总结：
   • 评估测试结果：根据测试结果评估软件的质量和稳定性，确定是否存在重大缺陷或风险。
   • 编写测试报告：总结测试过程、测试结果和发现的问题，提出改进建议。

二、Bug的管理

1. 提交Bug：
   • 测试人员发现Bug后，应详细描述Bug的现象、复现步骤、预期结果和实际结果等信息，并提交给开发人员或Bug管理系统。
   • 提交Bug时，应遵循一定的规范，如使用统一的模板、提供必要的截图或日志等。
2. 确认Bug：
   • 开发人员收到Bug报告后，应验证Bug的存在性和可复现性。如果确认是Bug，则进入修复阶段；如果不是Bug或无法复现，则与测试人员沟通并关闭Bug报告。
3. 修复Bug：
   • 开发人员根据Bug报告中的信息定位问题原因，并进行修复。修复完成后，应进行相应的回归测试以验证修复效果。
4. 验证与关闭：
   • 测试人员收到修复后的软件版本后，应重新执行相关的测试用例以验证Bug是否已被修复。如果Bug已被修复且未引入新的问题，则关闭Bug报告；否则，将问题反馈给开发人员继续修复。
5. 跟踪与统计：
   • 在整个Bug管理过程中，应实时跟踪Bug的处理进度和状态变化。同时，还应定期对Bug进行统计和分析，以了解软件的质量状况和开发效率，并为后续的开发和测试工作提供参考。