[开发测试]＜笔记＞ 软件测试(4) 测试用例和设计方法

1 测试用例

1.1 测试用例的定义

• 设计一个情况，软件程序在这种情况下，必须能够正常运行并达到程序所设计的预期结果。
• 如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示软件程序人员已经测出软件有缺陷，这时候就必须将问题标识出来，并通知开发人员。软件开发人员接到通知后，将这个问题修改完成于下一个测试版本内。
• 软件测试人员取得新的测试版本后，必须利用同一个用例来测试上述出现的缺陷问题，确保该问题已修改完成。

测试用例模板：

测试用例说明：

• 用例编号：一般编号规则：TestCase_项目名称_模块名称_功能名称_0001
• 测试项：测试用例的测试目的。一般情况下，用一句话表明目的。（表明测试模块、测试对象、方式、事件）。
• 依赖用例：一般功能流程上，下游的功能测试依赖于上游的功能测试的用例。
• 测试步骤：用最朴实的语言，写出来软件的操作步骤。要尽量详细。
• 测试数据：单独整合测试数据。必须和测试步骤中的数据保持一致。
• 预期结果：对象的准确，内容的准确。原则上每一个操作，都要有一个结果。在重要步骤之后，设定预期结果。一般和测试目的密切相关。
• 测试结果：要求在测试执行完成后添加。没有执行保持为空。测试结果只有两种：通过/失败；Pass/Failed。
• 测试人：测试的执行人。可以和设计者相同或不同。
• 备注：为了测试用例正常执行而做的特殊准备。

测试用例可以分为：功能（Function）、界面（UI）、性能（Performance）、安全（Security）、接口（Interface）

1.2 用例设计和编写的作用

• 有效性：测试用例是测试人员测试过程中的重要参考依据。
• 可复用性：良好的测试用例具有可重复使用的功能，提高测试效率。
• 易组织性：即使是小项目，也可能会有几千甚至更多的测试用例，测试用例可能数月甚至几年的测试过程中被创建和使用。
• 可评估性：从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保证。
• 可管理性：测试用例也可以作为检验测试人员进度、工作量以及跟踪/管理测试人员的工作效率的标准。

2 测试用例编写注意事项

• 不要设计“穷举测试用例”
• 在详细测试用例与有效测试时间中找到平衡点
• 好的测试用例应该多关注“反向测试问题”
• 测试用例库应该不断更新和维护
• 测试用例可以复用，但要注意数据有效性与环境变化
• 测试用例是设计出来的，不是写出来的
• 多去学习经验丰富的测试工程师所设计的测试用例
• 针对不同的需求类型和测试对象，灵活采用不同的测试用例设计方法

3 黑盒测试用例设计方法

3.1 测试数据选择

等价类划分法

1. 原理：

• 把程序的输入域划分为若干部分，然后从每个部分中选取少量数 代表性数据作为测试用例
• 每一类的代表性数据在测试中的作用等价于这一类中其他值，如果某一类中的一个数据发现错误，那么这一等价类中的其他例子也能发现同样的错误
• 反之，如果某一类中的一个数据没有发现错误，则这一类中的其他数据也不会发现错误

2. 步骤：

（1）确定等价类原则：

• 输入条件给出取值范围或值的个数时，可以确定一个有效等价类和两个无效等价类
• 输入条件给出输入值的集合或规定 “必须如何让”的条件时，可以确定一个有效等价类和一个无效等价类
• 输入条件为布尔量时，可确定一个有效等价类和一个无效等价类
• 规定输入值为一组（若为n个），并且程序要对每一个输入值分别处理时，可确定n个等价有效类和一个无效等价类
• 规定了输入数据必须遵守的规则时，可确定一个等价有效类（符合规则）和若干个无效等价类（从不同角度违反规则）
• 在已知划分的等价类中，各元素在程序中处理方式不同时，应该将该等价类进一步划分为更小的等价类

（2）划分等价类和列出等价类表：

• 有效等价类
• 无效等价类

（3）确定测试用例

• 为每个等价类规定一个唯一编号。
• 设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例覆盖。 设计一个新的测试用例，使其覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖。

以百度注册页面为例进行分析：
用户名：设置后不可更改；中英文均可；最多14个英文或7个汉字；
（隐性条件：用户名不可重复；不可为空；）

• 将等价类划分组成表格分析：

• 编写测试用例：
  

边界值分析法

1. 原则

• 如果输入条件规定了值的范围，则应取刚达到这个范围的值，以及刚刚超过这个范围边界的值作为测试输入数据。
• 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据
• 分析规格说明，找出其他可能的边界条件。根据规格说明，使用上两条
• 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例
• 如果程序中使用了一个内部数据结构，则应该选择这个内部数据结构边界上的值作为测试用例
  
  边界值只是一个特定的数据。例如文本框需要输入6到18位字符。边界值有：1）6个字符；2）18个字符。
  次边界：边界附近的值，按照系统规定的单位或者计算方式，一个数据的差异。

举例： 1）6≤x≤12，测试中x的边界值要选取哪几个值进行测试？
5，6，7，11，12，13
2）6＜x＜12，测试中x的边界值要选取哪几个值进行测试？
6，7，11，12

实战案例

• 一个程序读入3个整数，把这3个数值看作是一个三角形的3条边的长度值。
• 这个程序会给出弹窗提示信息，说明这个三角形是普通的、是等腰的、是直角的、还是等变的，以及相应的错误提示信息。
• 等价类划分
  
• 测试用例
  

3.2 测试步骤设计

因果图法

• 因果图法是一种适合于描述对于多种输入条件组合的测试方法；
• 根据输入条件的组合、约束关系和输出调价的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法
• 适合于检查程序输入条件涉及的各种组合情况

• 画图步骤
  step1： 根据功能说明书中规定的原因结果之间的关系画出因果图

• 原因和结果的关系
  恒等：原因A成立，结果B一定成立
  非：原因A成立，结果B一定不成立
  或：原因A、B、C三者只要一个成立，结果D一定成立
  与：原因A、B、C三者都成立，结果D成立

step2： 根据功能说明在因果图中加上约束条件

假如原因成立用1表示，不成立用0表示，则

• 原因之间的约束：
  互斥（exclusive）：不同时为1，即A+B+C≤1
  包含（include）：至少一个为1，即 1≤A+B+C≤3
  唯一（only）：有且仅有一个为1，即A+B+C=1
  要求（request）：原因B成立，要求A先成立
• 结果之间的约束：
  屏蔽（mask）：结果A出现，结果B一定不出现，即A=1，则B=0。例如：提示注册账号成功时，就一定不会收到数据填写错误的提示。

• 因果图使用实例
  有一个饮料自动售货机（处理单价为5角钱）的控制处理软件，它的软件规格说明如下：

  • 若投入5角钱的硬币，按下“橙汁”或“啤酒”的按钮，则相应的饮料就送出来
  • 若投入1元钱 的硬币，同样也是按“橙汁”或“啤酒”的按钮，则自动售货机在送出相应饮料的同时退回5角钱硬币。

  阅读和分析功能说明书，识别出“原因”和“结果”，并加以编号。

第一步：分析原因和结果；
第二步：画出原因和结果之间的关系；
第三步：根据需求描述原因、结果间的约束；

因果图使用中的局限性： 当原因和结果很多时，他们之间的关系连线就会很多，导致因果图可读性变差。因此常用于局部小功能（原因和结果不多）分析。

第四步：列出所有原因和结果的列表，设计初步的测试用例步骤；
C5是一种bug，不能做测试设计。
经分析发现：
1）只选择饮料，没有投币时，软件没有任何结果。
2）只投币，没有选择饮料的时候，软件没有任何结果。
3）不能把软件的缺陷设计成测试用例。

因果图优势在于能够发现设计中存在的不足。

第五步：写测试用例。

判定表法

判定表法是分析和表达多逻辑条件下执行不同操作的情况工具。主要适用于多条件的内容组合与结果分析。它由以下几个内容组成：

• 条件桩（Condition Stub）：列出了问题的所有条件。通常认为列出条件的次序无关紧要。
• 动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排序顺序没有约束。
• 条件项（Condition Entry）：列出针对它所列条件的取值。在所有可能情况下的真（1）假（0）值。
• 动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
  使用条件： 所有的条件桩在表中的位置和顺序互不影响；所有的动作桩的顺序不会因为条件顺序的变化而产生不同。
  实现步骤：
  1）识别出 操作条件（原因）和对应的动作（结果）；
  2）分析条件的条件项（组合数量）：如果有n个条件，每个条件有成立和不成立两种情况，那么最后一共会有2ⁿ个数量；
  3）简化和优化结果，排除一些不可能存在的情况。

判定表使用实例1
需求：订购单的检查

• 如果金额超过500元，又未过期，则发出批准单和提货单；
• 如果金额超过500元，但过期了，则不发批准单；
• 如果金额低于500元，则不论是否过期都发出批准单和提货单，在过期的情况下还需要发出通知单。

第一步：分析条件桩和动作桩、条件项和动作项

第二步：列出条件桩、动作桩、条件项、动作项

第三步：对判定表进行简化和优化
由上表看出，只要未过期，就会发批准单、提货单。（在测试时间不充足的情况下，可以选择二者中的一个情况测试）

第四步：将判定表中的每一列（条件项和对应的动作项）作为测试用例的数据、操作以及对应的的预期结果

判定表使用实例2

该判定表为某杂志的阅读指南判定，指导读者能够良性阅读。请对该判定表进行优化，将重复内容去掉，并说明原因。
1）合并1，2，3，4。只要疲倦就休息
2）合并7，8.只要疲倦且不感兴趣就跳下一章

场景法

• 原理
  • 现在的软件几乎都是用事件触发来控制流程的。测试时，可以生动地描绘出事件触发时地情景，有利于设计测试用例，同时使测试用例更容易理解和执行。
  • 基本流：软件功能按照正确的事件流实现的一条正确流程。通常一个业务仅存在一个基本流，且基本流仅有一个起点和终点。（软件功能正确实现的流程）
  • 备选流：除了基本流之外的各种支流，包含多种不同的情况。（基本功能流程之外的过程）
    
• 场景设计：
  • 场景1：基本流
  • 场景2：基本流 备选流1
  • 场景3：基本流 备选流2
  • 场景4：基本流 备选流1 备选流2
  • ……
• 设计用例的步骤
  • 根据说明，描述程序的基本流及各项备选流
  • 根据基本流和各项备选流生成不同的场景
  • 对每一个场景生成相应的测试用例
  • 对生成的所有测试用例重新复审，去掉多余的测试用例
  • 测试用例确定后，对每一个测试用例确定测试数据值

案例：ATM机的取款流程
基本流：

包含备选流的过程：

正交实验法

• 原理
  正交实验法就是利用 排列整齐的表——正交表 来对试验进行整体设计、综合比较、统计分析，实现通过少数的实验次数找到较好的生产条件，以达到最好效果。（由日本统计学家发明）
  这种试验设计法是从大量的试验点中挑选适量的具有代表性的点，利用已经造好的表格——正交表来安排试验并进行数据分析的方法。

• 核心概念
  1）试验因素（因子）、因素：影响实验结果的量
  2）水平：每一个因素的不同取值（状况）
  3）正交表特点：每列中不同数字出现的次数相等；任意两列组成的数字对出现的次数相等

• 正交实验法实现步骤
  1）分析所有对结果有影响的因素。从多个角度和方式进行分析（不要放过文本框、按钮等需求中提及或者没有提及的）
  2）分析每个因素的水平数量。充分利用等价类、边界值（需求中说明和未说明的都要分析）
  3）选择正交表。只有特定的因素数和水平数的组合才有对应的正交表。所以在现实中用到的时候，找最贴近的正交表（正交表的因素数和水平数一般要大于实际的因素数和水平数）

• 正交实验法表示

  • 正交表：一般正交表记为 L _n（m ^k）
  • n：试验次数，m：水平数 ，k：因素数
  • 仅适用于每一个因素的水平数都相同的正交表

• 实际案例

完全排列组合：3 * 3 * 3 = 27
使用正交实验助手：latin、blend，设计正交实验（3水平4因素9次实验）

生成正交实验计划表。每一列中，同一个数字出现的次数相等（3次），任意两列中，同一个数字对出现的次数相等。

功能图法

功能图法又叫状态迁徙图。

• 来源：在遇到有事务流或由于某种条件成立导致状态改变的软件时，如何测试用例的设计就比较麻烦。
• 状态迁徙图法的目标：设计足够多的测试用例达到对系统状态的覆盖、状态-条件组合的覆盖以及状态迁移路径的覆盖。
• 以操作系统的进程调度算法为例：

• 功能图法步骤

  • 列出所有可能的输入事件，以ip(inout) N的方式命名（N为1，2，3，……）
  • 把软件的打开 的初始状态定义为“空闲”状态
  • 在“空闲”状态上加所有可能的输入（只加一次）
  • 为上一步产生的新状态 加操作（只加一次 ，曾经加过的操作不能重复添加）
  • 循环执行上一步，直到没有新状态产生为止
  • 组合任意的状态，以列表的形式展现，设计和编写测试用例

  案例分析：以QQ登录界面为例，说明功能的变迁
  1）识别可以进行的操作：
  ip1：输入账号
  ip2：输入密码
  ip3：点击登录
  ip4：点击关闭按钮
  2）定义QQ登录界面为 空闲状态；
  3）给空闲状态加操作；
  （第一轮）
  
  第一轮分析产生了新的状态，针对新的状态进行分析
  （第二轮）
  
  第二轮分析产生了新的状态，针对新的状态进行分析
  （第三轮）
  
  虽然得到了一个新的状态（QQ主界面），但是和空闲状态 发生了“隔断”，因此将其视为空闲状态的结束，故可以结束分析过程。
  4）将状态变化过程列表化，准备设计测试用例。

设计用例的时候：
1）A列：从QQ的登录界面，直接点击关闭按钮， QQ登录退出
2）B列：从QQ的登录界面，先输入QQ号（状态变为QQ号已输入）；再点击关闭按钮， QQ登录退出
3）C列：从QQ的登录界面，先输入密码（状态变为密码已输入）；再点击关闭按钮， QQ登录退出
4）D列：从QQ的登录界面，先输入QQ号（状态变为QQ号已输入）；再输入密码（状态变为QQ号、密码已输入），点击登录，状态就会变成QQ主界面

测试用例的设计争取达到：“大道至简，大巧若拙”。越自然越好 。

3.3 其他用例设计方法

测试大纲法

• 一种着眼于需求的方法。
• 为列出各种测试条件，将需求转换为大纲的形式（思维导图、树形结构）。
• 无需用例设计。一般从根节点开始分析，到叶节点为止。这样的一条路径就是一条测试用例。
• 一般用于快速的测试和过程记录。用例一般进行后补。

探索性测试法

• 基于经验和直觉的测试方法。
• 是计划内测试用例设计的补充。
• 探索性测试在执行前也需要设计测试用例。

猴子测试（随意测试）

• 没有测试用例（无意识行为）。
• 测试往往不真实。
• 不能达到一定覆盖率。
• 许多测试都是冗余的。
• 需要使用同样的随机数进行重建测试。

4 用例测试方法综合选择

• 首先进行等价类划分。
• 在任何情况下都必须使用边界子分析方法。
• 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法。
• 对于参数配置类的软件，要用正交实验法选择较少的组合方式达到最佳效果。
• 状态迁徙图可以通过不同时期条件的有效性设计不同的测试数据。
• 对于业务流清晰的系统，可以用场景法贯穿整个测试案例过程。
• 可以用错误推测法追加一些测试用例
• 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例

以某教育APP为例进行分析

• 启动页，需求如下：
  1）读取版本更新信息。匹配当前APP与线上需要更新的APP版本是否一致；
  2）读取用户信息。未登录用户，则不用获取。已登录用户，验证是否登录过期。
  
  用例设计方法：采用场景法
  设计场景：
  1）APP的安装版本比最新版要低。启动就需要进行版本检测，并进行提示。
  2）APP安装版本与最新版一样。默认检测过程成功。
  3）APP启动检测用户登录状态，如果登录过期或者未登录，启动完成后直接跳转登录界面。
  4）APP启动检测用户登录状态，如果登录信息有效，启动完成后直接跳转至首页界面。

• 登录界面，需求如下：
  1）手机号：暂时只支持大陆手机；
  2）验证码：长度为6位数字；
  3）短信验证码文本内容：【正教】456712（正交验证码），30分钟内有效，为确保您账号安全，请勿把验证码告诉他人。感谢您关注正教！
  4）登录按钮点击后，出现弹窗提示，显示1s后消失。
  
  用例设计方法：等价类划分法、边界值分析法、因果图法
  等价类划分法：
  1）手机号的有效性。
  2）验证码包含不符合要求的字符。
  边界值分析法：
  1）手机号超过/不足长度要求。
  2）验证码超过/不足长度要求。
  3）使用超过有效期的验证码。
  4）弹窗提示超过或者不足1s。
  因果图法：
  1）提交数据时，网络中断，出现网络异常的提示。
  2）提交数据时，服务端崩溃或者无法提供正常服务，有服务器报错提示或者等待提示。
  3）提交数据时，手机号不符合要求（不存在），有手机号错误提示。
  4）提交数据时，验证码输入超时或不是收到的验证码，有验证码错误提示。

• 课程内容页，需求如图所示：
  用例设计方法：场景法、等价类划分法、边界值法
  场景法，设计场景：
  1）老师发布作业，学生提问。该课程今日有作业，有提问内容展示。
  2）老师发布作业，学生没有提问。该课程今日有作业，无提问内容展示。
  3）老师没有发布作业，学生提问。该课程今日没有作业，有提问内容展示。
  4）老师发布没有作业，学生美哟提问。该课程今日没有作业，无提问内容展示。
  等价类划分法、边界值法：
  1）日期显示是否超出天数：2017年2月是否出现29日
  2）日期显示是否重复：
  3）日期显示是否前后连续：

• 正交实验法较为特殊，一般用于系统设置页面，如下图所示：