软件测试：用例篇
软件测试：用例篇
本节主要内容
- 测试用例的基本要素
- 测试用例的设计方法
- 测试用例的有效性
- 测试用例的粒度和评价
测试用例的基本要素
测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包括：测试环境、操作步骤、测试数据、预期结果等要素。
评价测试用例好坏的标准：
- 用例表达性清楚，无二义性。
- 用例可操作性强
- 用例的输入与输出明确。一条用例只有一个预期结果。
- 用例的可维护性好。可维护性好包含两个方面：用例的可读性好、用例易修改。
- 用例对需求的覆盖率高。需求的覆盖率=用例的条数/功能点的个数。
- 暴露程序Bug的能力强。
测试用例的优点
- 测试执行者的依据
- 自动化测试的基础
- 评估需求覆盖率
- 用例的复用
- 基类测试的方法思路以供后续借鉴
测试用例的缺点
- 费时费力，往往在设计测试用例时花费的时间比执行是花费的时间还多。
- 测试的覆盖率无法衡量，不知道是否较全面的测试了所有功能。
- 对新版本的重复测试很难实施，存在大量冗余测试影响测试效率。
测试用例具体的设计方法
设计方法有5种：基于需求的设计、等价类、边界值、因果图、正交排列、场景设计法、错误猜测法。
基于需求的设计
RBT是基于需求的测试方法，会使测试更加有效，因为它使测试专注于质量问题产生的根源，即需求。
基于需求的测试是一种最根本的软件测试，主要关注以下两个问题：
1. 验证需求是否正确、完整、无二义性，并且逻辑一致。
2. 要从“黑盒”的角度，设计出充分并且必要的测试集，以保证设计和代码都能完全符合需求。
案例：
等价类
依据需求将输入划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。
- 有效等价类：对于程序的规格说明来说是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能。
无效等价类：根据需求说明书，不满足需求的集合。
案例：
超市买水果
有效等价类：苹果、桃子、香蕉…
无效等价类：牛奶、青菜…
边界值
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
案例一：
1.[1,50]:0,1,50,51
2.(1,50):1,2,49,50
3.(1,50]:1,2,50,514.[1,50):0,1,49,50
在实际的测试设计中，会将等价类和边界值结合起来使用。
案例二：
以注册邮箱的软件需求为例子
用户名要求长度为6-15位
边界值上点为：5，6，15，16 全了吗？
答案是：NO，最终我们确认的用例设计为：5，6，10，15，16
因果图
因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。
- 恒等
恒等：如果原因为真，那么结果必定为真。
- 与
只有2个原因都为真，那么结果才为真。
- 或
2个原因中有一个为真时，结果就为真。
- 非
只有原因为假，结果才为真。
因果图法设计测试用例的步骤如下：
- 分析所有可能的输入和可能的输出；
- 找出输出与输入之间的对应关系；
- 画出因果图；
- 把因果图转换成判定表；
把判定表对应到每一个测试用例。
案例三：
假设业务单据的处理规则为：“淘宝618活动，订单已提交，订单合计金额大于300元或有红包，则进优惠”。
1. 首先通过分析该条业务所有可能的输入和可能的输出为：
- 输入：订单已提交、金额大于300元、有红包
- 输出：优惠、不优惠
2. 第二步，找出输入与输出之间的对应关系，经分析，有以下对应关系：
- 订单未提交，则不优惠；
- 订单未提交，金额 > 300，不优惠；
- 订单未提交，有红包，不优惠；
- 订单未提交，金额 > 300，且有红包，不优惠；
- 订单已提交，金额 <= 300，且没红包，不优惠；
- 订单已提交，金额 > 300，优惠；
- 订单已提交，有红包，优惠；
- 订单已提交，金额 >300 且有红包，优惠。
3. 第三步，根据上一步的分析，画因果图如下图：
4. 第四步，根据因果图画出判定表，如下：
5. 最终的测试用例：
1，2，3，4，5（包含6，7，8）
因果图：
判定表：
因果法测试用例可以帮助测试人员理清输入和输出的关系，但是对于比较复杂的输入和输出，会耗费大量的时间。所以引出了下面的正交法。
正交排列
正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。
正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验。
正交法中的重要概念：
- 因素：在一项试验中，凡欲考察的变量称为因素（变量）。
- 水平：变量的取值。
正交表的构成：
- 行数：正交表中的行的个数，即试验的次数，用N代表。
- 因素数：正交表中列的个数，用C代表。
- 水平数：任何单个因素能够取到的值的最大个数。正交表中的包含的值为从0到数”水平数-1“或1到” 水平数“，用T代替。
正交表的表示形式：
L=行数（水平数*因素数） 即：
正交表的两条性质：
- 每一列中各数字出现的次数都一样多。
- 任何两列所构成的各有序对出现的次数都一样多。
正交法设计测试用例的步骤：
1. 分析有哪些因素（变量）；
2. 每个因素有哪几个水平（变量的取值）；
3. 选择一个合适的正交表；
4. 把变量的值映射到表中；
5. 把每一行各因素水平的组合作为一个测试用例；
6. 加上你认为可疑且没有在表中出现的用例组合。
案例四：
以注册邮箱为例：
1. 因素（变量）：姓名、邮箱、密码、确认密码、验证码
2. 水平（变量取值）：yes(填写)、no(不填写)
3. 表中的因素数(C) >= 5；表中的每个因素数的水平数(T) >= 2；行数取最少的一个，即试验次数最少的一个。 即 ：L=N(TC)=5*(2-1)+1=6
选择正交表，这里选择了L6_2_5。
4. 生成测试用例：注意要满足正交的两条性质，表格如下：
5. 增补测试用例：
只填姓名和验证码，不填email、密码和确认密码。
正交表：
作业：用什么方法来设计以下两个作业，5个条件都是可填和可不填的。
查询页面：姓名、性别、学号、学校、班级
正交法设计：
- 因素（变量）：姓名、性别、学号、学校、班级
- 水平（变量取值）：填写、不填写
- 表中的因素数(C)>=5；水平数(T)>=2；行数取最少的一个。即：L=N(TC)=5*(2-1)+1=6。选择正交表，L6_2_5。
- 生成测试用例：表格如下正交表1所示：
- 增补测试用例：
只填姓名和班级，不填性别、学号和学校。
正交表1：
场景设计法
事件流
通俗的说，单击鼠标后不同的触发顺序和处理结果就形成了时间流。
控制流
是指按一定的顺序排列程序元素来决定程序执行的顺序。
场景设计法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试
用例更容易理解和执行。
典型的应用是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。
错误猜测法
错误猜测法是经验丰富的测试人员喜欢使用的一种测试方法。
基于经验和直觉，找出程序中你认为可能出现的错误，有针对性地设计测试用例。
经验可能来自于在对某项业务的测试较多，也可以来自于售后用户的反馈意见，或者从故障管理库中整理bug。梳理出产品以往哪些地方容易出现问题，问题越多的地方，潜在的bug也就越多。
以注册邮箱为例：
1. 校验中特殊字符空格的处理：
- 当空格出现在前面或后面时，正规开发人员会对空格进行截取，所以不会影响；
- 但当空格出现在中间时，就会将空格认为是一个字符，就会报错。
2. 密码校验中的大小写
3. 姓名中的特殊字符
4. 密码发送是否明文
测试用例的有效性
- 苹果7手机微信添加了mobile单车小程序，扫码不能开锁，只能使用mobile APP开锁，测试用例未涉及到苹果7微信小程序扫码开锁。此时该测试用例就是无效的。
- 苹果7手机微信添加了mobile单车小程序，用例已写到了苹果7微信添加mobile小程序扫码开锁，问题被发现。此时该测试用例就是有效的。
- 已知某代码此处无bug，用某条测试用例来测试也没有出现bug，则这条测试用例也是有效的。
测试用例的粒度和评价
测试用例的粒度
粒度：指测试用例编写的详细程度
测试用例编写时：
1. 写的过于简单，则可能失去了测试周例的意义；
2. 写的过于复杂或详细，会带来两个问题：
- 效率问题
- 维护成本问题
- 容易限制测试人员的思维
大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。
主要考虑可参考以下内容：
- 产品的质量要求
- 项目对用例的要求
- 测试时间和资源是否充足
测试用例的评价
主要有：
- 同行评审：体现了敏捷的“个体和交互比过程和工具更有价值”这一原则。
- 用户检查：体现了敏捷的“顾客的协作比合同谈判更有价值”这一原则。
- 项目组评审