测试用例文档的价值在微软和软件测试行业之间有争论。有几个因素可以帮助决定是否选择测试用例文档。测试用例文档有如下一些好处：

　　历史借鉴。测试用例的存在要远远超过产品发布。持续工程以及产品未来版本的负责人往往需要借用测试用例来了解测试过什么，以及如何测试的。测试用例文档以及一个有组织的储存系统，对长期支持或修订产品的一部分是至关重要的策略。

　　测试进展跟踪。通过测试用例文档，可以跟踪一些额外的属性，如测试用例的执行数目、测试用例的通过或失败数目，以及每个功能领域的测试用例总数。

　　可重复性。好的测试用例文档可以由任何人在任何时候执行。这同样适用于自动和手动的测试用例文档。重复准确地执行同样的测试对重视步骤或检验回归是至关重要的。

　　测试用例文档也有如下缺点：

　　建立文档的时间。如果建立测试用例文档的时间比运行测试用例所需的时间还长，建立测试用例文档也许就没有意义了。经常有这样的情况，即测试用例只需要在一个单一的环境下执行寥寥几次。

　　功能变化引起测试用例过期。建立测试用例所需的时间很可能因为功能经常变化而增加，以至于失去控制。如果测试用例的功能领域变化频繁，建立测试用例文档就不一定是明智的。这种场景之一是尝试写测试用例以验证用户界面组件。

　　很难设想读者的知识。写测试用例的人往往对被测试的功能极为熟悉。这些人常犯的错误是在测试用例中使用术语或缩写，而将来运行测试用例的人很可能看不懂这些测试用例。出现这种情况时，测试用例已不再能准确地重复，测试用例也失去了这一关键属性。

　 　测试用例通常用测试用例管理器（TCM）来建立文档，微软大部分团队用测试用例管理器记录绝大多数测试用例。重要的是要记住，测试用例并没有定义所有的 测试活动。如缺陷大扫除，那是整个团队致力于数小时或数天的时间，专注于使用功能或应用程序，寻找可能被测试用例过的缺陷，这种测试活动在微软的各团队是 常见的。许多团队也在产品周期中花时间致力于客户的使用场景。例如，一些Visual Studio的团队经常花一些时间，整个团队除了在Visual Studio开发环境创造和建立各种应用程序外，什么都不做。