Restful: 一种软件架构风格,提供了一些设计原则和约束条件
- 一个资源对应于一个URI
- 前端和服务端分层明确
- 用HTTP动词(post,get,delete,put)描述操作
分层测试:UI,Service,Unit,依次成本减小,效果增加
黑盒测试用例设计方法
等价类划分法
- 将所有的可能输入数据(有效的和无效的)划分成若干个等价类,从各个等价类中选取有代表性的数据来覆盖测试用例。
- 适用于系统测试,集成测试,组建测试
- 类划分规则
- 若输入的数据是在一定的取值区间内,则确定一个有效类和两个无效类
- 输入条件是一个布尔值或者必须为一个值,则确定一个有效类true一个无效类false
- 输入条件要求满足多个条件,则确定一个有效类和多个无效类
- 输入条件规定了在n个值中取值,则确定n个有效类和一个无效类
边界值法
- 对等价划分类的一种补充,用来覆盖边界值的测试用例
- 设计原则:
- 最小值,比最小值略高,比最小值还小
- 最大值,比最大值略小,比最大值还大
错误推测法
- 定义:基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。
- 基本思想:列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。
因果图
- 用自然语言分析罗列出因(输入)和果(输出)的各种组合情况,生成因果图,继而转换成判定表。用于考虑多种组合条件下的结果。
- 设计步骤
- 分析需求,找出各个原因和结果并标记值。
- 分析需求,找出原因和原因,原因和结果之间的关系,制成因果图。
- 由于语法和环境原因,一些原因和原因、原因和结果之间的关系不可能出现,需要一些记号表明约束条件或限制条件。
- 制成判定表
-
因果图的画法:
(a)恒等。若原因出现,则结果出现;若原因不出现,则结果不出现。
(b)非。若原因出现,则结果不出现;若原因不出现,则结果出现。
(c)或。若几个原因中有一个出现,则结果出现;若几个原因均不出现,则结果不出现。
(d)与。若几个原因都出现,结果才出现;若几个原因中有一个不出现,则结果不出现
-
为了表示因果图中的约束条件,可用一些符号在因果图中加以标识。
从原因方面考虑主要有4种约束条件:
(a)E(互斥、排他)。a、b两个原因不会同时出现,最多只有一个出现。
(b)I(包含、或)。a、b、c三个原因至少有一个出现。
(c)O(唯一)。a、b两个原因必须有一个出现,且仅有一个出现。
(d)R(需求)。a出现时b必定出现。
从结果方面考虑主要有1种约束条件:
(a)M(屏蔽)。a出现时,b必定不出现;a不出现时,b则不确定。
判定表驱动法
- 把作为条件的所有输入值和作为结果的所有输出值罗列出来,形成的表格。
- 分为几部分:条件桩,条件项,动作桩,动作项。
- 优缺点:
- 优点:把所有可能项列出来,避免遗漏。
- 缺点:无法解决循环问题。
- 步骤:
- 确定条件数,假设有n个条件,每个条件有0和1两个值,则共有2^n种规则。
- 列出所有条件桩和动作桩。
- 填入条件项和动作项。
- 精简判定表
- 规则:任何一个条件组合的特定取值及其要执行的相应操作,在判定表中贯穿条件项和动作项的一列就是一条规则。
正交实验法
- 建表步骤
- 通过分析、刨析需求,找出最基本的功能点,作为因子。
- 按照等价划分类的方法找出每个因子的可能输入值作为水平值。
- 以以下的条件,选取合适的正交表:
- n(行数、测试用例数)=因子数(列数、变量数)*(水平数(取max值)(每个变量取值的个数)-1)+1
- 把条件带入到表中。
- 按照没一行的组合编写测试用例,必要时可适当增加。
流程分析法(场景图法)
- 从用户的角度出发,按照业务流或者不同的场景来设计测试用例。
- 优缺点:
- 优点:实用性强,设计出来的用例价值高
- 缺点:设计出来的用例不完整
- 流程种类:
- 基本流:流程从头至尾都是正确的,只有一条。
- 备选流:因错误操作或异常操作,导致业务失败并返回基本流,后来最终到达正确结果,可以有多条。
- 异常流:因错误操作导致流程最终失败,可以有多条。
- 设计步骤
- 画出业务流程图
- 定义状态节点和条件分支
- 确定测试路径
- 分析测试路径,去除多余无效的路径,填入测试数据
状态迁移图
- 适用于有状态变化的业务,用来设计案例来测试状态迁移中各种情况的正确性。例如播放音乐中音乐的状态。
- 步骤:
- 分析需求获取所有的状态。
- 绘制状态迁移图,有一个或多个的状态路径。
- 选取测试数据,构造测试用例。
- 这个博客有简单的例子http://blog.csdn.net/ggf123456789/article/details/8286181
功能图法
静态状态:输入值和输出值之间的逻辑关系。
动态状态:输入数据的次序或迁移的次序。