期末复习大纲

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

1. 简答题

1.1 什么是软件测试？

是为了发现错误而执行程序或系统的过程。通过在预设条件下运行软件，检验其是否满足规定需求，并找出预期结果与实际结果之间的差异。

1.2 软件测试具有哪些特性？

  1. 破坏性：试图「破坏」软件以发现缺陷。
  2. 不彻底性：无法进行穷尽测试。
  3. 周期性：测试-修改-回归测试的循环。
  4. 并行性：应与开发活动同步进行。
  5. 依赖性：策略依赖于软件的应用背景。

1.3 软件测试的对象包括哪些方面？

不仅是源程序，还包括软件开发全过程产生的所有文档（如需求规格说明书、设计文档）和数据。

1.4 软件测试的目标是什么？

核心目标是发现尽可能多的缺陷，度量和提高软件质量，确保软件满足用户明确或隐含的需求。

1.5 写出你认为软件测试应该遵循的最重要的几条原则。

  1. 尽早并持续测试。
  2. 测试只能证明缺陷存在，不能证明不存在。
  3. 不可能穷尽测试。
  4. 缺陷集群效应（二八定律）。
  5. 杀虫剂悖论（定期更新用例）。

1.6 软件测试方法可以分为哪几类方法？

  1. 按是否执行代码：静态测试、动态测试。
  2. 按代码可见性：白盒测试、黑盒测试、灰盒测试。
  3. 按测试阶段：单元测试、集成测试、系统测试、验收测试。

1.7 简单描述软件测试的信息流模型，指出在该模型中最关键的因素是什么？

  • 模型：输入（软件配置、测试配置、工具）→\to 测试执行 →\to 分析与排错 →\to 输出（测试结果/报告）。
  • 最关键因素：测试用例的设计（因为无法穷尽，必须设计高效用例）。

1.8 软件开发有哪些模型，软件测试分别处于什么位置？

  1. 瀑布模型：测试是编码之后的独立阶段（易导致问题发现晚）。
  2. V 模型：测试与开发各阶段一一对应（左开发，右测试）。
  3. W 模型/敏捷：测试与开发并行，贯穿全生命周期。

1.9 软件测试过程有哪些模型？这些模型各有什么特点？

  1. V 模型：强调测试阶段与开发阶段的对应关系。
  2. W 模型：强调测试与开发并行，尽早介入（双 V 模型）。
  3. X 模型：适用于探索性、迭代式的测试。

1.10 作为一种职业，你认为软件测试员应该具备哪些专业基础？

  1. 批判性思维（怀疑精神）。
  2. 专业技能（测试用例设计、故障诊断）。
  3. 工具掌握（自动化、管理工具）。
  4. 领域知识（理解业务）。
  5. 沟通能力。

1.11 在软件测试领域，最根本（关键）的问题在哪里？

资源有限与测试无穷之间的矛盾。即如何从无限的输入和路径中，设计出有限且高效的测试用例集，以尽可能多地发现缺陷。

1.11 软件测试工具大致可以分为几种？

  1. 测试管理工具（如 TestDirector）。
  2. 功能自动化工具（如 Selenium）。
  3. 性能测试工具（如 LoadRunner）。
  4. 白盒/单元测试工具（如 xUnit）。
  5. 静态分析工具。

1.12 软件测试管理具有什么作用？

对测试全过程进行计划、组织、控制和监督。

  • 时间维：管理测试流程进度。
  • 空间维：管理文档、缺陷和配置。
  • 人员维：管理团队协作。

1.13 简述软件测试发展的六个发展阶段。

  1. 调试导向（50s）：测调不分。
  2. 演示导向（60s）：证明软件正确。
  3. 破坏导向（70s）：为了发现错误。
  4. 评估导向（80s）：度量软件质量。
  5. 预防导向（90s）：尽早介入预防缺陷。
  6. 专业化/自动化导向（2000s+）：标准化、工具化、智能化。

1.14 缺陷管理具体包括哪些功能？

缺陷的预防、发现、记录（报告）、分类、跟踪、处理（修复）及统计分析。

1.15 什么是软件？

软件 = 程序 + 数据 + 相关文档。

1.16 什么是软件质量？

软件产品满足用户明确或隐含需求的程度。包括静态质量（代码/文档结构）和动态质量（正确性、可靠性、易用性等）。

1.17 什么是软件缺陷？

软件中存在的不符合用户需求、产品规格或预期的任何问题。包括：功能缺失、功能错误、隐性需求未满足、功能冗余、体验不佳。

1.18 软件测试发展的未来趋势是什么？

自动化、智能化（AI 测试）、云测试（TaaS）、全流程化（DevOps 整合）。

1.19 软件测试有哪些停止准则？

  1. 时间截止：到达预定日期。
  2. 用例执行：全部用例执行完毕。
  3. 覆盖率：达到预定代码/功能覆盖率。
  4. 缺陷指标：发现的缺陷数达标或单位时间发现率低于阈值。

1.20 解释软件的故障模型 PIE。

缺陷被观测到需经历三个步骤：

  1. 执行（Execution）：包含缺陷（Fault）的代码被运行。
  2. 感染（Infection）：执行导致程序产生错误的内部状态（Error）。
  3. 传播（Propagation）：错误状态传播到输出，形成可见故障（Failure）。

2. 名词解释

2.1 名词解释

  1. 黑盒测试：将软件视为不透明黑盒，不关心内部实现，只依据需求规格说明书验证外部功能。
  2. 白盒测试：将软件视为透明盒子，依据内部代码逻辑结构和实现来设计测试用例。
  3. 静态测试：不运行被测软件，通过人工或工具分析检查代码、文档。
  4. 动态测试：运行被测软件，通过输入数据并观察输出结果来进行测试。
  5. 文档审查：静态黑盒测试，检查需求、设计等文档的正确性与完整性。
  6. 同行评审：非正式评审，开发者之间互查代码（「好友评审」）。
  7. 桌面评审：由单人对照错误列表，在头脑中推演数据的代码检查（「一个人的走查」）。
  8. 代码走查：较正式，由代码作者向评审小组逐行讲解代码逻辑。
  9. 代码审查：最正式，代码作者不参与讲解，由评审小组依据清单系统性审查。
  10. 语句覆盖：最弱覆盖，程序中每个可执行语句至少执行一次。
  11. 判定覆盖：每个判定的真、假分支至少各执行一次。
  12. 条件覆盖：每个判定中的每个原子条件都至少取一次真值和假值。
  13. 判定/条件覆盖：同时满足判定覆盖和条件覆盖的要求。
  14. 条件组合覆盖：每个判定中所有原子条件的可能取值组合都至少执行一次。
  15. 修改决策条件覆盖（MC/DC）：每个原子条件都能独立影响判定的最终结果（高安全标准）。
  16. 路径覆盖：最强覆盖，覆盖程序中所有可能的执行路径。
  17. LCSAJ 覆盖：覆盖所有线性代码序列及其跳转（Linear Code Sequence And Jump）。
  18. 数据流测试：覆盖变量从定义点（Def）到使用点（Use）的路径。
  19. 等价类划分：将输入分为有效和无效等价类，假设类中数据等效，从中选取代表值测试。
  20. 边界值分析：选取正好等于、刚大于、刚小于边界的值进行测试（是等价类的补充）。
  21. 因果图与决策表：分析输入条件的组合逻辑关系（因）及其对应的输出（果）。
  22. 错误猜测：基于经验和直觉，推测可能存在的缺陷（如空值、0、特殊字符）。
  23. 状态转换测试：针对有状态记忆的系统，测试状态变迁的有效性和完整性。
  24. 语法测试：验证系统对合法/非法输入格式（语法）的处理能力。

2.2 名词术语分类填表

- 1 黑盒测试 2 白盒测试
3 静态测试 5 (文档审查) 6, 7, 8, 9 (各类评审/检查)
4 动态测试 19, 20, 21, 22, 23, 24 (黑盒技术) 10, 11, 12, 13, 14, 15, 16, 17, 18 (白盒覆盖技术)

2.3 白盒动态测试技术强弱关系

白盒测试覆盖标准由弱到强的层级关系为：路径覆盖 > 条件组合覆盖 > MC/DC > 判定/条件覆盖 > (判定覆盖, 条件覆盖) > 语句覆盖。

2.4 黑盒与白盒综合测试策略

核心策略：采用「灰盒」思维，分阶段结合使用。

  1. 阶段划分：

    • 单元/集成测试阶段：以白盒测试为主。先进行静态代码评审，再进行动态逻辑覆盖测试，确保代码结构健壮。
    • 系统/验收测试阶段：以黑盒测试为主。依据需求验证业务功能，确保满足用户需求。

  2. 具体方法组合：

    • 白盒层面：优先保证语句覆盖和判定覆盖，关键模块追求 MC/DC 或路径覆盖。
    • 黑盒层面：
      • 必选：先用等价类划分和边界值分析覆盖主要功能。
      • 组合：输入条件复杂时，使用因果图与决策表。
      • 特定：有状态交互用状态转换测试；格式严格用语法测试。
      • 补充：最后用错误猜测法补充测试遗漏。

3. 简述软件开发过程中测试方法的特点

3.1 单元测试（Unit Testing）

  • 对象：软件设计的最小单位（函数、类、模块）。
  • 依据：详细设计说明书。
  • 特点：白盒测试为主，由开发人员编写。
  • 目的：验证代码是否符合详细设计，尽早发现逻辑与数据结构错误。

3.2 集成测试（Integration Testing）

  • 对象：模块间的接口与交互。
  • 依据：概要设计说明书。
  • 特点：灰盒测试（结合白盒与黑盒），分渐增式（自顶向下/自底向上）和非渐增式（大爆炸）。
  • 目的：验证模块组装后的接口一致性及协同工作能力。

3.3 系统测试（System Testing）

  • 对象：完整的软件系统（含硬件、网络等）。
  • 依据：需求规格说明书。
  • 特点：黑盒测试，模拟真实运行环境。
  • 目的：验证系统是否满足功能及非功能（性能、安全等）需求。

3.4 验收测试（Acceptance Testing）

  • 对象：最终产品。
  • 依据：用户需求和合同。
  • 特点：以用户为主导，是交付前的最后一道关卡。
  • 目的：验证软件的有效性，确认产品是否满足用户的真实业务需求。

3.5 冒烟测试（Smoke Testing）

  • 定义：对新构建版本进行的快速、宽泛的测试。
  • 特点：浅而广，通常自动化，时间短。
  • 目的：确认核心功能正常，判断版本是否值得进行后续深入测试（版本准入）。

3.6 回归测试（Regression Testing）

  • 定义：修改代码后重新运行测试。
  • 特点：伴随整个维护期，自动化程度高。
  • 目的：防止代码修改（修复 Bug 或新功能）引入新的错误或破坏原有功能。

3.7 α 测试（α Testing）

  • 环境：受控的开发环境。
  • 人员：内部用户或专业测试人员（非开发者）。
  • 目的：在开发者在场的情况下，模拟用户操作，发现早期功能和体验问题。

3.8 β 测试（β Testing）

  • 环境：不受控的真实用户环境。
  • 人员：外部最终用户。
  • 目的：产品发布前的「公测」，收集真实场景下的兼容性、错误和反馈。

4. 简述以下软件特性或方面的测试特点

what(定义), why(目的), how(方法), …

4.1 负载测试（Load Testing）

  • What：在预期的最大负载下测试系统。
  • Why：验证系统在正常高负荷下是否还能承受。
  • How：模拟大量并发用户，逐步增加压力至预定阈值。

4.2 压力测试（Stress Testing）

  • What：在超出正常负载条件下测试系统。
  • Why：寻找系统的崩溃点（瓶颈）及恢复能力。
  • How：不断加压直到系统崩溃，观察失效行为。

4.3 性能测试（Performance Testing）

  • What：测试系统的响应时间、吞吐量等指标。
  • Why：评估系统运行效率，确保满足性能指标。
  • How：使用工具（如 JMeter）监控资源利用率和响应速度。

4.4 可靠性测试（Reliability Testing）

  • What：在规定时间内无故障运行的能力。
  • Why：评估系统的成熟度和平均无故障时间（MTBF）。
  • How：长时间连续运行，记录故障频率。

4.5 容量测试（Volume Testing）

  • What：测试系统处理海量数据的能力。
  • Why：确保数据库或文件系统在大数据量下不瘫痪。
  • How：构造超大规模数据库或文件进行增删改查。

4.6 安全性测试（Security Testing）

  • What：验证系统防御非法入侵和保护数据的能力。
  • Why：防止数据泄露、未授权访问。
  • How：SQL 注入、渗透测试、漏洞扫描。

4.7 安装测试（Installation Testing）

  • What：验证软件安装、升级、卸载的过程。
  • Why：确保用户能顺利部署软件。
  • How：在不同 OS、硬件环境下执行完整安装向导。

4.8 可用性测试（Usability Testing）

  • What：测试界面的易用性、友好性。
  • Why：提升用户体验（UX），降低学习成本。
  • How：邀请用户试用，观察其操作流畅度及困惑点。

4.9 稳定性测试（Stability Testing）

  • What：在特定负载下长时间运行的情况。
  • Why：发现内存泄漏或累积性错误。
  • How：7x24 小时持续运行业务脚本。

4.10 本地化和国际化测试（L10N & I18N Testing）

  • What：适应不同语言、地区格式（时间、货币）。
  • Why：确保软件适应全球市场。
  • How：切换 OS 语言，检查翻译准确性和界面布局。

4.11 可访问性测试（Accessibility Testing）

  • What：测试软件是否方便残障人士使用。
  • Why：法律合规，关怀特殊群体。
  • How：使用读屏软件，检查键盘导航支持。

4.12 授权测试（Authorization Testing）

  • What：验证用户权限分配的正确性。
  • Why：防止低权限用户访问高敏数据。
  • How：使用不同角色（管理员/普通用户）登录并尝试越权操作。

4.13 容错性测试（Fault Tolerance Testing）

  • What：系统在出现局部故障时维持运行的能力。
  • Why：确保系统足够健壮，不会因小错崩盘。
  • How：人为注入错误（如断网、断电），观察系统反应。

4.14 一致性测试（Conformance Testing）

  • What：验证软件是否符合特定行业标准或协议。
  • Why：确保合规性。
  • How：对照标准文档（如 IEEE、ISO）逐项检查。

4.15 配置测试（Configuration Testing）

  • What：在不同硬件组合和软件设置下测试。
  • Why：验证软件在各种环境下的适应性。
  • How：利用配置矩阵，覆盖不同驱动、分辨率、OS 补丁。

4.16 文档测试（Document Testing）

  • What：核对用户手册、帮助文档。
  • Why：确保文档描述与软件实际行为一致。
  • How：边看文档边操作软件，纠正描述错误。

4.17 兼容性测试（Compatibility Testing）

  • What：测试与其他软件、浏览器、OS 的共存能力。
  • Why：保证软件不与主流环境冲突。
  • How：跨浏览器测试、跨版本 OS 测试。

4.18 试玩（Playtest）

多用于游戏

  • What：主观感受测试。
  • Why：评估趣味性、平衡性和可玩性。
  • How：邀请玩家自由体验并收集反馈。

4.19 可恢复性测试（Recovery Testing）

  • What：系统崩溃后恢复数据和状态的能力。
  • Why：减少灾难发生时的损失。
  • How：强制断电或 Kill 进程，检查重启后数据完整性。

4.20 卸载测试（Uninstall Testing）

  • What：验证软件能否被彻底移除。
  • Why：防止垃圾文件残留影响系统。
  • How：执行卸载，检查注册表和文件目录是否有残留。

4.21 能力测试（Facility Testing）

  • What：验证软件是否具备了需求要求的所有功能设施。
  • Why：确保「该有的都有」。
  • How：对照需求清单遍历所有功能点。

4.22 健壮性测试（Robustness Testing）

  • What：系统处理无效输入或异常环境的能力。
  • Why：确保系统不会因非法操作而崩溃。
  • How：输入乱码、空值、超长字符串（Fuzzing）。

4.23 穿越测试（By-pass Testing）

  • What：尝试跳过正常流程步骤进行操作。
  • Why：防止逻辑漏洞（如跳过支付直接下载）。
  • How：直接访问后续页面的 URL，或禁用前端验证。

4.24 在线帮助测试（Online Help Testing）

  • What：检查内置帮助系统的准确性。
  • Why：确保用户遇到困难能得到正确指引。
  • How：F1 键检查、上下文敏感帮助链接检查。

4.25 数据转换测试（Data Conversion Testing）

  • What：旧系统数据迁移到新系统的正确性。
  • Why：确保升级后历史数据不丢失、不错乱。
  • How：迁移数据后，对比新旧数据库字段值。

4.26 备份测试（Backup Testing）

  • What：验证数据备份和还原功能。
  • Why：灾备基础。
  • How：执行备份 →\to 破坏数据 →\to 执行还原 →\to 验证数据。

4.27 接口测试（Interface Testing）

  • What：测试系统组件间或外部系统间的数据传输。
  • Why：确保数据交换逻辑正确。
  • How：使用工具（Postman）发送 API 请求并校验响应。

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

  • What：测试 GUI 的美观、布局和逻辑。
  • Why：确保界面符合设计规范。
  • How：视觉检查字体、颜色、对齐方式及控件状态。

4.29 余量测试（Remainder Testing）

  • What：针对资源临界点或逻辑边界的剩余量测试。
  • Why：处理「磁盘已满」「内存将尽」等极端情况。
  • How：填充磁盘直到只剩极小空间，观察软件行为。

4.30 协议测试（Protocol Testing）

  • What：验证通信协议（HTTP, TCP 等）的实现。
  • Why：确保通信符合标准，无数据包错误。
  • How：使用抓包工具（Wireshark）分析数据包结构。

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

  • What：检查程序运行后是否未释放内存。
  • Why：防止程序运行时间越长越卡顿甚至 Crash。
  • How：使用工具监控内存曲线，查找只增不减的对象。

4.32 存储测试（Storage Testing）

  • What：测试数据存储的极限和完整性。
  • Why：防止数据丢失或存储失败。
  • How：模拟 SD 卡拔出、磁盘写满、并发写入。

4.33 软件老化（Software Aging）

  • What：评估软件长时间运行后的性能衰退。
  • Why：预测系统寿命和维护周期。
  • How：长期监测资源消耗趋势，分析性能下降曲线。

4.34 不稳定性测试（Flaky Testing）

  • What：识别那些结果时对时错的测试用例。
  • Why：消除测试噪音，提高自动化信任度。
  • How：对同一版本代码重复运行多次测试，统计结果波动。

5. 简答题

核心检测能力是什么？或者说特点是什么？

5.1 组合测试（Combinatorial Testing）

  • 核心能力：检测由多参数相互作用（Interaction）引发的故障。
  • 特点：使用最少的测试用例覆盖参数间的所有组合（如两两组合覆盖）。

5.2 蜕变测试（Metamorphic Testing）

  • 核心能力：解决无测试预言（Oracle）问题（即不知道正确结果是什么）。
  • 特点：验证输入变化后，输出是否符合预期的蜕变关系。

5.3 基于规格说明的软件测试（Specification Based Software Testing）

  • 核心能力：验证软件是否满足功能需求。
  • 特点：黑盒测试，不看代码，仅依据需求文档设计用例。

5.4 基于模型的软件测试（Model Based Testing）

  • 核心能力：实现测试用例的自动化生成。
  • 特点：依据软件的行为模型（而非代码）自动推导测试用例。

5.5 基于错误的软件测试（Fault Based Testing）

  • 核心能力：检测特定类型的预估故障。
  • 特点：基于「错误猜测」或历史数据，针对性地设计用例去揭露潜在错误。

5.6 基于搜索的软件测试（Search Based Testing）

  • 核心能力：自动化生成满足特定目标（如覆盖率）的数据。
  • 特点：将测试生成转化为优化问题，使用元启发式算法（如遗传算法）求解。

5.7 统计测试（Statistics Testing）

  • 核心能力：评估软件的可靠性（Reliability）。
  • 特点：依据统计学原理进行抽样测试，估算故障率。

5.8 基于操作剖面的测试（Operational Profile Based Testing）

  • 核心能力：确保高频使用场景的可靠性。
  • 特点：依据用户实际使用的概率分布来分配测试资源。

5.9 变异测试（Mutation Testing）

  • 核心能力：评估测试用例集的质量（而非测软件本身）。
  • 特点：在代码中人工注入微小错误（变异体），看测试用例能否发现（杀死）它们。

5.10 脆弱性测试（Flaky Testing）

  • 核心能力：识别非确定性（Non-deterministic）故障。
  • 特点：找出那些在相同代码和环境下，结果忽通过忽失败的不稳定测试。

5.11 基于性质的软件测试方法（Property-Based Testing）

  • 核心能力：验证代码是否满足数学性质或不变量。
  • 特点：自动生成大量随机数据，检查是否违背定义的规则（如 reverse(reverse(list)) == list）。

5.12 极限测试（Extreme Testing）

  • 核心能力：适应需求快速变化，确保代码持续可用。
  • 特点：强调测试驱动开发（TDD），先写测试后写代码，全自动化单元测试。

5.13 模糊测试（Fuzzing Testing）

  • 核心能力：挖掘安全漏洞和崩溃（Crash）。
  • 特点：向目标发送大量随机、畸形或非预期的数据。

5.14 软件测试的控制论方法（Cybernetics Based） - 自适应测试

  • 核心能力：动态调整测试策略以提高效率。
  • 特点：引入反馈机制，根据前一次测试结果自动调整下一次测试的选择。

5.15 导向性随机测试（Concolic Testing）

  • 核心能力：提高路径覆盖率，深入复杂逻辑。
  • 特点：结合具体执行（Concrete）和符号执行（Symbolic）来求解路径约束。

5.16 图形用户界面测试（GUI Testing）

  • 核心能力：验证用户交互层的功能和易用性。
  • 特点：模拟用户对图形界面的操作（点击、输入），而非底层代码调用。

5.17 随机测试（Random Testing）

  • 核心能力：快速、低成本地发现基础错误。
  • 特点：输入数据从输入域中独立随机选取，无预设逻辑。

5.18 自适应随机测试（Adaptive Random Testing）

  • 核心能力：比纯随机测试更高效地发现错误。
  • 特点：确保测试用例在输入域中均匀分布（更分散），避免聚集。

5.19 反随机测试（Antirandom Testing）

  • 核心能力：最大化测试覆盖范围。
  • 特点：每次生成的测试用例都尽可能与之前的用例距离最远（汉明距离/笛卡尔距离）。

5.20 结对测试（Pair Testing）

  • 核心能力：兼顾覆盖率与效率（组合测试的一种）。
  • 特点：保证所有参数的两两组合至少出现一次。

5.21 在线测试（Online Testing）

  • 核心能力：监控生产环境下的实时状态。
  • 特点：系统运行时进行的非中断测试，通常用于被动监测异常。

5.22 探索性测试（Exploratory Testing）

  • 核心能力：发挥人的主观能动性和直觉。
  • 特点：测试设计与执行同时进行，强调测试人员的学习和即兴创造。

5.23 反模型测试（Anti-model Testing）

  • 核心能力：发现模型假设之外的错误。
  • 特点：专门寻找违背或挑战现有模型假设的行为路径。

5.24 成分测试（Compositional Testing）

  • 核心能力：验证组件集成后的正确性。
  • 特点：假设各组件已知正确，重点测试组件间的交互和接口。

5.25 有限状态机测试（FSM Testing）

  • 核心能力：验证状态转换逻辑的正确性。
  • 特点：基于 FSM 模型，检查状态、事件和转换是否符合预期。

5.26 基于 Petri 网的测试（Petri Net based Testing）

  • 核心能力：检测并发、异步和分布式系统的死锁或冲突。
  • 特点：利用 Petri 网模型描述系统的动态行为和资源流转。

5.27 基于模型检查的测试（Model Checking based Testing）

  • 核心能力：穷尽验证系统属性，证明无错。
  • 特点：遍历系统模型的所有可能状态，数学上证明是否满足规范。

5.28 TTCN 测试（TTCN Testing）

  • 核心能力：专用于通信协议和接口测试。
  • 特点：使用标准化的测试描述语言（TTCN-3）进行黑盒协议测试。

5.29 布尔规格测试（Boolean Specification Testing）

  • 核心能力：检测复杂的逻辑条件错误。
  • 特点：针对规格中的布尔表达式（与/或/非）和因果图进行分析测试。

5.30 基于统一建模语言测试（UML Based Testing）

  • 核心能力：弥合设计与测试的鸿沟。
  • 特点：直接从 UML 图（如类图、序列图、状态图）生成测试用例。

5.31 差分测试（Differential Testing）

  • 核心能力：发现实现差异或回归错误。
  • 特点：将同一输入给到两个不同的实现版本，比较输出是否一致。

5.32 故障注入测试（Fault Injection Testing）

  • 核心能力：验证系统的健壮性（Robustness）和容错能力。
  • 特点：故意在系统中引入错误（如断网、内存溢出），观察系统是否能恢复或安全降级。

6. 简单分析评论题

软件的特点是什么？测试方法有哪些特殊性？

6.1 面向对象软件的测试（Object Oriented）

  • 软件特点：封装性、继承性、多态性。
  • 测试特殊性：
    1. 单元层次变大：最小可测单元由「函数」变为「类」。
    2. 状态依赖：需考虑对象内部状态对方法行为的影响。
    3. 继承与多态：需测试父类与子类的交互及动态绑定带来的不确定性。

6.2 面向方面的软件测试（Aspect Oriented）

  • 软件特点：关注点分离（核心业务与横切关注点分离），通过「织入」机制结合。
  • 测试特殊性：
    1. 织入测试：重点测试 Aspect 代码织入核心代码后的行为正确性。
    2. 副作用检测：验证 Aspect 是否干扰了原有核心业务逻辑。

6.3 面向服务的软件测试（SOA）

  • 软件特点：松耦合、分布性、基于标准接口（如 Web Service）。
  • 测试特殊性：
    1. 黑盒为主：通常无源代码，依赖接口契约进行测试。
    2. 动态绑定：需验证服务在运行时的动态发现与绑定能力。
    3. 可靠性：重点关注跨网络的传输延迟与容错能力。

6.4 构件软件测试（Component Based）

  • 软件特点：可复用、即插即用、组装式开发。
  • 测试特殊性：
    1. 分级测试：分为「构件开发方测试」（验证功能）和「构件复用方测试」（验证集成）。
    2. 胶水代码：重点测试连接各构件的「胶水代码」及接口兼容性。

6.5 Web 应用软件测试（WEB Testing）

  • 软件特点：异构性、高并发、分布性、以内容为驱动。
  • 测试特殊性：
    1. 兼容性：需覆盖不同浏览器、操作系统和分辨率。
    2. 性能测试：重点关注高并发下的响应速度与服务器压力。
    3. 安全性：SQL 注入、XSS 跨站脚本等 Web 特有漏洞扫描。

6.6 普适计算环境下的软件测试（Pervasive Computing）

  • 软件特点：随时随地、上下文感知、资源受限。
  • 测试特殊性：
    1. 上下文测试：验证软件随环境变化（位置、光照等）的适应能力。
    2. 资源约束：严格测试电量消耗、网络断连及内存占用。

6.7 云测试（Cloud Testing）

  • 软件特点：虚拟化、多租户、弹性伸缩、按需服务。
  • 测试特殊性：
    1. 多租户隔离：验证不同用户间的数据与配置是否严格隔离。
    2. 弹性伸缩：测试系统在负载突增时自动扩展资源的能力。

6.8 物联网环境下的软件测试（IoT）

  • 软件特点：软硬结合、海量连接、异构协议、实时性。
  • 测试特殊性：
    1. 协议一致性：测试不同设备间通信协议（Zigbee, MQTT 等）的兼容性。
    2. 网络不稳：模拟弱网、丢包环境下的数据同步与容错。

6.9 并行软件测试（Concurrent Software）

  • 软件特点：多线程/进程同时执行、资源共享、非确定性。
  • 测试特殊性：
    1. 故障难重现：错误往往具有随机性，难以捕捉。
    2. 同步互斥：重点检测死锁（Deadlock）、竞态条件（Race Condition）和活锁。

6.10 嵌入式软件测试（Embedded）

  • 软件特点：专用硬件、实时性强、资源（内存/CPU）极度受限。
  • 测试特殊性：
    1. 交叉测试：需在宿主机开发，在目标机运行，环境不一致。
    2. 实时响应：必须严格验证中断处理与任务调度的时间确定性。

6.11 高可信软件测试（High Confidence）

  • 软件特点：高可靠性、高安全性、对故障零容忍（如航空航天）。
  • 测试特殊性：
    1. 形式化验证：引入数学方法证明程序的正确性。
    2. 全覆盖：要求极高的代码覆盖率（如 MC/DC 覆盖）及大规模故障注入测试。

6.12 网构软件测试（Internetware）

  • 软件特点：开放性、动态演化、自主适应。
  • 测试特殊性：
    1. 在线测试：软件在运行过程中会变化，需进行运行时监控与测试。
    2. 演化测试：验证软件自我调整后的功能是否符合预期。

6.13 移动应用软件测试（App Testing）

  • 软件特点：设备碎片化、网络切换频繁、触控交互。
  • 测试特殊性：
    1. 专项测试：耗电量、流量、安装/卸载/升级测试。
    2. 中断测试：测试运行中被电话、短信、低电量弹窗打断后的恢复能力。

6.14 人工智能软件测试（AI Testing）

  • 软件特点：数据驱动、结果具有概率性（非绝对）、逻辑不可解释（黑盒）。
  • 测试特殊性：
    1. 蜕变测试：解决缺乏「测试预言」（标准答案）的问题。
    2. 鲁棒性：重点测试对抗样本攻击（微小扰动导致识别错误）。

6.15 区块链软件系统测试（Blockchain）

  • 软件特点：去中心化、不可篡改、共识机制、智能合约。
  • 测试特殊性：
    1. 智能合约：代码一旦部署无法修改，需进行极严格的逻辑与溢出漏洞审计。
    2. 共识攻击：模拟 51% 攻击、双花攻击等特有安全威胁。

6.16 元宇宙测试（Metaverse）

  • 软件特点：沉浸式体验、实时渲染、虚实交互、超大规模。
  • 测试特殊性：
    1. 用户体验（QoE）：重点测试晕动症、延迟感及沉浸感。
    2. 互操作性：验证虚拟资产在不同虚拟世界间的流转与兼容。