测试用例写的太细化了，则适应不了系统的变更需求；写的太粗糙，则可操作性不强，太随意。，如果文档中的对操作步骤描述的过于具体，像下面这样：

01.在“用户名”项中输入“user”；

02.在“密码”项中输入“password”；

03.点击“确定”按钮。

这样的描述方式表面看起来可操作性似乎是增强了，任何人拿到这个文档都可以充当测试人员，检查一下这个功能是否存在缺陷。但是我们不要忘记，在开发过程中，变更的存在是必然的。一旦需求、设计或者应用程序中的某些细节发生了变化，比如“用户名”变成了“操作员”，“密码”变成了“口令”，“确定”变成了“登录”，或者输入项所接受的数据类型发生了变化，那么同这部分内容相关的所有的测试用例都需要修改。否则，我们凭什么可以保证这些描述不同的测试用例说的是同一样东西？如果我们只有这么一个测试用例，也许一切都不是问题，但是对于一个业务复杂、功能完整的系统，如果按照这样的方法描述测试用例，最终要么产生大量的测试用例文档，要么产生过长的单个文档。无论是那一种，如果发生了类似于上面说的变化，维护文档都将变成一次地狱式的体验。这也是为什么在网络上频频出现的这个问题，而且每次出现都会受到测试同行们的关注的原因。

那么这个问题应该任何解决呢？测试用例是不是把所有的流程写出来就可以了呢？如何在减少测试用例文档中包含过多琐碎的细节的同时保证测试用例的可操作性呢？又有什么方法可以提高我们维护测试用例文档的效率呢？笔者的建议是：关注“测试思想”而不是关注操作步骤。要理解这个问题，首先要弄明白测试用例的作用。就像用例一样，测试用例并不是用来描述具体的实现的，而是着重描述处理问题的思路——对于一项明确的测试内容进行测试的思路。作为测试用例的设计人员，如何理解基本流和备选流？如何深入分析并找到所有需要覆盖的路径和需要检查的特性？我们在测试用例中应该用容易理解的自然语言清晰的来描述我们将要如何进行测试，而不是简单的把在应用程序上如何操作的烦琐的步骤记录下来。把测试用例设计当成填写具体操作步骤的表格是人们对测试用例最大的误解。传统的测试用例文档编写有两种方式。一种是填写操作步骤列表：将在软件上进行的操作步骤一步一步详细的记录下来，包括所有被操作的项目和相应的值。另一种是填写测试矩阵：将被操作项作为矩阵中的一个字段，而矩阵中的一条条记录，则是这些字段的值。网络上对于这两种方式孰优孰劣的争论，将大家错误的引导向了两个极端：要么采用A，要么采用B。而大家却忽视了一点，对于工作方法的争论，本质上同工具的争论并不是一回事（例如曾经的VC、BCB之挣）。如果不同的方法各有优势，我们完全可以通过变通的方法，把优势的部分组合在一起来使用。操作步骤列表的优势在于对基本流和备选流进行分析后，它可以清晰的描述您的测试思路。而测试矩阵则更适合于用来存放测试数据，特别是那些需要人工赋予一个确定的值的特性。下面，我们来看一个例子，当然，这个例子同样是杜撰的。？需求名称：用户登录安全验证需求描述：用户登录安全验证是为了保证所有登录到系统中的用户，都是由系统管理员预先在系统中设定的。使用系统中不存在的用户名，或者用户名输入正确，但密码输入错误情况，都无法登录到系统中。当用户使用了不存在的用户名或错误的密码时，系统应分别给出适当的提示。如果用户连续三次无法使用正确的用户名和密码登录到系统，则系统应给出适当的提示，并退出当前程序。如果用户使用正确的用户名和密码登录到系统，则退出界面，转到系统主界面。对于用户登录界面和程序主界面，请参考相应的UI设计文档。

测试需求：

01.　检查能否使用正确的用户名和密码登录到系统；

02.　检查能否使用错误的用户名或密码登录到系统；

03.　检查使用错误的用户名和密码登录失败超过三次，是否会自动退出当前程序。

测试用例：

这个例子并不是按照RUP提供的标准模板编写的，它的目的只是要为大家展示，用前面所讲的方法，整理出来的测试需求和设计完成的测试用例到底是个什么样子。所以省略了很多细节，不过大家在实际编写测试用例文档的时候，可以根据自己的需要把相应的内容添加上去。同时，也可以在用户名和密码两个字段中填写准备使用的具体数据。相信大家已经看到，在我们的例子中，测试需求同测试用例之间并非是一一对应的关系因为一条测试需求未必是明确的对应到一个有效功能的（其实测试需求本身同软件需求和用例之间也未必是一一对应的）。而我们的测试用例所关注的，应该是一个有效功能。

不过不用担心，这种情况并不会增加管理测试需求和测试用例的成本，现在市面上提供的测试工具中已经有些是专门用来维护软件需求、测试需求同测试用例之间的关系的，并且它们提供的强大的视图功能还可以让您很容易的查看到测试用例对测试需求的覆盖情况。对于例子中的测试用例文档，已经被分成了两个部分，一部分是描述了测试用例执行者所应遵循的操作过程，一部分则是在操作中需要使用到的测试数据。这样做的原因是在我们的实际工作中，尤其是在进行功能测试时，很多时候都是使用雷同的操作过程和不同的测试数据来进行的。而使用上面的方法，可以不用再对原本在多个用例中重复出现的操作过程再次描述，而可以把更多的精力放到测试数据的设计和准备上。这样作带来的副产品，就是提高了测试用例的可维护性。怎么？还有人对笔者的观点持怀疑态度？那好吧，那么我们来尝试着证明一下。

我们的邮递员要在5个城市内奔波，并且每个城市都有些邮件需要投递，他需要找到可以一次走遍5个城市的所有路线。这听起来似乎并不是太复杂，利用我们已有的数学知识，很容易就可以得到答案。但是对于我们要测试的内容，通常都会包含更多复杂的规则。例如，我们有三个文本框，每个文本框每次都只能输入一个英文大写字母，允许输入的值只包括：A、B、C三个字母，当三个文本框输入不同的值的时候，我们不知道会发生什么，也不知道它们之间是否会互相影响，所以需要您来设计可以覆盖所有输入情况的测试用例来测试它。瞧，这很简单不是吗？如果我们希望每个测试用例在执行时一旦出现缺陷都可以很快的找到导致缺陷的原因，那么最好的办法就是每个测试用例只包括一个同其他测试用例不同的输入值。那么可供我们输入的值都有哪些呢？嗯，对于每个文本框，都至少有A、B、C三种已经声明的不同的值，另外，我们还要考虑当文本框为空、输入空格、输入非英文字符以及输入A、B、C之外的英文字符的情况。那么按照上面的方法，我们会有多少测试用例呢？答案是343个。这只是一个很简单的例子，我们工作中遇到的软件的业务规则和特性决不会比这少的，那会有多少个测试用例呢？God knows。 不过至少有一点可以肯定，我们无法在原有业务规则发生变化时高效的、无差错的维护完343个测试用例。但是如果使用我们前面所描述的方法，对于操作过程的改变，您只需要重新维护一次，而对测试数据的维护，也同样是非常简单的，而且并不会因为连续大量修改时出现的错误导致测试用例本身出现歧意。？在将主要精力从“设计”操作步骤转移到设计测试数据之后，我们还将从这种方法中获得更大的益处——通过“逆向测试数据分析”来提高测试工作的整体效率。这种“逆向测试数据分析”的方法，是假设软件中存在多个互相依赖的功能，而且这些功能中包含在“依赖链”最末端，并且不再被其他功能依赖的功能。在我们准备测试数据时，首先从这个“依赖链”最末端的功能开始，分析这个功能会对不同的输入产生哪些不同的结果。然后将所有的输入进行整理，分清哪些输入是来源于其前一个功能的输出。之后，对该功能的上一个功能进行同样的分析，整理出所有的输入和输出，但是这个功能的输出至少应该包含“依赖链”最末端功能接收到的全部输入。继续按照这样的思路循环向上，直到到达“依赖链”开始端的功能。不知道您在工作中有没有遇到这样的情况：在对那些“依赖链”上的功能进行测试时，一开始并没有严格的规范测试数据的使用，结果前一个功能测试时产生的数据根本无法在下面的工作中被很好的利用起来，反而因为大量无效数据增加了后面功能的测试难度。最终不得不对每一个功能重新准备测试数据。大量的时间，浪费在了这些重复而低效的劳动上？当然，如果希望可以进一步提高某个阶段测试工作的效率，还可以考虑应用“设计测试过程”的方法。这里所说的测试过程，指的是我们在执行测试时所设定的执行测试用例的先后顺序。之所以这样作，是因为可以充分的利用不同功能之间的耦合性，尽量通过一次操作来检查尽量多的内容，从而降低已完成工作的无效性或低效性，最终提高某个阶段的整体工作效率。不过，这项工作同样要求操作者必须对被测的系统所涉及的所有业务以及这些业务之间的关系都非常熟悉才行。？如果您正被测试工作的低效问题所困扰，那么建议您尝试一下上面的方法，希望会对您的工作有所帮助。