文章目录
- 一、软件测试的定义
- 标准定义
- Bug和缺陷
- 二、软件测试与软件质量保证
- 三、软件测试七大基本原则
- 四、软件测试分类
- 按测试手段
- 按测试执行方式
- 按测试阶段或层次
- 按测试对象
- 五、软件测试过程模型
- V模型
- W模型
- H模型
- X模型
一、软件测试的定义
| 正向观点 | 逆向观点 |
|---|---|
| 验证软件是否能正常工作 | 证明程序有错 |
标准定义
使用人工或自动手段，来运行或测试某个系统的过程。其目的在于验证它是否满足规定的需求或弄清预期结果与实际结果之间的差别。软件测试以是否满足需求为目标。
Bug和缺陷
bug是软件（包括程序和文档）中不符合用户需求的问题。
bug类型包括：
- 完全没有实现的功能
- 功能或性能上的问题或差异
- 多余的功能
二、软件测试与软件质量保证
软件质量保证（SQA） 是为确保软件开发过程和结果符合预期要求而建立的一系列规程，以及依照规程和计划采取的一系列活动及其结果评价。
| SQA | 软件测试 |
|---|---|
| SQA指导、监督软件测试的计划和执行 | 测试是SQA的重要手段之一。为SQA提供质量评价所需的数据 |
| SQA是一项管理工作 | 测试是一项技术性工作 |
| SQA是在预防问题 | 测试是在发现问题 |
| SQA侧重对流程的评审和监控 | 测试侧重对产品进行评估和验证 |
三、软件测试七大基本原则
- 不可能执行穷尽测试
- Zero bug和Good Enough
- 测试应尽早启动，尽早介入
- 测试应追溯需求
- 缺陷存在集群现象（二八原则）
- 缺陷具有免疫性（杀虫剂悖论）——使用交叉测试
- 测试只能证明软件存在错误而不能证明软件没有错误，测试是无法显示潜在的错误和缺陷
四、软件测试分类
按测试手段
- 白盒测试（逆向观点-证明程序有错）
接口测试也是一种白盒测试。 - 黑盒测试（正向观点-软件是否正常工作）
- 功能测试：逻辑功能、界面测试、易用性测试、安装测试、兼容性测试
- 性能测试：一般性测试、稳定性测试、负载测试、压力测试
按测试执行方式
- 静态测试：不实际运行被测软件，只是静态地检查程序代码、界面或文档中可能存在的错误
- 动态测试：通过观察代码运行过程，来获取系统信息，对系统进行验证。
| - | 黑盒 | 白盒 |
|---|---|---|
| 静态 | 不运行程序，只查看界面 | 不运行程序，静态查看代码 |
| 动态 | 运行程序，只看输入输出 | 运行程序，分析代码结构 |
按测试阶段或层次
- 单元测试：采用白盒测试的手段，针对模块或组件进行测试，和编码同步进行。
- 集成测试：白盒测试和黑盒测试相结合。将模块按设计要求组装起来。目标是发现接口问题。
- 系统测试：将软件系统看成一个系统测试。包括对功能、性能以及软件所运行的硬软件环境进行测试。
- 回归测试：在修改了旧代码后，重新执行上一个版本的测试用例以确认没有引入新的错误。
- 冒烟测试：对每一个新编译的正式版本，确认软件的基本功能正常，可以开展后续测试工作。
- 验收测试
- α测试：由一个用户在开发环境下进行的测试。
- β测试：使用由软件最终用户（多个）在用户场景进行的测试。
| - | 单元测试 | 集成测试 | 系统测试 | 验收测试 |
|---|---|---|---|---|
| 测试阶段 | 和编码同步进行 | 单元测试之后 | 集成测试之后 | 系统测试之后 |
| 测试对象 | 模块或组件 | 模块间接口 | 整个系统（软、硬件） | 整个系统 |
| 测试人员 | 白盒测试工程师和开发人员 | 白盒测试和开发人员 | 黑盒测试工程师 | 最终用户或者需求方 |
| 测试依据 | 《详细设计文档》 | 《概要设计文档》 | 《需求规格说明书》 | 《需求规格说明书》和验收标准 |
| 测试方法 | 白盒测试 | 黑盒和白盒测试相结合 | 黑盒测试 | 黑盒测试 |
| 测试内容 | 独立执行路径、局部数据结构、模块接口、边界条件、容错 | 模块间数据传输、功能冲突、模块组装功能正确、全局数据结构、单模块缺陷对系统的影响 | 功能、界面、可靠性了、易用性、性能、兼容性、安全性等 | 与系统测试相同 |
按测试对象
- 可靠性测试
- 兼容性测试
- 安全性测试
- 性能测试
- 功能测试
- 文档测试
- 界面测试：也称UI测试。测试功能模块界面上看到的所有元素（包括空文字、控件等）颜色风格是否统一，布局是否合理、美观，符合用户习惯等等。
五、软件测试过程模型
V模型
与软件开发瀑布模型相对应
局限性：软件测试作为设计和编码后的一个阶段，忽视了测试对需求分析、系统设计的验证。不能体现尽早测试的原则。
W模型
增加了软件开发各阶段中同步进行的验证和确认活动。
一旦由文档提供，就要及时确定测试条件、编写测试用例。
优点：
- 测试与开发同步进行
- 测试的不仅仅是程序，还包括需求和设计。
- 能尽早地发现软件缺陷
局限性：需求、设计、编码活动被视为串行的，同样，测试和开发也有前后关系。无法支持迭代的开发模型。
H模型
H模型将测试活动完全独立出来，形成了一个完全独立的流程，贯穿于产品的整个生命周期。将测试准备活动和测试执行活动清晰的体现了出来。
优点：
- 揭示了软件测试除测试执行外，还有很多工作；
- 软件测试完全独立，贯穿整个生命周期，与其他流程并行；
- 测试可以尽早准备、尽早执行，有很强的灵活性；
- 可以根据被测物的不同而分层次、分阶段、分次序进行，是可迭代的。
局限性：
- 对管理要求高
- 对技术要求高：要求合理定义每次迭代的规模。
- 测试就绪点模糊：很多时候并不知道测试就绪点应该放在哪是合适的。
X模型
针对单独的程序片段进行相互分离的编码和测试，通过频繁的交接，最终集成为可执行的程序。
X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。
