如何设计一个项目的测试用例

5.3.1  设计测试用例前的准备和材料的组织

软件测试是“使用人工或自动手段运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清实际结果与预期结果之间的差别”。可见，测试用例必须建立在需求的基础上，根据需求中的定义设计测试用例，检验系统的实际行为是否与需求指定的行为一致。

测试人员必须非常了解被测试的软件，需要有可测试的、完整的和详细的需求说明书。但是在实际工作中，定义了所有关系和依赖的完整而详细的需求是很少的，有的项目甚至根本没有需求文档。这时则可采用以下方法：

1. 阅读文档，向相关人员咨询

如果没有可以用来导出测试用例的需求，那么为了更好地了解正在开发的应用程序，测试人员可以向客户代表、技术人员当面咨询，同时还要阅读任何可以利用的文档，例如，当前系统或者遗留系统（就是当系统由于某些局限，如技术方面的局限，而无法满足新的业务要求，因而需要进行远远超出维护范畴的修改时，系统即己成为遗留系统，通常可以理解为上一版本的系统）的用户手册。如果存在遗留系统，那么可能会得到用于遗留系统开发过程的设计文档和设计标准。但是，设计文档并不一定能正确地描述用户需求。

2. 探索性测试

通常测试人员还可以通过探索性测试来获得更多的需求。如果对要测试的系统缺乏了解，不仅可以通过应用和分析确定应用程序的本质，还可以进行探索性的测试工作。这时可以把软件当产品说明书来对待，分步骤地逐项探索软件特性，记录软件执行情况，详细描述功能。

探索性测试与经过深思熟虑的、计划好的测试过程有所不同，它并不预先设计测试用例或者精确地按照一个计划来执行，它依靠的是测试人员的知识水平和创造力。探索性测试可以运用在整个编写测试计划、设计测试用例和执行测试过程中。如：

Ø 当测试人员执行一个测试过程，发现了一个错误并且试图重现并分析它的时候，为了有助于确定问题的原因和重现步骤，要使用探索性测试。

Ø 在发现缺陷的过程中，需要探索和研究缺陷与应用程序其他部分之间的关系，这通常要采用测试用例中没有的步骤。

运用探索性测试发现的问题将有助于测试人员确定工作的重点，例如：如果测试出系统的某个部分缺陷成堆，而另一个部分缺陷相对较少，那么就可以根据这些信息调整工作的重点。

由于探索性测试的指导思想是具体问题具体分析，所以它们是不能预先规划的，但是为了实现测试的可重复性，并达到足够的测试覆盖率，则可在执行前或者执行后把探索测试文档化。

5.3.2  测试用例的内容

ANSI/IEEE829标准称测试用例为“编写用于输入的实际数值和预期结果”。可见测试用例就是要确定向软件发送什么值或什么条件，以及预期的输出结果。通常，我们用Excel表格或Word表格的形式书写测试用例，这时可参阅表5-1和表5-2所示的模板，模板列出了测试用例的格式。

1. 测试用例模板

表5-1 Excel表格

表5-2 Word表格

接下来以Excel模板为例说明各主要条目的主要内容。

Ø 项目名称：指明本测试用例是用来测试什么软件项目的。

Ø 功能模块名：指明要测试的内容，如菜单名称、模块名称等。

Ø 测试目的：描述被测试功能的详细的特性及要测试的目标。

Ø 预置条件：执行测试用例之前所做的操作，如启动程序等。

Ø 用例编号：标识该测试用例的唯一编号。

Ø 相关用例（用例间的依赖关系）：列出必须先于本测试用例执行的测试用例。例如，在进行即时贴的删除便签测试之前，需要先执行添加新便签的测试。

Ø 用例说明：描述实现用例的步骤。

Ø 输入数据：描述测试用例所需的输入数据或条件。例如测试计算器，输入可以就是1 +1；测试基于文件的操作，输入可以是文件名，或者内容的描述。

Ø 预期结果：描述输入数据后程序应该输出的结果。例如，1+1的预期结果是2；输入文件名可以正确打开文件，文件的内容和预期的一致。通常情况下，可以通过检查具体的屏幕、报告、文件等方式来确认实际结果与预期结果是否一致。

Ø 测试结果：此项在测试执行时填写，说明测试用例是否通过，如果不通过(即执行测试用例过程中发现了缺陷)，就要生成缺陷报告，并注明缺陷的编号。这里的缺陷编号要与缺陷跟踪系统中的编号一致。

2. 测试用例实例

表5-3和5-4是根据Excel模板编写的两个关于即时贴程序的测试用例。

表5-3  测试用例1

表5-4  测试用例2

通过以上的实例可以看出，在设计测试用例时要注意以下几方面：

Ø 使用最有可能发现错误的用例。例如系统规定最多添加50个便签，可以测试添加第51个便签时系统是否不允许。

Ø 用例不重复、不冗余。如果检查了便签标题为40或41字节的情况，又同时检查标题为10、20、30字节的情况就是冗余的测试，因为它们和测试标题为40个字节的情况没有本质区别。

Ø 选取一组相似测试用例中最有效的。由于穷举测试是不可能的，也是不经济的，因此必须挑选有效的用例来测试。例如，测试便签标题可以是10、20、30或40字节，因为系统规定便签标题内容最多为40字节，所以可以选取40字节这个有代表性的值。

Ø 测试用例不要太简单，也不要太复杂。所有的测试过程都有一定的时间和预算限制，太复杂的测试用例过于消耗编写和执行的时间，另外，测试用例并不是一个测试人员使用，所有测试人员、程序员及其他相关人员都会读到测试用例，太简单的用例不利于使用和维护。测试用例要书写准确，简洁明了。必须给定明确的预期结果。测试执行结果的正确性是可判定的，每一个测试用例都应有相应的预期结果，不能是含糊不清、模棱两可的。例如添加第51个便签，实际结果是系统无反应，没有任何提示。如果我们不在预期结果中指出系统必须给出友好提示，就没办法判定输出是否正确。

测试用例的格式还可以有其他选择，我们可以在设计用例之前和其他人交流，发挥创造性，使用最有效、最方便的测试方法，注意不要偏离设计测试用例的目的，应保证测试的质量。

5.3.3  测试用例设计的注意事项

（1） 测试用例应尽早设计

通常应在测试设计阶段设计测试用例，即在需求规格说明书和测试计划完成之后。

（2） 测试用例由专门的人来设计

测试人员分不同角色，如测试经理、测试设计人员、测试执行人员和测试工具开发人员等。一般测试用例由测试设计人员来编写，由测试执行人员执行，因此，测试设计人员应具备一定的测试用例设计经验，并对被测软件有深入的了解。

（3） 测试用例的功能描述要与软件需求规格说明保持一致

测试用例设计的依据通常是用户需求，具体的参考资料是系统需求规格说明书和软件原型。因此，功能描述必须与需求规格说明一致。

（4） 测试用例的设计并非一劳永逸

由于用户的需求往往一直在变，应通过软件需求的版本控制，明确不同版本的产品中所实现的特性，哪些特性将在以后的版本中实现，然后在该需求版本划定的范围内设计测试用例。因此随着开发版本的迭代，测试用例的设计也是个迭代的过程。

（5） 在不知道预期结果的情况下应推迟用例设计

如果需求无法明确，或需求不明确，则对于该需求的测试用例设计应推迟，并及时与需求设计人员进行交流，尽快将需求准确定义下来。

（6） 在设计测试用例过程中注意与其他人员的沟通

测试用例编写时应与需求设计人员沟通，确保有明确的需求。测试用例编写之后，测试正式开始之前，应与需求设计人员及开发人员对测试用例进行评审，通过评审可以发现重复的用例，遗漏的用例，甚至是错误的用例。做到三方共识（开发人员可接受，用户可简单掌握，测试人员可通过），这对测试工作的开展有较好的辅助作用。

（7） 测试用例在不同阶段下实施时应该是独立的

目前，测试工作与开发工作已越来越相似，包括测试需求的整理、测试用例的设计及测试用例的实现。用例本身就是用来指导具体的测试实现，用例实现的时候可以是自动化脚本也可以是手工操作的具体步骤。

（8） 整个测试用例设计顺序逻辑性要强，以便于测试人员执行用例

若测试过程逻辑过于复杂且不连续，则应对测试用例进行分解。

（9） 测试用例应满足自清除性

每个测试用例最终都应返回到预置的测试环境，否则，测试用例将受到执行顺序的影响。

（10） 测试用例本身无法保证覆盖需求

测试用例是用来指导具体测试实现的，包括自动化脚本和手工测试步骤的实现。测试用例对测试需求的覆盖不是测试用例编写的目的，而是对测试工作的要求，即要求测试用例设计人员的阶段性工作的结果必须符合一定要求。测试用例本身是无法保证覆盖需求的。

（11） 每个测试用例应有一个唯一的标识（ID）