软件特性及方面测试

发表于 Waline： 阅读次数： 本文字数： 5.2k 阅读时长 ≈ 19 分钟

软件质量：测试的终极目标

在深入探讨各种具体的软件测试类型之前，我们首先需要明确所有测试活动的最终目标：确保和提升软件质量。软件质量并非单一维度，而是一个多维度的综合概念。国际标准 ISO/IEC 25010 为我们提供了一个全面的软件产品质量模型，它将软件质量划分为八大特性，每个特性又包含若干子特性。

ISO/IEC 25010 软件质量模型

这是一个行业公认的框架，用于评估软件产品的质量。理解这些特性有助于我们明白为何需要进行后面将要介绍的各种专项测试，因为每一种测试几乎都对应着提升这些质量特性的一个或多个方面。

graph TD
    subgraph "软件产品质量（ISO/IEC 25010）"
        A[功能适宜性<br>Functional Suitability]
        B[可靠性<br>Reliability]
        C[性能效率<br>Performance Efficiency]
        D[易用性<br>Usability]
        E[安全性<br>Security]
        F[兼容性<br>Compatibility]
        G[可维护性<br>Maintainability]
        H[可移植性<br>Portability]
    end

    A --> A1(功能完整性):::AT & A2(功能正确性):::AT & A3(功能适当性):::AT
    B --> B1(成熟度):::BT & B2(可用性):::BT & B3(容错性):::BT & B4(可恢复性):::BT
    C --> C1(时间特性):::CT & C2(资源利用率):::CT & C3(容量):::CT
    D --> D1(易理解性):::DT & D2(易学性):::DT & D3(易操作性):::DT & D4(用户差错防御):::DT & D5(用户界面美观性):::DT & D6(易访问性):::DT
    E --> E1(机密性):::ET & E2(完整性):::ET & E3(抗抵赖性):::ET & E4(可核查性):::ET & E5(真实性):::ET
    F --> F1(共存性):::FT & F2(互操作性):::FT
    G --> G1(模块化):::GT & G2(可重用性):::GT & G3(易分析性):::GT & G4(易修改性):::GT & G5(易测试性):::GT
    H --> H1(适应性):::HT & H2(易安装性):::HT & H3(易替换性):::HT

    style A fill:#f9f,stroke:#333,stroke-width:1px
    style B fill:#bbf,stroke:#333,stroke-width:1px
    style C fill:#bfb,stroke:#333,stroke-width:1px
    style D fill:#ffb,stroke:#333,stroke-width:1px
    style E fill:#fbb,stroke:#333,stroke-width:1px
    style F fill:#fbf,stroke:#333,stroke-width:1px
    style G fill:#bff,stroke:#333,stroke-width:1px
    style H fill:#ffd,stroke:#333,stroke-width:1px
    classDef AT fill:#f9f,stroke:#333,stroke-width:1px
    classDef BT fill:#bbf,stroke:#333,stroke-width:1px
    classDef CT fill:#bfb,stroke:#333,stroke-width:1px
    classDef DT fill:#ffb,stroke:#333,stroke-width:1px
    classDef ET fill:#fbb,stroke:#333,stroke-width:1px
    classDef FT fill:#fbf,stroke:#333,stroke-width:1px
    classDef GT fill:#bff,stroke:#333,stroke-width:1px
    classDef HT fill:#ffd,stroke:#333,stroke-width:1px

本章将要介绍的各类测试，正是为了系统性地验证和度量软件在这些质量特性上的表现。

性能与效率测试

对于大规模、高并发的复杂软件系统（如电商网站、社交平台），运行效率是决定用户体验和商业成败的关键。性能与效率测试是一个大家族，包含多个关系密切但侧重点不同的测试类型。它们共同的目标是评估系统在各种负载下的行为，但探索的「边界」和「目的」各不相同。

性能测试（Performance Testing）

  • 是什么：性能测试是一个总称，它通过模拟多种负载场景（正常的、峰值的、异常的）来评估系统的各项性能指标是否达到预设要求。
  • 为什么：核心目的是验证系统是否满足性能需求（如「99% 的请求响应时间在 200ms 以内」），并发现系统中存在的性能瓶颈，为性能调优提供依据。
  • 怎么做：
    1. 识别目标：明确需要测试的性能指标，如响应时间、吞吐量（TPS/QPS）、资源利用率（CPU, 内存） 等。
    2. 设计方案：使用自动化工具（如 JMeter, LoadRunner）设计负载模型，模拟用户行为。
    3. 执行与监控：在不同负载下运行测试，并实时监控各项性能指标。
    4. 分析与调优：分析结果，定位瓶颈，然后进行代码或架构优化，并重复测试进行验证。

性能测试是「体检」，检查系统各项性能指标是否「健康达标」。

负载测试（Load Testing）

  • 是什么：负载测试是性能测试的一种，它主要关注系统在预期和峰值用户负载下的表现。它通过逐步增加负载，观察系统性能指标的变化情况。
  • 为什么：目的是验证系统能否在预期的业务压力下稳定、正常地运行，确保其承载能力。
  • 怎么做：模拟实际的用户访问量，从正常负载逐渐增加到预期的峰值负载，持续观察响应时间、吞吐量等指标是否在可接受范围内。
  • 形象说明：好比测试一座桥的设计承载能力。设计标准是能同时通过 100 辆车，负载测试就是让 1 辆、10 辆、50 辆直到 100 辆车通过，并测量桥梁的各项指标（如晃动幅度）是否在安全范围内。

负载测试是「压力面试」，看系统在预期的工作压力下能否胜任。

压力测试（Stress Testing）

  • 是什么：压力测试，又称强度测试，是测试系统在超出其正常工作负载的极限或异常条件下的行为。
  • 为什么：目的不是看系统能否正常工作，而是看它在不堪重负时如何「优雅地失败」。我们想知道系统的崩溃点在哪里，以及它是否具备良好的容错能力和恢复能力。
  • 怎么做：
    • 破坏性压力测试：不断增加负载，直到系统崩溃或性能下降到不可接受的程度，从而找到系统的性能极限。
    • 稳定性压力测试（也称浸泡测试或耐久性测试，Soak Testing）：在高负载下长时间（如 24 小时以上）运行系统，以发现因资源泄漏（如内存泄漏）等问题导致的软件老化（Software Aging）现象。
  • 形象说明：继续用桥的例子，压力测试就是不断往桥上开卡车，直到把桥压垮为止，从而确定它的极限承载力。浸泡测试则像是让桥持续满负荷承载 72 小时，看它会不会因为金属疲劳而出问题。

压力测试是「极限挑战」，目的是把系统「玩坏」，看它在哪里崩溃，以及能否恢复。

容量测试（Volume Testing）

  • 是什么：容量测试关注的是系统处理海量数据的能力。它不一定涉及高并发用户，但一定涉及大数据量。
  • 为什么：目的是确定系统的数据容量极限，例如数据库能存储多少条记录而性能不会显著下降，或者系统能处理多大的文件。
  • 怎么做：向系统（特别是数据库）填充大量数据，然后在此基础上测试系统的查询、插入、更新等操作的性能。
  • 形象说明：测试一个仓库的容量。不是看能同时进出多少人（并发），而是看这个仓库最多能堆放多少货物（数据量）。

容量测试是「大胃王比赛」，看系统能「吃」下多少数据。

性能相关测试对比

测试类型 主要目的 测试方法 关注点
性能测试 评估指标：获取系统在特定负载下的各项性能指标。 模拟多种正常、峰值、异常负载。 响应时间、吞吐量（TPS/QPS）、资源利用率等。
负载测试 发现瓶颈：在不同负载下运行，观察性能变化，发现缺陷。 逐步增加负载，模拟真实用户行为组合。 系统在预期负载范围内的行为、性能拐点。
压力测试 测试极限：在高负载或极端条件下运行，评估系统的稳定性和恢复能力。 施加超过系统承载能力的负载，或在资源匮乏下运行。 系统的崩溃点、容错能力、恢复能力、是否存在内存泄漏。
容量测试 确定边界：找到系统能够处理的最大数据量或用户数。 逐步增加数据量或并发用户数，直到系统无法处理。 最大并发用户数、数据库最大记录数等极限值。

这几类测试关系密切，压力测试可以看作一种特殊的负载测试（高负载），而它们都属于性能测试的范畴。

可靠性与稳定性测试

这类测试关注软件在规定时间内和环境下，能否持续、稳定地提供服务，以及在出现故障时能否有效恢复。

可靠性测试（Reliability Testing）

  • 是什么：可靠性测试通过在特定环境下加载一定的业务压力并长时间运行，来评估软件系统无故障运行的能力。
  • 为什么：目标是量化系统的可靠性程度，确保软件能在预定环境中，在一定时间内持续正常运行。
  • 怎么做：
    1. 构建操作剖面（Operation Profile）：分析用户最常执行的操作及其概率，模拟真实的用户使用模式。
    2. 长时间运行：基于操作剖面生成测试用例并长时间执行。
    3. 度量与分析：记录失效（failure）数据，计算可靠性指标。
  • 核心指标：
    • MTTF (Mean Time To Failure)：平均无故障时间。
    • MTTR (Mean Time To Repair)：平均修复时间。
    • MTBF (Mean Time Between Failures)：平均故障间隔时间。MTBF=MTTF+MTTR\mathrm{MTBF} = \mathrm{MTTF} + \mathrm{MTTR}。
    • 可用性（Availability）：系统可正常使用的时间比例。Availability=MTTF/MTBF\mathrm{Availability} = \mathrm{MTTF}/\mathrm{MTBF}。

可靠性测试是「马拉松」，检验系统能否长时间稳定地「奔跑」而不出错。

稳定性测试（Stability Testing）

  • 是什么：稳定性测试与可靠性测试和压力测试中的浸泡测试非常相似，主要检测软件在长期或高负载使用过程中，性能是否稳定，以及是否会崩溃。
  • 为什么：确保系统不会因为长时间运行而出现资源耗尽、性能下降等问题。
  • 怎么做：模拟用户使用数年的情况，让系统在一定的压力下长时间运行，并持续监控性能指标（如响应时间、内存使用）是否保持在正常数值，是否出现波动或持续增长。

稳定性测试是「耐力跑」，看系统在高压下跑久了会不会「体力不支」。

可恢复性测试（Recovery Testing）

  • 是什么：可恢复性测试通过人为制造故障（如断电、网络中断、进程崩溃），来验证系统在灾难发生后重新建立功能并恢复数据的能力。
  • 为什么：确保系统在遭遇意外时，能够快速、有效地恢复服务，将损失降到最低。
  • 怎么做：常采用故障注入（Fault Injection）的方法，强制系统发生故障，然后测量其恢复过程。
  • 核心指标：
    • RTO (Recovery Time Objective)：恢复时间目标，即从灾难发生到业务恢复可接受的最长时间。
    • RPO (Recovery Point Objective)：恢复点目标，即可容忍的从灾难发生点到上一个有效数据备份点之间的数据丢失量。

可恢复性测试是「消防演习」，检验系统在「火灾」发生后能否快速恢复秩序。

备份测试（Backup Testing）

  • 是什么：作为可恢复性测试的重要补充，备份测试专门验证系统备份和恢复数据的能力。
  • 为什么：确保备份数据的完整性和可用性，是灾难恢复的基础。
  • 怎么做：
    1. 执行备份操作，检查备份过程是否成功，对系统性能影响是否在可接受范围内。
    2. 使用备份数据进行恢复操作，验证数据是否能被完整、正确地恢复。

备份测试是检查「救生艇」是否完好可用。

安全性测试

在数据日益重要的今天，安全性是软件的生命线。安全性测试旨在发现软件系统中的安全漏洞和潜在风险。

  • 是什么：安全性测试（Security Testing）是验证软件系统中用于防止和处理危险的安全机制是否有效。它通常从攻击者的视角出发，试图绕过或破坏这些安全机制。
  • 为什么：保护系统和用户数据免受未经授权的访问、使用、泄露、破坏、修改或销毁。
  • 怎么做：
    1. 功能验证：检查用户管理、权限控制、加密、认证等安全功能是否按设计实现。
    2. 漏洞扫描：使用自动化工具扫描已知的漏洞。
    3. 模拟攻击/渗透测试（Penetration Testing）：模拟黑客行为，尝试利用各种技术手段（如 SQL 注入、跨站脚本 XSS）攻击系统，以发现潜在的安全漏洞。
  • 核心理念：安全是相对的。当攻破系统的成本远大于其带来的利益时，非法入侵就失去了意义。
  • 重要参考：OWASP (The Open Web Application Security Project) 每年发布的 Top 10 Web 应用安全风险列表是 Web 安全测试的重要指南。

授权测试（Authorization Testing）

  • 是什么：授权测试是安全性测试的一部分，专门验证用户在通过认证（Authentication）后，其对资源的访问是否严格遵守了被赋予的权限。
  • 认证 vs. 授权：
    • 认证（Authentication）：确认「你是谁？」（例如，通过用户名密码登录）。
    • 授权（Authorization）：确认「你能做什么？」（例如，普通用户只能浏览，管理员可以删除）。
  • 为什么：防止用户越权操作，例如普通用户执行管理员才能进行的操作，或用户 A 查看用户 B 的私密数据。
  • 怎么做：尝试以不同角色的用户身份登录，验证其操作范围是否与权限设定一致。尝试通过修改 URL、请求参数等方式绕过权限管理策略，进行提权攻击。

授权测试是检查「门禁卡」，确保不同级别的卡只能打开对应的门。

用户体验与界面测试

这类测试关注软件是否易于使用、易于理解，并为包括残障人士在内的所有用户提供良好的体验。

可用性测试（Usability Testing）

  • 是什么：可用性测试通过观察真实用户使用产品的过程，来评估软件的易用程度和用户满意度。
  • 为什么：提升用户体验，降低用户学习成本，使用户能够高效、愉快地完成任务。
  • 怎么做：邀请一组有代表性的用户，让他们在典型的场景下完成指定任务，观察者在一旁记录用户遇到的困难、困惑点和操作行为。
  • 评估维度：
    • 易学性（Learnability）：新用户上手有多快？
    • 效率（Efficiency）：熟练用户完成任务有多快？
    • 易记性（Memorability）：用户隔一段时间后，是否还记得如何使用？
    • 错误率（Errors）：用户操作时犯错的频率和严重性？
    • 满意度（Satisfaction）：用户使用过程是否愉快？

可用性测试是「用户体验日」，让真实用户来评判产品好不好用。

可访问性测试（Accessibility Testing, a11y）

  • 是什么：可访问性测试是可用性测试的一个分支，专注于确保产品对于残障人士（如视力、听力、行动不便者）也是可用和无障碍的。
  • 为什么：这不仅是法律法规的要求和人道主义关怀，也能扩大产品的用户群体。一个设计良好的可访问性产品，对所有用户来说通常也更易用。
  • 怎么做：遵循 WCAG (Web Content Accessibility Guidelines) 等标准，测试软件是否支持辅助技术，例如：
    • 屏幕阅读器：能否为视障用户朗读界面内容。
    • 键盘导航：所有功能是否仅通过键盘就能操作。
    • 颜色对比度：文本和背景是否有足够对比度，便于弱视用户阅读。
    • 替代文本：图片是否有描述性文字。

可访问性测试是修建「信息盲道」，确保所有人都能无障碍地使用软件。

人机交互界面测试（User Interface Testing, UI Testing）

  • 是什么：UI 测试或 GUI 测试专注于验证用户界面的视觉元素是否正确、功能是否正常。
  • 为什么：确保用户看到和交互的界面与设计一致，没有显示错误、功能失灵或布局混乱的问题。
  • 怎么做：
    • 视觉检查：验证布局、颜色、字体、图标等是否符合设计规范。
    • 功能交互：测试按钮、菜单、输入框等所有可交互组件的功能是否正常。
    • 自动化测试：由于 GUI 测试的输入空间巨大（用户可以以任意顺序点击任意组件），常采用自动化工具进行回归测试，或使用基于模型的测试（Model-based Testing）来系统地生成测试序列。

UI 测试是检查产品的「颜值」和「五官功能」，确保其外观得体、反应正常。

环境与集成测试

这类测试确保软件能在多样的软硬件环境中正常工作，并与其他系统和谐共存。

兼容性测试（Compatibility Testing）

  • 是什么：兼容性测试用于验证软件在不同的硬件平台、操作系统、浏览器、网络环境以及与其他应用软件共存时能否正常运行。
  • 为什么：当今软件运行环境极其多样化，必须确保软件在主流环境中都能提供一致的功能和体验。
  • 怎么做：在多种目标环境中（如 Windows 10/11, macOS, Chrome/Firefox, 不同版本的 Office）重复执行核心功能测试。
  • 关键概念：
    • 向前兼容（Backward Compatibility）：新版本软件能处理旧版本创建的数据。
    • 向后兼容（Forward Compatibility）：旧版本软件能处理（或至少不破坏）新版本创建的数据。

兼容性测试是「社交能力测试」，看软件能否在不同的「朋友圈」里都表现得体。

配置测试（Configuration Testing）

  • 是什么：配置测试是兼容性测试的一种，特别针对高可配置的软件，验证其在不同配置选项组合下的表现。
  • 为什么：现代软件（如操作系统、数据库）通常有成百上千个配置选项，这些选项的组合可能引发意想不到的错误。穷尽所有组合（2N2^N）是不可能的。
  • 怎么做：由于配置空间巨大，需要采用采样策略来选择有代表性的配置组合进行测试，例如：
    • Each Choice：确保每个配置选项的每个值至少被测试一次。
    • Pair-wise Testing：确保任意两个配置选项的所有值组合至少被测试一次。

配置测试是「排列组合挑战」，在海量的配置选项中找到最可能引发问题的组合。

安装与卸载测试（Installation/Uninstall Testing）

  • 是什么：验证软件的安装、升级和卸载过程是否顺畅、正确、无残留。
  • 为什么：安装是用户与软件的第一次亲密接触，糟糕的安装体验会直接劝退用户。不干净的卸载会给用户的系统留下垃圾，引发问题。
  • 怎么做：
    • 测试首次安装、升级安装、自定义安装等不同安装路径。
    • 测试安装过程中的中断、回滚。
    • 测试卸载后，程序文件、注册表项、配置文件是否被完全清除。

安装/卸载测试是确保软件能「体面地来，干净地走」。

其他重要测试类型

除了上述几大类，还有许多针对特定方面的专项测试，它们同样至关重要。

  • 本地化与国际化测试（Localization/Internationalization Testing）

    • 国际化（i18n）：设计软件使其能够轻松适应不同语言和地区，无需修改代码。
    • 本地化（l10n）：将国际化的软件具体适配到某个特定地区，包括翻译文本、调整日期/货币格式、适应文化习惯等。
    • 测试重点在于验证界面翻译、文本长度变化后的 UI 布局、字符集支持、排序规则等。

  • 容错性测试（Fault Tolerance Testing）

    • 检查软件在异常条件下（如无效输入、硬件故障）的自我防护和恢复能力。它与健壮性测试、恢复性测试密切相关，强调系统在部分组件失效时仍能继续提供服务的能力。

  • 健壮性测试（Robustness Testing）

    • 健壮性包含容错能力和恢复能力。此测试通过构造无效或不合理的输入来引诱软件出错，以检验其处理异常情况的稳健程度。

  • 内存泄漏测试（Memory Leak Testing）

    • 检查程序在使用完动态分配的内存后是否正确释放。对于需要 7x24 小时运行的服务器应用尤其重要，否则可用内存会逐渐耗尽，最终导致系统崩溃。

  • 接口测试（Interface Testing）

    • 测试模块之间、子系统之间以及系统与外部组件之间的接口。验证数据传递的正确性、格式、以及异常处理。这是后端测试的核心部分，比 UI 测试更底层、更稳定。

  • 协议测试（Protocol Testing）

    • 验证软件实现是否遵循了特定的网络协议或通信标准（如 HTTP, TCP/IP）。确保其能与其他遵循相同标准的系统正确通信。

  • 文档测试（Document Testing）

    • 验证用户手册、在线帮助、开发文档等各类文档的正确性、完整性、清晰度和一致性。确保文档与软件实际行为相符。

  • 试玩测试（Playtest）

    • 主要用于游戏开发领域，通过邀请真实玩家来玩游戏的早期版本，以评估其可玩性、趣味性、难度平衡等，并收集反馈用于改进。本质上是游戏领域的可用性测试。