2、功能测试用例设计方法

测试用例的一般编写步骤：

拿到测试需求 -> 分析需求提取测试要点 -> 编写用例 -> 划分测试用例执行的优先级

测试用例编写需要满足的一般特性：

• 一致性：主要包括用例模板一致；各同事的编写手法大概一致；以及用例的细粒度一致。
• 覆盖率：主要包括对需求的覆盖（包含隐性需求）；新需求可能对那些功能会产生影响的覆盖；对各种场景的覆盖等 。
• 可执行性：主要是指步骤易于理解、信息描述准确、且能快速识别出测试点 。
• 执行准确性：是指用例执行的准确度。即是不是所有用例都执行到，执行情况是不是严格按照测试用例来执行的。
• 持续更新：要及时不断的更新，要尽量减少用例库中失效的用例 。
• 复用性：主要用例可以被不断的复用，从而减少维护成本。

黑盒测试用例设计方法：

黑盒测试用例设计方法包括等价类划分法、边界值分析法、场景法、因果图、判定表、正交排列、错误反推法等。

1、等价类划分法

等价类划分法是把所有可能输入的数据，有无效等价类和有效等价类（即正确输入和非法输入），即程序的输入域划分为若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的、常用的黑盒测试用例设计方法。

基本设计原则：

1、划分有效以及无效等价类，每一个等价类规定一个唯一的编号

2、设计一个新的测试用例数据，使其尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的无效等价类都被覆盖。（为什么多的覆盖，是因为 99%的问题都出现在无效等价类）

3、设计一个新的测试用例数据，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。（为什么只覆盖一个是因为以后出线bug方便排查）

举例：

个人微信红包按数据范围划分：

众所周知，个人微信红包发红包，可以发送0.01元到200元之间的红包，且小数点数不能超过2位，由此可以划分以下等价类

有效的：（有效类A）0.01-200，如 0.01, 200.00, 100.05

无效的：（无效类B）小于 0.01，如 0.001，0，-1

（无效类C）大于 200，如 200，200.56

（无效类D）0.01-200区间小数点后超出2位的值，如 100.123

（无效类E）非数字类型，如 aaa，f+-，中文

（无效类F）是否必填，如 不填

无不管是有效还是无效，每一个等价类都有一个唯一的编号。

从每个等价类里面取对应数据设计设计测试用例

2、边界值划分法

边界值分析法是对等价划分法的一个补充，边界值一般都是从等价类的边缘值去寻找，边界值分析的基本思想:正好等于，刚刚大于，刚刚小于边界的值。

0和负数是特殊值，以下情况下需要考虑

1、输入的是金额

2、输入的字段类型为整型或者是浮点型，手机号码大多情况都是字符串。

每一个输入项都可以考虑空格的输入，在输入项考虑空格的时候，我们考虑前、中、后

Eg1：比如生活中我们大家所熟悉的微信红包：最小金额 0.01元，最大金额 200元

边界值：0、0.01，0.02，199.99，200，200.01

特殊值：负数

Eg2：一个输入文件应包括 2～255条记录

边界值：1，2，3，254，255，256 2～255（有效类区间、无效类区间）

特殊值：0

Eg3：充值 Q币，10个起充，无上限，单位是 1个

边界值：9个，10个，11个

特殊值：0，负数

通常情况下，我们编写测试用例的时候，往往需要将等价类和边界值方法结合使用

3、场景法

通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。场景法需要着重考虑的是线上用户在实际使用应用的过程中，各种可能遇到的用户场景。

基本流：

是经过用例的最简单的路径（无任何差错，程序从开始直接执行到结束，也就是我们在各种测试数据、测试流程都正常的情况下，验证主功能是否正常）

备选流：

一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不在加入到基本流中（各种错误情况，各种可能出现的异常情况）

运用：

例：有一个在线购物的实例，用户进入一个在线购物网站进行购物，选购物品后，进行在线购买，这时需要使用帐号登录，登录成功后，进行付钱交易，交易成功后，生成订购单，完成整个购物过程。

• 基本流：（玩家账号存在，金额充足，商品有库存等）进入网站->选购商品->点击购买->账号登陆->付款交易->交易成功生成订单
• 备选流： 1) 进入网站->选购商品->点击购买->商品库存不足

2）进入网站->选购商品->点击购买->账号登陆->账号不存在->注册账号、登陆账号->付款交易->

交易成功生成订单

3) 进入网站->选购商品->点击购买->账号登陆->付款交易->余额不足->充值余额->重新付款交易->

交易成功生成订单

更多备选流...

4、因果图

因果图是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

产生背景：

等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。

如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。

基本步骤：

1）分析软件规格说明的描述中哪些是原因，哪些是结果。原因是输入或输入条件的等价类，结果是输出条件。给每个原因和结果并赋予一个标识符，根据这些关系，画出因果图。

2）因果图上用一些记号表明约束条件或限制条件。

3）对需求加以分析并把它们表示为因果图之间的关系图。

4）把因果图转换成判定表。

5）将判定表的每一列作为依据，设计测试用例。

基本图形符：

举例：

某软件规格说明书包含这样的要求：第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改，但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息M。

原因：

1——第一列字符是A；

2——第一列字符是B；

3——第二列字符是一数字。

中间状态：

11——第一列字符已输入

结果：

21——修改文件；

22 ——给出信息L；

23——给出信息M。

约束条件：

1、2互斥

5、判定表

判定表是分析和表达多逻辑条件下执行不同操作的情况的工具

组成：

判定表通常由四个部分组成：

1)条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。

2)动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

3)条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。

4)动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

步骤：

1)确定规则的个数.假如有n个条件。每个条件有两个取值（0,1）,故有2的n次方种规则。

2)列出所有的条件桩和动作桩。

3)填入条件项。

4)填入动作项。得到初始判定表。

5)简化、合并相似规则（相同动作）。

举例：

6、正交排列

在界面中有多个控件，控件之间有多种组合关系，如果组合的数量巨大（一般超过20种），没有必要将所有组合都测试，可以通过正交排列法将组合中最优，最少的组合进行测试。

正交排列与判定表因果图的区别在于：判定表（因果图）也是考虑控件组合，但是组合数量较少（一般不会超过20种），而且要求测试全面

举例：

正交表个数有限，并且一般要求每个控件的取值个数相等，在实践中很难遇到

一般原则：

（1）公平：每个控件都要参与组合（每行），每个控件的取值参与组合的次数尽量相同（每列）

（2）均匀：从所有的组合数据中，均匀、零星的挑选作为用例的组合数据，而不是只从某个局部选取。

7、错误反推法

基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法

它的要素共有三点，分别为：经验、知识、直觉。这是个很主观的方法，有时候需要自己的灵感、根据自己的经验去推断程序哪些地方可能出错。

举例：

测试密码：先输入错的，再输入对的，可不可以？先输入中文，再输入正确的密码，是否成功。错误推测法并不是一个设计用例必须的方法只是当你在设计用例的时候，突然间有想法了，那么就可以补充一下