Home 软件工程

1. 软件纠错 (Software Debugging)

助教批注：这部分主要讲“发现了Bug之后怎么修”。虽然名叫“测试”章，但纠错是测试后的关键步骤。重点在于理解不同方法的适用场景。

1.1 核心纠错策略

PPT介绍了四种主要的纠错（排错）手段：

  1. 试凑法 (Trial and Error)
    • 通俗解释：就是“猜”。设定一个可疑区域，修改代码试试看能不能修好，边试边瞧。
    • 特点：效率较低，适用于结构简单的小程序。
  2. 跟踪法 (Tracking Method)
    • 通俗解释：让程序一步步执行（单步调试），或者从报错的地方往回找原因。
    • 重点：回溯法 (Backtracking) 适合小程序；如果程序分支、嵌套太多，这种方法会极其繁琐，难以执行。
  3. 推理法 (Inference) —— ★ 高频考点
    • 归纳法 (Induction)：从特殊到一般。从测试结果的错误征兆入手，分析它们之间的联系，提出假设并证明。
    • 演绎法 (Deduction)：从一般到特殊。列举所有可能的原因，利用排除法，最后剩下最可能的假设。
  4. 蛮力法 (Brute Force)
    • 通俗解释：把内存、寄存器内容全部打印出来找错（Core Dump）。
    • 评价：效率极低，通常是没办法时的最后手段。

1.2 常用辅助技术

  • 插入打印语句：最原始但有效，缺点是需要修改源程序，可能会引入新错误。
  • 设置断点：利用调试工具，让程序在特定位置停下来观察变量状态。
  • 掩蔽部分程序：暂时注释掉或跳过某些代码段，缩小排查范围。

2. 软件测试的宏观策略 (Testing Strategy)

助教批注：这是本章的骨架。考试常考这四个阶段的顺序和各自的对象。

测试过程按逻辑顺序，由内向外扩展：

  1. 单元测试 (Unit Testing)：针对模块。
  2. 集成测试 (Integration Testing)：针对模块组装。
  3. 确认测试 (Validation Testing)：针对需求。
  4. 系统测试 (System Testing)：针对整个系统（含硬件）。

3. 单元测试 (Unit Testing)

3.1 核心概念

  • 对象：软件设计的最小单位——模块。
  • 方法：主要采用白盒测试，多个模块可以并行测试。
  • 依据：详细设计描述。

3.2 测试内容的五大支柱 (★ 重点)

  1. 模块接口：数据能不能正确进出？（形参实参匹配、全局变量一致性等）。
  2. 局部数据结构：变量定义、初始化有没有错？
  3. 边界条件：循环边界、最大最小值是否处理正确？（这是最容易出错的地方）。
  4. 独立执行通路：保证每条语句至少执行一次。
  5. 错误处理通路：报错信息是否友善？异常处理是否得当？

3.3 测试环境构建 (★ 必考术语)

因为模块不能独立运行，所以需要编写辅助模块：

  • 驱动模块 (Driver)：模拟主程序。它负责接收测试数据，传给被测模块，并输出结果。
  • 桩模块 (Stub)：模拟被调用的子模块。它代替被测模块需要调用的那些功能（通常只做简单的返回）。
    • 助教记法：Driver在上面“开”模块，Stub在下面“顶”着模块。

4. 集成测试 (Integration Testing)

助教批注：这一节的核心是组装策略的对比。

4.1 两种集成方式

  • 非增量式：一次性组装。缺点是出了错很难定位（一团乱麻）。
  • 增量式：逐步添加模块。优点是容易定位错误。

4.2 三大增量策略对比 (★ 重点分析)

策略 描述 优点 缺点 需要辅助模块
自顶向下 (Top-down) 从主控模块开始，由上往下组装 能尽早发现架构/主控问题 底层处理（如I/O）验证得晚 需要桩模块 (Stubs)
自底向上 (Bottom-up) 从底层模块开始，由下往上组装 能尽早发现底层算法/I/O问题 整个程序最后才能跑起来 需要驱动模块 (Drivers)
三明治式 (Sandwich) 混合策略：上层自顶向下，下层自底向上 兼顾两者优点 测试计划较复杂 Driver 和 Stub 都需要

5. 确认测试 (Validation Testing)

5.1 核心任务

  • 目标：验证软件是否符合软件需求规格说明书 (SRS)。
  • 方法：主要使用黑盒测试。
  • 配置复审：检查文档、代码、数据是否齐全。

5.2 Alpha 测试 vs. Beta 测试 (★ 常考辨析)

  • Alpha 测试：
    • 场所：开发者的环境（受控环境）。
    • 人员：用户在开发者指导下进行。
  • Beta 测试：
    • 场所：用户的实际使用环境（不受控）。
    • 人员：最终用户独立进行，开发者通常不在场。
    • 助教记法：Alpha是内测，Beta是公测。

6. 系统测试 (System Testing)

助教批注：系统测试不仅测软件，还要测软件在硬件、网络环境下的表现。

主要包含以下几种类型：

  1. 恢复测试：强迫系统失败（如断电、崩溃），看能不能在规定时间内恢复数据。
  2. 安全测试：模拟非法入侵（黑客攻击），检查系统的防范能力。
  3. 强度测试 (Stress Testing)：
    • 解释：让系统在异常资源配置下运行（如超大流量、内存耗尽）。
    • 目的：检查系统的“崩溃点”在哪里，也就是抗压能力。

7. 面向对象测试 (Object-Oriented Testing)

助教批注：这是进阶内容。重点理解OO测试与传统测试的区别。

7.1 OO测试的特点

  • 对象变化：传统单元测试针对“函数/过程”，OO单元测试针对类 (Class) 或 对象 (Object)。
  • 继承与多态带来的挑战：父类测过了，子类继承后必须重新测试，因为语境变了。

7.2 OO测试策略

  1. 单元测试：
    • 不再孤立测试单个操作，而是把类作为最小单元。
  2. 集成测试：
    • 基于线程 (Thread-based)：把响应某个事件的一组类放在一起测。
    • 基于使用 (Use-based)：先测独立的类（不依赖别人的），再层层往上测。
  3. 测试用例设计：
    • 随机测试：随机生成操作序列（如：开户 -> 存款 -> 取款 -> 销户）。
    • 划分测试：
      • 基于状态：改变状态的操作 vs 不改变状态的操作。
      • 基于属性：使用某些特定属性的操作。
    • 基于模型：利用UML的状态图 (State Diagram) 覆盖所有状态转换路径。

8. 章节总结

本章的核心在于建立一个完整的软件质量保证体系。你需要掌握从微观的代码纠错到宏观的系统测试的全过程。

  1. 纠错重点掌握归纳法与演绎法的逻辑。
  2. 单元测试需牢记驱动模块与桩模块的区别。
  3. 集成测试要能对比自顶向下与自底向上的优劣。
  4. 面向对象测试则强调了“类”作为测试核心单元的转变。

希望这份笔记能帮助你理清思路，考试顺利！