为了改进测试用例什么是值得做的？什么风险会促使你投资于更好地测试用例？在他们覆盖软件需求时，还不是足够的好吗？对这些问题的答案是，粗劣的测试用例的确会将你暴露于相当大的风险之下。他们在理论上可能覆盖了需要，但很难用来执行测试，并会获得含糊不清的结果。好的测试会获得更可靠的结果，而且会在以下三个范畴降低成本：
1.生产率 - 更短的时间撰写和维护用例
2.可测试性 - 更短的时间来执行他们
3.计划的可靠性 – 估算时有更好的可靠性
本文介绍如何避免因为粗劣的测试案例必然带来的损失。将让我们看到罩盖下各种不同的测试用例，并展示在控制风险的质量中，在何处以及如何建立测试用例。对如何提高生产率、可用性、计划的可靠性和资产管理，将给出切实可行的建议。一旦你了解测试用例是什么和为什么的问题，您可以使用一个标准的核查表，像附录A一样的一个附件，来确定风险领域并改善您当前的和未来的测试用例。
在准备测试软件的过程中，最繁杂的工作是编写测试用例。建立健壮的测试用例的动机是由可能性来激励的，测试用例将被重用于维护版本。超过所有软件开发工作的半数的工作是维护项目。你怎么才能编写良好的测试用例，它将提供经济的测试，首次测试后，在回归测试时将再次使用？让我们通过掀起测试用例的罩盖，看看里面是什么，来开始我们的答案吧。
● 看测试用例内部
● 测试用例的内容（element）
● 针对我们的目标，一个测试用例是一套基于系统需求的，带有预期结果的活动。用例包括这些内容：
● 测试的目标或将被测试的需求的描述
● 它将被如何测试的方法
● 测试的设置：接受测试的应用程序的版本、硬件、软件、操作系统、数据文件、安全访问、时间、逻辑的或物理的起止日期、先决条件（如其他测试），以及对于被测需求（一个或多个）的任何其他有关的设置信息
● 活动和预期的结果，或输入和输出
● 任何校样或附件（可选）
这些同样的内容必需被用在每一级测试——单元、集成、系统、或验收测试的测试用例中。对于功能、性能和可用性测试，它们同样有效。“预期结果”的标准并不适用于一个探索性质的诊断测试或其他测试。实际上诊断测试在其用例中需要其他内容。然而，如果测试是测量性能，那性能应属于一个范围，这个范围就是一个预期结果。
测试用例的另一种描述是，说明、目标和组织安排是用例或规格说明。完成它的步骤被称为脚本。而另一种观点认为目标或说明是一个场景（scenario）或功能用例（use case）。这些观点都符合本文提议的质量评估和改进。
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51Testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。
