[开发测试]软件测试理论

概念

测试原则：

1. 测试证明软件存在缺陷
2. 不能执行穷尽测试
3. 缺陷存在群集现象
4. 某些测试需要依赖特殊的环境
5. 测试应尽早介入
6. 杀虫剂现象：同样的一个测试用例不能重复执行多次，软件会对它产生免疫
7. 不存在缺陷谬论：任何软件都不会是完美的

软件三部分：

1. 功能集合
2. 使用说明书
3. 配置数据

测试对象：

1. 需求分析阶段：各种需求规格说明书
2. 软件架构设计：API接口文档
3. 编码实现阶段：源代码（白盒测试、单元测试）
4. 系统功能使用：软件功能主体（当前行业最多）

测试级别：

1. 单元测试[UT] 组成软件最小的低层代码结构

   (类、函数、组件) unit test

2. 集成测试[IT] 多个单元模块组合一起，验证之间沟通的桥梁能否正常工作(接口测试) system ingertation test

3. 系统测试[ST] 测试人员充当用户测试软件功能主体 system test

   • 功能测试 软件主体功能是否可用
   • 兼容性测试 在不同的环境下是否还可以使用
   • 安全测试 是否只是能授权用户提供功能使用
   • 性能测试 相当于当前软件消耗的资源 产出能力

4. 验证测试：

   • α测试 – 内测
   • β测试 – 公测
   • γ测试 – 软件版本正式发行的候选版
   • UAT[ user acceptance test ]测试 – 由客户派出对于业务非常精通的人员来使用该软件，从而对功能进行测试

常用的系统测试方法

• 按测试对象分类
  1. 白盒测试
  2. 黑盒测试
  3. 灰盒测试 接口测试
• 按测试对象是否执行
  1. 静态测试 测试不执行
  2. 动态测试 将软件在真实使用环境进行测试
• 按测试手段进行分类
  1. 手工测试 测试人员手动对被测对象进行验证，测试操作及环境改变灵活
  2. 自动化测试 ·自己写脚本 ·第三方工具

软件质量

1. 功能性：软件需要满足用户显式或者稳式的功能
2. 易用性：软件易于学习和上手使用
3. 可靠性：软件必须实现需求当中指明的具体功能
4. 效率性：类似于软件的性能
5. 可维护性：软件具有将某个功能修复之后继续使用的能力
6. 可移植性：可以从一个平台移植到另一个平台上去的能力

软件测试流程

1. 需求分析

   • 当前阶段的核心目的就是梳理清楚我们需要设计的点是什么
   • 需求的来源：需求规格说明书、API文档、竞品分析

2. 设计用例：

   • 用例就是用户为了测试软件的某个功能而执行的操作过程
   • 设计用例是有方法的（等价类、边界值、判定表…）

3. 评审用例：对当前的用例进行添加或删除

4. 配置环境：

   • 环境：当前被测对象运行所需要的执行环境[有一键安装的集成环境]
   • 环境分类：操作系统 + 服务器软件 + 数据库 + 软件低层代码的执行环境

5. 执行用例

   • 冒烟测试，快速的对当前软件的核心功能或主体执行流程进行验证，有问题将此版本回退给开发
   • 冒烟测试通过再开展全面的测试

6. 回归测试及缺陷跟踪

   • 回归测试指的就是当我们将某个缺陷提交给开发之后，由它们进行修复，修复完成后需要测试人员再次对其进行测试
   • 缺陷跟踪：指的是当测试人员发现某个缺陷之后需要一直对其进行状态的跟踪

7. 输出测试报告 产生的数据进行可视化输出

8. 测试结束 将整个测试过程中产生的一些文档整理归纳，方便后续版本使用

开发模型

###瀑布模型

说明：

1. 线性模型的一种，在所有模型中占有重要地位，是所有模型的一个基础
2. 每个阶段执行一次，按线性顺序进行软件开发

测试的切入点：

? - 测试阶段处于软件实现后，必须在代码完成后留出足够的时间给测试活动

• 优点：
  • 开发的各个阶段比较清晰
  • 强调早期计划及需求调查
  • 适合需求稳定的产品开发
• 缺点：
  • 依赖于早期的需求调查，不适应需求的变化
  • 单一流程不可逆
  • 风险往往延至后期才暴露，失去及早纠正的机会
  • 问题在项目后期才开始暴露
  • 前面未发现的错误会传递并扩散到后面的阶段，可能导致项目失败
  • 新产品不太适合
• 改良：
  • 沿用瀑布模型的线性思想，细化各个阶段，在某些重要关注的阶段之间掺入迭代的思想

快速原形模型

在开发真实系统之前，构造一个原型，在原型的基础上，逐渐完成整个系统的开发工作

第一步是建造一个快速原型，实现用户与系统的交互，用户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足用户的要求，开发人员可以确定用户的真正需求是什么

第二步是在第一步的基础上开发出用户满意的软件产品

• 优点：
  • 克服瀑布模型的缺点，更好地满足用户的需求并减少由于软件需求不明确带来的项目开发风险。适合预先不能确切定义需求的软件系统的开发
• 缺点：
  • 不适合大型系统的开发（适合开发小型的、灵活性高的系统）。前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新

螺旋模型

将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合

• 优点：
  • 螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估
• 缺点：
  • 采用螺旋模型需要具有相当丰富的风险评估经验和专门的知识，在风险较大的项目开发中，如果未能及时标识风险，势必造成重大损失。过多的迭代次数会增加开发成本，延迟提交的时间

软件测试模型

V模型

• 优点：
  • 包含了底层测试(单元测试)和高层测试(系统测试)；清楚的标识了开发和测试的各个阶段；自上而下逐步求精，每个阶段分工明确，便于整体项目的把控
• 缺点：
  • 自上而下的顺序导致了，测试工作在编码之后，就导致错误不能及时的进行修改；实际工作中，需求经常变化，导致v模型步骤，反复执行，返工量很大，灵活度较低
• 改良：
  • 每个步骤都可以进行小的迭代工作

W模型

• 优点：
  • 开发强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求和概要设计同样要测试
  • 更早地接入测试，可以发现开发初期的缺陷，那么可以用更加低的成本进行缺陷修复
  • 同样是分阶段的工作，便于控制项目过程
• 缺点：
  • 依赖于软件开发和软件测试依然保持一前一后的线性关系，依然无法支持迭代、自发性和需求等变更调整；
  • 对于当前很多项目，在执行的过程中根本不产生文档，那么W模型基本无法适用
  • 使用起来技术复杂度很高，对于需求和设计的测试要求很高，实践起来困难

H模型

• 测试流程：
  • 测试准备：所有测试执行活动的准备判断是否到测试就绪点
  • 测试就绪点：测试准入准则，即是否可以开始执行测试的条件
  • 测试执行：具体的执行测试的程序
• 其他流程：
  • 具体开发中的流程，如：设计流程
• 优点：
  • 揭示了软件测试除测试执行外，还有很多工作；
  • 软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行；
  • 软件测试活动可以尽早准备、尽早执行，具有很强的灵活性
  • 软件测试可以根据被测物的不同而分层次、分阶段、分次序的执行，同时也是可以被迭代的
• 缺点：
  • 管理型要求高:由于模型很灵活，必须要定义清晰的规划和管理制度，否则测试过程将非常难以管理和控制
  • 技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小
  • 测试就绪点分析困难：测试很多时候，并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很多困难
  • 对于整个项目组的人员要求非常高：在很好的规划制度下，大家都能高效的工作，否则容易混乱。例如：分了一个小的迭代，但是因为人员技能不足，无效完成，那么整个项目就会受到很大的干扰。

黑盒测试

• 能发现的错误

  • 功能不对或功能遗漏
  • 界面错误
  • 数据库访问或者处理错误
  • 性能问题

• 功能测试

  • 逻辑功能测试
  • 界面测试
  • 易用性测试
  • 安装测试
  • 兼容性测试

• 性能测试

  • 时间性能

  • 空间性能

  • 一般性能测试

  • 稳定性测试

  • 负载测试

  • 压力测试

其他

回归测试、冒烟测试、随机测试、验收测试

测试方法

黑盒测试方法（全）

黑盒测试9种常用方法

等价类划分法

用户所有可能输入的数据，划分成若干份（子集），然后从每一个子集当中选取少数具有代表性的数据作为测试用例

1. 文本框要求输入的长度
2. 输入的类型
3. 组成规则
4. 是否为空
5. 是否重复—区分大小写
6. 是否去除空格

边界值

上点：就是指得边界上得点，开区间的话，上点就是在域外，闭区间得话，上点就是在域内。

离点：指得就是离上点最近得点，如果是开区间，那么离点就在域内，如果是闭区间，那么离点就在域外。

内点：域内得任意点都是内点。

边界值的取值需要把上点值、离点值和内点值取到

因果图法

? 等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。多个输入条件组合起来可能出错的情况被忽视。

因：输入条件

果：输出条件、出结果

适用于输入条件之间有相互制约、相互依赖的情况

1.互斥：可不选，要选最多选一个。E（Exclude）表示

2.唯一：必选，且只能选一个。O（Only）表示

3.包含：至少选择一个，可以多选。I（Include）表示

4.要求：一个出现，另一个一定出现；反之另一个不确定。R（Required）表示

5.屏蔽：a成立时，b不成立；a不成立时，b的值不一定。M（Masked）表示

• 使用步骤
  • 找出所有的原因，原因即输入条件或输入条件的等价类
  • 找出所有的结果，结果即输出结果
    • 哪些条件不能组合到一起，哪些可以组合到一起
  • 明确所有输出条件之间的制约关系以及组合关系
    • 哪些输出结果不能同时输出，哪些可以同时输出
  • 找出什么样的输入条件组合会产生哪些输出结果
  • 把因果图转换成判定表/决策表
  • 为判定表/决策表中的每一列表示的情况设计测试用例

判定表法

由因果图通过分析得到判定表，再通过判定表编写测试用例

• 组成
  • 条件桩：问题的所有条件
  • 动作桩：问题的所有输出
  • 条件项：针对条件桩的取值
  • 动作项：条件项的各种取值情况下的输出结果
• 步骤：
  • 列出所有的条件桩和动作桩
  • 填入条件项
  • 填入动作项。得到初始判定表
  • 简化判定表（合并相似规则（相同动作））

合并使用“-”代表无关项，选什么都不影响

场景法

模拟用户操作软件时的场景，主要用于测试系统的业务流程

• 基本流
  • 按照正确的业务流程来实现的一条操作路径（模拟正确的操作流程）
• 备选流
  • 导致程序出现错误的操作流程（模拟错误的操作流程）

在使用场景法设计测试用例时，需要覆盖系统用例中的主成功场景和扩展场景，并且需要适当补充各种正反面的测试用例和考虑出异常场景的情形。

使用场景法测试程序没有问题时，可以再使用边界值、等价类方法对账号、密码进行更加细致、完整的测试

流程分析法

针对测试场景类型，属于流程测试场景的测试项下的测试子项

• 优点
  • 降低了测试用例的设计难度，只要搞清楚各种流程，就可以设计出高质量的测试用例，而且不需要太多测试方面的经验
  • 在测试时间较紧迫的情况下，可以有的放矢的选择测试用例，而不用完全根据经验取舍
• 步骤；
  • 详细了解需求
  • 根据需求说明或界面原型，找出业务流程的各个页面以及各个页面之间的流转关系
  • 画出业务流程（产品经理使用Axure软件制作）
  • 写用例，覆盖所有的路径分支

错误推断法

凭借直觉和推断设计测试用例

正交表

常用正交表

正交排列法；

使用最小的测试过程集合获得最大的测试覆盖率

均匀分散，整齐可比

表示：L_n(m^k)

- n是表的行数，也就是需要测试组合的次数
- k是表的列数，表示控件的个数（因素的个数，或因子个数）
- m是每个控件包含的取值个数（各因素的水平数，即各因素的状态数）

L₉(3⁴)

·有4个控件

·每个控件有3个取值

·9为需要测试的组合个数

·称为4因素3水平