|
|
| 仔细计划测试用例，是达成测试目标的必由之路。这样做的重要性体现如下。
|
|
|
| 即使在小型软件项目上，也可能有数千个测试用例。建立用例可能需要一些测试员经过几个月甚至几年的时间。正确的计划会组织好用例，以便全体测试员和其他项目小组成员有效地审查和使用。
|
|
|
| 我们已经知道，在项目期间有必要多次执行同样的测试，以寻找新的软件缺陷，保证老的软件缺陷得以修复。假如没有正确的计划，就不可能知道需要执行哪个测试用例，原有的测试是否得到重复。
|
|
|
| 有时我们需要回答整个项目期间的重要问题。例如，计划执行多少个测试用例；在软件最终版本上执行多少个测试用例；多少个通过，多少个失败；有忽略的测试用例吗，等等。如果没有测试用例计划，就不能回答这些问题。
|
|
|
| 在少数高风险行业中，软件测试小组必须证明确实执行了计划执行的测试。发布忽略某些测试用例的软件是危险的。正确的测试用例计划和跟踪提供了一种证实测试的手段。
|
|
|
|
|
| 大家知道，项目整体测试计划的级别非常高。它虽然把软件拆分为具体特性和可测试项，并将其分派到每个测试员头上，但是它并没有指明如何对这些特性进行测试，可能仅仅对使用自动化测试还是黑盒测试或者白盒测试有一些提示，但是并不会涉及如何使用以及在哪里使用这些工具。
|
|
|
| 为了更好地进行测试，我们需要为单个软件特性定义具体的测试方法，这就是测试设计说明。ANSI/IEEE 829中对测试设计说明的解释是：测试设计说明就是在测试计划中提炼测试方法，要明确指出设计包含的特性以及相关的测试用例和测试程序，并指定判断特性通过/失败的规则。
|
|
|
| 测试设计说明的目的是组织和描述针对具体特性需要进行的测试。然而，它并不给出具体的测试用例或者执行测试的步骤。以下内容来自于ANSI/IEEE 829标准，应该作为测试设计说明的部分内容。
|
|
|
| . 标识符：用于引用和定位测试设计说明的惟一标识符。该说明还应该引用整个测试计划，还应该包含任何其他计划或者说明的引用。
|
|
|
| . 要测试的特性：对测试设计说明所包含的软件特性的描述。例如“计算器程序的加法功能”、“写字板程序中的字体大小选择和显示”、“QuickTime软件的视频卡配置测试”。该部分还将明确指出要间接测试的特性，它通常作为主特性的辅助特性。例如，文件打开对话框的用户界面虽然不在测试设计说明中重点指出，但是在测试读写功能的过程中要间接测试。
|
|
|
| . 方法：描述测试的通用方法。如果方法在测试计划中列出，就应该在此详细描述要使用的技术，并给出如何验证测试结果的方法。例如，我们这样描述一种方法，开发一种测试工具，顺序读写不同大小的数据文件，数据文件的数目和大小及包含的内容由程序员提供的示例来确定。用文件比较工具比较输出的文件和源文件，如果相同，则认为通过；如果不同，则认为失败。
|
|
|
| . 测试用例信息：用于描述所引用的测试用例的相关信息。应该列出所选的等价区间，给出测试用例的引用信息以及用于执行测试用例的测试程序说明。例如：“检查最大值测试用例ID#15326”、“检查最小值测试用例ID#15327”，在这部分不定义实际测试用例。
|
|
|
| . 通过/失败规则：描述用什么规则来判定某项特性的测试结果是通过还是失败。这种描述有可能非常简单和明确，例如“通过是指当执行全部测试用例时没有发现软件缺陷”。也有可能不是非常明确，例如“失败是指10%以上的测试用例没有通过”。
|
|
|
|
|
| 如何记录和记载创建的测试用例？如果你已经开始进行一些软件测试了，就可能采用过一些用例描述格式。本节讲解编写测试用例的有关内容，指出将要考虑的重点。
|
|
|
| ANSI/IEEE 829标准称测试用例说明为编写用于输入输出的实际数值和预期结果，同时还明确指出，使用具体测试用例产生的测试程序的限制。一个测试用例的编写可参考下表。
|
|
|
|
|
|
|
| 测试用例应该解释要向软件发送什么值或者条件，以及预期结果。一个测试用例说明可以由多个测试用例说明来引用，也可以引用多个测试程序。ANSI/IEEE 829标准还列出了一些应该包含在内的重要信息，如下所示。
|
|
|
| . 标识符：由测试设计过程说明和测试程序说明引用的惟一标识符。
|
|
|
| . 测试项：描述被测试的详细特性、代码模块等，应该比测试设计说明中所列的特性更加具体。如果测试设计说明提到“计算器程序的加法功能”，那么测试用例说明就会相应地提到“加法运算的上限溢出处理”。它还要指出引用的产品说明书或者测试用例所依据的其他设计文档。
|
|
|
| . 输入说明：该说明列举执行测试用例的所有输入内容或者条件。如果测试计算器程序，输入说明可能简单到“1＋1”。如果测试蜂窝电话交换软件，输入说明可能是成百上千种输入条件。如果测试基于文件的产品，输入说明可能是文件名和内容的描述。
|
|
|
| . 输出说明：描述进行测试用例预期的结果。例如，1＋1等于2吗？在蜂窝软件中上千个输出变量设置正确吗？读取文件的全部内容和预想的一样吗？
|
|
|
| . 环境要求：是指执行测试用例必要的硬件、软件、测试工具、人员等。
|
|
|
| . 特殊要求：描述执行测试必须的特殊要求。测试写字板程序也许不需要任何特殊条件，但是测试一些特殊的软件（如核电站软件）就有特殊要求。
|
|
|
| . 用例之间的依赖性：如果一个测试用例依赖于其他用例，或者受其他用例的影响，就应该在此注明。
|
|
|
| 如果按照这里推荐的文档格式，对于每一个测试用例至少都要写上一页的描述文字，数千个测试用例可能要形成几千页文档。所以我们经常把ANSI/IEEE 829标准当作规范而不是标准使用（除非必须这样做，许多政府项目和某些行业要求按照此规格编写测试用例，但是在大多数情况下可以采用简便方法）。
|
|
|
| 采用简便方法并不是说放弃或者忽视重要的信息，而是意在找出一个更有效的方法对这些信息进行精简，例如，没有必要刻意要求不能用书面段落形式表述测试用例。如下表给出了一个打印机兼容性简单列表的例子。
|
|
|
|
|
|
|
| 表中的每一行是一个测试用例，有自己的标识符。伴随测试用例的所有其他信息，例如测试项、输入说明、输出说明、环境要求、特殊要求和依赖性等对所有这些用例都必须有，可以一并编写，附加到表格中。审查测试用例的人可以快速看完测试用例信息，然后审查表格，检查其范围。
|
|
|
| 表述测试用例的其他选择有大纲、状态表或数据流程图等方式。
|
|
|
|
|
| 编写完测试设计和测试用例之后，就要说明执行测试用例的程序。什么是测试程序呢？ANSI/IEEE 829标准把测试程序定义为“明确指出为实现相关测试设计而执行具体测试用例和操作软件系统的全部步骤”。
|
|
|
| 测试程序，有时也叫“测试脚本说明”，详细定义了执行测试用例的每一步操作。以下是需要定义的内容。
|
|
|
| . 标识符：用来把测试程序与相关测试用例和测试设计相联系的惟一标识。
|
|
|
| . 目的：本程序描述的目的以及将要执行的测试用例的引用信息。
|
|
|
| . 特殊要求：执行测试所需的其他程序、特殊测试技术或者特殊设备。
|
|
|
| . 程序步骤：执行测试用例的详细描述。它包含以下内容。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 如果我们把测试程序只理解成“尝试执行所有的测试用例并报告发现的问题”是不够的。这虽然简单、容易，但是无法告诉新加入的测试员如何进行测试，不能重复而且无法证明哪些步骤执行了。使用详细的程序说明，则把要测试什么、如何测试等问题都表述得一目了然。如下图所示是“Windows计算器”的测试程序说明的例子片断。
|
|
|
|
|
|
|
|
|
| 俗话说“做什么都要适可而止”，测试用例计划也一样。测试用例计划包括四个目标，即组织性、重复性、跟踪和测试证实。开发测试用例的软件测试工程师要力争实现这些目标，但是其实现程度取决于行业、公司、项目和测试组的具体情况，通常也不太可能按照最细致的程度去编写测试用例。
|
|
|
| 我们设计的测试用例计划要力求达到最佳的详细程度，比如，在一个测试程序中要求在PC机上安装Windows 2000来执行测试，测试程序在其设置部分声明需要Windows 2000，但是未声明Windows 2000的哪个版本。那么一两年内出现新版本会怎样？测试程序需要升级来反映这个变化吗？为了避免这个问题，可以省略具体的版本，而用“可用的最新版本”这样的说明来替代。
|
|
|
| 无比详细的测试用例说明减少了测试的随意性，使测试可以很好地重复，使得无经验的测试人员按照测试用例说明也能执行测试。但是编写如此细致的测试用例说明要花费相当多的时间和精力，并且由于细节繁多，也会阻滞测试工作，造成测试执行时间变长。
|
|
|
| 开始编写测试用例时，最好是采用当前项目的标准，同时需要根据ANSI/IEEE 829标准定义的格式，看什么符合项目要求，并可以做适当的调整。
|
|
|
| 不同的测试工程师设计的测试用例也会有所不同。通常有经验的测试工程师设计出来的测试用例，在深度及广度上会比经验少的测试工程师的完整，这也是所谓的测试经验值。举例来讲，客户反应前一版V1.3的软件在Windows 98的环境下运行时，在屏幕保护程序激活后会产生问题，开发工程师将这问题解决并且已提交修正版本供客户网络下载，并且目前开发工程师所开发的软件最新版本为V1.5版，软件测试工程师就必须在V1.5版的测试用例内，加入屏幕保护程序激活测试用例，甚至将这个用例增加至其他的测试平台。
|
|
|
