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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、如何把测试用例的重复率限定在适度的范围

　　（1）优化测试用例数据库的结构，分类要细致，关键词要准确

　　（2）简单或重要的功能点要容忍一定的冗余（重要功能点的重复测试可以避免一个测试人员的疏忽而导致动能点漏测，双保险）

　　（3）花费时间长，执行复杂的测试用例，对重复的检查要严格一些

　　（4）夸口测试用例的数量是没有意义的。

　　四、如何实现“以测养测”式的测试用例更新

　　测试用例不可能达到100%覆盖，所以说自由测试是不可少的补充，在自由测试中会发现很多未考虑到的问题，这些问题在被更改的同时，测试人员也要把发现的问题以新用例的形式记录下来。这样就可以长期对此问题进行监控，以保证将来再测试其他项目时测试人员不会把它漏掉。

　　在测试用例开发完成之后，以后如果发现有什么新的有趣的地方值得测试，需要及时把这些东西通过测试用例的形式记录下来。

　　五、如何实现测试用例在不同产品间重用

　　需要遵循两条原则：

　　（1）避免设计过于特定化的测试用例（详细到菜单项的每个菜单名）

　　（2）尽量缩小单一测试用例的覆盖范围，把测试用例设计得短小精悍

　　当有些用例确实不符合新产品的描述时，需要测试团队有统一的要求：

　　（1）以功能点衡量测试用例通过与否的标准，即待测的核心功能点工作正常，但测试用例中的其他描述与产品实现不符，这是我们仍旧认为此测试用例通过。当然这时需要马上做的是更新测试用例，使下一轮测试时不需要再面对这种情况。

　　（2）一切以测试用例为标准，稍有不符就算此用例失败，这能够迫使测试团队尽快采取行动更新测试用例，这种方式最简单直接，但是这样会导致测试结果无法准确地标示出软件实际的质量水平。

　　职场谏言：好多人的抱怨不见得就高明，职场中90%的人是在随波逐流和人云亦云，只有少数人有自己的思想、意志和雄心。

本文出自 hellorenwei 的51Testing软件测试博客：http://www.51testing.com/?578951