本节书摘来自异步社区《软件测试技术实战：设计、工具及管理》一书中的第2章，第2.7节测试用例不应该包含实际的数据，作者顾翔，更多章节内容可以访问云栖社区“异步社区”公众号查看。

2.7　测试用例设计的若干错误观点
2.7.1　能发现到目前为止没有发现的缺陷的用例是好的用例
首先申明，这句话十分有道理，但很多人都曲解了这句话的原意，认为“能够发现难以发现缺陷的测试用例才是好的测试用例”，却忘记了软件测试的目的所在，这是十分可怕的。笔者倾向于将测试用例当作一个集合来认识，对它的评价也只能对测试用例的集合来进行。软件测试本身是一种“确认和验证”的活动。软件测试需要保证以下两点。

• 程序做了它应该做的事情。
• 程序没有做它不该做的事情。

因此，作为软件测试实施依据的测试用例，必须能完整覆盖软件测试的需求，而不应该针对单个测试用例去评判好坏。

2.7.2　测试用例应该详细记录所有的详细操作信息
讨论这个问题前，可以先考虑一下软件测试的目的。软件测试的目的之一是尽可能发现程序中存在的缺陷。软件测试活动本身也可以被看作是一个项目，也需要在给定的资源条件下尽可能达成目标。根据笔者个人的经验，大部分的国内软件公司在软件测试方面配备的资源都是不足够的，因此必须在软件测试计划阶段明确软件测试的目标，一切围绕软件测试的目标进行。

除了资源上的约束外，测试用例的详细程度也需要根据需要来确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要写得太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的，就可以了。

一般在软件测试计划中，软件测试设计的时间占30%～40%，软件测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。

2.7.3　测试用例设计出来后是不用维护的
想必没有一个人会认可这句话是正确的，但在实际情况中，却经常能发现这种想法的影子。笔者曾经参与过一个项目，软件需求和设计已经变更了多次，但测试用例却没有任何修改。导致的直接结果是新加入测试工程师在执行测试用例时不知所措，间接的后果是测试用例成了一堆废纸，开发工程师在多次被无效的缺陷报告打扰后，对软件测试工程师不屑一顾。

这个例子可能有些极端，但测试用例与需求和设计不同步的情况在实际开发过程中确是屡见不鲜的。测试用例文档是“活的”文档，这一点应该被软件测试工程师牢记。

2.7.4　测试用例不应该包含实际的数据
在很多软件测试工程师编写的测试用例中，“预期输出”仅描述为程序的可见行为。其实，“预期结果”的含义并不只是程序的可见行为。例如，对一个订货系统，输入订货数据，单击“确定”按钮后，系统提示“订货成功”，这样是不是一个完整的用例呢？是不是系统输出“订货成功”，就应该作为唯一的验证手段呢？显然不是。订货是否成功还需要查看相应的数据记录是否更新，因此，在这样一个用例中，还应该包含对软件测试结果的显式的验证手段：在数据库中执行查询语句进行查询，看查询结果是否与预期一致。

测试用例是“一组输入、执行条件、预期结果”，毫无疑问地应该包括清晰的输入数据和预期输出。没有测试数据的用例最多只具有指导性的意义，不具有可执行性。当然，测试用例中包含的输入数据会带来维护、与软件测试环境同步之类的问题，关于这一点，《Effective Software Test》书中提供了详细的测试用例、软件测试数据的维护方法，供读者参考。