1.测试用例的概念和作用

1.1.引言

对一个测试工程师来说,测试用例的设计编写是一项必须掌握的能力，但有效的设计和熟练的编写测试用例却是一个十分复杂的技术，测试用例编写者不仅要掌握软件测试技术和流程，而且要对整个软件不管从业务，还是对软件的设计、程序模块的结构、功能规格说明等都要有透彻的理解。
测试的设计方法不是单独存在的，具体到每个测试项目里都有很多种方法，每种类型都有各自的特点。

1.2. 测试用例的定义：

1.2.1.什么是测试用例？

测试用例是执行测试的依据，把测试系统的操作步骤用文档的形式描述出来。
任意的测试用例都含有

（1）测试用例是为达到最佳的测试效果或高效的揭露隐藏的错误，而精心设计的少量测试数据，包括测试输入、执行条件和预期的结果，实际结果
（2）测试用例是执行的最小实体。
（3）测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障

1.2.2.测试用例的特征：

1、正确性：测试用例最好是要求输入用户实际数据已验证系统是否满足需求规格说明书的需求，并且测试用例中的测试的应保证至少覆盖需求规格说明书中的各项功能。
2、完整性：一些基本功能，如有遗漏，那是不可原谅的。
3、准确：按测试用例输入实施测试后，要能根据测试用例描述的输出得出正确的结论，不能出现模糊不清的语言。
4、清晰、简洁：好的测试用例描述清晰，每一步都应有相应的作用，有很强的的针对性，不应出现一些无用的操作步骤。
5、可维护性：由于软件开发过程中需求变更等原因的影响，常常对测试用例进行修改、增加、删除等，以便测试用符合相应测试要求。
6、适应性：测试用例应该适合特定的测试环境以及符合整个团队的测试水平。
7、可重复性：要求不同测试者在同样的测试环境下使用同样测试用例都能得出相应结论。
8、可追溯性、可移植性

1.3.编写测试用例的好处

1.1.3.测试用例的作用：

在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。
测试用例的使用令软件测试的实施重点突出、目的明确。
在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。
检验软件是否满足客户需求、体现一个测试人员的工作量、展现测试用例的设计思路
功能模块的通用化和复用化使软件易于开发，而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。

2.需求分析

2.1.什么是需求？

客户的需要的东西以及对东西的要求

2.2.需求的种类有什么？

1. 用户需求：关注系统是否满足用户习惯
2. 行业业务需求（界面提示信息为行业术语，处理和操作模式为行业从业人员习惯模式等）
3. 实际使用环境需求（网络带宽，速率，断电数据备份，软件部署设置等）
4. 操作使用需求（类似快捷键，紧急关闭，数据恢复保护，回退机制，安装兼容性，语言环境等）
5. 用户需求引发的测试需求（按软件测试质量模型进行划分）
6. 功能需求：关注系统是否满足功能要求

3.测试用例的设计方法和编写

3.1.如何设计测试用例？

对各个功能模块进行测试点分析提取测试点再对测试点进行用例编写
比如对PC端QQ账号的登录模块，提取测试点就有：

image.png

①正常登陆 ②账号为空时点击登录 ③密码为空时点击登录 ④账号密码都为空时点击 登录 ⑤密码错误时点击登录 ⑥找回密码功能是否有效 ⑦记住密码功能是否有效 ⑧ 自动登录功能是否有效9 多个qq号登录10.二维码扫描登录

3.2.编写测试用例该注意什么？

• 根据产品规格，测试基本功能；
• 考虑设计一般用户（非专业人员）的使用方案；
• 考虑设计稀有或特殊的使用方案；
• 与系统其他组成部分的配合（如FAX和上网可能要用到MODEM，？测试中考虑对设- 备的共享）；
• 考虑特殊情况（如内存和硬件的冲突等）；
• 设计极端情况（如内存泄漏、破坏性测试等）；
• 好的测试用例集能花费最小的代价（人力、物力、财力、时间）做最好的测试。

3.3.测试用例的4个特性

• 代表性：能够代表并覆盖各种合理的和不合理、合法的和不合法的、边界的和越界的以及极限的输入数据、操作等。
• 针对性：对程序中的可能存在的错误有针对性地测试
• 可判定性：测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果
• 可重现性：对同样的测试用例，系统的执行结果应当是相同的。
  第一个数字 和 第二个数字都为 0-10 之间的数 计算结果
  ？ + ？ = ？

1-10 1 -10 正向测试用例
反向

3.4.测试用例通常包括以下几个组成元素：

测试用例编号 测试用例名称 测试用例设计者 软件版本号 测试目的
参考信息 测试环境 输入数据 操作步骤 预期结果 测试结果 测试功能模块

3.5.测试用例示例

image.png

image.png

笔试题： 你用到的测试方法/测试策略有哪些？
等价类划分 边界值 因果图 场景法 正交表

4.编写测试用例的基本方法

4.1.等价类划分法

1.1.4.概念

等价类划分是把所有可能输入的数据分为若干个区域，然后从每个区域中取少量有代表性的数据进行测试即可。
等价类 ：何为等价类，某个输入域的集合，在这个集合中每个输入条件都是等效的。
一般可分为有效等价类和无效等价类

比如：在一个系统中，填写一个多少岁的未成年人数学考了多少分（假设成年人年龄为x,0<x<=18,数学成绩为y：0<=y<=100
那么年龄按照等价类划分可分为x<0,0<x<=18,x>18,有效等价类是0<x<=18，无效等价类是x<0，x>18
数学成绩按照等价类划分可分为y<0,0<=y<=100,y>100,有效等价类是0<=y<=100，无效等价类是y<0，y>100

1.1.5.示例

计算两个1～100之间整数的和。
如果要进行完全测试，一共要设计多少个测试用例呢？
加数1有1～100共计100个取值，加数2也有1～100共计100个取值，所以他们之间的组合就有100*100=10000种组合可能，但这只是测试了正常范围内的取值。如果用户输入的数据不在1～100之间呢，穷举测试肯定不可能的。由此引入了等价类划分思想。
等价类划分为：
有效等价类：指符合《需求规格说明书》，输入合理的数据集合
无效等价类：指不符合《需求规格说明书》，输入不合理的数据集合

image.png

我们将输入域分成了一个有效等价类（1～100）和两个无效等价类（<1和>100），并为每一个等价类进行编号，然后我们就可以从每一个等价类中选取一个代表性的数据来测试，设计如下表所示的测试用例

image.png

1.1.6.练习案例:

image.png

划分等价类并编号,下表为等价类划分的结果

image.png

4.2.边界值法

定义：边界值分析是取稍高于或稍低于边界的一些数据进行测试。
原因：程序开发循环体时的取数可能会因为<,<=搞错。
比如下面代码：

//有效等价划分    -1   0    100  101  
for(int i = 0;i <100; i ++) {   
　　int j = i+1;
　　System.out.println("循环第“+j+"次")//循环地做某件事情
}

这里的程序是循环了100次，所以会做100次;
如果程序员不小心，把i <100写成i <= 100，则会溢出，这时候边界值检查是一个很好的测试方法。
比如：在一个系统中，填写一个多少岁的成年人数学考了多少分（假设成年人年龄为x,0<x<=18,数学成绩为y：0<=y<=100
根据上面的等价类划分法我们可知，年龄的有效等价类是0<x<=18，所以边界值就是0，1，18，19
数学成绩的,有效等价类是0<=y<=100，所以边界值就是-1，0，100，101

对数据进行软件测试，就是在检查用户输入的信息、返回的结果以及中间计算结果是否正确。即使最简单的程序要处理的数据量也可能极大，使这些数据得以测试的技巧是，根据一些关键的原则进行等价类的划分，以合理减少测试用例，这些关键的原则是：边界条件，次边界条件、空值和无效数据。

1.1.7.确定边界值的方法（）

• 确定边界情况（输入或输出等价类的边界）
• 选取正好等于、刚刚大于或刚刚小于边界值作为测试数据
  输入要求是1 ～ 100之间的整数，因此自然产生了1和100两个边界，我们在设计测试用例的时，要重点考虑这两个边界问题。
  
  image.png
  
  注明:边界值不是从每个等价类中挑一个作为代表，而是把每个等价类的边界都进行测试。

4.3. 因果图法

1.1.8.概念

因果图法比较适合输入条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出。

1.1.9. 因果图基本图形符号

恒等：若原因出现，则结果出现；若原因不出现，则结果不出现。
非（～）：若原因出现，则结果不出现；若原因不出现，则结果出现。
或（∨）：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现。
与（∧）：若几个原因都出现，结果才出现；若其中有一个原因不出现，则结果不出现。

image.png

1.1.10.因果图的约束符号

E（互斥）：表示两个原因不会同时成立，两个中最多有一个可能成立
I（包含）：表示三个原因中至少有一个必须成立
O（惟一）：表示两个原因中必须有一个，且仅有一个成立
R（要求）：表示两个原因，a出现时，b也必须出现，a出现时，b不可能不出现
M（屏蔽）：两个结果，a为1时，b必须是0，当a为0时，b值不定

image.png

1.1.11.因果图测试用例

例如：有一个处理单价为2.5元的盒装饮料的自动售货机软件。若投入2.5元硬币，按“可乐”、“啤酒”、或“奶茶”按钮，相应的饮料就送出来。若投入的是3元硬币，在送出饮料的同时退还5角硬币。

分析这一段说明，我们可列出原因和结果
原因(输入)：
投入2.5元硬币；
投入3元；
按“可乐”按钮；
按“啤酒”按钮；
按“奶茶”按钮。
中间状态： ① 已投币；②已按钮
结果(输出)：
退还5角硬币；
送出“可乐”饮料；
送出“啤酒”饮料；
送出“奶茶”饮料；

image.png

判定表法

image.png

image.png

4.4.场景法

4.4.1. 场景法基本原理

原理：

• 现在的软件几乎都是用事件触发来控制流程的。测试时，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。

• 基本流：软件功能按照正确的事件流实现的一条正确的流程。

• 备选流：除了基本流之外的各支流，包含多种不容情况。

  
  
  image.png
  
  

  如图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。

• 场景模板
  遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：
  场景 1 基本流
  场景 2 基本流 备选流 1
  场景 3 基本流 备选流 1 备选流 2
  场景 4 基本流 备选流 3
  场景 5 基本流 备选流 3 备选流 1
  场景 6 基本流 备选流 3 备选流 1 备选流 2
  场景 7 基本流 备选流 4
  场景 8 基本流 备选流 3 备选流 4
  注：为方便起见，场景 5、6 和 8 只描述了备选流 3 指示的循环执行一次的情况。

• 注意

1. 场景中必须有基本流
2. 场景中必须有内容从用例开始，到用例结束。

4.4.2. 银行案例ATM

个人标识号 (PIN＝personal identification number )，用于保护智能卡免受误用的秘密标识代码。PIN 与密码类似，只有卡的所有者才知道该 PIN。只有拥有该智能卡并知道 PIN 的人才能使用该智能卡

流.png

image.png

第一次测试中，根据测试计划，我们需要核实提款用例已经正确地实施。此时尚未实施整个用例，只实施了下面的事件流：
基本流-提取预设金额（100 元、200元、500元、1000元）
备选流2 - ATM 内没有现金
备选流3 - ATM 内现金不足
备选流4 - PIN 有误
备选流5 - 帐户不存在/帐户类型有误
备选流6 - 帐面金额不足

image.png

image.png

4.4.3. 设计用例步骤

1. 根据说明，描述出程序的基本流和各项备选流
2. 根据基本流和各项备选流生成不同的场景
3. 对每一个场景生成响应的测试用例
4. 对生成的所有测试用例重新复审，去掉多余的测试用例
5. 测试用例确定后，对每一个测试用例确定测试数据值
   注意：
6. 场景法使用与解决业务流程清晰的系统或功能。
7. 每一个场景，都是一个测试用例。

4.5.错误推测法

错误猜测法是测试经验丰富的人喜欢使用的一种测试用例设计方法。
一般这种方法是基于经验和直觉推测程序中可能发送的各种错误，有针对性地设计。只能作为一种补充。

例如，测试手机终端的通话功能，可以设计各种通话失败的情况来补充测试用 例：

1. 无SIM 卡插入时进行呼出（非紧急呼叫）
2. 插入已欠费SIM卡进行呼出
3. 射频器件损坏或无信号区域插入有效SIM卡呼出
4. 网络正常，插入有效SIM卡，呼出无效号码（如1、888、333333、不输入任何号码等）
5. 网络正常，插入有效SIM卡，使用“快速拨号”功能呼出设置无效号码的数字

技巧：最重要的是要思考和分析测试对象的各个方面，多参考以前发现的bug的相关数据，总结的经验，个人多考虑异常的情况、反面的情况、特殊的输入，以一个攻击者的态度对待程序，就能设计出比较完善的测试用例来。

4.6.正交表法

1. 概述

• 日本人提出
• 使用工具：正交表
• 正交实验法就是利用排列整齐的表 -正交表来对试验进行整体设计、综合比较、统计分析，实现通过少数的实验次数找到较好的生产条件，以达到最高生产工艺效果。
• 这种试验设计法是从大量的试验点中挑选适量的具有代表性的点，利用已经造好的表格—正交表来安排试验并进行数据分析的方法。
• 正交表能够在因素变化范围内均衡抽样，使每次试验都具有较强的代表性，由于正交表具备均衡分散的特点，保证了全面实验的某些要求，这些试验往往能够较好或更好的达到实验的目的。
• 正交实验设计包括两部分内容：第一，是怎样安排实验；第二，是怎样分析实验结果。

2. 应用场景
   在一个界面中有多个控件，每个控件有多个取值，控件之间可以相互组合，不可能（也没有必要）为每一种组合编写一条用例，如何使用最少最优的组合进行测试。——正交排列法

3. 判定表
   因果图也是考虑控件组合，但是组合数量较少（一般不会超过20中）
   公式：L_n(m^k)
   k是表的列数，表示控件的个数（因数个数）
   m是每个控件的取值个数（因数水平）
   n是表的行数，也就是需要测试组合的次数
   正交表查询地址：https://www.york.ac.uk/depts/maths/tables/orthogonal.htm
   正交排列法：http://support.sas.com/techsup/technote/ts723_Designs.txt
   

   image.png
   
   
   image.png

4. 使用正交设计助手
   （1）下载解压正交设计助手
   （2）文件新建工程
   （3）实验新建实验
   ①实验说明
   

   实验说明.png
   
   ②选择正交表
   
   选择正交表.png
   
   ③因素与水平
   
   因素与水平.png
   
   ④确定
   
   结果.png

• 正交表测试用例设计方法的特点是什么？
  1、用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂；
  2、对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷，更复杂的缺陷，还是无能为力 的；
  3、体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法。

5. 测试用例的评审和变更

（1）变更背景
测试用例并非一成不变。如果软件修改之后发生变化，或者需求发生变更，那么测试用例便不再满足当前版本软件的测试需求，由此需要进行修改和变更操作。
（2）测试用例评审
首先要清楚评审的定义，是测试组内部的评审，还是项目组内部的评审。评审的定义不同，内容也不会相同。

• 如果是测试组内部的评审，应该着重于：

1. 测试用例本身的描述是否清晰，是否存在二义性；
2. 是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下；
3. 是否针对需求跟踪矩阵，覆盖了所有的软件需求；
4. 是否完全遵守了软件需求的规定。这并不一定的，因为即使再严格的评审，也会出现错误，应具体情况具体对待。

• 如果是项目组内部的评审，也就需要评审委员会来做了，角度不同，评审的标准也不同。比如收集客户需求的人员注重你的业务逻辑是否正确，分析软件需求规格的人注重你的用例是否跟规格要求一致，开发负责人会注重你的用例中对程序的要求是否合理。

测试用例的评审能够使用例的结构更清晰，覆盖的用户场景更全面对于测试工程师来说也是一个快速提高用例设计能力的过程。
1、需要评审的原因
测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。由于用例开发人员的设计经验和对需求理解的深度各不相同，所以用例的质量难免会有不同程度的差异。

2、进行评审的时机
一般会有两个时间点。第一，是在用例的初步设计完成之后进行评审第二是在整个详细用例全部完成之后进行二次评审。如果项目时间比较紧张，尽可能保证对用例设计进行评审，提前发现其中的不足之处。
3、参与评审人员
这里会分为多个级别进行评审。
1)部门评审，测试部门全体成员参与的评审。
2)公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。
3)客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。

4、评审内容
评审的内容有以下几个方面
1)用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
2)优先极安排是否合理。
3)是否覆盖测试需求上的所有功能点。
4)用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确期待结果是否有明显的验证方法。
5)是否已经删除了冗余的用例。
6)是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在"保护"20%的功能实现。
7)是否从用户层面来设计用户使用场景和使用流程的测试用例。
8)是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

个人认为，一个"健康"的测试用例至少要通过前5个标准。

5、评审的方式
1)召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。
2)通用邮件与相关人员沟通
3)通用IM工具直接与相关人员交流
方式只是手段，得到其它人员对于用例的反馈信息才是目的。
无论采用那种方式，都应该在沟通之前把用例设计的相关文档发送给对方进行前期的学习和了解，以节省沟通成本。

6、评审结束标准
在评审活动中会收集到用例的反馈信息，在此基础上进行用例更新，直到通过评审。

6. 测试用例基本思路

QQ邮箱登录模块

QQ邮箱登录.png