目录
1. 测试用例的基本要素
测试用例是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：
测试环境、操作步 骤、测试数据、预期结果等要素。
测试用例是方便于测试人员直接拿来测试的，不熟悉业务的人也能很快入手
评价测试用例的标准：
1）用例表达清楚，无二义性2）用例可操作性强。3）用例的输入与输出明确。一条用例只有一个预期结果。4）用例的可维护性好。5）用例对需求的覆盖率高，6）暴露程序Bug的能力强力。
1.1 测试用例 ：单位用户注册成功
|
步骤动作
:
|
期望的结果
:
|
|
进入注册页面，选择注册
|
系统展现注册页面
|
|
输入符合要求的单位名称、单位邮箱、密码、确认密码、 组织机构代码、验码，并确认同意《用户注册协议》， 提交注册信息
|
系统进行注册操作，发送激活邮件。注册成 功后，跳转到注册成功页面，并提示用户进行激活操作。
|
|
进入注册用的邮箱，进行激活操作
|
激活成功
|
|
用注册的邮箱和密码，进行登录操作
|
登录成功，系统展示欢迎页面
|
|
测试方式
|
手工
|
|
重要性
|
重要
|
|
测试环境
|
Chrome，IE |
|
测试前提
|
系统运行正常，邮件服务器已开启
|
|
功能模块
|
注册登录 |
1.2 测试用例对比
手机拍照测试用例
| 存在歧义的用例 | 明确清楚用例 |
| 标题：单拍。（标题不清楚） | 标题：单张拍照 |
| ....缺少用例元素“测试思路” | 测试思路：检查从按下快门到拍照结束整个过程的处理是否符合要求，包括拍照指示灯的状态，照片存储过程中屏幕的显示，拍完照片的正确性检查 |
| 预设条件：闪光强制关闭，电池充足 | 预设条件：闪光强制关闭，电池充足 |
| 步骤：....步骤不完整 1）镜头对着拍摄对象，按下快门按键。 2）按下下翻页键，浏览刚拍的照片 |
步骤： 1）用相机镜头瞄准拍摄对象，准备好后，按下快门键。 2）注意听按下快门键的声音 3）照片保存过程中，观察手机屏幕显示的变化 4）提示照片保存成功 |
| 预期输出：...相对的步骤没有输出 1）可见刚拍下的照片，照片正常 |
预期输出： 1）按下快门后，一秒内听到设置的快门声 2）照片保存过程中，手机屏幕显示正在保存的照片，保存完成后屏幕恢复为拍照模式 3）照片为即见即所得，查看照片的像素、色彩等于设置的模式一致。 |
2. 测试用例的好处
1）测试执行者的依据2）使得工作可重复，自动化测试的基础3）评估需求覆盖率4）用例的复用5）积累测试的方法思路以供后续借鉴
使用中带来困扰：
测试用例的设计是费时费力的工作，设计测试用例所花费的时间比执行所花费的时间还多
解决如下问题：
不知道是否较全面的测试了所有功能测试的覆盖率无法衡量对新版本的重复测试很难实施存在大量冗余测试影响测试效率
3. 用例设计方法
3.1 基于需求的设计
RBT( Requirements-Based Testing)
是基于需求的测试方法，会使测试更加有效，因为 它使测试专注于质量问题产生的根源，即需求。
基于需求的测试是一种最根本的软件测试，重点关注以下两大关键问题。
1 ）验证需求是否正确、完整、无二义性，并且逻辑一致。2 ）要从 “ 黑盒 ” 的角度，设计出充分并且必要的测试集，以保证设计和代码都能完全符合需求。
3.2 案例
1）用户需求
购买智能手机，测试用例：
1. 价格范围
2.品牌选项
3.智能手机
4.手机功能验证
打电话、接电话、发短信、收短信、听歌.......
2）软件需求
邮件事件流
1. 若用户未收到激活邮件，可在登录界面录入电子邮件及密码后，再次发送激活邮件。2. 每次发送的激活邮件，仅在发送邮件后起 24 小时之内有效，超过 24 小时后需重新发送激活邮件
测试用例
1-1 、未收到邮件，登录时输入电子邮件及密码后，再次发送激活邮件1-2 、已收到邮件，登录时输入电子邮件及密码后，不发送激活邮件2-1 、收到邮件， 24 小时内进行激活2-2 、收到邮件， 24 小时后链接过期进行激活。2-3 、收到邮件，已激活， 24 小时后链接过期，再次点击激活
页面检查
1 、收到激活邮件2 、邮件内容正确3 、激活 URl 正确，可激活4 、再次激活提示已激活5 、过期激活提示已过期
3.3 具体的设计方法
等价类
边界值
因果图
正交排列
场景设计方法
错误猜测法
3.3.1 等价类
例如将一个班级里的学生分为几类：优秀、中等、一般
依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。
有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类 验证程序是否实现了规格说明中所规定的功能和性能
无效等价类：根据需求说明书，不满足需求的集合。
等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充。
例如：
水果
有效等价类：苹果、橙子、桃子
无效等价类：青菜、米、饮料
字符类型
A-Z,
不区分大小写：
有效等价类：为
A-Z,a-z
，
无效等价类：￥、%、@等特殊字符
3.3.2 边界值
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
例如：
1）输入框长度为1-10，取边界值：1、10，0、112）运动员的参赛项目为1-4项，取边界值：0项，1项，2项，3项，4项3）查询页面有999行，每50行为一页。取边界值输出0行，50行，51行，999行
例如：
注册邮箱的软件需求
用户名要求长度为6-15位，边界值5,6,15,16
但是在实际测试设计中，会将等价类和边界值结合起来使用，那么我们最终可以确认的用例为：5、6、10、15、16
3.3.3 因果图
1）恒等
如果原因为真，那么结果必定为真。 例如：这颗树上结果了，那么这棵树上一定有果子
2）与
只有两个原因，并且都为真，那么结果一定为真。
3）或
两个原因中，有一个为真时，结果就为真。
4）非
只有原因为加，结果才为真
因果图法设计测试用例的步骤如下：
1) 分析所有可能的输入和可能的输出。2) 找出输入与输出之间的对应关系。3) 画出因果图。4) 把因果图转换成判定表。5) 把判定表对应到每一个测试用例
案例一：
假设业务单据的处理规则为：“淘宝618活动，提单已提交，订单合计金额大于300元或有红包，则进优惠”。
1. 对于这条业务规则，首先通过分析所有可能的输入和可能的输出，可以得到如下结果：
● 输入：订单已提交，金额大于 300、 有红包。● 输出：优惠、不优惠。
2. 然后，进行第二步，找出输入与输出之间的对应关系。通过分析，可以看出有以下的对应关系。
1) 订单已提交，订单金额大于 300 元，则优惠。2) 订单已提交，订单金额小于等于 300 元，无红包，不优惠3) 订单已提交，有红包，则优惠。4) 订单已提交，订单金额大于 300 元，有红包，则优惠。5) 订单未提交，不优惠
3. 为了方便画出因果图和判定表，需要对所有输入和输出编号，现在编号如下
1 ：订单已提交。2 ：订单金额大于 300 元。3 ：有红包21 ：优惠22 ：不优惠
4.
画因果图
5. 画判定表
有三个条件，输出有2个取值，所以表的列数为 2*2*2 = 8
6. 最终的测试用例
1
，
2
，
3
，
4
，
5
（包含
6
，
7
，
8
）。
案例二
注册的需求为用例：
姓名、邮箱、密码、确认密码、验证码必须全部输入，才能进行注册
需要设计多少用例？
2x2x2x2x2
。
因果法设计测试用例可以帮助测试人员理清输入和输出的关系，但是对于比较复杂的输入和输出，会耗费大量时间
3.3.4 正交排列
当因果法设计用例过多时，使用正交排列
正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。
正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。
正交试验设计是一种基于正交表的、高效率、快速、经济的试验
因素（Factor）：在一项试验中，凡欲考察的变量称为因素（变量）
水平（位级）
（
Level
）：在试验范围内，因素被考察的值称为水平（变量的取值）
正交表的构成：
行数
(Runs)
：
正交表中的行的个数，即试验的次数
,
用
N
代表。
因素数
(Factors)
：
正交表中列的个数，用
C
代表
水平数
(Levels)
：
任何单个因素能够取得的值的最大个数。正交表中的包含的值为从
0
到数
“
水平数
-1”
或 从
1
到
“
水平数”
，用
T
代表
正交表的表示形式：
L=
行数
(
水平数
*
因素数
) L=N(TC)
正交表的两条性质：
每一列中各数字出现的次数都一样多。
任何两列所构成的各有序数对出现的次数都一样多。
正交法设计测试用例的步骤：
1 、有哪些因素（变量）2 、每个因素有哪几个水平（变量的取值）3 、选择一个合适的正交表4 、把变量的值映射到表中5 、把每一行的各因素水平的组合作为一个测试用例6 、加上你认为可疑且没有在表中出现的用例组合
案例：
以注册为例
1
、因素：姓名、邮箱、密码、确认密码、验证码
2
、水平：填写、不填写
3、表中的因素数=5；
表中至每个因素数的水平数=2
行数取最少的一个，即试验次数最少的一个
L=N(TC)=(2-1)*5+1=6=6(25)
L=6(25)
N
试验次数
T
水平数
C
因素数
选择正交表，这里选择了
L6_2_5
。正交表不是随便选择的，而是设计好的
4
、生成测试用例
5、增补测试用例
姓名、邮箱、密码、确认密码、验证码都不填写
3.3.5 场景设计法
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。
典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。
案例：
注册例子
想象注册的场景来设计用例，这与根据需求的业务流来设计差不多。主要是想象各种业务流来设计用例。例如我们可以再想象以下场景：
1 、用户激活后再次点击邮件激活链接？2 、已注册用户再次注册？
3.3.6 错误猜测法
错误猜测法是经验丰富的测试人员喜欢使用的一种测试方法。
基于经验和直觉，找出程序中你认为可能出现的错误，有针对性地设计测试用例。经验可能来自于在对某项业务测试较多，也可以来自于售后用户的反馈意见，或者从故障管理库中整理bug
。梳理出产品以往哪些地方容易出现问题，问题越多的地方，潜在的bug
也就越多。
注册案例
1 、校验中特殊字符空格的处理 ?2 、密码校验中的大小写？3 、姓名中的特殊字符？4 、密码发送是否明文
4. 测试用例的有效性
测试用例对应的功能已删除，不可操作了
执行一条测试用例未发现
BUG
，实际该处有
BUG
执行一条测试用例发现了
BUG
执行一条测试用例未发现
BUG
，实际该处
BUG
已修改
5. 测试用例的粒度和评价
5.1 测试用例的粒度
好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试
粒度：指测试用例编写的详细程度。
测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，
如探索 性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法， 具体到界面元素的操作步骤，指定测试的方法和工具等
(1)
测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。
(2)
测试用例写得过于简单，则可能失去了测试周例的意义。过于简单的测试用例设计其实并没有进行
“
设计
”
，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试 的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。
大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。
主要考虑可以参考如下内容：
产品的质量要求项目对用例的要求测试时间和资源是否充分
5.2 测试用例的评价
测试用例设计出来了，如何提高测试用例设计的质量？就像软件产品需要通过各种手段来保证质量一样，测试用例 的质量保证也需要综合使用各种手段和方法。评审分为正式和非正式评审
同行评审用户检查项目组评审
1
）测试用例的检查可以有多种方式 但是最敏捷的应当属临时的同行评审。同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“
个体和交互比过程和工具更有价值
”
，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。
2
）除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让用户参与评审，从而体现敏捷的
“
顾客的协作比合同谈判更有价值”
这一原则。这里顾客的含义比较广泛，关键在于如何定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；如果测试是被定义为对开发提供帮助和支持，那么顾客显然就是程序员了
3) 由测试负责人组织协调开展会议，用例编写人对用例进行讲解，参会人员有异议的当场提出。
6. 测试案例
某手机软件有用
TF
卡导出数据的功能，请写出测试此功能点的思路
|
考虑方向
|
检查点
|
测试思路描述
|
|
正向
|
导出数据正确性
|
导出数据，验证数据正确性
|
|
逆向
|
导出数据有效性
|
无数据时，导出功能是否正确
|
|
边界容量
|
TF
卡空间不足
|
只能容纳部分数据
|
|
边界容
|
TF
卡容量已满
|
|
|
容错
|
TF
卡写保护
|
|
|
容错
|
TF
卡无法识别
|
|
|
容错
|
人为中断
|
导出时拔掉
TF
卡
|
|
容错
|
导出时断电、关机等
|
再开机后检查能否正确导出
|
|
性能
|
连续多次导出
|
脚本实现，大量导出，查看数据是否正确
|
|
性能
|
检查导出速度
|
|
|
兼容性
|
不同品牌和容量
|
|
|
兼容性
|
不同分区格式
FAT,FAT32
，
NTFS
|