3-测试用例（CASE）

X-musk

已于 2023-08-28 09:24:00 修改

阅读量2k

点赞数 2

分类专栏：测试文章标签：测试用例

于 2023-07-07 22:40:19 首次发布

本文链接：https://blog.csdn.net/WWXDwrn/article/details/131605054

版权

测试专栏收录该内容

17 篇文章 0 订阅

订阅专栏

1.什么是测试用例？

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合。

这组集合包含：测试环境、操作步骤、测试数据、预期结果（标题、序号、重要性、优先级、操作方式）等要素。

测试用例解决了两大问题：测什么，怎么测。

PS：测试用例的基本要素（4个）

测试环境
操作步骤
测试数据
预期结果

（测试用例的基本要素不需要执行结果）

eg：就像在线oj里面的用例

测试环境：LeetCode提供给我们一个测试环境：如Windows系统+Chrome浏览器。
测试数据：牛客网可以自己输入测试数据，后台也提供了测试数据。
操作步骤：写代码，点击提交。
预期结果：点击提交，通过率为100%。若预期结果和实际结果相同，说明测试用例通过，否则不通过。

PS：评价测试用例的标准

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

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

2.测试用例的带来的好处

一个项目写多少测试用例不确定，根据项目难易程度、需求而定。

但测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多。那为啥还要写？原因：

测试用例是测试执行者的依据。
测试用例可评估需求覆盖率。
测试用例可以提高测试人员的工作效率 / 降低测试人员工作的重复性问题。复用性，借鉴意义。
测试用例是建立自动化测试的基础。【自动化就是把测试人员双手解放，让代码代替人来执行测试】

3.测试用例的设计方法（基于黑盒测试）

3.1.基于需求进行测试用例的设计

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

参考标准：需求文档。
只是针对需求进行了大概的测试。

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

3.1.2.功能需求测试分析

对于功能测试中，可以借助功能框图来帮助进行测试的需求分析。概括起来，功能测试需求通常包括以下几个方面。

系统各个功能界面的验证。
借助业务把功能串起来进行测试。
功能的一致性，交互性（多功能交互操作）的测试。
系统的不同输入，结果输出的业务数据测试。
功能的错误操作，异常操作的测试（属于负面测试）。
功能实现用到的算法验证，有时需要运用代码评审。
用户操作的易用性，用户体验，往往结合功能测试同时验证。

针对具体的需求，可以根据业务、用户角色、用户操作区域等将系统功能分解成若干个功能模块，然后按照功能模块分别进行测试。按照功能模块划分，业务模块划分是最常见的做法。

例1：简单日历系统的功能需求分析

对日历根据web界面的功能布局分析出的功能框图如下：

也可以采用思维导图的方式，更方便、有效，只管呈现测试需求的分析结果，可以更好地支持测试分析思路的连贯性。

例2：百度云盘手机端的功能需求分析

在进行需求分析的时候，还要考虑业务规则如：上传文件的大小有没有限制；一次性上传多少数量的文件，比如小于100个；文件夹最多有多少层等等。

例3：163邮箱注册的功能需求分析

3.1.3.非功能需求测试分析

非功能需求测试主要涉及性能，安全性，可靠性，兼容性，易维护性和可移植性等。从测试需求分析来看，每一类非功能特性测试都需要根据需求单独分析。他们之间可能会存在相互影响，如安全性越高，就越有可能给易用性，性能带来更大的挑战。

这里要说明的是对于每一个应用软件系统，非功能特性的质量需求都是存在的，但是不同的项目类型对各个非功能特性的要求是不一样的，这个需要根据具体的项目、具体需求和不同产品应用的特点进行分析。

纯客户端软件，比如文字处理软件（Word，PPT)，媒体（音频/视频）播放软件（电脑自带的）等。这类软件对系统的功能测试要求是最低的；但是对兼容性和稳定性，可移植性有一定的要求。
企业内部的客户端/服务端（C/S)应用系统，比如电子邮件，即时通信系统（飞Q，企业QQ）等。在系统功能测试需求上比纯客户端复杂，要求功能正确，稳定性能好；但是整体上看，对性能，安全性，兼容性要求不高。
外部大型复杂网络应用系统，比如电子商务，网上银行，视频网站（腾讯，优酷）等。除了有复杂的系统的功能测试需求外；在系统的性能，安全性，兼容性，容错性，可靠性等都有很高的要求。

此外，对于大型企业级应用系统，由于应用模式，系统架构的不同（分布式，微服务等），我们必须结合架构和应用模式来具体分析非功能性测试需求，特别是可扩展性，可靠性，安全性等。技术架构对功能的影响小，但是非功能性测试要深入架构分析，才能更好的把握测试范围和测试方法。

例：163邮箱注册的非功能需求分析

PS：如何模拟网络？

借助工具：

Charles（公司里使用较多）
Fiddler

3.2.具体的设计方法

①等价类

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

等价类分类：

有效等价类：满足用户需求的输入集合/符合需求规格说明书的数据。
无效等价类：不满足用户需求的输入集合/不符合需求规格说明书的数据。

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

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

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

例：

②边界值

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

6 < username.length < 15
7 <= username.length <= 14

(二者等价)

边界点划分：

上点：边界上的点。（不管是开区间还是闭区间）
内点：边界内的点。（其中任意一个点，不管是开区间还是闭区间）
离点：边界值附近的一个点。（闭区间区间外距离上点最近的点，开区间区间内距离上点最近的点）

例1：[6, 15]

上点：6，15
内点：12（6~15都可）
离点：5，16

例2：(6, 15]

上点：6，15
内点：12（6~15都可）
离点：7，16

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

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

例：

③判定表法（由因果图法进化而来）

PS：因果图法（了解即可）

因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。

因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。

因果图需要掌握的关系：

与：所有原因都为真，那么结果为真；如果一个原因为假，此时结果为假。

或：所有原因中有一个为真，结果就为真；如果所有原因都为假，此时结果为假。

恒等：如果原因为真，那么结果必定为真。

非：只有原因为假，结果才为真。

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

分析所有可能的输入和可能的输出。
找出输入与输出之间的对应关系。
画出因果图。
把因果图转换成判定表。
把判定表对应到每一个测试用例。

案例：

因果法设计测试用例可以帮助测试人员理清输入和输出的关系，但是对于比较复杂的输入和输出，会耗费大量时间。

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

关系：

与：所有原因都为真，那么结果为真；如果一个原因为假，此时结果为假。
或：所有原因中有一个为真，结果就为真；如果所有原因都为假，此时结果为假。
恒等：如果原因为真，那么结果必定为真。
非：只有原因为假，结果才为真。

设计测试用例的步骤：

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

例：

注：第四步只列出了测试点，后面还需要补充测试用例要素。

④正交表法

当遇到软件测试中输入条件组合数很多的情况时，比如下图这种：

我们不可能把所有选择排列全部列举并测试，这时就用到了正交表法设计测试用例。

可以使用自动化生成测试用例的工具——allpairs，来帮助我们快速生成相应的测试用例。

正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。

正交试验设计是一种基于正交表的、高效率、快速、经济的试验。

正交法的目的是为了减少用例数目。其最基本的思想是使用最小的测试组合来获得最大的测试覆盖率，适用于搜索、查询、多种输入条件组合等场景。

什么是正交表？

名词：

因素（Factor）：输入的变量。
水平（位级）（Level）：每一个输入变量的取值。

正交表的构成：

行数(Runs)：正交表中的行的个数，即试验的次数，用N代表。
因素数(Factors)：正交表中列的个数，用C代表。
水平数(Levels)：任何单个因素能够取得的值的最大个数。正交表中的包含的值为从0到数“水平数-1”或从1到“水平数”，用T代表。

正交表的表示形式：

L=行数(水平数*因素数) 即L=N(TC)

正交表的2条性质：

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

如何通过正交表设计测试用例？

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

例：

1）充分理解需求：姓名、邮箱、密码、确认密码、验证码必须全部输入，才能进行注册。

2）确定因素、水平：

因素：姓名、邮箱、密码、确认密码、验证码。
水平：填写、不填写。

3）画正交表：（使用allpairs来画）

PS：工具allpairs下载使用

1.下载链接 Download Allpairs 1.2.1 选择第一个选项，如下图所示：

2.下载好之后是一个名为pairs的压缩包，allpairs工具不用安装，解压到想要的路径即可使用。

3.新建excel表格，将因素和水平填进去：

4.将上述表格的数据进行复制，粘贴到记事本：

5.将其保存到allpairs的下载路径下：

6.使用Win+R打开cmd命令行窗口，进入pairs文件夹。

7.输入 allpairs.exe 20230425.txt > 20230425_result.txt 命令，即可生成一个名为 20230425_result.txt 的文本文档，里面存储的便是生成的测试用例。

8.打开20230425_result.txt 文本文档，里面存储的便是生成的测试用例：

测试用例中的~意味着此时这个取值可以是填写，也可以是不填写。

4）补充正交表

5）将正交表转换成测试用例

这里只列出测试点，后续还需要补充测试要素，才是完整的测试用例。

⑤场景设计法

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。

该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，使测试用例更容易理解和执行。

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

主事件流：用户经常使用的场景，相当于是主事件流。
次事件流：用户在使用时，可能会出现许许多多的意外，此时就相当于是次事件流。

如何通过场景设计法设计测试用例？

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

通常情况下，需要把用户经常用到的功能模块串联起来一起进行测试。

例：追女神

先打招呼（不理人、拒绝）-> 要联系方式（联系方式给错了） -> 聊天了解（没有话题、已读不回、光速秒删） -> 吃饭（被放鸽子、迟到、没选好吃饭地点） -> 表白（果断拒绝） -> 追女神成功

在上述例子中，黑色表示主事件流，蓝色表示次事件流。

例：ATM机取款（场景法设计测试用例）

将每一个个主事件流和次事件流串起来，就相当于是一个个测试用例。

⑥错误猜测法

错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。

这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。

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

这个方法的缺点是难以系统化，并且过度依赖个人能力。没有确定的方法。

例：以注册为例

校验中特殊字符空格的处理?
密码校验中的大小写？
姓名中的特殊字符？
密码发送是否明文？

4.什么样的测试用例是一个好的测试用例？

4.1.什么是测试用例的有效性？

4.2.测试用例的粒度

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

测试用例可以写得很简单，也可以写得很复杂。

最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。

而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法，具体到界面元素的操作步骤，指定测试的方法和工具等。

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

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

主要考虑可以参考如下内容：

产品的质量要求
项目对用例的要求
测试时间和资源是否充分

但是不管用例怎么简化，都不应该省略。

4.3.测试用例的评价

测试用例设计出来了，如何提高测试用例设计的质量？就像软件产品需要通过各种手段来保证质量一样，测试用例的质量保证也需要综合使用各种手段和方法。评审分为正式和非正式评审。

同行评审
用户检查
项目组评审

测试用例的检查可以有多种方式，但是最敏捷的应当属临时的同行评审。同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。
除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让用户参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于如何定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；如果测试是被定义为对开发提供帮助和支持，那么顾客显然就是程序员了。
由测试负责人组织协调开展会议，用例编写人对用例进行讲解，参会人员有异议的当场提出。