系列文章目录

文章目录

系列文章目录
前言
第1章软件测试概述
- 1.1 软件、软件危机和软件工程
- - 1.1.1 基本概念
  - 1.1.2 软件工程的目标及其一般开发过程
  - 1.1.3 软件过程模型
- 1.2 软件缺陷与软件故障
- - 1.2.1 基本概念
  - 1.2.2 典型案例
- 1.3 软件测试的概念
- - 1.3.1 软件测试的定义
  - 1.3.2 软件测试的目的：保证软件产品的最终质量
  - 1.3.3 软件测试的基本原则
  - 1.3.4 软件测试的局限性
- 1.4 软件质量与质量模型
- - 1.4.1 软件质量的含义
  - 1.4.2 软件质量模型
- 1.5 软件测试的分类
- 1.6 软件测试过程模型
- 1.7 测试的生命周期
总结

前言

第1章软件测试概述

1.1 软件、软件危机和软件工程

1.1.1 基本概念

软件 = 程序 + 数据(库) + 文档
软件测试：为了尽快尽早地发现在软件产品中所存在的各种软件缺陷而展开的贯穿整个软件开发生命周期、对软件产品(包括阶段性产品)进行验证和确认的活动过程
软件危机的表现：
- 软件生产供不应求
- 软件生产率随软件规模与复杂性提高而下降
- 软件开发的进度与成本失控
- 软件系统实现的功能与实际需求不符
- 软件难以维护
- 软件文档配置没有受到足够的重视
软件危机的表现：
- 软件生产供不应求
- 软件生产率随软件规模与复杂性提高而下降
- 软件开发的进度与成本失控
- 软件系统实现的功能与实际需求不符
- 软件难以维护
- 软件文档配置没有受到足够的重视

1.1.2 软件工程的目标及其一般开发过程

微观目标：生产出满足需求的软件（成本、时间、质量、可维护性等）
宏观目标：提高软件质量和生产率，最终实现软件的工业化生产
一个软件产品从形成概念开始，经过开发、测试、使用和维护，直到最后退出使用的全过程称为软件生存周期
软件定义：计划和需求分析
软件开发：概要设计、详细设计和实现
软件测试：单元测试、集成测试、系统测试和验收测试
软件使用和维护：改正性维护、适应性维护和完善性维护

1.1.3 软件过程模型

瀑布过程模型
- 1970年温斯顿•罗伊斯(Winston Royce)提出
- 瀑布过程模型强调阶段的划分及其顺序性、各阶段工作及其文档的完备性
- 是一种严格线性的、按阶段顺序的、逐步细化的开发模式
螺旋过程模型
- 螺旋过程模型的基本思路是，依据前一个版本的结果构造新的版本
- 这个不断重复迭代的过程形成了一个螺旋上升的路径
增量过程模型
- 增量过程模型是用一种几乎连续的过程小幅度地推进项目
快速原型过程模型
- 快速原型过程模型首先是快速进行系统分析，在设计人员和用户的紧密配合下，快速确定软件系统的基本要求，尽快实现一个可运行的、功能简单的原型系统，然后通过对原型系统逐步求精，不断扩充完善得到最终的软件系统

1.2 软件缺陷与软件故障

1.2.1 基本概念

软件缺陷是存在于软件(文档、数据、程序)之中的那些不希望或不可接受的偏差。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活
软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态，此时若无适当措施(容错)加以及时处理，便产生软件失效
软件缺陷(software bug)的主要类型
- 软件未达到产品说明书中已经标明的功能；
- 软件出现了产品说明书中指明不会出现的错误；
- 软件未达到产品说明书中虽未指出但应当达到的目标；
- 软件功能超出了产品说明书中指出的范围；
- 软件测试人员认为软件难以理解、不易使用，或者最终用户认为该软件使用效果不良。

1.2.2 典型案例

1.3 软件测试的概念

1.3.1 软件测试的定义

定义1 ：正向逆向思维共存
- Bill Hetzel，1973年
- 测试就是建立一种信心，确信程序能够按预期的设想运行
定义2：正向逆向思维共存
- Glenford Myers，1979年
- 软件测试是为发现错误而执行程序的过程
定义3 ：注重软件质量评价
- Bill Hetzel，1983年
- 测试是以评价一个程序或者系统属性为目标的任何一种活动，测试是对软件质量的度量
定义4：注重软件质量评价
- Craig & Jaskiel ，2002年
- 测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程
IEEE标准术语：突出用户重要作用
- “使用人工或自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清楚预期结果与实际结果之间的差别”
软件缺陷在开发前期发现比在开发后期发现，在资金、人力上节约90%
软件缺陷在推向市场前发现比在推出后发现，在资金、人力上节约90%
软件测试应该从软件生命周期的第一个阶段开始，并贯穿于整个的软件生命周期
检验各阶段的成果是否接近预期目标，尽可能早的发现错误并加以修正

1.3.2 软件测试的目的：保证软件产品的最终质量

测试是一个程序的执行过程，其目的在于发现错误
一个好的测试用例很可能会发现至今尚未察觉的错误
一个成功的测试是发现至今尚未察觉的错误的测试
直接目的：发现软件缺陷
最终目的：验证用户需求
附加目的：改进开发过程

1.3.3 软件测试的基本原则

穷尽测试是不可能的，测试需要终止
- 穷尽测试：对所有输入数据的各种可能进行排列组合试验的测试
测试工作具有创造性，但很困难
- 测试是破坏性工作？重复性的工作？
- 测试需要有创造性和洞察力、广泛的知识、测试经验和正确的测试方法
测试工作应由独立的专业的软件测试机构完成
- 程序员应避免测试自己编写的程序
- 编写软件组织不应测试自己编写的软件
Pareto原则
- 程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比
- 错误总是倾向于聚集存在
- 寄生虫现象
- 杀虫剂现象
测试需尽早介入，且贯穿于整个生命周期
设计测试用例时应考虑各种情况
- 测试用例的编写不仅应当根据有效和预期的输入情况，而且应当根据无效和未预料到的输入情况
- 检查程序是否“未做其应该做的”，还要检查程序是否“做了其不应该做的”
计划测试工作时不应默许假定不会发生错误
- Glenford Myers (1979): “Testing is the process of executing a program or system with the intent of finding errors.”

1.3.4 软件测试的局限性

输入/状态空间的无限性
故障敏感性和巧合正确性
- 代码对测试包隐藏故障的能力称为故障敏感性
- 错误的代码执行时，却产生了正确的结果，被称为巧合正确性
系统缺陷的不确定性
- 由于无法确切知道系统的缺陷数量及所在的位置，对修正这些缺陷而带来的新的缺陷也是不可预测的，所以系统质量是不容易把握的

1.4 软件质量与质量模型

1.4.1 软件质量的含义

能满足给定需求的特性（功能、性能）
具有所期望的各种属性的组合的程度，即软件结构良好，合理利用系统资源，易读、易于理解，并易于修改、维护
能满足用户综合期望的程度，软件系统具有友好的用户界面，便于用户使用
软件的组合特性。软件生存周期中各阶段文档齐全、规范，便于配置、管理

1.4.2 软件质量模型

McCall(1979年)
ISO/IEC 9126-1991
新的ISO/IEC 9126
ISO/IEC 25010-2011

1.5 软件测试的分类

软件测试知识体系
按测试执行方式
- 静态测试：不需要执行所测试的程序，查询代码是否符合规范，对程序的数据流和控制流进行分析
- 动态测试：选择实际测试用例运行所测试程序，模拟用户输入
按测试对象
- 黑盒测试：
  - 行为测试、功能测试、基于需求的测试、数据驱动测试
  - 需求覆盖率
- 白盒测试：
  - 结构测试、基于代码的测试、逻辑驱动测试
  - 代码覆盖率
- 灰盒测试：白盒 + 黑盒
按照测试过程
按测试目的
- 功能测试、健壮性测试
按测试执行手段
- 自动化测试和手工测试

1.6 软件测试过程模型

V模型
W模型
- 增加对每个阶段的验证和确认
- W模型由两个V字型模型组成，分别代表测试与开发过程
- W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的
H模型
- H模型将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来
- H模型揭示了软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行