【软件测试】用例篇

最新推荐文章于 2024-07-31 23:49:59 发布

kokouya

最新推荐文章于 2024-07-31 23:49:59 发布

阅读量463

点赞数

分类专栏：测试

本文链接：https://blog.csdn.net/qq_43606352/article/details/103327741

版权

测试专栏收录该内容

5 篇文章 0 订阅

订阅专栏

测试用例的评价（如何确保测试用例的正确性）

一、测试用例的基本要素

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试。

评价测试用例的标准：对比好坏代码的评价标准。

用例表达清楚，无二义性。。
用例可操作性强。
用例的输入与输出明确。一条用例只有一个预期结果。
用例的可维护性好。
用例对需求的覆盖率高
暴露程序Bug的能力强力。

二、测试用例的设计方法

总体设计方法：基于需求的设计

基于需求的测试是一种最根本的软件测试，重点关注以下两大关键问题：

（1）验证需求是否正确、完整、无二义性，并且逻辑一致。

（2）要从“黑盒”的角度，设计出充分并且必要的测试集，以保证设计和代码都能完全符合需求。

用户需求:
购买3000块钱以内的华为智能手机
测试用例：
1.价格<=3000元
2.品牌为华为
3.智能手机
4.手机功能验证：
4-1.打电话
4-2.接电话
4-3.发短信
4-4.收短信
...

具体的设计方法

一、等价类

思想（目的）：减少测试用例，解决输入无穷的问题，达到尽可能多的功能覆盖

使用场景：输入无穷

概念：无穷的输入分为 N 个类，然后从类里边提取一个数据进行测试，只要这一个测试数据通过，我们就认为他所在的这一类数据全部测试通过。

有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能。
无效等价类：根据需求说明书，不满足需求的集合

例如：超市买水果

有效等价类：苹果、桃子、葡萄

无效等价类：大米、饮料、土豆

二、边界值

使用场景：对输入或输出的边界值进行测试的一种黑盒测试方法。

取值规则：

开区间向内取值，如 (1,20) 取 1，2，20。
闭区间向外取值：如 [1,20] 取 0,1,20,21。(1,10] 取 1,2,20,21。

通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

三、因果图

1、使用场景：输入条件（原因）和输出动作（结果）之间的关系，适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。

2、因果图基本关系：

3.因果图法设计测试用例的步骤如下：

分析所有可能的输入和输出。
找出输入与输出之间的对应关系。
画出因果图。
把因果图转换成判定表。（列数算法：输出当作底数，输入当作幂数）
把判定表对应到每一个测试用例。

4.举例：

假设业务单据的处理规则为：“淘宝618活动，提单已提交，订单合计金额大于300元或有红包，则进优惠”。

（1）对于这条业务规则，首先通过分析所有可能的输入和可能的输出，可以得到如下结果：

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

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

订单已提交，订单金额大于300元，有红包，则优惠。
订单已提交，订单金额大于300元，（无红包）则优惠。
订单已提交，（订单金额小于等于300元）有红包，则优惠。
订单已提交，订单金额小于等于300元，无红包，不优惠。
订单未提交，不优惠

（3）画出因果图：

（4）画判定表：有 3 个条件，输出有 2个取值，所以表的列数为 2 * 2 * 2 = 8 列。

（5）将判定表对应到每个测试用例上：1 ，2,，3，4，5 （包含6,7,8）就表示上述 5 个测试用例。

四、正交排列表

目的：减少测试用例条目，用尽量少的用例覆盖输入的两两组合。

思想：正交表

1、正交表的构成

行数：实验次数，用 N 表示。

因素数：正交表中列的个数，用 C 表示。

水平数：任何单个因素所能取的值的最大个数，用 T 表示。

2.正交表表示形式：L = 行数（水平数因素数）。行数 N = （T - 1）* C + 1。

3.正交表性质：

性质1：每一列中数字出现的次数一样多。

性质2：任何两列锁构成的各有序数对出现的次数都一样多。

满足第二性质一定满足第一性质，满足第一性质不一定满足第二性质。

关于第二性质的判断：一列只能出现一个有序对数，且该有序对数至少出现两次。

4.正交表设计测试用例步骤：

有哪些因素（变量）
每个因素有哪几个水平（变量的取值）
选择一个合适的正交表
把变量的值映射到表中
把每一行的各因素水平的组合作为一个测试用例
加上你认为可疑且没有在表中出现的用例组合

5.举例：注册

（1）因素：姓名、邮箱、密码、确认密码、验证码。C = 5

（2）水平：填写、不填写。T = 2

（3）行数 N = （T - 1）* C + 1 = 6。则 L = 6（25）。

（4）生成及增补测试用例：

6.实际工作中这种做法不常见，科学实验性项目需要这样做，十几种可能会看代码或者想象可能的代码来减少用例。

五、场景设计法

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，使测试用例更容易理解和执行。
典型的应用是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。

1.登录所触发的事件：

判断用户是否存在
判断用户名和密码是否匹配
判断用户状态是否正确
click

2.注册为例；

3.每个场景只有一个入口和一个出口。

场景一：基本流

场景二：基本流 - 备选流1

场景三：基本流 - 备选流3 ……以此类推。

（箭头的方向与顺序无关，且每个流只能经过一次）

六、错误猜测法

错误猜测法是经验丰富的测试人员喜欢使用的一种测试方法。

猜测的来源：

测试人员对项目测试时间长。A:功能‘业务复杂度了解。B：对开发人员的能力了解。
用户反馈
缺陷（产品上线之前）、故障库（发布之后线上/生产环境出现的问题）

举例：以注册为例

（1）输入框长度不够：错误猜测法、（无效）等价类

（2）校验中特殊字符空格的处理?首尾是否有空格

（3）密码校验中的大小写？

（4）姓名中的特殊字符？

（5）密码发送是否明文

三、测试用例的粒度和评价

测试用例的粒度

粒度：指测试用例编写的详细程度。

(1)测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。
(2)测试用例写得过于简单，则可能失去了测试周例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。

大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。
主要考虑可以参考如下内容：