软件测试与维护（八）Integration Test & System Test

软件测试与维护（八）：Integration Test & System Test

测试环境的建立

测试环境的五要素

• 基本要素：软件、硬件
• 派生要素：网络环境、数据准备、测试工具

测试部门建设模式

• 独立运作、与第三方测试机构合作、与相关企业合作、测试外包、项目经理式外包
• 例：TPC事物处理性能委员会

架构

• 软件逻辑架构（软件技术架构）
• 系统物理架构
  • 将具体的软件元件放在物理元件上
  • 具体用了几台机器做什么用，机器上装了什么软件

集成测试 Integration Test

基本概念

• 集成 Integration：putting the pieces together
• 集成测试：将单元组装起来再进行测试，以检查这些单元之间的接口是否存在问题，如：数据丢失、模块间相互影响、组合后不能实现主功能等。
• 集成测试前的准备：人员安排、测试计划、测试内容、集成策略、测试方法
• 集成测试目标 Objectives：
  • 保证系统设计的完整性 Gain confidence in the integraity of overall system design
  • 保证各个组件间正常的交互 Ensure proper interaction of compoents
  • 运行简单系统层的测试 Run simple system-level tests

集成策略

• 集成测试的模式

  • 非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式。
  • 渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合起来测试。

• 非渐增式测试模式

  • 大棒集成 Big bang
    • 知道全部的模块测试完成，再组合起来测试。
    • 问题：
      • 避免了脚手架（桩模块和驱动模块的开销）
      • 不易发现错误

• 渐增式测试模式

  • 自顶向下集成测试 Top-Down
    • 驱动程序/驱动模块（driver）：用以模拟被测模块的上级模块。启动被测模块，并打印出相应的结果。
    • 桩程序/桩模块（stub）：用以模拟被测模块工作过程中所调用的模块。 桩模块由被测模块调用。
    • 好处：
      • 总是有顶层的系统
      • 桩模块可以从接口说明书来书写
    • 坏处：
      • 可能会太迟发现性能问题
      • 桩模块花费多
  • 自底向上集成测试 Bottom-up
    • 好处：
      • 基础函数得到最多的测试
      • 驱动程序相对便宜
    • 坏处：
      • 只有在最后才能测试完整的系统
  • 混合策略测试 Modified Top-down Integration
  • 关键先行 Critical-first
    • 首先集成最重要最关键的模块，之后增加其他的模块
    • 保护了最重要的模块

• Function-at-a-time

• 几种集成测试方法性能的比较

  	自底向上	自顶向下	混合策略	大棒集成
  集成	早	早	早	晚
  基本程序能工作时间	晚	早	早	晚
  需要驱动程序	是	否	是	否
  需要桩程序	否	是	是	否
  计划与控制	容易	难	中	容易

系统测试 System Test

基本概念

• 系统测试目标
  • 获得对整个系统完整性的信心 Gain confidence in the integrity of the system as a whole
  • 确保符合功能需求 Ensure compliance with functional requirements
  • 确保符合非功能需求 Ensure compliance with non-functional requirements

功能测试

• 概念

  • 在集成测试结束之后，依据系统的需求规格说明书和产品功能说明书对系统的整体功能进行的全面测试。
  • 采用黑盒测试方法。

• 功能测试要求

  • 根据系统功能规格说明书准备测试计划 Prepare a test plan from the functional specification of the system
  • 对全部功能设计测试 Prepare tests for all areas of functionality
  • 审查测试计划和测试 Review test plan and tests
  • 执行测试 Execute tests
  • 监控缺陷率 Monitor fault rate
  • 功能测试报告

• 功能测试主要内容

  • 功能流程、界面、菜单按钮、各种输入域、各种链接、各种文字图片、与外系统的接口、软硬件的兼容、版本的兼容

• 回归测试

  • 定义
    • 对修正缺陷后的软件进行再次的测试，不仅测试被修复的软件缺陷是否已经解决，还要测试软件旧有的功能与非功能是否满足要求。
  • 方法
    • 再测试全部用例
    • 基于风险选择测试：测试关键的、重要的、可疑的，跳过非关键的、稳定的
    • 基于操作剖面选择测试
    • 再测试修改的部分

• 冒烟测试

  • 定义

    • 冒烟测试就是在每日build建立后，对系统的基本功能进行简单的测试。这种测试强调功能的覆盖率。

  • 目的

    • 通过最基本的测试，如果最基本的测试都有问题，就直接打回开发部了，减少测试部门时间的浪费。

非功能测试 Non-functional Test

• 性能指标

  • 客户端指标：响应时间、并发数
  • 服务器端指标：CPU占有率，内存占有情况等

• 压力测试 Stress Testing

  • 定义：
    • 一种需要反常数量、频率或资源的方式下，执行可重复的负载测试或强度测试，以检查程序对异常情况的抵抗能力，找出性能瓶颈。
    • 异常情况主要指的是峰值（瞬间使用高峰）、大量数据的处理能力、长时间运行等情况。压力测试总是迫使系统在异常的资源配置下运行。
  • 测试压力估算
    • 给出合理的压力估算值（结合峰值），为压力测试提供数据依据
  • 测试环境准备
    • 软硬件、网络、数据、测试程序
    • 两种压力测试：稳定性压力测试、破坏性压力测试
  • 稳定性压力测试
    • 稳定性压力测试，也叫可靠性测试（reliability testing），或疲劳测试，是指以合理的估算压力连续运行被测系统，检查系统运行时的稳定程度。
    • 通常用mtbf（mean time between failure，错误发生的平均时间间隔）来衡量系统的稳定性。
    • 24*7的方式
    • 使用场合：为了给出系统一个实际使用的指标和范围、使用边界条件。
  • 破坏性压力测试
    • 定义
      • 通常是指持续不断的给被测系统增加压力，直到将被测系统压垮为止。
      • 是采用破坏的手段，目的是为了找到系统的瓶颈。

• 容量测试 Capacity Testing

  • 目的：通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。

• 通过压力测试的稳定性测试，可以得到容量值。

• 性能测试 Performance Testing

  • 定义：通过测试确定系统运行期间的性能表现与性能数据，如：CPU使用的效率、运行速度、响应时间、占有系统资源等方面的系统数据，给出合理的系统配置。
  • 作用：
    • 去定在什么样的压力下系统达到最佳状态（稳定性压力测试），什么压力是系统的极限（破坏性压力测试）
    • 根据性能指标确定实际的软硬件运行环境
  • 性能合理的范围
    • 服务器CPU的占有率：一般在85%以内
    • 内存占有率：80%以内
  • 性能测试与瓶颈分析
    • 步骤
      • 性能测试与数据收集
      • 性能瓶颈分析
      • 性能调优解决方案

• 压力测试工具 LoadRunner

  • Virtual User Generator 创建脚本
    • 创建脚本，选择协议
    • 录制脚本
    • 编辑脚本
    • 检查修改脚本是否有误
  • 中央控制器（Controller）来调度虚拟用户
    • 创建Scenario（一个测试用例），选择脚本
    • 设置机器虚拟用户数
    • 设置Schedule
    • 如果模拟多机测试，设置IP Spoofer
  • 运行脚本
    • 分析scenario
  • 分析测试结果

• 安全测试 Security Testing

  • 检查系统对非法侵入的防范能力。
  • 准则：使非法侵入的代价超过被保护信息的价值，此时非法侵入者无利可图。

• 容错测试 Recovery Testing

  • 检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。