软件测试理论
软件开发
软件的特性
- 可靠性：在指定的条件下使用时（如特定环境、给定时间），软件产品维持规定的性能级别的能力（无故障运行的概率）
-
- 容错性（可靠性的子特性）：在软件发生故障或者违反指定接口的情况下，软件产品维持规定的性能级别的能力
软件开发模型
传统软件开发模型
瀑布模型
线性顺序执行：需求->设计->编码->测试->维护
强调严格的阶段划分
渐进式模型
分块建造
螺旋模型
风险驱动，迭代进行，逐版本完善
敏捷软件开发模型
极限编程（eXtreme Programming, XP）
- 核心：通过高频率的反馈和调整，应对快速变化的需求，强调迭代式、增量式的开发（通常为1-2周）。
- 核心实践
-
- 结对编程：所有生产代码都由两名程序员在一台电脑上共同完成。一人写代码，另一人审查代码。
-
- 测试驱动开发：在编写功能代码之前，先编写失败的自动化测试用例。然后编写代码使测试通过，最后重构代码。
-
- 持续集成：开发人员每天多次将代码集成到主干。每次集成都会触发自动化构建和测试，以便快速发现集成错误。
-
- 重构：持续地改进代码结构，在不改变外部行为的前提下，提高其可读性和可维护性。
-
- 客户现场：理想情况下，客户代表是团队的一部分，随时可以澄清需求并提供反馈。
软件测试过程模型
V模型
- 核心：将开发阶段与测试阶段一一对应，强调测试贯穿于整个软件生命周期，是瀑布模型的变种。
- 特点：在编码之前就进行测试计划和分析
V模型测试级别
单元测试、集成测试、系统测试、验收测试
用户需求 -> 验收测试设计需求分析 -> 系统测试设计概要设计 -> 集成测试设计详细设计 -> 单元测试设计编码单元测试集成测试系统测试
验收测试
W模型
- 核心思想：“双V”模型，强调测试与开发并行，认为测试不仅是阶段，更是一种活动。
H模型
- 核心思想：H模型将测试活动完全独立出来，强调测试准备与执行的分离。
+------------------+ +------------------+| 测试准备活动 | | 测试执行活动 || (Test Preparation)| | (Test Execution) |+------------------+ +------------------+| || |+---------v-----------------------v---------+| 测试流程 || (Test Process) |+---------^-----------------------^---------+| || |+------------------+ +------------------+| 其他开发流程 | | 其他开发流程 || (e.g. Dev, BA) | | (e.g. Dev, BA) |+------------------+ +------------------+|<--- 触发/就绪点 --->| |<--- 触发/就绪点 --->|(Triggers) (Triggers)
X模型
前置测试模型
- 核心思想：将测试活动尽可能地提前到开发周期的早期进行，以尽早发现和预防缺陷。相比W更是一种质量保证策略思想，W是一种具体的测试过程模型
敏捷测试模型
- 核心思想：敏捷测试模型是一个持续循环的闭环，强调整个团队对质量负责。
测试分类/用例设计
透明度
白盒测试
- 核心：设计用例来覆盖代码的不同方面
- 依据：以程序内部的逻辑结构为基础的测试用例设计
方法
控制流测试
语句覆盖
- 每条可执行语句至少被执行一次。缺点：覆盖率最弱
分支/判定覆盖
每个分支/判断取真/假至少各执行一次。由多组合而成的判断，无法保证每个条件都得到验证
条件覆盖
每个条件取真/假至少各执行一次
判定-条件覆盖
既使得每个判断的所有可能结果至少执行一次，又使得每个条件的所有可能取值至少执行一次。
条件组合覆盖
每个判断中所有条件的可能取值组合都至少出现一次
路径覆盖
设计测试用例，覆盖程序中所有可能的执行路径。缺点：对于复杂程序，几乎无法实现100%路径覆盖。
数据流测试
- 是什么？关注的是程序中变量的“定义”（如赋值）和“使用”（如在表达式中引用）之间的关系。它旨在发现诸如“使用了未初始化的变量”或“定义后未使用的变量”这类错误。
- 测试目标： 覆盖变量的“定义-使用”链。例如，测试用例需要保证对于每个变量的定义，都能测试到其后续的所有使用路径。
符号求值
- 是什么？是一种程序分析技术，它不使用具体的输入值来执行程序，而是使用抽象的符号（如 x, y, z）作为输入，并沿着程序路径推导出输出值或路径条件的符号表达式。
- 目标：生成测试用例，发现路径错误
黑盒测试
- 是什么？黑盒法是根据程序的功能来设计测试用例的，高级别阶段测试主要是黑盒测试（集合测试混合）
方法
等价类划分
- 有效等价类
- 无效等价类
边界值分析
错误推测法
判定表
- 核心思想：列出所有条件组合及对应输出结果
- 组成部分：条件桩（所有输入条件）、动作桩（所有可能操作）、条件项（条件组合）、动作项（对应操作）
因果图
- 核心思想：是判定表的前导工具。用逻辑图（与或非）连接需求中的原因（输入条件）和结果（输出）。因果图中的每条路径对应判定表中的一列（即一条规则）。再根据判定表设计测试用例：判定表中的每一列规则都可以设计为一个测试用例。
正交法/正交表法/正交排列法/正交试验法
- 核心思想：利用正交表从大量的、全面的测试组合（如：多因素多水平）中，科学地挑选出数量最少、但最具代表性的测试用例集，覆盖所有因素的俩俩组合。
功能图
由因果图和状态迁移图结合而成。它主要用于测试程序在多种输入条件下的输出，并特别关注程序状态的变化。适用有清晰状态变迁的功能（如工作流）。
状态迁移图
- 核心思想：针对状态转换明确的软件（如工作流、安装向导）。绘制出所有可能的状态以及状态之间的转换路径，然后设计用例覆盖这些路径。
- 示例：MP3播放器（状态：播放、暂停、停止）；设计用例验证从“播放”到“暂停”、从“暂停”到“播放”等所有转换是否正确。
场景法
- 核心思想：基于用户使用场景来设计用例，是业务功能测试的主要方法。
验收阶段
回归测试和模型测试（通常称为“原型测试”或“概念验证测试”）不属于任何单一模型。它们是贯穿整个软件生命周期的测试类型或测试活动。
集成测试
将已经通过单元测试的模块逐步组装起来并进行测试。
非增量式集成
将所有模块一次性全部组装在一起，然后作为一个整体进行测试。
增量式集成（Incremental Integration）
模块是逐步被集成的，每次只增加一个模块到一个已经过测试的子系统上。
1. 自上而下集成（Top-Down Integration）
- 从程序的顶层主控模块开始，沿着软件的控制层次向下逐步集成子模块。
- 在集成过程中，对于那些尚未集成的下层模块，使用桩模块（Stub，一种模拟被调用模块功能的虚拟实体）来替代。
2. 自下而上集成（Bottom-Up Integration）
- 从系统最底层的、不再调用其他模块的原子模块开始集成和测试。
- 在集成过程中，需要编写驱动模块（Driver，一种模拟调用被测模块的上层模块的虚拟实体）来调用和测试底层模块。
3. 混合策略（Sandwich Integration / Hybrid Integration）
- 结合了自上而下和自下而上两种策略的优点。它同时从顶层和底层向中间层集成和测试，最终在中间层汇合。
系统测试
- 系统测试目的是对最终软件系统进行全面的测试确保最终软件系统产品满足需求
- 系统测试使用黑盒技术技术，主要测试被测应用的高级互操作要求，而无需考虑被测应用的内部结构。
验收测试-阿尔法测试（Alpha Testing） & 贝塔测试（Beta Testing）
它们是软件正式发布前的最后两道关键测试环节，目的都是为了从最终用户的角度验证软件的可用性、功能和性能，但执行的环境和参与者截然不同。
| 特性 | alpha | beta |
|---|---|---|
| 测试地点 | 开发环境 | 用户环境 |
| 测试人员 | 内部员工 | 潜在用户 |
| 测试阶段 | beta前 | alpha后发布前 |
| 主要目的 | 发现重大缺陷、验证功能是否完整 | 获取用户反馈、测试兼容性和可用性、发现特定环境下bug |
| 可控性 | 高 | 低 |
| 保密性 | 高 | 低 |
自动化测试
- 自动化测试（快速回归缺陷）和手工测试发现缺陷的类型不同，而不是数量上谁多谁少。
- 显著提高测试覆盖率
- QTP（QuickTest Professional，现在称为UFT - Unified Functional Testing）是一款传统的功能自动化测试工具。它默认/最主要使用的脚本语言是 VBScript (VBS)。
性能测试
- 目标：①发现性能缺陷；②性能调优；③能力检验和规划
- 在性能下降曲线上，最大建议用户数通常处于平坦区和性能轻微下降区的交界处
方法
负载测试
目的是为了探测软件在满足预定性能需求/特定负载下的性能
压力测试
证系统最高能达到什么程度（极限负载），目的是利用压力来揭示软件中存在的潜在缺陷
并发测试
疲劳强度/耐久性测试
- 评估软件系统在连续长时间、高负载（非极限）运行下的稳定性和可靠性。
- 问题：内存泄露、资源耗尽、性能衰减、系统稳定性、日志与文件管理
- 执行：测试环境准备、测试脚本编写、配置负载、监控取证、结果分析
测试主流程概念
软件质量
- 软件质量特性是指软件的功能性，可靠性，易用性，效率，可维护性，可移植性。
软件质量管理（QM）
质量保证（QA）
过程向导，制定标准、流程、评审、培训
质量控制（QC）
产品导向，测试、跟踪、监督
软件测试的目的：发现并预防缺陷，提供信心和信息
同行评审
- 管理评审：关注项目进度、资源分配、成本等管理层面的评审。
- 技术评审：关注技术方案、架构、代码等技术层面的评审。
- 文档评审：关注需求文档、设计文档等文档质量的评审。
- 过程评审：关注开发过程是否符合规范，例如流程执行情况、标准遵循等。
代码走查
代码走查（Code Walkthrough）是一种非正式的同行评审技术，目的是通过集体讨论来检查代码，发现缺陷、遗漏和矛盾的地方。其目标包括：
- 发现异常：找出代码中的错误、潜在问题或异常行为。
- 改进产品：通过反馈优化代码质量、可读性和可维护性。
- 考虑替代方案：讨论是否有更好的实现方式或设计模式。
- 评估对标准和规格的符合：检查代码是否遵循编码规范、设计要求和功能规格。
软件测试进入准则
开始测试前必须满足的条件，以确保测试的有效性和效率
软件需求
为解决待定问题而由被开发或被修改的软件所展示出的特性。基本特性是可验证性
测试用例
测试用例的期望结果必须预先定义，不能依赖执行获得。
缺陷
- 软件实现了产品规格说明没有提到的功能， 属于缺陷（未在规格说明中定义，可能多余或错误）。
测试出口准则
项目启动活动（Project Initiation）是项目管理的第一个阶段，其主要目的是明确项目愿景、目标、范围和关键干系人，确保所有参与者对项目有一致理解。项目启动活动聚焦于阐明项目目标、获得授权、识别干系人及初步范围