测试用例设计详解课件

1、 软件测试2022年8月1日第3章：测试用例设计学习目标:了解测试用例的内容和作用了解白盒测试用例方法掌握等价类划分、边界值分析了解因果图和判定表法熟悉场景法 掌握测试用例的编写什么是测试用例？测试用例(Test Case)是为特定目标开发的测试输入、执行条件和预期结果的集合。需要在开发的早期准备测试用例。测试用例的完成并非一劳永逸，因为测试用例是来源于测试需求，而测试需求的来源包括了软件需求、系统设计、详细设计，甚至包括了软件发布后，在软件产品生命周期结束前发现的所有软件错误。3.2 开发测试用例确定测试用例之所以很重要，原因有以下几方面。 1、测试用例构成了设计和制定测试过程的基础。2、测

2、试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，您对产品质量和测试流程也就越有信心。3、判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。类似下面这样的说明：“95%的关键测试用例已得以执行和验证”，远比“我们已完成 95%的测试”更有意义。4、测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。5、测试设计和开发的类型以及所需的资源主要都受控于测试用例。6、测试用例通常根据它们所关联关系的测试类型或测试需求来

3、分类，而且将随类型和需求进行相应地改变。什么是好的测试用例？容易发现软件错误可重复性清晰定义测试通过/失败标准没有冗余。3.2 开发测试用例用例覆盖程度 毫无疑问，这一点应该是最重要的，无需多说，覆盖率最大化是一套测试用例的最重要评价标准，如果漏测就杯具了。用例是否已经达到工作量最小化 在满足用例覆盖程度最大化的前提下，应该尽量减小执行用例所需要的工作量。这些方面的方法有不少，如条件覆盖，分支覆盖等方法。面对不同的测试对象，也有不同的方法来保证：对于网页背后的php逻辑，可以通过在网页上测试后，用一些工具比如xdebug来统计代码覆盖率；对于向外提供接口的server，采用的方式就是分析在外面

4、暴露的接口设计用例，大致的通过接口参数来估计一下分支判断的情况。用例的分类以及描述是否足够清晰 用例的分类，在这里是指相同类型的用例是否放在一起了。例如：接口类的用例，参数的取值范围是1-3，但是现在却传入4；数据类用例，状态机现在位于状态2，却要求状态跳转到无法到达的4；逻辑类用例，正常功能的产出等。将相同类型的用例放在一起，有助于理清思路，清楚了解用例设计是否完备。 用例的描述，是指描述的清晰程度是否能够形成文档。例如上面参数取值范围的例子，用例这样写：“传入错误的值”或者“传入非1-3的值”，明显没有写成“传入值4”有效。用例是否表明了测试目的 写明用例的测试目的，对文档的易于理解性和工

5、作交接的好处不言而喻，现代软件工程不可能只有一个人在做事情，项目于人员的变动也是难免的。在过程中留下足够的信息，可以在后续工作提高很多效率。 测试用例需要很详细吗？如果对产品不熟悉的人来执行系统测试，测试用例中测试过程应该写得较为详细，以确保测试步骤能正确执行。如果测试人员对产品有较多的了解，测试用例中测试过程就不必写得太详细。测试用例的作用指导测试的实施。测试用例主要在实施测试时作为测试的标准，测试人员按照测试用例严格执行用例和测试步骤，逐一实施测试。作为编写测试脚本的“设计规格说明书”。有利于编写自动测试的脚本。评估测试结果的度量基准。分析缺陷的标准。如何确定测试用例中预期结果项目专家或其

6、他方面的专家（主要的程序员、设计者、项目经理等）将知道如何确定输出结果。用户文档可以包含一些用户场景范例。需求文档也可以提供必要的信息。其他相关文档也可以提供相关线索。最终用户也许能够描述所期望的响应结果。谈谈如何写好测试用例在测试的过程中，打交道最多的是测试用例，从需求开始到方案，到形成用例，执行过程中与实际的出入，测试完成后用例的修改，维护等，没有一个过程可以说不需要测试用例之说。如何写“好”测试用例。让人看了一目了然，就看有新人拿到这个用例，能对程序有一点点基本的了解，就可以按照用例完完整整的执行下去。需要关注以下几点：1、对功能的理解。这个是最重要的，也是能反映出每个人对同一功能描述而

7、有不同的理解方式，故一定要深刻理解功能。2、编写用例永远要考虑两面性。事物都是两面的，只有一面的事物那是“怪物”，所以在编写测试用例时先要心中有数。3、确定测试用例的目的。如果不了解为何要写这个用例，那你达到的目的就是按需求或者按任务来完成而已，这样的用例是否适用还有待于商榷；只有了解这个功能的来源，为什么要做这样的功能，希望最后的结果是什么，这些通通考虑清楚了，就不会为了完成任务而去编写出“普通”的测试用例，而是一份优秀合格的测试用例，这样会大大提高工作效率及审核打回的次数。4、测试用例所包含的内容：最基本最简单的测试用例应该包含四项内容，即描述、预置条件、操作步骤、预期结果。一般为更好的管

8、理及维护测试用例，我们会增加测试用例的编号及功能。1）测试用例的描述项，一般人在写的时候根本不去关心这到底有何用，有的甚至为空，更有甚者把需求中的几个字直接复制过来，不管是否通顺与否都放在那里认为就可以了，预置条件可以说是一个总结语，即你要明白这个用例是要验证什么的，因为一个功能有很多用例，你不可能每个描述都是一样的，那这样还不如不要描述。2）预置条件项，任何一个事务都有起源，有始有终才是一个完整的过程，预置条件也可以说是一个基础，基础打好了，一切才能顺利动工。预置条件是为操作步骤服务的，当然有些可能说不需要预置条件，其实任何用例都是有预置条件的，我们说没有预置条件只是隐藏了本身的特点而已。简

9、单来说，发送一条命令测试用例，前期不需要预置条件，但其隐藏的就是有号，且通信正常，还要有MONEY用来发送短信；但实际中我们并不需要写这些预置条件，因为是这是本身特点决定的。3）操作步骤是非常重要的一环，与预期结果是等同的地位。测试用例设计是否高效，由预置条件及操作步骤决定，在操作步骤中，按正常步骤来测试，好像都不会出问题，但真正出问题的就是你想不到的，不是按常规则出牌的才会发现真正有价值的缺陷，所以在设计测试用例时，不要嫌麻烦，认为那一项就好了，别的都应该能检测到，认为写某一项是不必要的，多余的，其实这些想法是错误的，问题就往往出现在你认为这无关功能上。设计操作步骤还依赖于测试经验是否丰富，

10、有些经验丰富的人员设计的测试用例往往会出乎意料，也是在测试阶段最容易发现问题的用例。比如很简单的一个编辑功能，要求其内容不能重复，一般人在写用例的时候都在编辑中去修改成别的名字，而有经验的测试人员会直接编辑一下而不改变内容，一般的程序员是不会考虑到此问题的，如果说出现提示错误一般都是程序逻辑问题。4）预期结果，此项是验证所写用例是结果如何，所以如果没有预期结果，在测试时则无任何可参照的，预期结果与操作步骤的关系相当大，一般来说，不同的操作步骤能生成不同的预期结果，因此在测试测试用例的时候，尽可能的考虑不同的操作步骤，是否会产生同一个结果，有时在设定测试用例的时候，根据结果来推断操作步骤，这也应

11、该是设计用例时的一种参照方法。在测试时，预期结果直接导致着测试是否通过。测试用例文档由简介和测试用例两部分组成。简介部分描述了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。 测试用例的基本元素：测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。测试索引包括用例编号、用例名称等信息。测试环境说明执行该测试用例的软硬件及数据环境。3.2.5 测试用例内容测试用例示例一 说明 测试用例ID： TC-001 软件版本： 子系统： 用户名字段测试 操作系统： 测试人员姓名： 测试日期： 初始设置 1打开注册会话框 2在用户名字段放入字符“王” 3确保所有其他输

12、入字段为空输入 1将光标置于用户名字段 2输入字符“帅”预期结果 用户名字段出现字符“王帅”实际结果 通过 失败测试用例示例二说明 测试用例ID： TC-002 子系统： 彩色版本 被测系统 开发版本： 02.13 操作系统版本： windows 2000 硬件平台： PC Pentium 初始设置： 将图像系统配置为处理256X1024的图像输入 1加载并显示图像Flip1024.bmp 2输入命令 3预期结果 1屏幕显示图像Flip1024.bmp 2实际结果测试记录 测试日期： 结果： 通过 失败 测试人员姓名： 问题报告号： 测试机器： 测试用例示例三不同组织会定义自己内部的测试用例格

13、式。测试用例ID： TC-003测试用例作者： Henry测试位置（路径）：TestServer:CTestProjectTestSuit.最后版本日期： mm/dd/yy需求编号： SC001测试配置号： ST02测试用例依赖： 运行该测试前需要先运行测试用例TC-001测试目标： 验证系统能进行有效的用户注册，对无效的用户注册给出错误提示。 测试过程测试设置 None N/A详细步骤 期望结果 通过（）1在主菜单中点击“注册” 界面上显示用户注册窗口 2在用户名字段输入 3 测试清除 None N/A 测试结果测试人：XuFang 测试日期：mm/dd/yy 测试结果（P/F/B）：F没有

14、将测试数据和测试逻辑分开的测试用例可能显得非常庞大，不利于测试人员理解。将测试用例参数化，可以简化用例，使测试用例逻辑清晰，数据与逻辑的关系明了，易于理解；有利于提高测试用例的复用性。测试用例中数据需要和过程分离吗 ？白盒测试作为结构测试方法，是按照程序内部的结构测试程序，对软件的过程性细节做细致的检查，测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例。 3.2 白盒测试用例设计测试如下程序该如何选择测试数据?Procedure(VAR A,B,X:REAL)；BEGIN IF (A1) AND (B=0) THEN Y:=X/A ; IF (A=2) OR (X1) THEN Z

15、:=X+1END;程序逻辑结构Procedure(VAR A,B,X:REAL); BEGIN IF（A1) AND (B=0) THEN X:=X/A ; IF (A=2) OR (X1) THEN X:=X+1 END;A1ANDB=0X:=X/AA=2OR X1X:=X+1YNYN白盒测试用例设计方法白盒法又称为逻辑覆盖法，其测试用例选择，是按照不同覆盖标准确定的。语句覆盖判定覆盖条件覆盖条件组合覆盖弱强判定条件覆盖路径覆盖1、语句覆盖： 选择足够的测试用例，使得程序中每个语句至少都能被执行一次。2、判定覆盖： 执行足够的测试用例，使得程序中每个判定至少都获得一次“真”值和“假”值。3、

16、条件覆盖：执行足够的测试用例，使得判定中的每个条件获得各种可能的结果。白盒法常用的覆盖标准4、判定/条件覆盖： 执行足够的测试用例，使得判定中每个条件取到各种可能的值，并使每个判定取到各种可能的结果。5、条件组合覆盖： 执行足够的例子，使得每个判定中条件的各种可能组合都至少出现一次。 6、路径覆盖： 执行足够的例子，覆盖程序中所有可能的路径。白盒法常用的覆盖标准语句覆盖：使得程序中每个语句至少都能被执行一次A1ANDB=0Y:=X/AA=2OR X1Z:=X+1abcde应执行路径：ace选择用例：(2,0,4),(2,0,3) 用例格式：输入(A,B,X)，输出(A,B,X)YNYN判定覆盖

17、:使得程序中每个判定至少为TRUE或FALSE各一次A1ANDB=0Y:=X/AA=2OR X1Z:=X+1abcde应执行路径：ace abd或： acd abe选择用例(其一）： (2,0,4),(2,0,3) ace (1,1,1),(1,1,1) abd (2,1,1),(2,1,2) abe (3,0,3),(3,1,1) acdYYNNA1ANDB=0Y:=X/AA=2OR X1Z:=X+1abcde条件覆盖：使得每个判定判定中的每个条件获得各种可能的结果应满足以下情况：判定一: A1, A1, B=0, B0判定二: A=2, A2, X1, X1选择用例： (2,0,4) (1

18、,1,1) NNYY2A1A20B=04X11A1A=21B01X1注意:(1,0,3)(2,1,1)思考：该测试数据能完成测试前面的一、二？判定/条件覆盖：使得判定中的每个判定至少为TRUE或FALSE各一次并且每个条件获得各种可能的结果A1ANDB=0Y:=X/AA=2OR X1Z:=X+1abcde应满足以下情况： 条件: A1, A1, B=0, B0 A=2, A2, X1, X1 应执行路径ace abd或： acd abe选择用例： (2,0,4),(2,0,3)（ace) (1,1,1),(1,1,1) (abd)YYNN条件组合覆盖：使得每个判定中条件的各种可能组合都至少出现

19、一次A1Y:=X/AA=2Z:=X+1abcdeB=0X1YNYNYNYN满足以下情况： A1, B =0 A1, B0 A1, B =0 A1, B0 A=2, X1 A=2, X1 A2, X1 A2, X1选择用例：(2,0,4),(2,0,3) (2,1,1),(2,1,2) (1,0,3),(1,0,4) (1,1,1),(1,1,1) 路径覆盖：执行过程序中所有可能的路径A1ANDB=0Y:=X/AA=2OR X1Z:=X+1abcdeYYNNA B X执行路径2 0 31 0 12 1 13 0 1a c e a b da b e a c d白盒法步骤：1）选择逻辑覆盖标准。2）

20、按照覆盖标准列出所有情况。3）选择确定测试用例。4）验证分析运行结果与预期结果。白盒测试和单元测试单元测试是测试的一个阶段，白盒测试时测试用例设计的一种方法。在单元测试中经常采用白盒测试方法。单元测试过程中，测试者需要模拟被测单元与其他模块间的管理，因此需要设置一些辅助的测试模块。辅助测试模块分为两种：一种是驱动模块（Driver），另一种是桩模块（Stub）。黑盒测试不考虑程序的内部结构与特性，只根据程序功能或程序的外部特性设计测试用例。黑盒测试方法主要等价类划分边值分析因果图判定表法场景法错误推测3.2.7 黑盒测试用例设计保险费率计算程序功能 该程序计算保险费，计算方式为投保额保险率 ，

21、保险率又依点数不同而有别 ，10 点以上费率为0.6 % ，10点以下费率为 0.1% 测试如下程序该如何选择测试数据?保费计算点数规则如下：年龄：一或两位数字。性别：以英文Male、 Female、 M、 F表示。婚姻： 已婚、 未婚。抚养人数：空白或一位数字。程序输入数据要求：1 等价分类法等价类：指某个输入域的子集合，在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。基本思想：根据程序的I/O特性，将程序的定义域划分为有限个等价区段 “等价类”，从等价类中选择出的用例，具有“代表性”。等价类分为： 有效等价类 对于程序的规格说明是合理的、有意义的输入数据构成的集合。 无效等价类

22、对于程序的规格说明，是不合理的，是没有意义的输入数据构成的集合。等价分类法步骤 应按照输入条件（如输入值的范围，值的个数，值的集合，输入条件必须如何）划分为有效等价类和无效等价类。例如：每个学生可选修1-3门课程 可以划分一个有效等价类：选修1-3门课程。 可以划分两个无效等价类：未选修课，选修课超过3门。又如：标识符的第一个字符必须是字母。 可以划分为一个有效等价类：第一个字符是字母。 可以划分一个无效等价类：第一个字符不是字母。 划分“等价类” 显然，关键是如何划分等价类等价分类法步骤等价分类法步骤A、为每个等价类编号；B、使一个测试用例尽可能覆盖多个有效等价类C、特别要注意的是：一个测试

23、用例只能覆盖一个无效等价类。 选择测试用例等价分类法步骤保险费率计算程序根据输入数据值域划分等价类保险费率计算程序根据输入数据值域划分等价类（续）继续分析细分有效等价类和无效等价类 有效等价类无效等价类无效等价类年龄2039任选一个（1）年龄4059任选一个（2）年龄60岁以上（3）；20岁以下任选一个（4）大于60（5）；小于20任选一个（6）大于99选一个（7）性别英文Male（8）；M（9）任选一个非英文字，如“男”（10）非Male、M、Female、F任意英文字，如“Child”（11）性别英文Female（12）；F任选一个（13）婚姻已婚（14）非“已婚”或“未婚”之任意字符。如

24、“离婚”（15）继续分析细分有效等价类和无效等价类 有效等价类无效等价类无效等价类婚姻未婚（16）抚养人数空白（17）抚养人数16（18）小于1选一个（19）抚养人数79（20）大于9选一个（21）保险费率10点以上（0.6%）（22）保险费率10点以下（0.1%）（23）根据等价类选择测试用例目标：覆盖所有等价类用例编号年龄性别婚姻抚养人数保险费率覆盖等价类127Female未婚空白0.6%（1）、（11）、（15）、（16）、（21）250Male已婚20.6%（2）、（7）、（13）、（17）、（21）370F未婚70.1%（3）、（12）、（15）、（19）、（22）415M未婚空白0

25、.6%（4）、（8）、（15）、（16）、（21）50M已婚4无法推算（5）6100Female未婚5无法推算（6）用例编号年龄性别婚姻抚养人数保险费率覆盖等价类71男已婚6无法推算（9）899Child未婚1无法推算（10）930Male离婚3无法推算（14）1075Female未婚0无法推算（18）1117Male已婚10无法推算（20）2 边值分析法 基本思想：选择等价类的边缘值作为测试用例，让每个等价类的边界都得到测试，选择测试用例既考虑输入亦考虑输出。采用边界值分析测试的基本思想是：故障往往出现在输入变量的边界值附近。 因此，边界值分析法利用输入变量的最小值(min)、略大于最小值(

26、min+)、输入值域内的任意值(nom)、略小于最大值(max-)和最大值(max)来设计测试用例。 分析步骤： A、先划分等价类。 B、选择测试用例，测试等价类边界。为什么使用边界值分析法？无数的测试实践表明，大量的故障往往发生在输入定义域或输出值域的边界上，而不是在其内部。因此，针对各种边界情况设计测试用例，通常会取得很好的测试效果。怎样用边界值分析法设计测试用例？（1）首先确定边界情况。通常输入或输出等价类的边界就是应该着重测试的边界情况。（2）选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值。举例 常见的边界值对16-bit 的整数而言 3276

27、7 和 -32768 是边界屏幕上光标在最左上、最右下位置报表的第一行和最后一行数组元素的第一个和最后一个循环的第 0 次、第 1 次和倒数第 2 次、最后一次举例 利用边界值作为测试数据项边界值测试用例的设计思路字符起始-1个字符/结束+1个字符假设一个文本输入区域允许输入1个到255个 字符，输入1个和255个字符作为有效等价类；输入0个和256个字符作为无效等价类，这几个数值都属于边界条件值。数值最小值-1/最大值+1假设某软件的数据输入域要求输入5位的数据值，可以使用10000作为最小值、99999作为最大值；然后使用刚好小于5位和大于5位的 数值来作为边界条件。空间小于空余空间一点/

28、大于满空间一点例如在用U盘存储数据时，使用比剩余磁盘空间大一点（几KB）的文件作为边界条件。选择测试用例的原则(1) 如果输入条件规定了值的范围，则应取刚达到这个范围的边界值以及刚刚超过这个范围边界的值作为测试输入数据。(2) 如果输入条件规定了值的个数，则用最大个数、最小个数和比最大个数多1个、比最小个数少1个的数作为测试数据。(3) 根据程序规格说明的每个输出条件，使用原则 (1)。(4) 根据程序规格说明的每个输出条件，使用原则 (2) 。(5) 如果程序的规格说明给出的输入域或输出域是有序集合 （如有序表、顺序文件等），则应选取集合中的第一个和 最后一个元素作为测试用例。(6) 如果程

29、序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。(7) 分析程序规格说明，找出其它可能的边界条件。 A、按照输入值范围的边界。 例如：输入值的范围是-1.0至1.0，则可选择用例 1.0、1.0、-1.001、1.001。 B、按照输入/输出值个数的边界。 例如：输入文件可有1-255个记录，则 设计用例：文件的记录数为 0个、1个、255个、256个。 C、输出值域的边界。 例如：检索文献摘要，最多4篇。设计用例：可检索0篇、1篇、4篇，和5篇（错误）。 D、输入/输出有序集（如顺序文件、线性表）的边界。 应选择第一个元素和最后一个元素。边值分析法举例3 因果

30、图法 一种黑盒测试方法方法的依据：需求规格说明中的因果关系。把输入条件视为“因”，把输出条件视为“果”，将黑盒看成是从因到果的网络图，采用逻辑图的形式来表达功能说明书中输入条件的各种组合与输出的关系。根据这种关系可选择高效的测试用例。因果图符号恒等c1=1e1=1c1=0e1=0非c1c2c3c1e1c1e1e1c1c2e1c1=1e1=0c1=0e1=1c1=1 或c=1 或c=1 e1=e1=0否则c1=1 且c=1e1=e1=0否则或与a输入条件的约束bEacIbabOE约束（异）：a,b中至多有一个可能为，即a和b不能同时为约束（或）：a,b和c中至少有一个必须是1,即a、b和c不能同

31、时为0O约束（唯一）：a和b中必须有一个 且仅有一个为abRR约束（要求）：a是时，b必须是 即不可能a是时b为输出条件的约束abMM约束（强制）：若结果a是时， 则结果b强制为因果图方法举例某程序要求：第一列字符必须是或，第二列字符必须是一个数字，在此情况下对文件进行修改。若第一列字符不正确，则给出信息；若第二列字符不是一个数字，则给出信息。分析原因第一列字符是第一列字符是第二列字符是一个数字结果21修改文件22给出信息23给出信息因果图21222311E分析规范，即将问题分为若干可工作的步骤。标识出规范中的原因与结果。原因输入条件 结果输出或系统变换分析规范语义、内容，转换为因果图。将因果

32、图转换为判断表。将判断表的每一列，转换为一个测试用例。总结：因果图法的步骤4 判定表法 一种黑盒测试方法系统功能要求： 订购单的检查。如果金额超过500元，又未过期，则发出批准单和提货单；如果金额超过500元，但过期了，则不发批准单；如果金额低于500元，则不论是否过期都发出批准单和提货单，过期还要发出通知单。订购单检查判定表金额 500 500 =500 =500 状态 未过期 已过期 未过期 已过期 发出批准单 发出提货单 发出通知单 条件动作可简化把判定表转换为测试用例判定表里每一个条件项和对应的动作项都是一条规则。判定表里每一条规则都可以转化为测试用例。5 场景法需要进行银行ATM机取

33、款功能测试。利用黑盒方法该如何设计测试用例？问题布置面对实际系统测试如何入手？场景：从用户的角度来描述系统的运行行为，反映系统的期望运行方式，是由一系列的相关活动组成的。学会使用系统该功能，熟悉操作步骤和使用场景考虑系统实现该功能的具体约束和要求（业务需求和规则）1、分析用户操作步骤和使用场景取款成功步骤如下：插入卡输入密码输入取款金额取款成功，钱输出退卡2、结合业务需求和规则系统只能对加入银联的当前能正常工作的银行卡办理取款业务。包括本行银行卡、非本行银行卡。必须是活动的帐号才能取款，冻结的帐号不能取款。成功办理取款业务必须输入正确的银行卡密码。密码连续输入三次不正确，ATM机器警告后吞卡。ATM机中金额不足取款金额，系统给出提示，不能完成取款操作。若银行卡帐内金额不足取款金额，系统给出提示，不能完成取款操作。3、根据场景设计测试用例测试用例ID场景