第一章、软件测试分类

1.按阶段分

  • 单元测试
    • 测试：针对单个功能进行测试，如：登录、购物车等
    • 开发（更多的理解）：针对代码进行测试（一般由开发负责、或自动化测试协助）
  • 集成测试
    • 组装测试
  • 系统测试
    • 针对系统进行整体性测试
      • 软件功能
      • 硬件功能
  • 验收测试(用户检验产品是否满足自己预期)
    • α测试：bug比较多、内测版本
  • β测试：bug相对比较少、公测版本
  • γ测试：候选发布版本

2.按是否覆盖源代码划分

  • 黑盒测试
    • 把软件看作一个 “黑盒子”,只关心输入与输出的对应关系
  • 白盒测试
    • 需阅读代码，明确程序的执行流程、数据流向和逻辑判断
  • 灰盒测试
    • 黑盒测试与白盒测试的结合,测试人员不需要完全掌握源代码,但需了解软件的部分内部结构(如模块接口、数据流向、核心逻辑设计),结合功能需求和内部结构设计用例。

3.按是否运行划分

  • 静态测试
    • 不运行被测试程序
    • 测试对象
      • 文档
      • 代码
  • 动态测试
    • 运行测试程序
    • 测试对象
      • 运行中的程序

4.按是否自动化划分

  • 手工测试（功能测试）
  • 自动化测试

5.更多

  • 冒烟测试
    • 每次开发提交新的版本都先进行冒烟测试。
    • 测试点:
      • 最基本功能,如用户正常登陆
      • 最核心的业务流程,如电商购买商品全过程
  • 回归测试
    • 测试点
      • bug回归
      • 旧功能回归
  • 随机测试
  • 探索测试

第二章、软件质量模型

1.质量模型标准

对测试的作用：提供测试设计的不同角度和思路

ISO/IEC 25010

质量特性（Quality Characteristic）子特性（Sub - characteristic）定义与示例（Standard Definition & Example）
1. 功能适用性功能完整性、功能正确性）、功能适当性定义：软件产品在规定条件下使用时，提供满足预定用户明示和隐含需求功能的能力。 示例：金融软件需精准覆盖利息计算、账户管理等功能，确保功能无遗漏（完整性 ）、计算逻辑准确（正确性 ），且功能设计贴合金融业务操作场景（适当性 ） 。
2. 性能效率时间特性、资源利用效率、容量定义：在规定的时间和吞吐量参数内执行功能的能力，以及有效利用资源（如 CPU、内存、存储、网络设备等 ）的能力 。 示例：电商秒杀系统需保障百万级用户并发访问时，响应时间控制在合理阈值（时间特性 ），同时优化服务器资源占用（资源利用效率 ），支撑高并发下的数据处理量（容量 ） 。
3. 兼容性共存性、互操作性定义：软件与其他系统、组件协同工作的能力 。 示例：智能家居生态中，不同品牌智能设备（如智能门锁、照明系统 ）需在同一家庭网络环境下稳定共存（共存性 ），且能通过中控系统相互调用功能、传输数据（互操作性 ） 。
4. 易用性可识别性、易学性、可操作性、用户容错性定义：软件产品被用户理解、学习、使用和吸引用户的能力 。 示例：面向视障用户的软件，需支持屏幕阅读器（可识别性 ），操作流程简单易懂（易学性 ），交互逻辑清晰好操作（可操作性 ），即便用户误操作也有纠错机制（用户容错性 ），界面设计符合通用审美（用户界面美学 ） 。
5. 可靠性成熟度、容错性、可恢复性、可用性定义：在规定条件下，软件产品维持规定性能水平的能力 。 示例：云服务平台需通过大量实际场景验证，降低故障发生频率（成熟度 ）；出现硬件故障时，仍能保障服务不中断（容错性 ）；故障修复后，快速恢复业务数据与服务状态（可恢复性 ）；保障业务时段内服务持续可用（可用性 ） 。
6. 安全性保密性、完整性、抗抵赖性、真实性、可核查性定义：保护信息和数据，抵御未授权访问、使用、修改、破坏，以及保障行为可追溯的能力 。 示例：医疗系统采用区块链存储患者病历，加密确保只有授权人员查看（保密性 ），数据不可篡改（完整性 ），操作留痕可查（可核查性 ），验证用户身份真实（真实性 ），防止抵赖操作（抗抵赖性 ） 。
7. 可维护性易分析性、易修改性、稳定性、易测试性定义：软件产品纠错、改进功能或适应环境变化时，可被修改的能力 。 示例：微服务架构中，单个服务模块出现问题，能快速定位根源（易分析性 ）；更新功能时，少量修改代码即可实现（易修改性 ）；修改后不会引发其他模块异常（稳定性 ）；新增功能或修复后，可高效验证是否符合预期（易测试性 ） 。
8. 可移植性适应性、易安装性、替换性、可一致性定义：软件产品从一个环境转移到另一个环境的能力，以及在指定环境下被安装、替代的能力 。 示例：基于容器化技术开发的应用，可快速部署到不同云服务器环境（适应性 ）；用户可通过简单操作完成安装配置（易安装性 ）；当需要升级或替换时，能无缝切换新版本（替换性 ）；遵循行业通用的移植、安装标准规范（可一致性 ） 。
9. 无害性（25010 新增维度 ）风险识别、故障安全性、安全集成定义：软件产品避免对人员、业务、设备、环境等造成伤害或损失的能力 。 示例：工业控制软件需内置风险预警逻辑，识别设备过载、参数异常等危险（风险识别 ）；出现故障时，自动触发安全停机等保护机制（故障安全性 ）；与其他系统集成时，通过安全校验防止引入外部风险（安全集成 ），像核电站控制系统，保障异常时不会引发安全事故 。

第三章、软件开发过程模型

1.开发模型介绍(又称软件生命周期模型)

开发模型（软件生命周期模型）是指软件从开始研制到最终被废弃所经历的各个阶段。在不同的阶段里，由不同的组织和人员执行不同的任务。软件测试与软件的开发模式有着紧密的联系，作为一名测试人员，应该充分理解软件的开发模型，以便找准自己在其中的位置，从而发挥自身的价值。

2.瀑布模型

瀑布模型流程图:

image-20250708214601444

项目计划->需求分析->概要设计->详细设计->编码->软件测试->运行维护

  • 特点:
    • 线性模型,在所有开发模型中占有重要地位,是其他模型的基础
    • 以文档驱动,每个阶段执行一次,按照线性顺序进行软件开发
  • 优点:
    • 开发的各个阶段比较清晰
    • 当前阶段完成后,只关注后续阶段
  • 缺点:
    • 依赖于其的需求分析,不适应需求的变化
    • 风险往往后期显露,失去及早纠错的机会

第四章、软件测试过程模型

1.测试模型介绍

在软件测试的实施中，针对于测试过程出现的问题，通过经验总结得到测试过程模型，旨在提高软件开发测试过程中的效率与效果

2.V模型

- V模型具有代表意义的模型，最早由Paul Rook在20世纪80年代后期提出，由英国国家计算机中心发布- V模型是瀑布模型的变种，反映测试活动与需求分析、产品设计之间的关系- V模型从左到右，描述了开发与测试过程之间的阶段对应关系

image-20250708215207070

用户需求->需求分析->概要设计->详细设计->编码->单元测试->集成测试->系统测试->验收测试

优点：

  • 展示测试由底层到高层按阶段测试的实现过程

缺点:

  • 不适应需求的变化

3.W模型

- W模型,简称"双V模型",即以开发主导的一个"V",和以测试主导的另一个"V"- 为了克服V模型的缺点,引入了W模型

image-20250710200844055

优点:

  • 测试伴随整个产品开发周期,测试对象不仅是程序还有需求,设计文档
  • 测试介入较早,及早发现问题,降低修复成本

缺点:

  • 实施起来比较复杂,难度大,对需求阶段和测试阶段的测试设计要求较高(计算机技术、业务知识、管理能力、测试素质等)

第五章、测试用例

  1. 测试用例的定义

测试用例,也叫Test Case,为了特定的目的而设计的一组测试输入,执行条件和预期结果的文档

  1. 测试用例的核心要素
常见测试用例的核心8要素
  • 用例编号：表示用例的唯一性,有时也叫用例ID
  • 用例标题：表示要测试或验证的目的,通常一句话简要描述
  • 测试项目：当前测试的功能所属范围
  • 用例级别：表示用例测试功能的重要程度或者影响力
  • 预置条件：验证该功能需要的前提条件
  • 输入数据：必要的输入数据
  • 执行步骤：验证该功能需要的先后操作步骤
  • 预期结果：希望得到的结果
image-20250710202932078

1.等价类划分法

  • 概念：通过科学的方法找到具有共同特性的测试输入的子集,能够从穷举测试中解放(大大减少了测试用例的数量,提升测试效率)。
  • 分类
    • 有效等价类：满足需求
    • 无效等价类：不满足需求
  • 设计测试用例的步骤
    • 需求分析
    • 划分等价类
      • 有效
      • 无效
        • 规则
        • 长度
        • 类型
        • 是否为空(必填项)
        • 是否重复
    • 设计用例
  • 典型应用场景
    • 输入框

2.边界值划分法

  • 作用：对等价类的补充,统计表明程序最容易出错的地方就是在边界附近。
  • 概念：基于边界值【有效等价类和无效等价类的分界点】设计测试用例的一种【黑盒】方法
  • 边界值
    • 上点：边界之上的点
    • 内点：边界之内的点
  • 设计测试用例步骤
    • 需求分析
    • 划分等价类
    • 确定边界
      • 上点
      • 内点
      • 离点
    • 设计测试用例
  • 适用场景
    • 在等价类的基础上针对有边界范围的测试数据输入的地方
    • 常见词语描述：大小、尺寸、重量、最大、最小、至多、至少等修饰词语
    • 典型代表：有边界范围的输入框类测试

离点：离边界最近的左右两点

image-20250710220109030

3.判定表划分法

  • 概念：存在多个输入条件、多个输出结果,输入和输出之间有组合关系,输入和输出之间有依赖或制约关系
  • 判定表组成:
    • 条件桩：所有输入条件，如欠费状态、关机状态
    • 动作桩：所有的可能的输出结果，如允许主被叫、不允许主被叫
    • 条件项：单个条件的取值范围，一般都是有效等价类和无效等价类
      • 表示方式
        • 字符:
          • 真/有效等价类/Y
          • 假/无效等价类/N
        • 数字
          • 真/有效等价类/1
          • 假/无效等价类/0
    • 动作项：基于每一种条件的组合，得到确认的结果，如打不通等
  • 设计测试用例的步骤
    • 明确条件桩(找到所有的输入条件)
    • 明确动作桩(找到所有的输出结果)
    • 对条件桩进行全组合
    • 明确每个组合对应的动作桩(基于每一种条件的组合情况,确定本组合下的输出结果。)
    • 设计测试用例,每行数据对应一条测试用例

4.因果图划分法

  • 概念:用图解的方法表示输入的各组合关系,写出判定表,进而设计测试用例的一种黑盒测试方法。
  • 适用范围:适用于分析程序输入条件的各种组合情况,以及输入和输出之间的依赖关系。
  • 核心
    • 因：条件
    • 果：结果
  • 基本符号（掌握）
    • 恒等（-）：条件成立，结果成立。
    • 或（V）OR：只要有一个条件成立，结果就成立；所有条件都不成立时，结果才不成立。
    • 与/且（^）AND：多个条件必须同时成立，结果成立；只要有一个不成立，结果就不成立。
    • 非（~）NOT：条件成立，结果不成立；条件不成立，结果成立。
  • 设计测试用例的步骤
    • 需求分析
    • 画出因果图
    • 将因果图转换为判定表
    • 生成测试用例

5.场景法(流程图法)

概念: 场景法就是模拟用户操作软件时的场景,主要用于测试多个功能之间的组合使用情况

  • 使用测试阶段
    • 集成测试
    • 系统测试
    • 验收测试
  • 设计测试用例的步骤
    • 需求分析
    • 绘制流程图
    • 设计测试用例(一条流程路径就是一条测试用例)
  • 流程图常用符号
    • 开始或结束: 椭圆
    • 方向或路径: 箭头
    • 处理或操作: 长方形
    • 判断: 菱形
    • 输入或输出: 平行四边形
案例: ATM机的取款流程图

image-20250907163232824