等价类划分法测试用例_测试用例书写分类

1. 测试用例

简单来说,就是测什么,怎么来测的.

买手机、买电脑，要试用一下：开机、屏幕、运行速度、内存大小；这就是生活中的测试用例！

1.1 定义

测试用例(Test Case)是为特定的目的而设计的一组测试输入、执行条件和预期的结果，以便测试是否满足某个特定需求。通过大量的测试用例来检验软件的运行效果，它是指导测试工作进行的依据。

买手机：按开机键，相当于输入了一组数据来测试，执行条件指的是开机的前提条件，比如是否有电；预期结果就是能顺利打开手机，那么测试完毕后，是否达到了想要的需求（顺利开机）。

2. 等价类划分法

• 等价类划分是一种重要的、常用的黑盒测试方法，不需要考虑程序的内部结构，只需要考虑程序的输入规格即可。
• 它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性。

计算器：到底输入几组数据才算测试完毕？（讨论课题）
计算0到100之间的加法(包括0和100);

答案：一个一个测试效率低下，一定要分类测试！
1、整数（在范围内的整数-99到99）取最大、最小、中间
2、小数（在范围内的整数-99到99）
3、符号（+-/*，。、！@#￥%……&*（））
5、汉字
6、空格
7、不输入
通过上面的描述，我们发现我们用户所有可能输入的数据，划分成了若干份（或者也可以称为子集），然后从每一个子集当中选取少数具有代表性的数据作为测试用例，这种测试用例我们称为“等价类划分法”。

2. 1 分类

• 有效等价类
  • 指符合《需求规格说明书》，输入合理的数据集合
• 无效等价类
  • 指不符合《需求规格说明书》，输入不合理的数据集合.

2.2 等价类的思考步骤

1. 先确定有效和无效等价类
2. 有效等价类就是题目条件（两端的极值（边界值）要判断、中间随意一个值也要判断）
3. 无效等价类先划分与条件相反的情况，再找到特殊情况（中文、英文、符号、空格、空）

2.3 等价类分类总结

通过上面的案例，我们可以总结一下，当我们在测试文本框的程序可以考虑如下的情况：

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

3. 边界值

3. 1 什么是边界?

边界是指对于输入等价类和输出等价类而言，稍高于其边界值及稍低于其边界值的一些特定情况。
边界值分析法也是一种常用的黑盒测试方法。

特别强调

大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部

3. 2 特别注意

有效数据和无效数据的分界点，往往作为程序员编写程序的判断点，是程序员容易犯错误的地方，也是测试人员重点测试的内容。

3.3 确定边界值

• 确定边界情况（输入或输出等价类的边界）.
• 选取正好等于、刚刚好大于或刚刚好小于边界值作为测试数据.
• •边界值的取值依据输入范围区间不同而有所不同，但是都需要把上点值、离点值和内点值取到。（闭两边、开中间）

1. 如果是闭区间[1,10]
	1. 上点值: 1,10
  2. 内点值: 5,
	3. 离点值: 0,11
2. 如果是开区间,例如(1,10)
    1. 上点值: 1,10
    2. 内点值: 5,
	3. 离点值: 2,9
3. 如果是半开半闭区间:
	1. 上点值: 1,10
    2. 内点值: 5, 
	3. 离点值: 2,11

3. 4 边界值方法小总结

1. 如果输入条件规定了值得范围，则应取刚到到这个范围的边界值，以及刚刚超越这个范围边界的值作为输入数据.

2. 输入条件规定了值得个数

3. 边界值和等价类区别：边界值分析不是从某等价类中随便挑一个作为代表，而是这个等价类的每个边界都要作为测试条件

4. 因果图法

因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况

4.1 特点

• 考虑输入条件的相互制约及组合关系
• 考虑输出条件对输入条件的依赖关系

4.2 产生背景

1. 等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。
2. 如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。

4.3 因果图的核心

• 因果图法比较适合输入条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出
  • 因果图中的 '因' --- 输入条件.
  • 因果图中的'果' --- 输出条件.
• 因果图法要注意考虑
  • 所有输入/输出条件的相互制约关系以及组合关系;
  • 输出结果对输入条件的依赖关系，也就是什么样的输入组合会产生怎样的输出结果，即“因果关系”;

4.4 因果图的基本符号

• 基本符号
  • 通常在因果图中用Ci表示原因
  • 用Ei表示结果
  • 各结点表示状态
    • 可取值“0”或“1”
      • 0表示某状态不出现，
      • 1表示某状态出现。
• 恒等
  • 若原因出现,则结果出现.
  • 若原因不出现,则结果也不出现.
• 非(~)
  • 若原因出现,则结果不出现.
  • 若原因不出现,则结果出现.
• 或(v)
  • 若几个原因当中有一个出现,则结果出现;
  • 若几个原因都不出现,则结果不出现.
• 与(^)
  • 若几个原因都出现,则结果才出现;
  • 若其中一个原因不出现,则结果不出现.

4.4 因果图中的约束条件(了解)

• 互斥
  • 最多一个成立, 比如下拉菜单选项
• 包含
  • 至少有一个必须成立(下拉菜单)
• 屏蔽
  • a成立时,b不成立;a不成立时,b不一定成立.
• 唯一
  • 三个条件中只有一个是成立的(下拉菜单)
• 要求
  • 一个出现,另外一个必出现.比如银行取钱

4.5 基本步骤

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

5. 判定表法

因果图只是一种辅助工具，通过分析最终得到判定表，再通过判定表编写测试用例。但有时画因果图非常麻烦，影响测试效率，可以直接写判定表，进而编写测试用例.

5.1 组成

• 条件桩：问题的所有条件
• 动作桩：问题的所有输出
• 条件项：针对条件桩的取值
• 动作项：条件项的各种取值情况下的输出结果

5.2 基本使用

• 列出所有的条件桩和动作桩
• 填入条件项
• 填入动作项。得到初始判定表
• 简化判定表（合并相似规则（相同动作）)

5. 3 示例

怎样从传统意义上来说, 一个学生是一个好学生?

遵纪守法的前提下，学习成绩好是一个好学生、品德高尚也是一个好学生；（只要违法乱纪就绝对不是一个好学生；成绩和品德有一项，再加上遵纪守法也是好学生）;

判定表

​

合并使用-代表无关条件,选择什么都不影响结果

这种简化写法并不常用.因为在使用的时候还是要将它展开来使用滴.
强烈建议不要去简化写法.

6. 场景法

• 场景法就是模拟用户操作软件时的场景，主要用于测试系统的业务流程
  • 当拿到一个测试任务时，我们并不是先关注某个控件的边界值、等价类是否满足要求，而是先要关注它的主要功能和业务流程是否正确实现，这就需要使用场景法来完成测试。
  • 当业务流程测试没有问题，也就是该软件的主要功能没有问题时，我们再重点从边界值、等价类等方面对控件进行测试
• 在冒烟测试时也主要采用场景法进行测试

6.1 场景法中两个重要概念

• 基本流(正确的流程)
  • 按照正确的业务流程来实现的一条操作路径（模拟正确的操作流程）
• 备选流(错误的流程)
  • 导致程序出现错误的操作流程(模拟错误的操作流程);
  • 用例场景是用来描述流经用例路径的过程，这个过程从开始到结束遍历用例中所有基本流和备选流
  • 冒烟测试就是使用此种方法来使用的.

6.2 用例场景产生的背景

现在的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景。而同一事件不同的触发顺序和处理结果形成事件流。

将这种在软件设计方面的思想引入到软件测试中，生动的描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时测试用例也更容易的得到理解和执行。

• 在使用场景法设计测试用例时，需要覆盖系统用例中的主要场景和扩展场景，并且需要适当补充各种正反面的测试用例和考虑出异常场景的情形。
• 当使用场景法测试程序没有问题时，可以再使用边界值、等价类方法对账号、密码进行更加细致、完整的测试。

7 流程分析法

流程分析法主要是针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计，是从白盒测试设计方法中的路径覆盖分析法借鉴过来的一种方法。

• 在白盒测试中，路径就是指函数代码的某个分支组合，路径覆盖法需要构造足够的用例覆盖函数的所有代码路径。
• 在黑盒测试中，若将软件系统的某个流程看成路径的话，则可以针对该路径使用路径分析的方法设计测试用例。

7.1 优点

• 降低了测试用例设计难度，只要搞清楚各种流程，就可以设计出高质量的测试用例来，而不需要太多测试方面的经验；
• 在测试时间较紧迫的情况下，可以有的放矢的选择测试用例，而不用完全根据经验来取舍.

7.2 步骤

1. 详细了解需求
2. 根据需求说明或界面原型，找出业务流程的各个页面以及各页面之间的流转关系；
3. 画出业务流程（产品经理使用Axure软件制作）
4. 写用例，覆盖所有的路径分支

7.3 流程分析法总结

• 流程分析法适用于有先后顺序的测试。常用于业务流程测试、安装流程测试等
• 流程分析法重点在于测试流程。因此，一般每个流程用一个测试用例验证。
• 特别注意:
  • 流程测试没有问题并不能说明系统功能没有问题，还需要针对每步功能进行测试。对于包含复杂流程的系统，只有功能点和处理流程都进行测试覆盖，才算是比较充分的测试。

8 错误推测法

错误推测法是指利用直觉和经验猜测出出错的可能类型，有针对性列举出程序中所有可能的错误和容易发生错误的情况，它是测试经验丰富的测试人员喜欢使用的一种测试用例设计方法。

8. 1 基本思想

基本思想是列举出可能犯的错误或错误易发生的清单，然后根据清单编写测试用例；这种方法很大程度上是凭经验进行的，即凭人们对过去所作测试结果的分析，对所揭示缺陷的规律性作直觉的推测来发现缺陷。

• 采用错误推测法，最重要的是要思考和分析测试对象的各个方面，多参考以前发现的Bug的相关数据、总结的经验，个人多考虑异常的情况、反面的情况、特殊的输入，以一个攻击者的态度对待程序，才能够设计出比较完善的测试用例.

9. 总结

测试用例书写分类

本篇完

谢谢阅读