测试流程体系
目录：
- 软件测试基本概念
- 软件测试模型
- 软件测试工作流程
- 测试左移和测试右移
1.软件测试基本概念
- 通过手工或者工具对"被测对象"进行测试
- 验证实际结果与预期结果之间是否存在差异
软件测试作用
- 通过测试工作可以发现并修复软件当中存在的缺陷，从而提高用户对产品的使用信心。
- 测试可以降低同类型产品开发遇到问题的风险。
软件缺陷
- 软件缺陷被测试工程师和开发工程师们称作bug
- 软件缺陷会导致软件不能正常运行，它的存在会在一定程度上导致软件不能满足用户的需求,甚至有可能破坏或泄漏用户的重要数据
软件测试原则
软件测试基础概念_阿瞒有我良计15的博客-CSDN博客
- 测试显示缺陷的存在
- 穷尽测试是不可能的
- 测试尽早介入
- 缺陷集群性(2/8原则)
- 杀虫剂悖论
- 测试活动依赖于测试内容
- 没有错误是好是谬论
软件测试对象
- 需求分析阶段:需求文档、接口文档
- 编码实现阶段:源代码
- 系统功能使用:软件程序
测试用例
为特定的目的而设计的一组测试输人、执行步骤和预期的结果，以便测试产品否满足某个特定需求的文档
2.软件测试模型
V模型
软件测试V模型_阿瞒有我良计15的博客-CSDN博客
- V模型是瀑布模型的一种改进
- V模型标明了测试过程中的不同阶段
- 需求分析:需求文档
- 概要设计:系统架构、模块划分、模块与模块之间的接口
- 详细设计:模块内部实现的逻辑和方法
- 编码:用代码实现设计的内容
- 单元测试:测试代码中最小模块是否符合详细设计
- 集成测试:测试各个模块组成到一起后是否可以正常使用
- 系统测试:测试已经集成在一起的产品是否符合需求文档中的要求
- 验收测试: 测试产品是否符合用户的需求
优点
- 既有底层测试又有高层测试。
- 将开发阶段清楚的表现出来，便于控制开发的过程。
缺点
- 容易让人误解为测试是在开发完成之后的一个阶段。
- 由于它的顺序性，当编码完成之后，正式进入测试时，这时发现的一些bug可能不容易找到其根源，并且代码修改起来很困难。
- 如果需求变更较大，导致要重复变更需求、设计、编码、测试。返工量大。
W模型
软件测试W模型_阿瞒有我良计15的博客-CSDN博客
- W模型明确表示出了测试与开发的并行关系
- W模型中测试伴随着整个软件开发周期，并且测试的对象不仅仅是程序，需求和设计同样要测试
W模型的优缺点
优点
- 将测试贯穿到整个软件的生命周期中，且除了代码要测试，需求、设计等都要测试。
- 更早的介入到软件开发中，能尽早的发现缺陷进行修复
- 测试与开发独立起来，并与开发并行。
缺点
- 无法支持迭代的开发模型
- 对有些项目，开发过程中根本没有文档产生，故W模型无法使用
- 对于需求和设计的测试技术要求很高，实践起来很困难
H模型
- 软件开发中需求、设计、编码等活动被分阶段执行、但是实践中，他们并不是完全串行的,它们之间更多时候是交叉进行的，更多的是迭代执行
- 把测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来
H模型的优缺点
优点
- 软件测试完全独立，贯穿整个生命周期,且与其他流程并发进行。软件测试活动可以尽早准备、尽早执行，具有很强的灵活性
缺点
- 测试就绪点分析困难
- 对于整个项目组的人员要求非常高
软甲测试H模型是软件测试中一种测试过程模型，其名称来源于其形状类似英文字母H。该模型是一种组合了瀑布模型、V模型和敏捷开发的测试过程模型。
软甲测试H模型包含以下几个阶段：
1. 需求分析阶段：在此阶段，测试团队与业务分析人员和项目管理人员合作，理解软件需求和业务规则。测试团队通过分析需求文档、原型等，生成测试需求和测试计划。
2. 系统测试阶段：在此阶段，测试团队根据需求分析阶段的测试计划设计系统测试用例，并开始执行测试。系统测试主要用于验证整个软件系统的功能、性能和稳定性。
3. 集成测试阶段：在系统测试阶段之前，需要进行集成测试。集成测试主要针对不同模块或组件之间的集成和接口进行测试。测试团队根据系统设计和组件之间的接口规范，设计和执行集成测试用例。
4. 单元测试阶段：在集成测试阶段之前，需要进行单元测试。单元测试主要针对软件中的单个模块或函数进行测试。测试团队根据模块设计和功能规范，设计和执行单元测试用例。
5. 验收测试阶段：在系统测试和集成测试完成后，进行验收测试。验收测试是由用户或业务代表来执行的，用于验证系统是否满足业务需求和用户期望。
6. 回归测试阶段：在软件修改或新功能添加后，需要进行回归测试。回归测试是为了确保修改或添加的功能不会影响到原有的功能。测试团队重新执行先前的测试用例，并添加新的测试用例来验证软件的稳定性。
7. 敏捷循环阶段：在软甲测试H模型中，敏捷开发的理念和实践被引入，允许团队在项目开发中进行迭代和增量式的测试。测试团队与开发团队合作，共同完成每个迭代周期内的需求分析、设计、开发和测试。
软甲测试H模型的优点包括：
- 综合了瀑布模型和V模型的优点，强调需求分析和早期测试阶段，提前发现和解决问题；
- 具有较高的可控性和可估计性，减少了后期问题的风险；
- 敏捷循环阶段使得团队可以更加灵活地应对变化，并实现快速交付；
软甲测试H模型的缺点包括：
- 需要充分的沟通和协作，团队成员之间的配合和合作对于模型的成功实施至关重要；
- 模型相对较复杂，需要更多的资源和时间来进行测试规划和执行；
- 不适用于所有开发项目，需要根据团队的具体情况和项目要求进行酌情选择。
总之，软甲测试H模型是一个结合了瀑布模型、V模型和敏捷开发的综合测试过程模型，提供了全面的测试覆盖和敏捷开发的灵活性，使团队能够更好地控制质量并满足业务需求。
3.软件测试工作流程
传统测试流程
-
单元测试：单元测试是针对软件中的单个模块或函数进行的测试。目的是验证单元的功能是否按预期工作。通常由开发人员编写和执行，以确保代码的正确性并尽早发现和修复潜在的问题。
-
集成测试：集成测试是针对软件的不同模块或组件之间的集成和接口进行的测试。它旨在验证模块之间的协作和数据传递是否正确，以及是否满足设计和规范。测试团队根据组件接口规范设计和执行集成测试用例。
-
冒烟测试：冒烟测试是一种简单的测试，用于验证软件的基本功能是否正常工作。它通常在每个新版本或构建之后进行，以确保软件在进行更详细的测试之前是可用和可靠的。冒烟测试目的是验证软件的核心功能，快速筛选出严重的问题。
-
系统测试：系统测试是针对整个软件系统进行的测试，以验证其功能、性能和稳定性是否满足需求。测试团队会根据需求分析阶段的测试计划设计系统测试用例，并执行测试。系统测试旨在模拟最终用户的操作环境和使用情况。
-
回归测试：回归测试是在软件修改或新功能添加后进行的测试，以确保修改或添加的功能不会影响到原有的功能。它重新执行先前的测试用例，并添加新的测试用例来验证软件的稳定性。回归测试旨在捕获由于修改引入的潜在问题。
-
验收测试：验收测试是由用户或业务代表来执行的测试，用于验证系统是否满足业务需求和用户期望。它确保软件按照预期工作，并且能够满足用户的需求。验收测试通常发生在软件的最终阶段，以确认软件的可交付性。
系统测试流程
- 需求分析：在系统测试流程的开始阶段，测试团队与业务分析人员和项目管理人员一起分析软件需求和业务规则。通过仔细审查需求文档、原型等，测试团队能够理解系统所需的功能和性能要求，并确保对系统需求的充分理解。
- 测试计划：测试计划是制定整体测试策略和测试方法的重要文档。在测试计划阶段，测试团队根据需求分析和项目要求，确定测试目标、范围、时间、资源和进度等。测试计划还包括定义测试环境和提供测试的输入数据等。
- 测试设计：在测试设计阶段，测试团队根据需求分析和测试计划，制定具体的测试策略和测试方案。测试设计包括选择合适的测试技术和方法，确定测试用例的优先级和范围，以及规划测试数据和测试环境的准备工作。
- 用例评审：在测试设计阶段，测试用例需要经过评审来确保其质量和有效性。用例评审是测试团队和相关利益相关者共同审查测试用例的过程，以确保测试用例的准确性和完整性。评审期间，团队成员提出意见和建议，确保测试用例满足预期的测试目标。
- 测试执行：在测试执行阶段，测试团队根据测试计划和测试设计中定义的测试用例，按照预定的测试策略和方法执行测试。测试执行包括准备测试数据和测试环境，执行测试用例，记录测试结果，以及检测和报告任何发现的问题或缺陷。
- Bug管理：在测试执行阶段，测试团队会发现和记录测试中发现的问题或缺陷。通过使用专门的缺陷跟踪工具，测试团队能够管理和追踪缺陷的状态、修复过程和验证结果。优秀的缺陷管理可帮助团队及时解决问题并确保质量。
- 发布维护：一旦经过充分测试并修复缺陷，系统测试阶段结束，软件可以准备发布部署。在发布维护阶段，测试团队与开发团队合作进行最终的功能测试和验证，以确保软件在生产环境中正常运行并满足用户需求。同时，团队也负责对软件进行后续维护和支持。
Bug管理流程
4.测试左移和测试右移
测试左移
- 左移是往测试之前的开发阶段移
- 测试团队在软件开发周期早期就开始介入
- 对代码进行测试
- 从发现bug到预防bug
测试左移-质量保障手段
- 代码评审(code review)
- 代码审计
- 单元测试
- 自动化冒烟测试
- 研发自测
测试右移
- 右移是往发布之后移。
- 产品上线后进行线上监控。
测试右移-线上监控
- 闭环的线上问题反馈-检查-解决-更新流程
- 更便捷的日志查看、回传服务
- 丰富有效的log，便于问题的快速定位
- 丰富的监控指标（例如业务异常点指标)
- 业务监控（例如短信发送等)
- 关键指标每日监控（服务器指标)
- 生产数据监控（警报)