相信大家已经看到，在我们的例子中，测试需求同测试用例之间并非是一一对应的关系因为一条测试需求未必是明确的对应到一个有效功能的(其实测试需求本身同软件需求和用例之间也未必是一一对应的)。而我们的测试用例所关注的，应该是一个有效功能。不过您不用担心，这种情况并不会增加您管理测试需求和测试用例的成本，现在市面上提供的测试工具中已经有些是专门用来维护软件需求、测试需求同测试用例之间的关系的，并且它们提供的强大的视图功能还可以让您很容易的查看到测试用例对测试需求的覆盖情况。
对于例子中的测试用例文档，已经被分成了两个部分，一部分是描述了测试用例执行者所应遵循的操作过程，一部分则是在操作中需要使用到的测试数据。这样做的原因是在我们的实际工作中，尤其是在进行功能测试时，很多时候都是使用雷同的操作过程和不同的测试数据来进行的。而使用上面的方法，可以不用再对原本在多个用例中重复出现的操作过程再次描述，而可以把更多的精力放到测试数据的设计和准备上。这样作带来的副产品，就是提高了测试用例的可维护性。
怎么?还有人对笔者的观点持怀疑态度?那好吧，那么我们来尝试着证明一下。
我们的邮递员要在5个城市内奔波，并且每个城市都有些邮件需要投递，他需要找到可以一次走遍5个城市的所有路线。这听起来似乎并不是太复杂，利用我们已有的数学知识，很容易就可以得到答案。但是对于我们要测试的内容，通常都会包含更多复杂的规则。
例如，我们有三个文本框，每个文本框每次都只能输入一个英文大写字母，允许输入的值只包括：A、B、C三个字母，当三个文本框输入不同的值的时候，我们不知道会发生什么，也不知道它们之间是否会互相影响，所以需要您来设计可以覆盖所有输入情况的测试用例来测试它。
瞧，这很简单不是吗?如果我们希望每个测试用例在执行时一旦出现缺陷都可以很快的找到导致缺陷的原因，那么最好的办法就是每个测试用例只包括一个同其他测试用例不同的输入值。那么可供我们输入的值都有哪些呢?嗯，对于每个文本框，都至少有A、B、C三种已经声明的不同的值，另外，我们还要考虑当文本框为空、输入空格、输入非英文字符以及输入A、B、C之外的英文字符的情况。那么按照上面的方法，我们会有多少测试用例呢?答案是343个。这只是一个很简单的例子，我们工作中遇到的软件的业务规则和特性决不会比这少的，那会有多少个测试用例呢?God knows. 不过至少有一点可以肯定，我们无法在原有业务规则发生变化时高效的、无差错的维护完343个测试用例。
但是如果使用我们前面所描述的方法，对于操作过程的改变，您只需要重新维护一次，而对测试数据的维护，也同样是非常简单的，而且并不会因为连续大量修改时出现的错误导致测试用例本身出现歧意。
在将主要精力从“设计”操作步骤转移到设计测试数据之后，我们还将从这种方法中获得更大的益处——通过“逆向测试数据分析”来提高测试工作的整体效率。
这种“逆向测试数据分析”的方法，是假设软件中存在多个互相依赖的功能，而且这些功能中包含在“依赖链”最末端，并且不再被其他功能依赖的功能。
在我们准备测试数据时，首先从这个“依赖链”最末端的功能开始，分析这个功能会对不同的输入产生哪些不同的结果。然后将所有的输入进行整理，分清哪些输入是来源于其前一个功能的输出。之后，对该功能的上一个功能进行同样的分析，整理出所有的输入和输出，但是这个功能的输出至少应该包含“依赖链”最末端功能接收到的全部输入。
继续按照这样的思路循环向上，直到到达“依赖链”开始端的功能。
不知道您在工作中有没有遇到这样的情况：在对那些“依赖链”上的功能进行测试时，一开始并没有严格的规范测试数据的使用，结果前一个功能测试时产生的数据根本无法在下面的工作中被很好的利用起来，反而因为大量无效数据增加了后面功能的测试难度。最终不得不对每一个功能重新准备测试数据。大量的时间，浪费在了这些重复而低效的劳动上。
文章来源于领测软件测试网 https://www.ltesting.net/
