一提到测试用例不得不说下其实现在测试用例的处境还是很尴尬的，第一，基本的几种用例设计方法过于简单，以至于新人也能写出好几百用例，但是有价值的用例却百无一二，第二，开发人员和经理不明白用例的真正价值，分辨不出哪些是有价值的用例，哪些是低价值或者没价值的用例。用例的设计其实分了几个阶段，这几个阶段在我的另一篇博文有提及，（用例设计心得--新人之路系列）这里我们只针对用例文档的价值来做一些讨论，假设我们用场景法来设计一个用例，必然的数据会有编号，描述，预期结果，实际结果，备注，缺陷编号，不少朋友是这么觉得吧，其实不然，用例文档的设计实际上是不应该存在模式的，具体的项目不同，你的用例格式就不同，甚至你的设计方法变了，需要涉及到得内容也就变了，假设我的这个场景的用例牵涉到了新增和修改，那么除了用例描述，用例内容，是不是还应该加上一个测试数据跟踪呢？测试用例的价值本身就在于不确定性，针对测试的功能点，测试的方法，设计出更有效有价值的用例格式，而不是依葫芦画瓢听人说要有预期，你就加个预期要有实际就加个实际，如果你不能真正的了解到这些内容的价值，那即是你的格式有了这些内容，你写出来的用例也必然不会具备这些内容真正的价值，因为用例格式需要针对项目和设计方法来讲，我就举几个简单的列子，对于一个输入框，用等价类划分来设计测试用例，这个时候，我们需要包括预期结果，实际结果，使用数据，如果你们公司对缺陷有很好的管理，按照类型给缺陷分了类，你这里也可以加上缺陷编号，自然用例编号是少不了的，在需求明确的情况下加上一个对应的需求编号。这样你的这个格式已经很好了，这也是我们最常见的格式。而假如我要对一个业务的流程做测试，用的方法是场景法，这个时候，应该有用例编号，用例描述，涉及功能块，预期结果，实际结果除了以上之外还应该针对性的加上测试数据追踪，如果你的流程牵涉到了状态的变动并且很频繁的话，那你还需要加上一个状态跟踪，如果还有其他细节，你也应该考虑下价值然后根据你自己的判断选择加或者不加。相信朋友们看到这里已经了解到用例的价值是建立在格式的不确定性上，如果你给自己的用例下了一个格式，看起来确实严格 并且一致了许多，但实际上却也失去了很多应有的价值。
围绕用例的格式说了许多，那么测试用例在实际项目中的价值体现在哪里呢，最常见也是最被大家认可接受的一种价值就是引领测试，根据测试用例进行测试，覆盖率与free test 相比要高出许多，从工作的心态上来讲，一个只需要按照指定的步骤一步一步操作，一个则需要随时考虑下一步操作，哪个心态更为积极，哪个更为消极，相信不用我多说，大凡做过测试的朋友就一定做过free test也就是不根据用例进行测试，点到哪里测到哪里，这种工作模式，很容易让人情绪烦躁，在情绪不稳定的时候，工作的效率可想而知了，经常遇见的典型的问题是，我这个功能测完了，下个地方又测哪，这个价值是公认的，那么我来说个很多人知道，却没有明确认可的价值，一份好的测试用例不亚于需求的价值，或者说，测试用例实际上是对需求的一种翻译，是整个项目的一个镜像文件，项目经理可以对比需求和测试用例清楚的了解到哪些地方是遗漏的，哪些地方是重点测试了的，而在交接工作时（有新的测试员加入项目组）也可以根据这份用例文档对系统的框架再次有个了解同时也避免了许多重复的工作，正规的流程来讲，测试员设计好测试用例后是需要提交给经理审核的，这个时候用例文档的价值是第一次体现，项目经理结合自己对项目的了解同时从他个人的角度出发和测试员提供的用例文档进行对比，有可能会提出一些你遗漏掉的模块直接的影响就是开始测试时你的用例覆盖面积更广，在最后测试报告时，测试用例的文档也能体现出价值，通过使用的测试用例，对测试的覆盖率进行评估，在管理的角度有一环节，项目风险评估，而测试用例文档就位这个风险评估提供了一份很实用的参考数据，风险评估是每一位经理都应该掌握的一门技术，如果不能做有效的评估，那你所在的项目隐患就是比较严重的了，也许有朋友会说，风险评估不是我该考虑的，是经理考虑的事情，那么我只能重复一下之前提到过的一个核心，测试员的职责，是完善项目，提高项目质量，而不是简单的找BUG 。
以上单独说了每一种文档的价值体现，那么一份完整的包括了需求，计划，用例，缺陷报告，测试报告的测试文档其价值又体现在哪里，这个问题很简单，体现在具体的项目质量，项目管理等很多方面，其效应远不是1+1=2这么简单，首先从项目管理来讲，文档的完整和价值直接关系着项目经理的工作量，其实现在很多项目经理都平白增加了许多工作量，小的项目经理甚至对软件自己还要测试一次，因为他不清楚哪些地方测了哪些地方没测，重要的地方测试力度是否足够，测试效率是否因为一些可以忽略的功能点而减少，这些没有文档的证明，没有数据的支持是不能够得到保证的，自然也没有办法对项目进行风险评估，而对风险进行评估是项目经理一项很重要的任务，其次，由于文档的不完善引起的工作不明确的问题也有很多，包括测试覆盖面积重复，遗漏面积过多，这个原因也很简单，只是因为项目经理不敢保证测试的结果是否真的符合出口标准，要知道，项目在后期发现大的或者过多的BUG严重影响用户使用的话，项目经理是需要承担相应责任的，归根结底依然还是老问题，没有文档的说明，没有数据的支持，导致项目经理不能全面了解项目的进度和质量以至于不能进行合理的评估。那么从项目质量上来讲，我们来举一个很简单的例子，其实朋友们也可以动手一起参与，首先准备四张扑克牌 各自剪去不一样的面积，每张扑克牌代表了需求，用例，缺陷，实际项目，或者其他的测试文档，那么文档的质量就是扑克牌的质量，我们将四张扑克牌重叠起来，从上下侧面对它进行观察，这个时候我们就会很直接的发现哪个地方有缺漏，哪个地方多余了，这种视觉效果是很直接的，而在这之后我们将扑克牌折叠多次，使扑克牌表面凹凸不平，或者捏成一团，再将他们折叠起来，再来进行观察，这个时候我们就会发现很多地方被折痕掩饰住了，我们很难从中了解到项目的质量，这对我们挖掘文档的价值，通过文档来对项目进行评估照成了很大的不便，也就照成了很多多余的工作量，而这部分的工作量其实是无意义的，可以避免的。
因为经验有限暂时未接触到其他的测试文档，如果朋友们有自己的意见和看法，也希望拿出来交流交流，共同进步。
版权声明：本文出自 Mr.曾 的51Testing软件测试博客：http://www.51testing.com/?434556
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
