选择一个测试类型 对一种类型的测试用例的偏好超过另一个，多起因于机构的文化和观念，而不是什么最适合于软件和测试计划。“我们一直这样做”已和一些难改的谬论相结合：
谬论之一。分步测试用例要花太长的时间来编写。我们负担不起。
事实：他们可能会或不会需要较长的时间来编写，粒度小使他们健壮和易于维护。他们是唯一充分测试一些功能的方法。
谬论之二。矩阵始终是最好的选择。选用它吧。
事实：一个长期存在的问题是如何把一个矩阵和适当的组织安排信息放在一起。这一组织安排信息往往被忽略，或更糟糕的是，如果输入的不同的组织安排或分类不能强加成一个带有类似组的矩阵，他们根本就不能被测试。
谬论之三。高技术是最好的。如果您可以自动化测试用例，就去做它。
事实：使用自动化测试的决定应基于许多因素。
谬论之四。我们没有时间编写手工测试用例。让我们自动化测试用例吧。
事实：自动化测试用例的创建需要比其他两种类型更长的时间。
如果一个有支配权力的人不懂装懂的说出这些谬论，一个不成熟的组织（一个更多地依靠杰出人士而不是过程的组织）是最容易认为这些谬论是正确的。他们的质量之路将是一个漫长的道路。他们会继续误解测试用例，直到他们经受打乱的时间表或经费损失为止，显然他们经受的这些起因于不良的测试。
为工作使用最佳的测试用例类型的另一个约束是在文字和数字表达之间的接近状况。如果你擅长于一个或另一个，你可能更喜欢你可以直观地去做的测试用例类型。分步用例倾向于更多的文字，而矩阵倾向于更多的数字。良好的培训应建立起对于使用所有类型的用例的了解和信心，对于每一处它都是最有成效的。然而，个人偏好是一个不可忽视的因素。如果你是一个经理，你需要通过教育和范例克服困难。
往往最有成效的途径是使用所有三种类型的用例。前两个用于单元、集成和系统测试；而自动化脚本用于回归测试。
提升测试用例
提高测试用例的可测试性
准确的说，可测试性的定义是指易于测试。易于测量执行测试需要多久，在测试过程中测试者是否需要获得说明。准确意味着，如果测试者遵循指导，那么通过或失败的结果将会是正确的。
用语言提高可测试性
测试步骤应该编写在生动的用例中。告诉测试者做什么。例如：
● 做这个。做那个。
● 浏览购物车页面。
● 对比车中物品和屏幕捕获的物品。
● 点击<OK>。
应始终明确的是，是测试者做一些事，还是系统做它。如果一个测试者读到， “按钮被按下，”这意味着他或她应该按下按钮呢，还是它意味着已经按下后验证系统显示它？搞乱测试者最好的一种办法是混淆活动和结果。比如，活动总是在左侧，结果在右侧。测试者做什么总是一个活动。系统显示什么或者做什么始终是一个结果。
如果我们知道一个对象的内外，养成一个简单的习惯，就是以不同的方式提及相同的事情。测试语言要一丝不苟地命名显屏、字段、服务器、Web网页、或其他测试对象。在一个开发团队，我们习惯于在某些对象甚至是原型以前，一般就提到它，如“电子邮件答复屏幕，”而它的标签实际将指：“订单确认。”或者我们可能用数字指一个显屏，无论测试者在哪儿看它，数字都不会出现。测试必须有精确的参考来指导测试者。
如果您为了测试者注意以后将核实的输入，建立了结构化的字段，测试可能加速。例如，如果你正在测试一个审核日志，你事先不能知道测试者将完成一个审核活动的确切分钟。如果你告诉他们注意它，它可能被胡乱地写在测试中，纸片上，或加进一个临时文件。他们可能不会找麻烦来标明什么是什么，并可能不得不到处搜寻来找到它。最好是在测试中留下一个标记的空格，在这里，他们可以写下输入，示例：
删除条目日期：________时间： _______
条目编号：________
测试者登录ID ：________
通过控制长度来提高可测试性
一个测试用例应该多长？一个好的分步用例长度是10-15步，除非测试者不节省他们的工作。保持测试这么简短有几个好处：
● 简短的用例用更少的时间来测试每一个步骤
● 测试者不太可能受迷惑，犯错误，或需要帮助。
● 测试经理可以准确估计需要多少时间来测试
● 结果更容易追踪
不要试图在10-15个步骤的标准上作弊，把很多活动填满一个步骤。
一个步骤应该是一个明确的输入或测试任务。您总可以在相同的步骤中添加一个简单的完成标志，如单击<OK>或按<Enter>。同样，一个步骤可以包括一套逻辑相关的输入。您不必对每个步骤都有结果，如果系统不响应某一步的话就不需用。
保持单个测试简短的目标并不是不符合用最少数量的测试来测试应用系统的传统的目标。传统目标标准的目的是要精巧，当合理的测试业务场景或用例（use case）和需求一样多时，会工作到10-15步。该标准的目的还在于避免重复，即在一些测试中测试相同的需求。你可能不想通过使每一个测试都很长，来创建最低数量的测试，因为对于测试或维护来说，这将是一个恶梦。看老的“最低数量的测试，”的更好的方法是，衡量是否是一个“最低数量的步骤。”那么通过将50个步骤放入一个中以创造较少的测试是感觉不到好处的。
对于一个矩阵，一个好的长度是可以测试约20分钟。
自动化脚本的长度不是一个测试执行问题，因为测试通常是几秒钟。相反，问题是内容、维护和缺陷跟踪的管理。每个脚本一个业务场景或用例是足够的。它可以根据需要循环多次来加载数据或执行变量组合。
累积用例的优点和缺点
累积用例是那些依赖于以前的用例来运行的用例 — 在你测试＃6以前，你得先运行测试 1-5。您的目标是让测试尽可能的独立。这给了安排测试最大的灵活性，并减少了维护时间。可惜的是，它落后的一面是，该标准可能会不符合其他标准，如保持每个测试用例简短和不重复覆盖。你如何达到这一点呢？
● 问问自己，是否你真正需要从另一个测试输入数据？如果是这样，测试必须是具有累积性的。
● 只要有可能，提供一个以前的测试的替代品。这意味着它们可以使用在以前的测试中建立的数据，同时它们也可以使用其他数据。例如：“你需要两个处于90天拖欠状况的帐户，如为逾期帐户的测试用例所创建的账户。”
● 提及其他测试时要象共有的一样尽可能在精确性上保持一致。不要只用编号提及一些测试。测试重编号后。如果您使用一个编号，还包括标题或说明。这可避免维护时的恶梦。
改善可用性或可测试性的另一个问题是测试用例的顺序，它们应该根据业务使用排序。什么是最终用户通常首先做得，不是他们首先不得不做的，象在累积用例中一样？如果测试者是一个商业用户，他们将有一个他们希望完成软件任务的心理模式。通过复制其模式来适应他们，增加了他们的测试生产率。
用模板提高生产率
测试用例模板是一个带有标签字段的表单。附加的附录B是一个分步测试用例的模板。这是开始提高测试用例的一个重要的方式。它加快开始编写过程，并提供一个好用例的各个内容。这里是使用模板的一些其他的好处：
● 防止空白页的恐慌
● 对混乱现象给于帮助
● 用标准创建
● 打印好看的测试
● 协助测试者找到信息
● 可以包括与测试过程相关的其他字段
