软件测试学习之旅----用例篇

测试用例（Test Case）是向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。（测试方式、标题、重要性、优先级、功能模块等），测试用例是伴随我们软件测试一生的东西，写好的测试用例是一个软件测试人员追求的目标。

设计测试用例的方法

基于需求的设计

RBT( Requirements-Based Testing)是基于需求的测试方法，会使测试更加有效，因为 它使测试专注于质量问题产生的根源，即需求。，分化需求，细化需求，从需求中提炼功能模块，划分子功能，根据每一个子功能去写测试用例。以下的方法都属于黑盒测试的方法。

等价类

依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用 例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能 穷举测试的问题。
等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充。

• 有效等价类：根据需求规格说明，有意义的输入的数据集合，称为有效等价类
• 无效等价类：根据需求说明书，不满足需求的集合。

边界值

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法 的补充，这种情况下，其测试用例来自等价类的边界。

因果图

因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系（需要了解程序的输入和输出）。因果图 法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输 入条件的各种情况。
因果图的需要掌握的基本知识：恒等、与、或、非
因果图法设计测试用例的步骤：

• 分析出所有的输入和输出
• 分析出不同的输入组合和不同输出之间的关系
• 画因果图
• 根据因果图画判定表
• 把判定表转换成测试用例

举个例子吧：马上618吧大家又要买的东西吗？
假设业务单据的处理规则为：“淘宝618活动，提单已提交，订单合计金额大于300元或有红包，则进优惠”。
1.对于这条业务规则，首先通过分析所有可能的输入和可能的输出，可以得到如下结果：

• 输入：订单已提交、金额大于300、有红包。
• 输出：优惠、不优惠。

2.然后，进行第二步，找出输入与输出之间的对应关系。通过分析，可以看出有以下的对应关系。

• (1)订单已提交，订单金额大于300元，则优惠。
• (2)订单已提交，订单金额小于等于300元，无红包，不优惠
• (3)订单已提交，有红包，则优惠。
• (4)订单已提交，订单金额大于300元，有红包，则优惠。
• (5)订单未提交，不优惠。

3.画因果图

4.画判定表

5.写测试用例
订单已提交，金额大于300，有红包，有优惠
订单已提交，金额大于300，没有红包，有优惠
订单已提交，金额小于等于300，有红包，有优惠
订单已提交，金额小于等于300，没有红包，没有优惠
订单未提交，金额大于300，没有红包，没有优惠
订单未提交，金额小于等于300，有红包，没有优惠
订单未提交，金额小于等于300，没有红包，没有优惠
订单未提交，金额大于300，有红包，没有优惠

正交法

正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找 出最优的水平组合。
正交表的元素：
因素：输入变量的个数
水平数：变量的取值（当水平数不一样的时候，正交表的行数就需要去查表啦）
正交表的构成：
列：因素数（变量的个数）
行：L（正交表的行） = （水平数 - 1）* 因素数 + 1
正交表的性质：
每一列不同数据出现的次数一样
任意两列不同的数据的组合出现的次数一样
正交表设计测试用例的步骤

1. 确定所有的输入（变量）
2. 确定每一个变量的取值的个数
3. 确定因素数（正交表的列）水平数，正交表的行
4. 根据正交表的性质，把变量的值映射到表中
5. 写测试用例，正交表的每一行就是一个测试用例
6. 补充正交表中没有但是认为可能会出现的测试用例

场景设计法

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处 理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试 用例更容易理解和执行。

典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视 业务流程要点的错误倾向

以注册为例

错误猜测法

错误猜测法是经验丰富的测试人员喜欢使用的一种测试方法。
基于经验和直觉，找出程序中你认为可能出现的错误，有针对性地设计测试用例。经验可能来自于在对某项业务的 测试较多，也可以来自于售后用户的反馈意见，或者从故障管理库中整理bug。梳理出产品以往哪些地方容易出现 问题，问题越多的地方，潜在的bug也就越多。小白勿用哦,但我们也会称为大佬的，加油！