测试用例是测试设计的结果，也是绝大部分测试活动的指导性文档，它用测试的语言把需要测试人员执行的工作和检查点描述出来，从而规范测试人员的测试点，并保证一个足够的测试覆盖率（Test Coverage）。

　　设计和构思测试用例时，要像织网一样把测试点设计周密，分布均匀，使之有效和有意义。

　　标准的测试用例，一般包含这样一些内容：

　　（1）编号：每个测试用例的唯一编号，有助于其和测试结果、错误报告等其他文档的链接；

　　（2）测试模块：讲述此测试用例测试的大模块；

　　（3）标题：用简单的一句话来描述此测试用例；

　　（4）测试目的：描述设计此测试用例的目的是什么；

　　（5）测试级别：按照测试用例的重要性来给不同测试用例分级别；

　　（6）先决条件：执行此测试用例之前需要做的准备；

　　（7）输入：测试人员执行测试所需的动作；

　　（8）期望输出：在检查点上待测设备应有的正常反应、动作或显示。

　　除关注上述内容外，要能写出高质量的测试用例，还需要测试工程师们认真思考这样的几个命题：

　　（1）如何保证合适的测试用例覆盖率；

　　（2）如何确保紧跟开发文档的变化；

　　（3）如何把测试用例的重复率限定在适度的范围；

　　（4）如何实现“以测养测”式的测试用例更新；

　　（5）如何实现测试用例在不同产品间重用。

　　一、如何保证合适的测试用例覆盖率

　　测试是一个经济学的概念，不计成本的测试最终会受到市场的惩罚和用户的抛弃。所以为了体现这种明智，测试用例设计所追求的目标不是100%覆盖，而应该是均匀覆盖。让测试用例均匀覆盖功能点的理念，其核心是没有重大漏测。

　　我们知道一个测试用例应该对应至少一个功能点，那么要保证测试用例覆盖率尽可能完整，首先要明确待测功能中有那些功能点，其次才是如何用测试用例对这些功能点进行覆盖。需求跟踪矩阵是对功能点进行有效管理和密切跟踪的一种工具。

　　在实际的项目中如果没有时间精确跟踪到小的功能点，对于大的功能模块总该有一种机制去跟踪，要不然你不管他不管，最后有大的重要的功能模块被漏测，你就要有大麻烦了。

　　二、如何确保紧跟开发文档的变化

　　现实生活中的开发项目，没有一个是从一而终的，项目从最开始做起，随着中间不停的修正，到最后的阶段往往已经面目全非了。

　　在实施了有效管理的项目中，开发一端的任何变化，应该都能清晰及时准确地反馈到测试团队，经过及时地更改（更新测试用例或文档来适应新的变化），他们不会在实际测试中误导测试人员。此外，有效管理不仅仅针对测试人员，在这种时候，开发的修改流程一定要定义得非常严格，如果开发人员能够随意地更改设计，那么对于项目的任何人来讲这都是一种灾难。