软件测试教程（测试系列4）

最新推荐文章于 2024-10-28 10:57:05 发布

努力敲代码的小白✧٩(ˊωˋ*)و✧

最新推荐文章于 2024-10-28 10:57:05 发布

阅读量141

点赞数

分类专栏：测试文章标签：功能测试

本文链接：https://blog.csdn.net/weixin_61599986/article/details/131780790

版权

测试专栏收录该内容

10 篇文章 2 订阅

订阅专栏

本文介绍了测试用例设计的基本要素和多种方法，包括基于需求、等价类划分、边界值分析、因果图和判定表、正交表、场景设计法及错误猜测法。强调了测试用例应具备的清晰性、可操作性和需求覆盖率，并提供了实例来说明各种设计方法的运用。

摘要由CSDN通过智能技术生成

前言：

在上一节中讲述了一次基本的测试过程，在我们开始做了一段时间基础测试，熟悉了业务之后，往往会分配来写测试用例，并在日常测试中，有时也需要补充测试用例到现有的案例中。那么下面我就给大家来分享我们常用的编写测试用例的方法。

1.测试用例的基本要素

在之前也给大家提到过测试用例的基本方法，这里小编在带着大家一起来回顾一下测试用例的四要素：测试环境、测试数据、操作步骤、预期结果。

测试用例是为了实施测试而向被测试的系统提供的一组集合，这组集合中就包含了上述测试用例的四要素。一个好的测试用例是一个熟悉测试业务的人也能依据用例来很快的进行测试，评价测试用例的标准是对比好坏用例的评价标准：

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

2.测试用例的设计方法

2.1基于需求的设计方法

基于需求设计测试用例是测试设计和开发测试用例的基础，第一步就是要分析测试需求，验证需求是否正确、完整、、无二义性，并且逻辑自洽，在需求正确的基础上细化测试需求，从测试需求提炼出一个个测试点或者是测试项，然后根据每一个测试点进行测试用例的设计。

在分析测试需求时，一般分为功能测试需求和非功能测试需求。

参考标准是：需求文档。

我们是通过需求文档——>梳理需求——>针对文档设计测试用例（基于需求设计测试用例）来设计的。

比如我要设计一个登录界面，那么基于需求设计的话我就可以将其分为功能和非功能两类：

功能：登录账号，登录密码，点击同意协议....
非功能：UI设计，界面的颜色，字体的大小形式...

那么基于需求的测试用例设计法只是对测试用例设计了一个大体的框架，那么里面具体的设计还得看以下的这些设计的方法，搭配下面的设计法才能够真正的设计出一个测试用例来。

2.2等价类

什么是等价类呢？依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

他其实就像是我们数学中学的抽象检测法一样，就是将样本先进行分类，然后再每组中抽一个进行检测。

在等价类中我们会将其分成有效等价类和无效等价类。

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

等价类只考虑输入域的分类，没有考虑输入的组合，需要其他的设计方法和补充。

例如：有些登录或者是注册界面在输入用户名或者是密码的时候会规定长度，比如是6~16位，那么它的有效等价类就是6~16位，而无效等价类就是小于6位和大于16位。

等价类思想设计测试用例的步骤：

充分理解需求。
划分有效等价类，划分无效等价类。
从有效等价类中抽取其中一个数据进行设计测试用例；从无效等价类中抽取其中一个进行测试用例的设计。

2.3边界值

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

那么这里我们通常会有三个点：上点、内点、离点。

下面小编就给大家来分别解释一下这三个点都是代表的啥。

上点：边界上的点就是上点。
内点：边界内的点就叫内点。
离点：在闭区间内，离上点最近的且在区间外的点就是离点，在开区间内，离上点最近的点且在区间内的点就叫离点。这里需要大家注意的是开区间和闭区间的时候离点的位置是不一样的。

下面我们通过一个图来深刻体会一下三个点的具体位置。

注意：里面的离点我用星星给给大家标注出来啦！！！

边界值设计测试用例方法的步骤：

充分理解需求。
找到边界点。
针对边界点设计测试用例。

例如上述给大家讲的用户名的长度设计，如下所示：

2.4因果图

因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的互相关系，因果图是借助图形来设计测试用例的一种系统方法，特别适合用于别测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。

这里我们主要用到的是判定表，所以就直接给大家讲解如何用判定表来设计测试用例。

2.4.1判定表

判定表：是一种表达逻辑判断的工具。

它的关系有：

与：所有条件必须满足，如果有一个不满足，次结果就为假。
或：满足其中一个条件结果就为真，如果条件全部为假，结果就为假。
恒等：条件为真。结果一定为真。
非：条件为假，结果才为真。

通过判定表设计测试用例的步骤：

分析所有可能的输入和输出。
找出输入与输出之间对应的关系。
设计判定表。
把判定表对应到每一个测试用例。

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

①那么根据上述信息我可以抽象出：

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

②写出输入和输出对应的关系。

订单已提交，金额大于300，有红包，有优惠。
订单已提交，金额大于300，无红包，无优惠。
订单已提交，金额小于300，有红包，有优惠。
订单已提交，金额小于300，无红包，无优惠。
订单不提交，金额大于300，有红包，无优惠。
订单不提交，金额大于300，无红包，无优惠。
订单不提交，金额小于300，有红包，无优惠。
订单不提交，金额小于300，无红包，无优惠。

③那么接下来我们就根据上述信息来画判定表。

	1	2	3	4	5	6	7	8
订单提交	Y	Y	Y	Y	N	N	N	N
金额大于300	Y	Y	N	N	Y	Y	N	N
有红包	Y	N	Y	N	Y	N	Y	N
有优惠	Y	Y	Y	N	N	N	N	N
无优惠	N	N	N	Y	Y	Y	Y	Y

2.5正交表

什么是正交表？最简单的正交表是L^4(2^3)，含义如下：“L”代表正交表：L下角的数字“4”表示有4横行，简称行，既要做四次试验；括号内的指数“3”表示有3纵行，简称列，即最多孕允许安排的因素是3个；括号内的数“2”表示的主要部分只有2中数字，即因素有两种水平1与2，正交表的特点是其安排的试验方法具有均衡搭配特性。

这里有两个非常重要的概念：因素和水平，下面给大家分别解释一下。

因素：输入的变量。
水平：每一个输入变量的取值。

如下所示：

列号	1	2	3	4
实验号	1	2	3	4
1	1	1	1	1
2	1	2	2	2
3	1	3	3	3
4	2	1	2	3
5	2	2	3	1
6	2	3	1	2
7	3	1	3	2
8	3	2	1	3
9	3	3	2	1

正交表的两条性质：

每一列各数字出现的次数都一样多。
任何两列中的各有序数对出现的次数都一样多。

那么了解了正交表之后，我们如何通过正交表设计测试用例呢？
通过正交表设计测试用例的步骤：

充分理解需求。
确定因素，确定水平。
画正交表。
补充正交表。
将正交表转换成测试用例。

这里我们是借助allpairs来画正交表的。

①将因素和水平放到Excel表格中。

②将Excel表格的内容直接复制到TXT文本中。

③cmd进入到allpairs安装路径下面。

操作步骤入下所示：

④生成正交表。

打开上述新生成的TXT文件。

下面就来通过正交表来设计出上述的测试用例：
注意：在上表中小编并没有给大家写全，只是列举了一部分，由于空间有限所以没有给大家列举完，有兴趣的同学可以下来一一列举出来。

2.6场景设计法

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

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

通过场景设计法来设计测试用例步骤：

充分理解需求。
确定主事件流。
确定次事件流。
每一个事件流就是一个测试用例。

我们以ATM机取款为例：

2.7错误猜测法

错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。

错误推测法和目前流行的“探索式测试方法”的基本思想一致，这类方法在敏捷开发模式下的投入产出比很高，被广泛应用于测试。

所以针对与错误猜测法我们就只能多看测试用例多实践，在实践中总结经验。

3.测试用例设计的模拟

3.1 实体测试用例的设计

水杯测试用例的设计：

3.2 软件测试用例的设计

微信发送朋友圈设计测试用例：

4.测试用例的粒度和评价

好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试。

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

测试用例可以写的很简单，也可以写的很复杂，最简单的测试用例是测试的纲要，仅仅指处要测试的内容。

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

结束语：

这节小编就与大家分享到这里啦！这节里面小编主要带着大家一起学习了如何设计一个测试用例，那么下来之后大家也可以自己去尝试着设计一下，后期小编将给大家介绍软件测试的进阶篇，里面大家可以具体学到更多的有关于测试用例设计的方法，希望对大家后期学习测试有一定的帮助，想要学习的同学记得关注小编和小编一起学习吧！如果文章中有任何错误也欢迎各位大佬及时为小编指点迷津（在此小编先谢过各位大佬啦！）