对测试用例的投资：

　　改进测试用例有什么价值呢？当你集中精力于更好的用例时，你会遇到什么样的风险呢？之前的用例已经覆盖了软件需求，那还不够好吗？这些问题的答案是，粗糙的测试用例会将你置于相当大的风险中。他们能从理论上覆盖需求，但是很难执行测试，预期的结果也是模棱两可。好的测试用例包含更可靠的测试预期并且能从三方面降低测试成本。

　　1、生产力：更少的时间来编写和维护用例

　　2、可测性：更少的时间啦执行这些用例

　　3、调度的可靠性：更可靠的测试预期

　　本文介绍了如何避免由于粗糙的用例设计所带来的风险。我们将更底层地从不同类型的测试用例分析，并展示在何处及如何建立质量来控制风险。它会就如何提高生产率，可用性，调度的可靠性和资产管理提供切实可行的建议。一旦你了解了用例的“什么”和“为什么”，你可以使用一份标准的检查点清单来确定风险领域以改善当前和未来的测试用例。

　　为测试软件所做的最多的工作就是编写测试用例。激励大家编写强健的测试用例的是维护版本成本减少的可能性。半数以上的软件项目都是需要长期维护的项目。那么你怎样擦能写出既经济，有能在回归测试中再次使用的高质量的测试用例呢？让我们开始寻找答案，撩起测试用例的面纱，看看里面究竟有什么。

　　展望测试用例内部：

　　测试案例的要素：

　　对我们而言，一个测试用例建立在系统需求之上的一系列动作和预期结果的集合。测试用例包括下面这些内容：

　　◆ 测试目的或者对于所测试内容需求的描述

　　◆ 测试方法

　　◆ 测试计划：应用程序版本，硬件环境，软件环境，操作系统，数据文件，

　　安全访问，测试时间，逻辑或物理的日期，测试先决条件(比如其他测试)，以及其他任何与被测软件系统需求相关的测试信息。

　　◆ 步骤和预期结果，或者输入输出

　　◆ 任何检验或附件（可选）

　　这些相同的元素，需要在每种级别测试的测试用例中体现：集成，系统，或 验收测试，对于功能，性能和可用性测试同样适用。“预期结果“标准不适用于诊断或其他探索性测试。诊断测试需要在他的用例中添加其他因素。不过，如果我们测试的结果应该属于一个范围，那么这也是“预期的结果”。测试用例的一个替代描述是说明，目的和设置情况或详细说明书。完成这些的步骤被称为脚本。然而另观点是将目的或者描述称为测试场景或者测试用例。所有这些观点在本文中对于质量评估和改进建议都是一致的。

　　测试用例的质量：

　　有一种误解，用例的编写质量是就跟欣赏一幅画一样，是主观的，就如情人眼里出西施。其实，用例的编写质量是客观的和可衡量的。如附录A中所示，我们能建立一个清晰的检查点列表，包含测试用例的结构性因素- -测试目的，测试方法，测试计划，输入和输出。然后遍历每条用例，元素是有或没有？此外对它们的结构，测试用例也必须符合下面这些质量标准。

　　◆ 精确的，他们只测试在他们的说明中需要进行测试的。

　　◆ 经济的，他们只有为了测试目的所必须的测试步骤说明，而不是为软件写一个手册

　　◆ 可重复，自立式的，测试用例是一个对照实验。不管是谁在什么时间执行测试，都应该得到完全相同的测试结果。如果只有测试编写者能够执行测试并获得结果，或如果不同的测试人员得到不同的测试结果，那么我们需要在测试步骤及动作设计上做更多的工作。

　　◆ 适当的，测试用例要对测试人员和的环境都应该是合适的。如果所设计的测试用例只是理论上的，实际执行需要的技能没有一个测试人员拥有，那么这只是一个空架子而已。当你知道谁是将第一次执行测试，你需要为他的测试执行铺好路：用例维护和回归。

　　◆ 可追踪性，你需要知道你用例所测试的软件需求是什么？它可能符合所有其他标准，但如果其结果，及格或不及格，不打紧，何必呢？

　　◆ 自我清理，执行完后将环境清理干净，测试环境返回测试前的状态。例如，不在错误的日期离开所测试的测试系统。自动化脚本，可通知其它脚本来做到这一点。不要将这个标准和破坏性混淆。测试应具有破坏性，包括通过一些可控制的，可重复的方法模拟一个生产环境。

本文转载自51Testing软件测试网，查看全文：http://www.51testing.com/html/64/n-225564.html