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

　　如何评价测试用例的好坏？

　　这部分内容的出现，完全是因为不久前同几个朋友的一次讨论。当时大家都认为对于一个测试用例好坏的评价，无外乎两个标准：是否可以发现尚未发现的软件缺陷？是否可以覆盖全部的测试需求？但是后来发现这两个标准对于一些问题是处理不了的。例如，对于一个质量非常好的软件产品，存在的软件缺陷异乎寻常的少，测试用例设计人员准备了大量的测试用例，已经完全覆盖了测试需求，但是只有很少一部分测试用例在执行时发现了缺陷，而其他用例都顺利通过了。那么是否就可以认为顺利通过的那部分测试用例不好呢？对于这个问题，笔者认为不管是测试用例是否可以发现尚未发现的缺陷，还是测试用例对测试需求的覆盖度，都是用来评估测试设计人员工作能力和经验的标准，而对于如何评价测试用例的优劣，应该还有其他标准。当然，在不同的团队中可能存在不同的标准，但下面两条应该是适合于任何团队的。 1.易用性。对于一个即熟悉测试工作，又熟悉被测应用的测试人员，应当可以花费 很少的时间就可以理解测试用例中表达的测试思路，并可以很快的执行完这个测试用例。 2.易维护性。当开发过程中的某些因素影响了测试需求，测试用例的作者或其他测试设 计人员，应该可以花费很少的时间就完成定位并维护所有相关测试用例的工作。

　　一些题外话

　　曾经有朋友问：如果测试用例同软件的具体实现互相独立，怎么保证测试用例的可操作性呢？怎么保证任何一个人都可以一拿到测试用例就可以直接上机执行测试呢？笔者的回答是：尽量不要让这种事情发生。首先，笔者一直不赞同那种让“任何人”都可以充当测试人员，按照手中测试用例执行测试的做法。因为对于被测应用的全面了解和熟悉，是作为一个测试人员最基本的要求——在前面的文字中对于软件需求的熟悉也多次被强调。我们无法预知让一个对软件以及软件所涉及的实际业务不够熟悉的人，依靠一份他同样不熟悉的操作步骤列表来执行测试会有什么样的结果。但是有一点可以明确，这就好像让一个没有医学背景的人，仅仅依靠一本七年制本硕连读的《内科学》教材来为患者检查是否患有心脏病，最终结果是患者承担了全部的风险。其次，测试用例的本来目的是为了描述我们的“测试思想”——也就是“怎样测”，而是否可以熟练的操作被测应用，并不是在测试用例这个“对象”中所要考虑和保证的，应当剥离出来，作为独立的部分进行处理。而问题的关键，在于如何保证拿到测试用例的人有足够的能力和经验来执行测试，这完全可以通过公司内部对软件及软件所涉及的实际业务的培训，或者软件的操作手册。总之，还是尽量不要随意的加入“任何人”到测试工作中吧。