软件测试
软件质量的含义
软件质量是与软件产品满足明确或隐含需求的能力有关的特征和特征的总和，其含义有以下四个方面
- 能满足给定需求的特性（在功能，性能等方面都符合要求）
- 能满足用户综合期望的程度（有友好的用户界面，便于用户使用）
- 具有所期望的各种属性的组合的程度（软件结构良好，便于修改和维护）
- 软件的组合特性（软件生存周期中各阶段文档齐全，规范，便于配置管理）
软件测试的定义
软件测试就是为了发现错误而执行程序的过程。
在IEEE提出的软件工程标准术语中，软件测试被定义为：使用人工或自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清楚预期结果与实际结果之间的差别
软件测试的目的
- 发现软件缺陷和错误
- 对软件质量进行度量和评估
- 保证软件产品的最终质量
软件测试的原则
- 尽早测试
- 全面测试
- 全过程测试
- 独立的，迭代的测试
- Pareto原则
- 完全测试是不可能的，测试需要终止
- 妥善保存一切的测试过程文档
软件测试的VW模型
V模型反映出了测试活动和分析设计活动的关系，但是也存在一定的局限性，它仅仅把测试作为编码后的一个阶段，是针对程序运行寻找错误的活动，而忽视了测试活动对需求分析，系统设计等活动的验证和确认功能
W模型由两个V模型组成，分别代表测试和开发过程，相对于V模型，W模型增加了软件开发各个阶段中应同步进行的确认和验证活动
软件测试的基本流程
单元测试的定义
单元测试是对软件设计的最小单元：模块进行正确性检验的测试工作，主要测试模块在语法，格式和逻辑上的错误
多采用白盒测试进行测试
单元测试的主要任务
- 模块接口测试
- 模块局部数据结构测试
- 模块独立执行路径测试
- 各种错误处理测试
- 模块边界条件测试
单元测试的环境
在对每个模块进行单元测试时，不能完全忽视他们和周围模块的相互关系，为模拟这些关系，在单元测试时，需设置若干辅助测试模块。辅助模块有两种，一种是驱动模块，用于模拟被测试模块的上级模块，驱动模块在单元测试中接收测试数据，把相关的数据传送给被测模块，启动被测模块，并打印出响应的结果。另一种是被调用子模块，用以模拟被测模块工作过程中所调用的模块。被调用子模块由被测模块调用，它们一般只进行很少的数据处理，例如打印入口和返回。
集成测试的概念
集成测试是在单元测试的基础上，测试将所有软件单元按照概要设计规格说明的要求组装成模块，子系统或系统的过程中，各部分功能是否达到或实现相应技术指标及要求的活动。集成测试主要是测试软件单元的组合能否正常工作以及其他组的模块能否集成起来工作。
集成测试的主要任务
- 将各模块连接起来，检查模块相互调用时，数据经过接口是否丢失
- 将个子功能组合起来，检查是否到达预期要求的各项功能
- 一个模块的功能是否会对另一个模块的功能产生不利的影响
- 全局数据结构是否有问题，会不会被异常修改
- 单个模块的误差积累起来，是否被放大，从而达到不可接受的程度
增量式集成测试方法和特点
非增量式集成测试：采用一步到位的方法进行测试，即对所有模块进行个别的单元测试后，按程序结构图将各模块连接起来，把连接后的程序当做一个整体进行测试。
增量式集成测试：单元的集成是逐步实现的，集成测试也是逐步完成的。也可以说它把单元测试和集成测试结合起来进行。
增量式集成测试的方法：
- 自顶向下的增量式集成测试：逐步集成和逐步测试是自上而下进行的，即模块集成的顺序首先是主控模块（主程序），然后按照软件控制层次结构向下进行集成
- 自底向上增量式集成测试：自底向上增量式集成测试是从最底层的模块开始，按结构图自下而上逐步进行集成并逐步进行测试工作，由于是从最底层开始集成，测试到较高层模块时，所需的下层模块已经具备，所以也就不再需要使用被调用模拟子模块来模拟测试。
- 三明治集成测试：三明治集成测试是将自顶向下和自底向上测试两种模式有机结合起来，采用并行的自顶向下和自底向上集成方式。同时自底向上集成时，先期完成的模块将是后期模块的被调用程序，而自顶向下集成时，先期完成的模块将是后期模块的驱动程序，从而使后期模块的单元测试和集成测试出现了部分交叉。
系统测试的概念
集成测试通过以后，各模块已经组装成一个完整的软件包，这时候就要进行系统测试。
系统测试是指将通过集成测试的软件系统，作为计算机系统的一个重要组成部分，与计算机硬件，外设，某些支撑软件的系统等其他系统元素组合在一起所进行的测试，目的在于通过与系统的需求定义做比较，发现软件与系统定义不符合或矛盾的地方。
系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等是否满足需求分析所指定的要求
系统测试的类型
- 验证测试
- 功能测试
- 性能测试
- 可靠性，稳定性测试
- 兼容性测试
- 恢复测试
- 安全测试
- 强度测试
- 用户界面测试
验收测试的概念
验收测试是在软件开发结束后，用户对软件产品投入实用应用以前，进行的最后一次质量检验活动。
验收测试主要是验证软件功能的正确性和需求的符合性
验收测试的主要内容
- 配置复审（保证软件配置齐全，分类有序，并且包括软件维护所需要的细节）
- 合法性检查（检查开发者在开发软件时，使用的开发工具和库是否合法，有相关的发布许可）
- 软件文档检查
- 软件代码测试 （检查命名规范，注释，数据等内容）
- 软件功能和性能测试
测试用例的概念
测试用例是测试执行的最小实体，是为特定的目的而设计的一组测试输入，执行条件和预期的结果
测试用例的作用
- 有效性
- 避免测试的盲目性
- 可维护性
- 可复用性
- 可评估性
- 可管理型
优秀测试用例的要素
- 用例的编号（软件名称简写-功能块简写-NO）
- 测试标题（测试用例的描述）
- 测试项（描述测试项和详细特征）
- 测试环境要求
- 测试输入说明
- 操作步骤
- 预期结果
- 测试用例设计人员和测试人员
- 测试日期
- 测试优先级
软件缺陷的概念和要素
软件缺陷简单说就是存在软件（文档，数据，程序）之中的那些不希望，或不可接受的偏差，而导致软件产生质量问题。只要符合下面5个规则中的一条，就可以叫做软件缺陷
- 软件未达到软件规格说明书中规定的功能
- 软件超出软件规格说明书中指明的范围
- 软件未达到软件规格说明书中指出的的应达到的目标
- 软件运行出现错误
- 软件测试人员认为软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好
软件缺陷的有效描述规则
- 单一准确(每个报告只针对一个软件缺陷)
- 可以再现(提供出现这个缺陷的精确步骤，使开发人员看懂，可以再现并修复缺陷)
- 完整统一(提供完整，前后统一的软件缺陷修复步骤和信息，如图片信息，log文件等)
- 短小简练(使用关键词，使软件缺陷的标题描述短小简练，又能准确解释产生缺陷的对象)
软件测试的生命周期
在整个缺陷的生命周期中，随着测试工作 的进展，缺陷的状态在不断变化：
- New（新缺陷）：软件中新发现的缺陷， 一般由测试人员提交。当然也可能是开发人员自己在单元或代码测试过程中提交，或来自软件使用的最终用户，又或测试现场反馈得到的缺陷报告。
- Accepted（接受）：经过缺陷评审委员会的确认，认为缺陷确实存在。
- Assign（分配）：将该缺陷分配给相关的开发人员来进行修改。
- Open（打开）：处于该状态时，缺陷已经被确认并已经分配给相关的开发人员进行相关的修改。
- Fixed（已修改）：开发人员已经解决的缺陷并经过内部的验证。
- Reopen：开发人员确认修改后提交测试组，但是测试人员验证发现，该问题仍然存在，此时将状态设置为Reopen。
- Closed（关闭）：缺陷状态处于已修改，并通过测试人员的验证后，由测试人员将其状态置为Closed。
软件测试过程中主要文档类型和作用
- 测试计划
- 测试设计规格说明
- 测试用例说明
- 测试规程规格说明
- 测试日志
- 测试缺陷报告
- 测试总结报告
软件测试的过程及其主要工作
- 测试项目启动（确定项目组长，组建小组等）
- 测试计划阶段（确定测试范围，测试策略和方法，对计划和资源进行分析和估计）
- 测试设计阶段（设计测试用例，选择测试工具，写测试脚本等）
- 测试执行阶段（建立或设置相关的测试环境，准备测试数据，执行测试用例）
- 测试结果的审查和分析（对测试结果进行整体的综合分析，以确定产品质量的当前状态，为产品的改进或发布提供数据和依据）
黑盒测试和白盒测试的概念
黑盒测试：已知产品的功能设计规格和用户手册，可以通过测试证明每种功能是否实现且符合需求。
白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，以及所有内部成分是否经过检查。
软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。
软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。
黑盒测试和白盒测试的方法
黑盒测试
- 等价类划分法
- 边界值分析法
- 决策表
- 场景图法
- 因果图法
- 功能图分析法
- 错误推断法
- 正交试验法
白盒测试
- 静态分析
- 代码检查
- 静态结构分析
- 动态分析
- 基本路径测试
- 域测试
- 符号测试
- Z路径覆盖
- 程序变异
基本路径测试法
基本路径测试中，设计出的测试用例要保证在被测程序的每一条可执行语句上至少执行一次
- 根据过程设计结果画出程序的控制流图
- 计算程序的环路复杂度
- 导出基本路径集，确定程序的独立路径
- 设计相应的测试用例
环形复杂度计算
- 流图中区域的数量对应于环形复杂度
- 给定流图G的环形复杂度为V(G)，定义为V(G) = E - N + 2，E是流图中边的数量，N是流图中节点的数量
- 给定流图G的环形复杂度V(G)，定义为V(G) = P + 1，P是流图G中判定节点的数量
有多少个V(G)就有多少个路径
另外一个例子
等价类划分法
等价类是某个输入域的子集，使用这一方法时，把所有可能的输入数据（即将程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据）作为测试用例，每一类的代表性数据在测试中的作用等价于这一类的其他值。
有效等价类：指对于程序规格说明来说，由合理的、有意义的输入数据构成的集合。
无效等价类：指对于程序规格说明来说，由不合理的、无意义的输入数据构成的集合。
划分等价类的方法
- 按区间划分：如果输入的数据属于一个取值范围，则可以确定一个有效等价类和两个无效等价类(大于和小于的情况)
- 按数值划分：如果规定了输入数据的一组值，而且程序要对每个输入值分别进行处理，则可为每一个输入值确定一个有效等价类，此外针对这组值确定一个无效等价类，它是所有不允许输入值的集合
- 按限制条件划分，在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类
- 按限制规则划分：在规定了输入数据必须遵守的规则的情况下，可确定一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）
- 按处理方式划分：在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将等价类进更一步的划分为更小的等价类
在确定了等价类后，建立等价类表，列出所有划分出的等价类，再从划分出的等价类中按照下面原则选择测试用例
- 每一个等价类规定一个唯一的编号
- 设计一个新的测试用例，使其尽可能多的覆盖尚未覆盖的有效等价类，重复这一步骤，直到所有的有效等价类都被覆盖为止
- 设计一个新的测试用例，使其仅覆盖一个无效等价类，重复这一步骤，直到所有的无效等价类都被覆盖为止
决策表法
也称判定表，是分析和表达多逻辑条件下执行不同操作的情况的工具，能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏，设计出完整的测试用例集合
一个决策表由“条件和活动”两部分组成，也就是列出了一个测试活动执行所需的条件组合。所有可能的条件组合定义了一系列的选择，而测试活动需要考虑每一个选择。
判定表的建立步骤
- 列出所有的条件桩和动作桩
- 确定规则的个数
- 填入条件项
- 填入动作项
- 合并相似规则
决策树
场景法
现在的软件几乎都是用事件触发控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流，经过用例的每条路径都用基本流和备选流来表示。
基本流：
采用直黑线表示，是经过用例的最简单路径（无任何差错，程序从开始直接执行到结束）
备选流：
采用不同颜色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不再加入到基本流中(各种错误情况)
应用场景法进行黑盒测试的步骤如下：
- 根据说明，描述出程序的基本流和各项备选流
- 根据基本流和各项备选流生成不同的场景
- 对应每一个场景生成相应的测试用例
- 对生成的所有测试用例重新复审，去掉多余的测试用例，确定测试用例后，对每一个测试用例确定测试数据值
例子1
另一个例题
