分步测试的用例不一定需要有一个按键的细节程度，如图1所示。那个操作步骤，可以在更高的层次，例如：打开“我的帐户”页面，搜索交易日期范围，注意范围：______，打印报告，提出报告，等等。

　　矩阵，矩阵用例最有成效的用途是：

　　● 在一张表中填写各种不同的值，同一领域，不同的值，输入文件

　　● 相同的输入，不同的平台，浏览器，配置

　　● 屏幕字符

　　● 输入和输出最好以矩阵表示

　　几乎所有的测试，可以表示成为一个矩阵，但问题是决定矩阵是否是最好的测试方法。矩阵由描述，计划以及如何记录结果组成，这是最重要的。如何测试矩阵这对于用例设计者而言这可能是显而易见的，但对于其他测试人员，如果没有更多的指导，情况就不一样了。

　　矩阵的变化其实就是各种输入。一个分步测试或矩阵可以作为测试的解释性要素插入进来。

　　自动化脚本，决定使用自动化测试软件更大程度取决于做测试的项目和组织，而不是被测试的是什么产品。还有一些技术上的问题必须满足，各种工具都各不相同，但大多数应用程序都可以找到一个合适技术。项目管理人员必须明白需要编写自动化测试用例比手动测试时间长，因为必须手动测试用例仍然需要先写。当接口是稳定的，则测试也是可被记录的。自动化测试真正的回报是在软件生命周期的维护阶段。然后那时候，脚本可以重复执行，即使是在无人值守的时候，测试时间大量节省。

　　管理部门必须提供一些使用工具语言如C + +或Visual Basic来编程的人。简单的脚本可以由大多数的测试分析人员去录制，但更强大的脚本往往需要使用自定义函数和对象，必须由程序员编写的。一个小组可以由几个人做普通的记录/回放脚本，一个人编程一起工作。

　　对比其他几种比较适合于录制和播放，或数据驱动的脚本，使用自动化工具的性能和负载测试就不仅仅是这些了。他们可能使用常规的分步用例或矩阵来详细介绍自动化工具如何使用，以创建虚拟用户，运行事务脚本，监控性能，以及其他活动。

　　选择测试类型

　　人们选择哪种测试用例的类型，更多的是由所在组织的文化以及直觉来决定的，即“什么才是适合软件以及测试方案的”。“我们一直是这样做”往往被加入一些神秘色彩，难以消灭：

　　神话1，分步测试用例需要很长时间才能完成，我们消耗不起。

　　现实：他们可能会或可能不会花费更长的时间写作，粒度使他们牢固，易于维护。它们是用来充分测试某些功能的唯一方法。

　　神话2，矩阵始终是最好的选择，使用它

　　现实：一个永恒的问题是将恰当的设置信息放到一个矩阵中。这常常导致信息被忽略，或更糟糕的是，如果不同的设置或输入类不能成为一类进入矩阵，他们不会被测试到的。

　　神话3，高科技是最好的，如果你能将测试用例自动化，那么就这样做。

　　现实：决定使用自动测试应基于许多因素。

　　神话4，我们没有时间写手动测试用例，让我们自动化。

　　现实：自动测试用例相比于其他两种类型需要更长的时间来编写

　　不成熟的组织（个性超过流程的）当领导人这样告诉他们时，是最容易假设这些神话是真的。他们质量的道路将是非常漫长的。他们可以继续对于测试用例的误解，直到他们认识到计划没有完成或预算损失，显然是由于不良的测试所引起的。

　　另一种阻碍大家利用最合适的测试用例用于工作的原因是是口头之间的紧张关系和数字 表达。如果你擅长于多种测试类型，那么您可能更喜欢某种测试类型，而不是直观。分步测试更倾向于口头，矩阵则更倾向于数字。良好的培训应建立对于每种测试用例的理解和信任，每一个种测试都有它最有生产力的应用场景。但是个人喜好是一个不容忽视的因素。如果你是经理，你需要通过教育和实例来弄懂。通常，最有成效的途径是使用所有三种类型用例方法，前两个主要用于单元，集成和系统测试，回归测试使用自动化的脚本。

　　改进测试用例

　　提高测试用例的可测试性

　　可测性的定义是很容易测试。实际上，容易可通过需要多长时间执行测试来衡量，以及测试人员在测试过程中是否对自己所进行的事情有明确的认识。也就是说，如果测试人员依照用例执行，测试结果无论是否通过，都是正确的。

　　通过语言改善可测试性

　　测试步骤应该用积极的用例，告诉测试人员做什么，例如：

　　● 这样做，那样做

　　● 导航到购物车页面

　　● 比较购物篮中的商品与屏幕截图

　　● 单击<确定>按钮