测试流程体系

简介

测试流程体系（Testing Process Framework）是指在软件开发生命周期中，为确保软件质量而定义的一系列系统化和标准化的测试活动、方法、工具和管理流程。其目的是通过规范的流程和严格的测试，发现和解决软件中的缺陷，提高软件的稳定性、可靠性和可维护性。

测试流程体系价值

学习和实施测试流程体系对软件开发团队和项目的成功至关重要。它不仅有助于提高软件质量和开发效率，还能降低成本、管理风险、满足合规要求，并提升客户满意度和团队能力。

• 提高软件质量。
• 降低开发成本。
• 提高开发效率。
• 提升团队能力。
• 提高客户满意度。

基础概念

软件测试基本概念

软件测试

• 通过手工或者工具对"被测对象"进行测试。
• 验证实际结果与预期结果之间是否存在差异。

软件测试作用

• 通过测试工作可以发现并修复软件当中存在的缺陷，从而提高用户对产品的使用信心。
• 测试可以降低同类型产品开发遇到问题的风险。

软件缺陷

• 软件缺陷被测试工程师和开发工程师们称作bug。
• 软件缺陷会导致软件不能正常运行，它的存在会在一定程度上导致软件不能满足用户的需求，甚至有可能破坏或泄漏用户的重要数据。

软件测试原则

• 测试显示缺陷的存在（Testing shows presence of defects）
• 穷尽测试是不可能的（Exhaustive testing is impossible）
• 测试尽早介入（Testing Early）
• 缺陷集群性(2/8原则)（Defect Clustering）
• 杀虫剂悖论（Pesticide Paradox）
• 测试活动依赖于测试内容（Testing is context dependent）
• 没有错误是好是谬论（Absence of error - Fallacy）

1. 测试显示缺陷的存在（Testing shows presence of defects）
   • 测试的本质是证明软件存在缺陷，而不是软件没有任何缺陷。 测试只能证明软件是存在缺陷的（证伪），而不是证明软件是没有缺陷的（证实）。
   • 软件测试不能预知缺陷，只能发现缺陷。
2. 穷尽测试是不可能的（Exhaustive testing is impossible）
   • 穷尽测试指的是对软件系统进行全面、彻底的测试，覆盖所有可能的输入、路径和状态。然而，由于软件系统的复杂性，几乎不可能测试所有可能的情况，因为它需要大量的时间。相反，测试团队只能专注于一些重要的指标。
   • 例如，一个有多个输入字段和条件的程序，可能有数以万计的可能组合，穷尽测试会非常昂贵且不可行。
3. 测试尽早介入（Testing Early）
   • 缺陷的修复成本与其发现时间成反比，且越晚修复其修复成本将会成指数级增长。

1. 缺陷集群性(2/8原则)（Defect Clustering）
   • 二八原则，即：80%的错误是由20%的模块引起的。
   • 在测试中，应该优先关注那些容易出错的区域。
2. 杀虫剂悖论（Pesticide Paradox）
   • 当我们反复使用相同的杀虫剂的时候，会有少量害虫产生免疫而存活下来，使得杀虫剂失去药效。
   • 如果对相同的缺陷进行相同的测试，可能不会找到新的缺陷。就像对抗杀虫剂的昆虫一样，使用相同的策略可能导致昆虫适应新的环境。所以需要不断更新和改进测试方法和策略，以应对新的缺陷和软件变化。
3. 测试活动依赖于测试内容（Testing is context dependent）
   • 测试活动的效果和方法高度依赖于测试内容的质量和完整性。测试内容包括需求文档、设计文档、用户故事等。如果这些内容不准确或不完整，测试活动也会受到影响。
4. 没有错误是好，是谬论（Absence of error - Fallacy）
   • 即使软件经过全面的测试，也不可能完全保证没有任何错误。软件中可能存在未被发现的缺陷。

软件测试对象

• 需求分析阶段：需求文档、接口文档。
• 编码实现阶段：源代码。
• 系统功能使用：系统程序。

测试用例

• 为特定的目的而设计的一组测试输入、执行步骤和预期的结果，以便测试产品否满足某个特定需求的文档。

软件测试模型

软件测试和软件开发一样，都遵循软件工程原理，遵循管理学原理 。测试专家通过实践总结出了很多很好的测试模型。这些模型将测试活动进行了抽象，明确了测试与开发之间的关系，是测试管理的重要参考依据。

V 模型

‌V 模型是一种‌软件开发模型，它强调在软件开发过程中测试和验证的重要性。V 模型从整体上看起来像一个 V 字型结构，由左右两边组成。左边代表需求分析、概要设计、详细设计、编码等开发阶段，右边则代表单元测试、‌集成测试、‌系统测试、‌验收测试等测试阶段。每个开发阶段的输出都与一个相应的测试阶段相对应，确保软件的质量和可靠性。

• V 模型是瀑布模型的一种改进。
• V 模型标明了测试过程中的不同阶段。

V 模型阶段任务

• 需求分析：
  • 从用户、利益相关者和市场调研中收集需求信息。
  • 对需求定义，明确并记录功能需求、非功能需求（如性能、安全性、可靠性）和约束条件。
  • 进行需求验证，确保需求是完整的、一致的、可测试的，并且符合用户的期望。
  • 产出需求规格说明书（SRS），编写正式的需求规格说明文档，作为后续设计和开发的基础。
• 概要设计：
  • 设计系统整体架构，包括主要组件和它们之间的交互关系。
  • 将系统划分为若干个模块或子系统，并定义模块的接口和职责。
  • 编写概要设计文档，描述系统的结构和模块的功能。
• 详细设计：
  • 详细描述每个模块的内部逻辑、数据结构、算法和接口。
  • 编写详细设计文档，提供每个模块的详细实现方案和接口定义。
  • 对详细设计进行评审，确保设计符合需求并且可实现。
• 编码：
  • 实现系统的功能，并确保代码质量和稳定性。
  • 为后续的集成和测试阶段提供可靠的代码基础。
• 单元测试：
  • 验证每个模块的功能和性能，确保模块在独立运行时能够正常工作。
  • 提高系统的稳定性和可靠性。
• 集成测试：
  • 确保模块在集成后能够正确地协同工作。
  • 发现和修复模块集成时出现的缺陷。
• 系统测试：
  • 确保系统作为一个整体满足所有需求和规格。
  • 验证系统的功能、性能、安全性等方面的表现。
• 验收测试：
  • 确保系统满足用户的实际需求和期望。
  • 确认系统可以投入生产环境并正式交付给用户。

V 模型的优缺点

• 优点：
  • 既有底层测试又有高层测试。
  • 将开发阶段清楚的表现出来，便于控制开发的过程。
• 缺点：
  • 容易让人误解为测试是在开发完成之后的一个阶段。
  • 由于它的顺序性，当编码完成之后，正式进入测试时，这时发现的一些bug可能不容易找到其根源，并且代码修改起来很困难。
  • 如果需求变更较大，导致要重复变更需求、设计、编码、测试。返工量大。

W 模型

‌W 模型是一种软件开发模型，它是 ‌V 模型的扩展，旨在解决传统开发模型在需求分析和设计阶段的局限性。这种模型在两个主要阶段之间增加了反向的设计和需求分析阶段，确保了开发早期阶段的需求和设计的准确性和有效性。与传统的瀑布模型相比，W 模型增强了团队之间的沟通和协作，允许在早期阶段进行迭代和变更。此外，W 模型强调测试应伴随整个开发周期，不仅限于代码编写后的测试，从而有助于在开发早期就发现和修复问题。‌

• W 模型明确表示出了测试与开发的并行关系。
• W 模型中测试伴随着整个软件开发周期，并且测试的对象不仅仅是程序，需求和设计同样要测试。

W 模型的优缺点

• 优点
  • 将测试贯穿到整个软件的生命周期中，且除了代码要测试，需求、设计等都要测试。
  • 更早的介人到软件开发中，能尽早的发现缺陷进行修复。
  • 测试与开发独立起来，并与开发并行。
• 缺点
  • 无法支持迭代的开发模型。
  • 对有些项目，开发过程中根本没有文档产生，故 W 模型无法使用。
  • 对于需求和设计的测试技术要求很高，实践起来很困难。

H 模型

‌H 模型是一种将测试活动完全独立出来的模型，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。 H 模型相对于 ‌V 模型和 ‌W 模型，更加注重测试的灵活性和独立性。‌

• 软件开发中需求、设计、编码等活动被分阶段执行、但是实践中，他们并不是完全串行的，它们之间更多时候是交叉进行的，更多的是迭代执行。
• 把测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。
• 测试在该模式下主要完成三部分工作：测试前期的准备、测试就绪点的预判、测试执行。
• 测试人员需要根据实际项目的特点，及时判断当下测试执行的条件是否满足，然后尽早地投入测试工作中。

H 模型的优缺点

• 优点：
  • 软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行。
  • 软件测试活动可以尽早准备、尽早执行，具有很强的灵活性。
• 缺点：
  • 测试就绪点分析困难。
  • 对于整个项目组的人员要求非常高。

软件测试工作流程

传统测试流程

• 单元测试：
  • 单元测试是指对软件的最小可测试部分（通常是一个函数或方法）进行测试。
  • 目标是验证该单元在独立运行时是否能够正确执行其功能。
  • 通常由开发人员在编码阶段进行，并使用单元测试框架（如 JUnit、pytest）来自动化测试。
• 集成测试：
  • 集成测试是在各个单元或模块集成后，对它们之间的接口和交互进行测试。
  • 目标是发现模块之间的集成问题，确保它们在一起协同工作时能够正常运行。
  • 可以分为两种类型：增量集成测试（逐步集成并测试）和大爆炸集成测试（一次性集成所有模块并测试）。
• 冒烟测试：
  • 冒烟测试是一种基本功能测试，用于验证新版本的软件构建是否稳定，可以进行更深入的测试。
  • 通常在每次构建之后进行，测试范围较小，只覆盖关键功能。
  • 目标是快速确认软件的核心功能是否正常运行，类似于硬件中的“冒烟测试”（确保设备接通电源后不冒烟）。
• 系统测试：
  • 系统测试是在完整的系统上进行的全面测试，验证整个系统是否符合需求规格说明书（SRS）中的要求。
  • 包括功能测试、性能测试、安全性测试、兼容性测试等多种类型。
  • 目标是确保系统作为一个整体在真实环境中能够正常工作。
• 回归测试：
  • 回归测试是在软件修改或更新后进行的测试，以确保新版本没有引入新的缺陷，并且之前修复的问题没有重新出现。
  • 目标是验证修改对其他功能的影响，确保软件的整体稳定性。
  • 通常使用自动化测试工具进行，覆盖范围较广。
• 验收测试：
  • 验收测试是由最终用户或客户进行的测试，验证软件是否满足业务需求和用户需求。
  • 目标是确认系统准备好投入实际使用，通常是开发和测试的最后一个阶段。
  • 包括Alpha测试（内部用户测试）和Beta测试（外部用户测试）。

系统测试流程

• 需求分析：
  • 理解和分析系统需求，明确测试范围和测试目标。
  • 编写需求分析文档，作为测试计划和测试设计的基础。
  • 确保测试团队对系统需求有全面的了解，以便制定有效的测试策略。
• 测试计划：
  • 为测试过程提供明确的指导和框架，确保测试活动有序进行。
  • 明确测试团队的角色和职责，分配具体任务。
  • 确定测试工具和测试标准。
• 测试设计：
  • 确保测试用例的全面性和覆盖率，为后续的测试执行提供详细指导。
  • 设计测试用例，覆盖所有功能需求和非功能需求（如性能、安全性、兼容性等）。
  • 创建测试数据和测试环境，确保测试环境与生产环境尽可能一致。
  • 编写详细的测试用例文档，描述测试步骤、预期结果和实际结果。
• 用例评审：
  • 确保测试用例的质量和准确性，提高测试执行的有效性。
  • 组织评审会议，邀请相关团队成员（如开发人员、业务分析师）对测试用例进行评审。
  • 讨论并确认测试用例的完整性、准确性和有效性。
  • 根据评审反馈对测试用例进行修改和完善。
• 测试执行：
  • 验证系统是否符合需求规格说明书中的要求，发现并报告系统中的缺陷。
  • 按照测试计划和测试用例，执行系统测试。
  • 记录测试结果，标记测试通过和失败的用例。
  • 发现并记录缺陷，提交缺陷报告。
• Bug管理：
  • 确保所有发现的缺陷得到及时修复和验证，提升系统的质量。
  • 跟踪和管理测试中发现的缺陷，记录缺陷的详细信息。
  • 协调开发团队修复缺陷，并进行验证测试。
  • 维护缺陷状态（如新发现、已修复、已验证、已关闭）和优先级。
• 发布维护：
  • 确保系统顺利发布并在实际环境中稳定运行，及时响应用户反馈和问题。
  • 准备发布文档，包括发布说明、已知问题和解决方案。
  • 收集用户反馈，进行必要的维护和优化。

Bug 管理流程

Bug处理主流程：

1. 当测试人员发现 Bug 后，提交相关的缺陷场景描述及现象，即缺陷的状态为 New。
   • 测试人员在创建缺陷之前首先应该保证，这个缺陷是没有被提过的，以免造成有重复的缺陷。
2. 创建时会指定给开发，缺陷创建成功后，对应的开发确认缺陷，即缺陷的状态为 Open。
   • 开发接收到一个缺陷时，首先是根据测试人员的描述对缺陷进行分析及重现，如果发现不是缺陷或缺陷对应的场景无法复现，则需要将缺陷直接重新指派给测试人员，并注明原因。
3. 当开发确认缺陷并解决完后，此时，缺陷的状态为 Fixed，并当前缺陷被重新指派给测试人员。
4. 测试发现缺陷的指派更改后，进行当前缺陷的回归测试，若通过，则关闭缺陷，即缺陷的状态为 Close。

测试左移和测试右移

测试左移

• 左移是往测试之前的开发阶段移。
• 测试团队在软件开发周期早期就开始介人。
• 对代码进行测试。
• 从发现 bug 到预防 bug。

测试左移-质量保障手段

• 代码评审（code review）：
  • 由团队成员（通常是开发人员）检查代码的质量，包括编码规范、逻辑正确性、可读性和可维护性。
  • 通过评审发现潜在的缺陷和问题。
• 代码审计：
  • 由独立的审计团队或工具对代码进行全面检查，重点关注安全性、性能、合规性和潜在的漏洞。
  • 发现代码中的安全漏洞和性能瓶颈，提升系统的安全性和性能。
• 单元测试：
  • 验证每个代码单元的功能，确保其在独立运行时能正常工作。
  • 提高代码的稳定性和可维护性。
• 自动化冒烟测试：
  • 使用编写的自动化脚本，在每次代码变更后快速验证系统的核心功能。
  • 确保系统的基本功能在持续集成过程中始终保持正常。
• 研发自测：
  • 开发人员在提交代码前自行进行测试，包括单元测试、功能测试和集成测试。
  • 在代码提交前发现并解决潜在问题，减少后续测试阶段的缺陷数量。

测试右移

• 右移是往发布之后移。
• 产品上线后进行线上监控。

测试右移-线上监控

• 闭环的线上问题反馈-检查-解决-更新流程。
• 更便捷的日志查看、回传服务。
• 丰富有效的log，便于问题的快速定位。
• 丰富的监控指标(例如业务异常点指标)。
• 业务监控(例如短信发送等)。
• 关键指标每日监控(服务器指标)。
• 生产数据监控(警报)。

总结

• 软件测试基础概念。
• 软件缺陷基础概念。
• 软件测试原则。
• 软件测试对象。
• 测试用例
• 软件测试模型：V 模型、W 模型、H 模型。
• 软件测试工作流程：传统测试流程、系统测试流程、Bug管理流程。
• 测试左移、测试右移。