设计和维护测试用例¶
第 11 章¶
设计和维护测试用例¶
测试用例是为了实现测试有效性的一种最基本的手段。好的测试用例可以帮助我们更快地发现缺陷，并在测试过程中不断被重复使用。同时，在测试过程中可以通过对测试用例的组织和跟踪来完成对测试工作的量化和管理。本章将从软件测试实践中一些常用的测试用例设计思想、方法和组织角度，来阐述如何设计测试用例。
通过本章的学习，可以了解和掌握以下内容。
11.1 测试用例构成及其设计¶
测试用例是有效地发现软件缺陷的最小测试执行单元，是为了特定目的 (如考察特定程序路径或验证是否符合特定的需求) 而设计的测试数据及与之相关的测试规程的一个特定的集合。测试用例在测试中具有重要的作用，测试用例拥有特定的书写标准，在设计测试用例时需要考虑一系列的因素，并遵循一些基本的原则。
测试用例设计的方法很多，普遍会采用黑盒测试方法和白盒测试方法。这些基本方法已在第 3 章中做了详细讨论，其中黑盒测试方法包括等价类划分法、边界值分析方法、因果图、决策表、功能图法、正交试验法等，而白盒测试方法包括语句覆盖、条件覆盖、分支覆盖、条件 - 分支组合方法、基本路径覆盖等。测试用例设计方法还可以采用数据流分析、控制流分析、业务逻辑时序分析、基于程序错误的变异、基于代数运算符号和形式逻辑等方法来完成。
11.1.1 测试用例的重要性¶
前面的章节中，已经多次提到在测试过程中需要通过执行测试用例来发现缺陷。为什么需要测试用例呢？在测试过程中使用测试用例具有以下几个方面的作用。
因此，测试用例将会使得测试的成本降低，并具有可重复使用功能，也是作为检测测试效果的重要因素，设计良好的测试用例是测试的最关键工作之一。
测试用例不是每个人都可以编写的，它需要撰写者对产品的设计、功能规格说明书、用户场景以及程序 / 模块的结构都有比较透彻的了解。测试人员刚开始工作时，只能执行别人写好的测试用例，随着测试人员的经验积累和技术的提高，逐渐掌握测试用例的设计方法和所需的知识，这时测试人员就能够独立编写测试用例，当然，可以请资深人员帮助审查，以控制测试用例的质量。
11.1.2 测试用例设计书写标准¶
在编写测试用例过程中，需要遵守基本的测试用例编写标准，并参考一些测试用例设计的指南。在 ANSI/IEEE 829—1983 标准中，列出了和测试设计相关的测试用例编写规范和模板，而标准模板中主要元素罗列如下。
来说，在整个测试模块里面应该包含整个测试环境的特殊需求，而单个测试用例的测试环境需要表征该测试用例单独所需要的特殊环境需求。
（4）输入标准 (Input Criteria)：用来执行测试用例的输入需求。这些输入可能包括数据、文件或者操作 (例如鼠标的单击、击键等)。
(5) 输出标准 (Output Criteria): 标识按照指定的环境、条件和输入而得到的期望输出结果。如果可能，尽量提供适当的系统规格说明来证明期望的结果。
(6) 测试用例之间的关联：用来标识该测试用例与其他测试用例之间的依赖关系。在测试的实际过程中，很多的测试用例并不是单独存在的，它们之间可能有某种依赖关系，例如，用例 A 需要基于 B 的测试结果正确的前提上才被执行，此时需要在 A 的测试用例中表明对 B 的依赖性，从而保证测试用例的严谨性。
综上所述，如果使用一个数据库的表来描述测试用例的主要元素，如表 11-1 所示。
表 11-1 测试用例元素表示
| 字段名称 | 类型 | 是否必选 | 注释 |
| 标志符 | 整型 | 是 | 唯一标识该测试用例的值 |
| 测试项 | 字符型 | 是 | 测试的对象 |
| 测试环境要求 | 字符型 | 否 | 可能在整个模块里面使用相同的测试环境需求 |
| 输入标准 | 字符型 | 是 | |
| 输出标准 | 字符型 | 是 | |
| 测试用例间的关联 | 字符型 | 否 | 并非所有的测试用例之间都需要关联 |
如果用数据词典的方法来表示，测试用例可以简单地表示成：测试用例 = \(\{输入数据+操作步骤+期望结果\}\) , 其中 \(\{\}\) 表示重复。这个式子还表明，每一个完整的测试用例不仅包含被测程序的输入数据，而且还包括执行的步骤、预期的输出结果。
接下来，这里用一个具体的例子来描述测试用例的组成结构。例如，对 Windows 记事本程序进行测试，选取其中的一个测试项 ——“文件 (File)” 菜单栏的测试。
测试对象：记事本程序 “文件” 菜单栏（测试用例标识 1000，下同），所包含的子测试用例描述如下：
| -- -- -- -- 文件/新建(1001)
| -- -- -- -- 文件/打开(1002)
| -- -- -- -- 文件/保存(1003)
| -- -- -- -- 文件/另存(1004)
| -- -- -- -- 文件/页面设置(1005)
| -- -- -- -- 文件/打印(1006)
| -- -- -- -- 文件/退出(1007)
| -- -- -- -- 菜单布局(1008)
| -- -- -- -- 快捷键(1009)
选取其中的一个子测试用例 —— 文件 / 退出 (1007) 作为详细例子 —— 完整的测试用例描述，如表 11-2 所示。通过这个例子，可以了解测试用例具体的描述方法和格式。通过实践，获得必要的技巧和经验，能更好地描述出完整的、良好的测试用例。
表 11-2 一个具体的测试用例
| 字段名称 | 描述 |
| 标志符 | 1007 |
| 测试项 | 记事本程序,“文件”菜单栏——“文件”→“退出”菜单的功能测试 |
| 测试环境要求 | Window 2000 Professional,中文版 |
| 输入标准 | (1)打开 Windows 记事本程序,不输入任何字符,鼠标单击选择菜单——“文件”→“退出”。(2)打开 Windows 记事本程序,输入一些字符,不保存文件,鼠标单击选择菜单——“文件”→“退出”。(3)打开 Windows 记事本程序,输入一些字符,保存文件,鼠标单击选择菜单——“文件”→“退出”。(4)打开一个 Windows 记事本文件(扩展名为.txt),不做任何修改,鼠标单击选择菜单——“文件”→“退出”。(5)打开一个 Windows 记事本文件,做修改后不保存,鼠标单击选择菜单——“文件”→“退出” |
| 输出标准 | (1)记事本未做修改,鼠标单击菜单——“文件”→“退出”,能正确退出应用程序,无提示信息。(2)记事本做修改未保存或者另存,鼠标单击菜单——“文件”→“退出”,会提示“未定标题文件的文字已经改变,想保存文件吗?”单击“是”按钮,Windows 将打开“保存”/“另存”对话框;单击“否”按钮,文件将不被保存并退出记事本程序;单击“取消”按钮将返回记事本窗口 |
| 测试用例间的关联 | 1009(快捷键测试) |
11.1.3 测试用例设计考虑因素¶
一般来说，穷举测试是不可能实现的，因此试图用所有的测试用例来覆盖所有测试可能遇到的情形是不可能的，所以，在测试用例的编写、组织过程中，应尽量考虑有代表性的典型的测试用例，来实现以点带面的穷举测试，这要求在测试用例设计中考虑以下一些基本因素。
行模拟，还需要考虑各种网络连接方式的速度。在本地化软件测试时，需要尊重用户的所在国家、区域的风俗、语言以及习惯用法。关于本地化语言的测试，详见第 10 章。
示例一¶
用户登录的功能设计规格说明书 (摘选)
1. 用户登录¶
1.1 满足基本页面布局图示 (登录页面图，此处略去)。
1.2 当用户没有输入用户名和密码时，不立即弹出错误对话框，而是在页面上使用红色字体来提示，见 2 描述。
1.3 用户密码使用掩码符号 (*) 来标识。
1.4 * 代表必选字段，将出现在输入文本框的后面。
2. 登录出现错误¶
当出现错误时，在页面的顶部会出现相应的错误提示。错误提示的内容见 3。错误提示是高亮的红色字体实现。
3. 错误信息描述¶
3.1 用户名输入为空
| 属性 | 值 |
| 编号 | MSG0001 |
| 显示的页面 | ErrorPage0001 |
| 出现条件 | 当用户输入的用户名为空而试图登录 |
| 提示信息 | 错误:请输入用户名 |
3.2 密码为空
| 属性 | 值 |
| 编号 | MSG0002 |
| 显示的页面 | ErrorPage0002 |
| 出现条件 | 当用户密码输入为空且没有出现 WMSG001 的提示信息 |
| 提示信息 | 错误:请输入密码 |
3.3 用户名 / 密码不匹配
| 属性 | 值 |
| 编号 | MSG0003 |
| 显示的页面 | ErrorPage0003 |
| 出现条件 | 当用户名和密码不匹配时 |
| 提示信息 | 错误:您输入的用户名或者密码不正确 |
通用安全性设计规格说明书 (摘选)
1. 安全性描述¶
1.1 输入安全性：在用户登录或者信用卡验证过程中，如果三次输入不正确，页面将需要重新打开才能生效。
1.2 密码：在所有的用户密码中，都必须使用掩码符号（*），数据在数据库中存储使用统一的加密和解密算法。
1.3 Cookie: 在信用卡信息验证，用户名输入时，Cookie 都是被禁止的，当用户第一次输入后，浏览器将不再提供是否保存信息的提示信息，自动完成功能将被禁用。
1.4 SSL 校验：所有的站点访问时，必须经过 SSL 校验。
2. 错误描述 (略)¶
测试用例
结合相关规格说明书要求，理解和掌握测试用例设计的关键点，测试用例设计如表 11-3 所示。这里实际把多个测试用例放在一起，构成单个功能测试的用例集合。
表 11-3 用户登录功能测试用例 (集合)
| 字段名称 | 描述 |
| 标志符 | 1100 |
| 测试项 | 站点用户登录功能测试 |
| 测试环境要求 | 1. 用户test/pass为有效登录用户,用户test1为无效登录用户。2. 浏览器的Cookie未被禁用 |
| 输入标准 | 1. 输入正确的用户名和密码,单击“登录”按钮。2. 输入错误的用户名和密码,单击“登录”按钮。3. 不输入用户名和密码,单击“登录”按钮。4. 输入正确的用户名并不输入密码,单击“登录”按钮。5. 三次输入无效的用户名和密码尝试登录。6. 第一次登录成功后,重新打开浏览器登录,输入上次成功登录的用户名的第一个字符 |
| 输出标准 | 1. 数据库中存在的用户将能正确登录。2. 错误的或者无效用户登录失败,并在页面的顶部出现红色字体:“错误:用户名或密码输入错误。”3. 用户名为空时,页面顶部出现红色字体提示:“请输入用户名”。4. 密码为空且用户名不为空时,页面顶部出现红色字体提示:“请输入密码”。5. 三次无效登录后,第4次尝试登录会出现提示信息“您已经三次尝试登录失败,请重新打开浏览器进行登录”,此后的登录过程将被禁止。6. 自动完成功能将被禁用,查看浏览器的Cookie信息,将不会出现上次登录的用户和密码信息,第一次使用一个新账户登录时,浏览器将不会提示“是否记住密码以便下次使用”对话框。7. 所有的密码均以“*”方式输入 |
| 测试用例间的关联 | 1101(有效密码测试) |
示例二¶
在上面提到的用户登录页面的示例一中，需要考虑特殊字符的输入，尤其是脚本语言敏感的字符输入。将上面的测试用例集合进行完善如下 (用粗体标出), 如表 11-4 所示。
表 11-4 用户登录功能测试用例的完善
| 字段名称 | 描述 |
| 标志符 | 1100 |
| 测试项 | 站点用户登录功能测试 |
| 测试环境要求 | 1. 用户pass/pass为有效登录用户,用户pass1/pass为无效登录用户,用户pass'jean/ password为有效登录用户。2. 浏览器的Cookie未被禁用 |
| 输入标准 | 1. 输入正确的用户名和密码,单击“登录”按钮。2. 输入错误的用户名和密码,单击“登录”按钮。3. 不输入用户名和密码,单击“登录”按钮。4. 输入正确的用户名并不输入密码,单击“登录”按钮。5. 输入带特殊字符的用户名(带/,',"或#,如pass'jean)和密码,单击“登录”按钮。6. 三次输入无效的用户名和密码尝试登录。7. 第一次登录成功后,重新打开浏览器登录,输入上次成功登录的用户名的第一个字符 |
| 输出标准 | 1. 数据库中存在的用户(pass/pass,pass'jean/password)将能正确登录。2. 错误的或者无效用户登录失败,并在页面的顶部出现红色字体:“错误:用户名或密码输入错误。”3. 用户名为空时,页面顶部出现红色字体提示:“请输入用户名”。4. 密码为空且用户名不为空时,页面顶部出现红色字体提示:“请输入密码”。5. 含特殊字符(‘,/‘”,#)的用户名,如数据库中有该记录,将能正确登录,如无该用户记录,将不能登录,校验过程和普通的字符相同,不能出现空白页面或者脚本错误。6. 三次无效登录后,第4次尝试登录会出现提示信息“您已经三次尝试登录失败,请重新打开浏览器进行登录”,此后的登录过程将被禁止。7. 自动完成功能将被禁用,查看浏览器的Cookie信息,将不会出现上次登录的用户和密码信息,第一次使用一个新账户登录时,浏览器将不会提示“是否记住密码以便下次使用”对话框。8. 所有的密码均以“*”方式输入 |
| 测试用例间的关联 | 1101(有效密码测试) |
11.1.4 测试用例设计的基本原则¶
在设计测试用例时，除了需要遵守基本的测试用例编写规范外，还需要遵循一些基本的原则。
1. 避免含糊的测试用例¶
含糊的测试用例给测试过程带来困难，甚至会影响测试的结果。在测试过程中，测试用例的状态是唯一的，一般是下列三种状态中的一种。
如果测试未通过，一般会有对应的缺陷报告与之关联；如未进行测试，则需要说明原因 (测试用例条件不具备、缺乏测试环境或测试用例目前已不适用等)。因此，清晰的测试用例将会使得测试人员在进行测试过程中不会出现模棱两可的情况，对一个具体的测试用例不会有 “部分通过，部分未通过” 这样的结果。如果按照某个测试用例的描述进行操作，不能找到软件中的缺陷，但软件实际存在和这个测试用例相关的错误，这样的测试用例是不合格的，将给测试人员的判断带来困难，同时也不利于测试过程的跟踪。
举例：还用示例一来说明，对用户登录的页面校验测试设计，如测试用例描述如下。
(1) 输入正确的用户和密码，所有程序工作正常。
(2) 输入错误的用户和密码，程序工作不正常，并弹出对话框。
像上面这样的测试用例，未能清楚地描述什么样是程序正常工作状态以及程序不正常工作状态，这样含糊不清的测试用例必然会导致测试过程中问题的遗漏。
2. 尽量将具有相类似功能的测试用例抽象并归类¶
我们一直强调软件测试过程是无法穷举测试的，因此，对相类似的测试用例的抽象过程显得尤为重要，一个好的测试用例应该是能代表一组同类的数据数据或相似的数据处理逻辑过程。
3. 尽量避免冗长和复杂的测试用例¶
这样做的主要目的是保证验证结果的唯一性。这也是和第一条原则相一致的，为的是在测试执行过程中，确保测试用例的输出状态唯一性，从而便于跟踪和管理。在一些很长和复杂的测试用例设计过程中，需要对测试用例进行合理的分解，从而保证测试用例的准确性。在某些时候，当测试用例包含很多不同类型的输入或者输出，或者测试过程的逻辑复杂而不连续时，需要对测试用例进行分解。
11.2 测试用例的组织和跟踪¶
测试用例最终是为实现有效的测试服务的，那么怎样将这些测试用例完整地结合到测试过程中加以使用呢？这就涉及测试用例的组织、跟踪和维护问题。
11.2.1 测试用例的属性¶
在整个测试设计和执行过程中，可能涉及很多不同类型的测试用例，这要求我们能有效地对这些测试用例进行组织。为了组织好测试用例，必须了解测试用例所具有的属性。不同的阶段，测试用例的属性也不同，如图 11-1 所示。基于这些属性，可以采用数据库方式更有效地管理测试用例。
其中，标识符、测试环境、输入标准、输出标准等构成了测试用例的基本要素，在 11.1 节中已做过介绍，而其他的具体属性，下面给予详细的说明。
11.2.2 测试套件及其构成方法¶
如何进行测试用例的组织？组织测试用例的方法，一般采用自顶向下的方法。首先在测试计划中确定测试策略和测试用例设计的基本方法，有时会根据功能规格说明书来编制测试规格说明书，如图 11-2 所示，而多数情况下会直接根据功能规格说明书来编写具体的测试用例。
在测试用例组织和执行过程中，还需要引入一个新概念 —— 测试套件 (Test Suite)。测试套件是根据特定的测试目标和任务而构造的某个测试用例的集合。这样，为完成相应的测试任务或达到某个测试目标，只要执行所构造的测试套件，使执行任务更明确、更简单，有利于测试项目的管理。测试套件可以根据测试目标、测试用例的特性和属性 (优先级、层次、模块等), 来选择不同的测试用例，构成满足特定的测试任务要求的测试套件，如基本功能测试套件、负面测试套件、Mac 平台兼容性测试套件等。
那么如何构造有效的测试套件呢？通常情况下，使用以下几种方法来组织测试用例。
以上各种方式中，根据程序的功能模块进行组织是最常用的方法，同时可以将三种方式混合起来，灵活运用。例如，可以先按照不同的程序功能块将测试用例分成若干个模块，再在不同的模块中划分出不同类型的测试用例，按照优先级顺序进行排列，这样就能形成一个完整而清晰的组织框架。
如图 11-3 所示，体现了测试用例组织和测试过程的关系，这是基于前面的测试用例特性分析，以及如何有效地完成测试获得的。这个过程可以简单描述如下。
11.2.3 跟踪测试用例¶
在测试执行开始之前，测试组长或测试经理应该能够回答下面一些问题。
根据这些问题，对测试执行做到事先心中有数，有利于跟踪测试用例执行的过程，控制好测试的进度和质量。
前面提到，测试过程中测试用例有三种状态 —— 通过 (Pass)、未通过 (Fail) 和未测试 (Not Done)。根据测试执行过程中测试用例的状态，针对测试用例的执行和输出而进行跟踪，从而达到测试过程的可管理性以及完成测试有效性的评估。跟踪测试用例，包括以下两个方面的内容。
（1）测试用例执行的跟踪。良好的测试用例自身具有易组织性、可评估性和管理性，实现测试用例执行过程的跟踪可以有效地将测试过程量化。例如，在一轮测试执行中，需要知道总共执行了多少个测试用例？每个测试人员平均每天能执行多少个测试用例？测试用例中通过、未通过以及未测试的各占多少？测试用例不能被执行的原因是什么？当然，这是个相对的过程，测试人员工作量的跟踪不应该仅凭借测试用例的执行情况和发现的程序缺陷多少来判定，但至少可以通过测试执行情况的跟踪大致判定当前的项目进度和测试的质量，并能对测试计划的执行做出准确的推断，以决定是否要调整。
（2）测试用例覆盖率的跟踪。测试用例的覆盖率指的是根据测试用例进行测试的执行结果与实际的软件存在的问题的比较，从而实现对测试有效性的评估。
如图 11-4 所示，在一个测试执行中，92% 的测试用例通过，5% 的测试用例未通过，3% 的测试用例未使用。在发现的软件缺陷和错误中，有 92% 通过测试用例检测出来，而有 10% 未通过测试用例检验出来，此时，需要对这些软件错误进行分类和数据分析，完善测试用例，从而提高测试结果的准确性，使问题遗漏的可能性最小化。
、如图 11-5 所示是针对每个测试模块的测试用例的跟踪示意图，通过对比，不难发现，模块二和模块三的未通过率和未使用率都比较高，此时测试组长需要对这两个模块的测试用例以及测试过程进行分析，是这个模块的测试用例设计不合理？还是模块本身存在太多的软件缺陷？根据实际的数据分析，可以对这两个模块重新进行单独测试，通过纵向的数据比较，来实现软件质量的管理和改进。
凭借个人的记忆来跟踪测试用例，几乎是不可能的，所以一般会采用下列方法来跟踪测试用例。
（1）书面文档。在比较小规模的测试项目中，使用书面文档记录和跟踪测试用例是可行的一种方法，测试用例清单的列表和图例也可以被有效地使用，但作为组织和搜索数据进行分
析时，就会遇到很大的困难。
（2）电子表格。一种流行而高效的方法是使用电子表格来跟踪和记录测试的过程，如图 11-6 所示，通过表格列出测试用例的跟踪细节，可以直观地看到测试的结果，包括关联的缺陷，然后利用电子表格的功能比较容易进行汇总、统计分析，为测试管理和软件质量评估提供更有价值的数据。
图 11-6 跟踪和记录测试的过程
| A | B | C | D | E | F | |
| 1 | 测试跟踪表 | |||||
| 2 | 测试组件/测试用例 | 测试结果(2004/01/10) | 测试结果(2004/01/20) | 测试结果(2004/01/30) | 软件缺陷ID列表 | |
| 3 | 模块一 | |||||
| 4 | 测试用例1001 | PASS | PASS | PASS | ||
| 5 | 测试用例1002 | PASS | PASS | PASS | ||
| 6 | 测试用例1003 | FAIL | PASS | PASS | 10 | |
| 7 | 测试用例1004 | PASS | PASS | PASS | ||
| 8 | 测试用例1005 | PASS | PASS | PASS | ||
| 9 | 测试用例1006 | FAIL | FAIL | PASS | 13,15 | |
| 10 | 测试用例1007 | PASS | PASS | PASS | ||
| 11 | 测试用例1008 | PASS | PASS | PASS | ||
| 12 | 测试用例1009 | PASS | PASS | PASS | ||
| 13 | 测试用例1010 | PASS | PASS | PASS | ||
| 14 | ||||||
| 15 | 模块二 | |||||
| 16 | 测试用例2001 | FAIL | PASS | PASS | 19 | |
| 17 | 测试用例2002 | PASS | PASS | PASS | ||
| 18 | 测试用例2003 | PASS | PASS | PASS | ||
| 19 | 测试用例2004 | PASS | PASS | PASS | ||
| 20 | 测试用例2005 | FAIL | FAIL | FAIL | 11,20,24 | |
| 21 | 测试用例2006 | PASS | PASS | PASS | ||
| 22 | 测试用例2007 | PASS | PASS | PASS | ||
| 23 | 测试用例2008 | PASS | PASS | PASS | ||
| 24 | 测试用例2009 | PASS | PASS | PASS | ||
| 25 | 测试用例2010 | PASS | PASS | PASS | ||
（3）数据库是最理想一种方式，通过基于数据库的测试用例管理系统，非常容易跟踪测试用例的执行和计算覆盖率。测试人员通过浏览器将测试的结果提交到系统中，并通过自己编写的工具生成报表、分析图等，能更有效地管理和跟踪整个测试过程。
11.2.4 维护测试用例¶
测试用例不是一成不变的，当一个阶段测试过程结束后，我们或多或少会发现一些测试用例编写得不够合理，需要完善。而当同一个产品新版本测试中要尽量使用已有的测试用例，但某些原有功能已发生了变化，这时也需要去修改那些受功能变化影响的测试用例，使之具有良好的延续性。所以，测试用例的维护工作是不可缺少的。测试用例的更新，可能出于不同的原因。由于原因不同，其优先级、修改时间也会有所不同，详见表 11-5。
表 11-5 测试用例维护情况一览表
| 原因 | 更新时间 | 优先级 |
| 先前的测试用例设计不全面或者不够准确,随着测试过程的深入和对产品功能特性的更好理解,发现测试用例存在一些逻辑错误,需要纠正 | 测试过程中 | 高,需要及时更新 |
| 所发现的、严重的软件缺陷没有被目前的测试用例所覆盖 | 测试过程中 | 高,需要及时更新 |
| 新的版本中添加新功能或者原有功能的增强,要求测试用例做相应改动 | 测试过程前 | 高,需要在测试执行前更新 |
| 测试用例不规范或者描述语句的错误 | 测试过程中 | 中,尽快修复,以免引起误解 |
| 旧的测试用例已经不再使用,需要删除 | 测试过程后 | 中,尽快修复,以提高测试效率 |
维护测试用例的过程是实时的、长期的，和编写测试用例不同，维护测试用例一般不涉及测试结构的大改动，例如在某个模块里面，如果先前的测试用例已经不能覆盖目前的测试内容，可能需要重新定义一个独立的测试模块单元来重新组织新的测试用例。但在系统功能进行重构时，测试用例也会随之重构。测试用例的维护流程如图 11-7 所示。
（1）任何人员（包括开发人员、产品设计人员等）发现测试用例有错误或者不合理，向编写者提出测试用例修改建议，并提供足够的理由。
11.2.5 测试用例的覆盖率¶
测试用例的覆盖率是评估测试过程以及测试计划的一个参考依据，它根据测试用例对测试的执行结果与软件实际存在的问题进行比较，从而获得测试有效性的评估结果。例如，确定哪些测试用例是在发现缺陷之后再补充进来的，这样就可以基本给出测试用例的覆盖率:
测试用例的覆盖率 = 发现缺陷后补充的测试用例数 / 总的测试用例数
如果想更科学地判断测试用例覆盖率，可以通过测试工具来监控测试用例执行的过程，然后根据获得的代码行覆盖率、分支或条件覆盖率来确定测试用例的覆盖率。
我们需要对低覆盖率的测试用例进行数据分析，找出问题的根本原因，从而更有针对性地修改测试用例，更有效地组织测试过程。例如，通过了解哪些缺陷没有测试用例覆盖，可以针对这些缺陷添加相应的测试用例，这样就可以提高测试用例的质量。
当然，测试用例的覆盖率并非一个绝对的判定因素，它对整个测试过程起到一个分析、参考的作用，应该知道，将测试用例的覆盖率作为检验测试过程和代码质量的依据是不够准确或充分的。
小结¶
测试用例的设计是测试过程中一个很重要的组成部分，围绕测试用例而形成的测试过程和组织方法是一个比较复杂的软件过程，测试用例的设计也是循序渐进的过程，是随着测试过程的进行和完善而逐渐成熟起来的。
在白盒测试用例设计方法中，以逻辑覆盖法为主，包括语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖和路径覆盖。而在等价类划分法、边界值分析法、错误推测法、因果图法、功能图法等黑盒测试用例设计方法中，常常将等价类划分法和边界值分析法组合起来使用。
根据测试用例的属性，分阶段、分模块来构造测试套件，更好地组织和执行测试用例。随着需求的变化，测试用例要做相应的改动；随着测试的深入，我们会对产品的特性有更深的理解，发现更多的缺陷，需要不断完善现有的测试用例。也就是说，在整个软件开发周期中要对测试用例进行有效的跟踪和维护。