测试用例是一系列特定的软件行为，用于验证软件的某特定功能、检查软件能否正确处理某种出错行为、或者检查其他一些软件质量衡量的属性 （如性能、安全、可靠性等）。 一个测试用例是一个正式的文件或记录，描述了测试活动是怎样具体执行的。测试用例设计的目的就是发现缺陷，但是测试用例的用处远远超出发现缺陷。

测试用例文档的一些好处如下：

1、历史借鉴：测试用例的存在要远远超过产品发布。持续工程（Sustained engineering）以及产品未来版本的负责人往往需要借用测试用例来了解测试过什么，以及是如何测试的。测试用例文档和一个有组织的储存系统对长期支持或修订产品的一部分是至关重要的策略。----注----为了便于后来者对于测试用例的使用和借鉴，测试用例设计要尽量描述准确、步骤清晰。

2、测试进展跟踪：通过测试用例文档，可以跟踪一些额外的属性，如测试用例的执行数目，测试用例的通过或失败数目，以及每个功能领域的测试用例总数。 ----注----在测试用例管理系统中要准确且实际地描述用例的执行结果，包括其他必填的属性，便于分期人员从各个属性和维度进行测试过程分析。

3、可重复性：好的测试用例文档可以由任何人在任何时候执行。这同样适用于自动和手动的测试用例。重复准确地执行同样的测试对重现步骤或检测回归是至关重要的。 ----注----测试用例的描述要准确、全面，要能保证除自己以外的测试人员能正确理解和执行该用例。

测试用例文档也有缺点：

1、建立文档的时间：如果建立测试用例文档的时间比运行测试用例所需的时间还长，建立测试用例文档也许就没有意义了。经常有这样的情况，即测试用例只需要在一个单一的环境下执行寥寥几次。 ----注----但是从测试用例价值的角度来考虑，建立测试用例文档却是个不可裁剪的过程。但是，这个缺点会随着用例设计的熟练程度的提高以及用例设计平均时间成本的减小而逐渐减弱。

2、功能变化引起测试用例过期：建立测试用例所需的时间很可能因功能经常变化而增加，以至于失去控制。如果测试用例的功能领域变化频繁，建立测试用例文档就不一定是明智的。这种场景之一是尝试写测试用例以验证用户界面组件。 ----注----功能需求或者设计和实现的变化常常导致测试用例需要调整和修改，甚至有时候修改用例的时间会超过新建用例的时间。因此，在用例设计过程中，保持与设计、开发人员的密切沟通，及时了解功能变化的情况十分必要。否则后期再修改用例的时间成本很大。当然，在软件开发后期，软件需求和设计尽量保持稳定是最合适的。

3、很难设想读者的知识：写测试用例的人往往极为熟悉被测试的功能。这些人常犯的错误是在测试用例中使用术语或缩写，而将来运行测试用例的人很可能看不懂这些测试用例。出现这种情况出现时，测试用例已不再能准确地重复，测试用例也失去了这关键属性之一。 ----注----为了用例便于后来者正常使用该用例，用例设计应尽量避免使用只有自己熟悉的专业词汇和缩写词，或者存在用例描述太简洁但自己能理解的情况。

测试用例设计的误区

创建好的测试用例是一个困难的过程。即使一个错误就可以毁掉测试用例的意图。一些易出问题的领域如下： 

1、步骤缺乏：  匆忙建立的测试用例或假设测试用例的一些步骤会被执行而未将它们包括在测试用例里是非常常见的错误, 它造成不能准确地重复。----注----必要的用例步骤不能省，避免在执行用例的时候出现描述不清导致模棱两可的情况发生，从而影响案例执行进度。

2、太多细节： 虽然提供具体和足够的信息很重要，不必要的字词或冗长的解释，会使测试用例难以遵循。仅需包含足够的信息以便精确地运行测试用例。  ----注----太多的细节描述会增加案例设计的成本，适可而止即可。

3、行话太多： 不要以为运行测试用例的人（包括产品技术支持和持续工程）都知道所有你写的缩略语，代号和缩写。阐明任何对整个产品生命周期有价值和必要的信息。  ----注----同上缺点3的注释。

4、不明确的通过/失败标准： 如果运行测试后，不清楚测试是否通过或失败，那测试用例是毫无用处的。----注----测试用例的预期结果一定要准确和清晰。对于测试后存在不符合预期结果的情况，即可判断为失败，全部符合预期结果则为成功。

注：本文为《微软的软件测试之道》一书9.3.2和9.3.4章节内容整理后的阅读笔记，感谢本书作者Alan Page。