测试用例

目录：
一、概念 基本要素
二、设计方法
1.基于需求的设计方法
2.等价类法
3.边界值法
4.因果图法
5.正交排列法
6.场景设计法
7.错误猜测法
三、测试用例的有效性
四、测试用例的粒度和评价

一、测试用例的概念以及要素
1.概念：向被测试的程序输入的一组集合
2.这组集合的要素是:测试环境、测试步骤、测试数据、预期结果、备注、测试版本、前提条件等

二、测试用例的设计方法（这7种方法都是V模型中的系统测试阶段里面的黑盒测试方法所用到的编写测试用例的方法）
1.基于需求的设计方法：
根据需求来写测试（他使测试专注于质量问题所产生的根源，即需求）
难点：能读出需求以外的测试点（一定要对需求非常了解才能想到需求以外的测试点）
案例：

2.等价类：

• 思想：解决输入无穷。
• 目的：减少测试用例。
• 使用场景：输入
• 概念：无穷的输入进行N个归类（必须是所有的数据全部归类），从每一类中提取一个数据进行测试，只要数据测试通过，认为这个数据所在的这一类的数据全部测试通过
• 有效等价类:符合要求，满足需求（对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是 否实现了规格说明中所规定的功能和性能）
• 无效等价类:有效等价类以外（根据需求说明书，不满足需求的集合）
• 等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充。
• 案例： 超市买水果
  有效等价类:苹果、桃子、梨 无效等价类:青菜、 米、饮料，…
  以上述的需求为例:
  |用户名 | 必填，录入用户名 | 6至15 | 字符类型A-Z,不区分大小写|用户名由长度为6-15位的字符串组成
  那么针对字符有效等价类为：A-Z,a-z，
  无效等价类为两个:数字:1，0.1，-1 特殊字符:@，#，¥，空
  思考一下:如何针对6-15位长度设计测试用例?

3.边界值法：

• 使用场景：输入和输出
• 概念：输入和输出的“边界值”
• 是等价类的一种补充方法，基本成对出现
• 举例：

4.因果图法：

• 使用场景：输入（原因）和输出（结果）的关系
• 概念：输入和输出的关系，输出依赖输入（原因可以是多个，结果是依赖原因的）
• 因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况
• 恒等 与 或 非
• 步骤：

1. 分析出所有的输入。
2. 分析出所有的输出。
3. 分析出输入和输出之间的所有关系。
4. 画因果图
5. 把因果图转换为判定表：判定表列数（算出的：输入是幂数，输出是底数）例如：3个输入；2个输出；判定表的列数为2的3次方

• 案例：

5.正交排列法：

• 思想：正交表—正交试验（抽样）
• 两条性质：任何列中出现的数字的个数一样；任何两列中有序对数出现次数一样
• 目的：减少测试用例
• 因素（变量）、水平（变量的取值）、行数、因素数、水平数、
• L=N（TC）
• L—正交表、N—实验次数、T—水平数=变量的取值、C—因素数=变量
• 行数：即表的行的个数，即实验的次数N
• 因素数：正交表中列的个数，用C表示
• N（实验次数）是通过水平和因素算出来的
  N=（T-1）*C+1
• 正交表步骤：

1. 你出所有的因素
2. 理出所有的水平
3. 选出一个合适正交表
4. 画出正交表，把水平一一带进去
5. 每一航行的各因素水平的组合就是一个测试用例
6. 需要测试的数据加进来，补充测试用例

• 案例

6.场景法：

• 业务流程：把各个孤立的功能点串起来，但是一个业务流程不一定是一个场景
• 事件、事件流：
  点击页面的登录按钮（这一瞬间会触发以下5个事件
  1. 判断用户名是否存在？
  2. 判断用户名和密码是否正确。
  3. 判断用户状态是否正确？
  4. 判断用户是否激活
  5. click或submit（最后环节）
     例如：上述1-2-3-4-5就是一个事件流
• 出现两个单位

1. 功能（业务流里边的单位）
2. 事件（事件流里边的单位）
   如果以业务流程这个角度，他的单位是功能而讲的话，登录按钮就不是一个场景；但是我们以事件流来讲他的单位是事件的话，这时，他是一个场景。所以说场景可大可小，取决于取的单位；单位不一样，有可能是场景有可能不是场景；同一个功能，在不同的单位里，可能是场景可能不是场景。

7.错误推测法（是由来源的）：

• 推测来源

1. 对某个项目测试的时间长
2. 用户的反馈
3. 缺陷、故障库

• 举个例子：
  输入框的类型可以用两种编写测试用例的方法来写：等价类中的无效等价类、错误推测法（只针对于输入框的类型不符合标准的时候，因为验证输入框的类型不符合标准的时候他们的测试点是一样的）
  但是反过来，不是所有的都是一样的，比如说某个某块的业务逻辑比较复杂，只能用错误推测法，因为这个模块的业务逻辑比较复杂，比较容易出bug，这时，跟是否有效无效等价类是没有关系的（不是所有的无效等价类和错误推测法都是同等的，要看你使用的场景）