软件测试（二）--测试用例

一、什么是用例:

用例就是用户使用案例的简称。以手机用例为例：
1.是否能开机：打开手机按下电源键3秒，看是否能开机。
2.验证内存：打开手机设置查看内存是否为64G.
3.验证屏幕：打开手机在白屏背景下检查屏幕是否有黑点。
4.检查运行速度：打开手机下载吃鸡游戏是否运行流畅。

二、什么是测试用例：

测试用例就是为测试项目设计的执行文档。测试按照文档走。
测试用例的作用：
1、防止漏测；
2、实施测试的标准。

用例设计编写格式。用例执行时八大要素

1、用例编号：项目_模块_编号
2、用例标题：预期结果（测试点）
3、模块、项目：所属项目或模块
4、优先级：表示用例的重要程度或者影响力P0~P4（P0最高）用户使用率最高的功能模块是优先级最高的
5、前置条件：要执行此条用例，有哪些前置操作
6、测试步骤：描述操作步骤
7、测试数据：操作的数据，没有的话可以为空
8、预期期望：期望达到的结果

三、练习：

根据以下测试点编写用例：
需求：
QQ登录（4条）1、账号为空，2、账号未注册，3、密码为空，4、密码错误

四、测试用例应该怎么去设计？

1.能对穷举场景设计测试点

方法：等价类划分法

说明：
在所有测试数据中，具有某种共同特征的数据集合进行划分
分类：
1.有效等价类：满足需求的数据集合2.无效等价类：不满足需求的数据集合
步骤：
1.明确需求2.确定有效和无效等价类3.提取数据编写测试用例
适用场景：
针对：需要有大量数据测试输入，但是没法穷举测试的地方，常见输入框、下拉列表、单选复选框。
典型代表：页面的输入框类测试

案例：需求：

验证QQ账号的合法性，要求：6~10位自然数

案例：需求：

验证某城市电话号正确性，要求;1、区号：空或者是三位数2、前缀码：非“0”且非“1”开头的三位数字3、后缀码：四位数字

2.对限定边界规则设计测试点

方法:边界值分析法

边界范围节点：
选取正好等于、刚好大于、刚好小于边界的值作为测试数据：
上点：边界上的点（正好等于）；
离点：距离上点最近的点（刚好大于或刚好小于）；
内点：范围内的点（区间范围内的数据一般取居中方便不与离点混淆）
注意：
1.以后看到边界范围的按照位数来说用例最多设计7条
2.边界值能解决位数限制问题，但不能解决类型问题。（要结合等价类）

应用设计步骤：

1、明确需求，
2、确定有效和无效的等价类（非数字要考虑），
3、确定边界范围值，
4、提取数据编写测试用例

案例：

需求：通过边界值验证标题长度的合法性；
要求：标题长度大于0，小于等于30个字符。（其实1，和29等价与内点15，故而1和29可以省略，以此优化，因此7条用例可以优化为5条）

适用场景：

1.在等价类的基础上针对有边界范围的测试数据输入的地方（重点关注边界）
2.常见词语描述：大小，尺寸，重量，最大，最小，至多，至少等修饰词。
3.典型代表：有边界范围的输入框类测试。
强调：单个输入框，常用的方式是边界+等价类。

3.能对多条件依赖关系进行设计测试点

方法：判定表法

判定表法的引入，是用来解决我们有条件依赖关系的目标

判定表法说明：

1.等价类边界值分析法主要关注单个输入条件的测试
2.并未考虑输入条件之间的各种组合、输入条件与输出结果之间有相互的制约关系的测试。

判定表定义及组成部分

规则：
1、判定表中贯穿条件项和动作项的一列就是一条规则
2、假设有n个条件，每个条件的取值有两个（0，1）全组合有2的n次方种规则。
定义：
是一种以表格形式表达多条件逻辑判断的工具；
组成：
1、条件桩：列出问题中所有条件，次序无关紧要；
2、动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束；
3、条件项：列出条件对应的取值，所有可能情况下的真假；
4、动作项：列出条件项在各种取值情况下应采取的动作结果。

案例：

验证“若用户欠费或关机，则不允许主机被叫”功能的测试

判定表法设计用例步骤

1.明确需求
2.画出判定表;
1)列出条件桩和动作桩
2）填写条件项，对条件项进行组合
3）根据条件项的组合确定动作项
4）简化、合并相似规则（有相同的动作）
3.根据规则编写测试用例

案例

适用场景：

有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖或制约关系；判定表一般适用于条件组合数量较少的情况（比如4个条件以下）

4.能对项目业务进行设计测试点

方法：场景法

（测试之初先测业务，保证业务能跑通再去测别的，不然测试将没有意义）

流程图：

使用标准图形和箭头来表示程序或业务的走向，正常情况下由产品人员、开发人员画。

流程图对测试人员有什么作用？

1.能够看懂流程图，设计业务用例
2.当需求文档信息不全时，能够根据需求，梳理出流程
网页版工具：https://processon.com/windows
工具：visio
业务测试覆盖：重点
1.覆盖业务测试，需要使用流程图；
2.测试项目之前先测试业务整个可通再测试单功能单模块。
作用：梳理业务用例

介绍：

说明：
场景法也可以叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例
意义：
1.用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用；
2.测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试。

使用场景：

根据实际场景，来测试业务用例，可以使用场景法

案例

有流程图开发才能把逻辑判断清楚，测试才能测。左边那条用例叫做冒烟测试用例：也就是上一步具不具备可测性，可以才能进入下一个关卡

错误推测法

介绍：

定义：
通过经验推测系统可能出现的问题；
思想：
根据经验列举出可能出现的清单，根据清单分析问题可能原因，推测发现缺陷；
场景：
1.时间紧任务量大时，根据之前项目类似经验找出易出错模块重点测试。
2.实践宽裕通过该方法列出之前出现问题较多的模块再次测试。
问：时间紧，任务量大，人手少怎么保证把这个项目测完？这更多考研的时经验和能力以及分清主次原因，答：时间紧任务量大，我就不会去写用例，我会跟产品人员沟通完确定那些是重要业务，把测试点列好，先验证主要业务再去验证主要的模块的正向再逆向，按照时间节点走，以此类推，时间不够我将加班。用例可以在后期去补。
当所有用例都测完，并且bug都修复完了，离上线还有几个小时，这个期间你可以以你的经验去测试（覆盖）主要业务中未测到的功能，你去验证，这个时候用到错误推荐法才是靠谱的