测试文档的价值--新人之路系列

测试文档的价值--新人之路系列
    这篇日志也是写给新人朋友看的，国内的测试尚未定型，大家都在摸索阶段，在分享我的心得时也希望能得到更多朋友的反馈

    所谓测试文档，包括产品需求，测试需求，测试计划，测试报告，特别提醒的是缺陷报告和测试用例也属于测试文档范围，同时，不要小看其中的任何一种文档，你看轻这些文档的价值，只是因为你没有真正的了解，不会开枪的人，即使给他一把真抢，他也只会当做板砖来砸人。

    对于需求部分，相信很多中型公司已经意识到了这类文档的价值，其实了解这个不难，对于项目而言测试人员越早介入，为这个项目付出的资源包括金钱，人员，时间就越少，
试想如果项目开发完了，在开始测试，这时的缺陷甚至有可能让你付出比开发更多的精力，而如果从需求介入，开发人员拿到手的需求已经是经过评审经过确认了的，开发出来的产品自然更为优秀，维护时的成本自然就低。这个道理网上有很多，我就不多说了

    测试计划，不少中小型公司还没有用到，其实这个测试计划的作用就好比给你指引一条方向，没有约束的测试，他的可散发性实在太大，如果把项目比作一条横线，那么测试范围就是这条横线上下的空间，可以无穷无尽的散发。而如果有了测试计划，就将测试的范围缩小成了一个圈，或者说一个矩形，我们的测试人员只需要在规定的范围内测试就可以了，由于范围的缩小同时带来的效应也就是单位面积的覆盖率提高很多很多

    测试报告的使用应该是在一些中型偏大的公司，这些公司大多已经过了CMMI的认证，这些文档往往是做来存档所用，通过测试报告，也可以大致了解项目的质量，包括缺陷集中的区域，使用用例的数量，覆盖面积，其实测试报告实际上就是一个测试用例和缺陷报告的统计。

   以上3种测试文档是大家经常了解并且已经认可了的，接下来的2种，测试用例和缺陷报告，却是很多人忽视掉得存在，不仅仅是新人朋友，一些做了1.2年测试的测试员，也不一定能把握这两类文档，在介绍这2类文档之前，先给大家介绍一下2 8原则，1个项目，百分之80的功能是用的比较少的，百分之20的功能是经常用的，我们测试的时候就把百分之80的精力放在那百分之20的功能上，剩下的百分之20则用来测另外的百分之80功能。这个原则很出名，大概意思就是这样了。感兴趣的朋友可以查查资料。

   先说缺陷报告，刚接触测试时，因为是新人还不熟悉怎么操作，有开发人员说，“你就把报错的地方截个图丢给我们就行了” 不知道大家遇见过没有，我还没遇见，只是我的同事遇见了，其实这种情况很简单，你只要问一句你是测试员还是他是测试员，相信你能得到自己的答案，我们部门经理在指点我们写需求时，提到过一句话“文档里面的每一句话都是有价值的，即便是编号，序号，也要付给他一个价值，不能说你想怎么编就怎么编” 虽然这句话是再需求时说的，不过在缺陷报告乃至测试用例时依然有用，

   我们测试员的职责是什么？找BUG？破坏系统？不是。我们只有一个职责，完善我们的项目，提高项目的质量，那么我们思考问题时的角度就要变换下了，如果只是找BUG，那你可以把你找的BUG截个图丢给开发，就像那些开发人员说的一样，不过你的缺陷报告没有得到哪怕一丝的价值，如果我们是为项目的质量考虑，那么你就必须要想一想，缺陷要怎么提交才能更有价值，首先你提交的缺陷必须要带上重现的步骤，而不是简简单单的一张图，一句话“这里出错”就解决了，你还得帮助开发人员对BUG进行定位，对缺陷的定位，我个人认为是测试工作的一处核心体现，非常重要，也是辨别你在测试这个行业上是否入门的一个判断标准。言归正传，试问你连重现步骤都没有，开发人员拿到后怎么去改，你是想让开发人员自己去找到那个BUG吗？重现步骤是必须有的，这些内容能帮助开发人员快速定位缺陷，减少不必要的工作量，缩短工作时间，那么一份合格的缺陷报告就这样完了吗？ 肯定不是，你自己要对缺陷进行一个分类，这里指的分类不是缺陷类型，而是缺陷位置，必不可少的你就应该多一列内容，功能模块名，这个内容的价值体现在哪里? 在回归测试和验收测试，甚至评审，一份清晰明了的缺陷报告，能够让人直观的知道哪些功能模块的缺陷比较多需要注意，整体功能模块的缺陷数量走势，甚至可以根据这个在测试报告中以图表的形式展现缺陷的分布，和随着更新版本也就是回归测试后，整体缺陷数量的趋势。而记录你的测试痕迹也是很重要的，这些痕迹包括你使用的账号，如果必要的话，产生缺陷的数据也可以留着，有些BUG不好重现，这时你就要将测试数据保留，并且在报告中注明测试数据，开发人员可以通过追踪你出错的数据来给BUG进行定位，不要小看缺陷报告，每一分缺陷报告里面的每一句话你都应该让他有自己的价值，这样才是一名合格的测试员，不要给自己找借口诸如，测试完了最后再整理成规范的缺陷报告之类的，你这样想只能说明你的测试思维很不成熟，开发人员已经将缺陷改了，那就是编制一个再好的缺陷报告，价值又在哪里体现呢，更何况如果不当时记录下来，凭脑子记忆你又能记多久？又能记多少？又根据什么来写？又拿什么来保证没有遗漏呢。
   值得一提的是，缺陷报告和用例设计对于新人朋友来讲是一个弥补工作经验的途径，向我之前所提，不少测试人员工作1,2年依然不了解缺陷报告和测试用例的价值在何处，这就是缩短新人朋友和有经验的朋友之间差距的地方了。

   再来谈谈测试用例，这两天在加班一个项目，是临时调遣，类似于验收测试吧，只有3天得时间要测完整个系统，这种情况其实来不及设计测试用了的，但是高强度的工作也让我逐渐体会到测试用例的好处，其实很简单，当你了解测试用例是怎么回事的时候再让你高强度的不写用例进行测试，你的感受就会特别深，这个项目的经理再最初安排任务时说“你们先了解下业务，用例就不要写了，以前我们用过，没什么效果”当时我还很奇怪，怎么会用例没有效果呢，直到我看见他们所谓的用例，只能说那样的用例真的是没什么价值，这组用例只是简单的对每个功能按钮做了测试，根本就不能称之为用例，当然格式还是很规范的，可惜里面却是些没有价值的内容。
    一提到测试用例不得不说下其实现在测试用例的处境还是很尴尬的，第一，基本的几种用例设计方法过于简单，以至于新人也能写出好几百用例，但是有价值的用例却百无一二，第二，开发人员和经理不明白用例的真正价值，分辨不出哪些是有价值的用例，哪些是低价值或者没价值的用例。用例的设计其实分了几个阶段，这几个阶段在我的另一篇博文有提及，（用例设计心得--新人之路系列）这里我们只针对用例文档的价值来做一些讨论，假设我们用场景法来设计一个用例，必然的数据会有编号，描述，预期结果，实际结果，备注，缺陷编号，不少朋友是这么觉得吧，其实不然，用例文档的设计实际上是不应该存在模式的，具体的项目不同，你的用例格式就不同，甚至你的设计方法变了，需要涉及到得内容也就变了，假设我的这个场景的用例牵涉到了新增和修改，那么除了用例描述，用例内容，是不是还应该加上一个测试数据跟踪呢？测试用例的价值本身就在于不确定性，针对测试的功能点，测试的方法，设计出更有效有价值的用例格式，而不是依葫芦画瓢听人说要有预期，你就加个预期要有实际就加个实际，如果你不能真正的了解到这些内容的价值，那即是你的格式有了这些内容，你写出来的用例也必然不会具备这些内容真正的价值，因为用例格式需要针对项目和设计方法来讲，我就举几个简单的列子，对于一个输入框，用等价类划分来设计测试用例，这个时候，我们需要包括预期结果，实际结果，使用数据，如果你们公司对缺陷有很好的管理，按照类型给缺陷分了类，你这里也可以加上缺陷编号，自然用例编号是少不了的，在需求明确的情况下加上一个对应的需求编号。这样你的这个格式已经很好了，这也是我们最常见的格式。而假如我要对一个业务的流程做测试，用的方法是场景法，这个时候，应该有用例编号，用例描述，涉及功能块，预期结果，实际结果除了以上之外还应该针对性的加上测试数据追踪，如果你的流程牵涉到了状态的变动并且很频繁的话，那你还需要加上一个状态跟踪，如果还有其他细节，你也应该考虑下价值然后根据你自己的判断选择加或者不加。相信朋友们看到这里已经了解到用例的价值是建立在格式的不确定性上，如果你给自己的用例下了一个格式，看起来确实严格 并且一致了许多，但实际上却也失去了很多应有的价值。
    围绕用例的格式说了许多，那么测试用例在实际项目中的价值体现在哪里呢，最常见也是最被大家认可接受的一种价值就是引领测试，根据测试用例进行测试，覆盖率与free test 相比要高出许多，从工作的心态上来讲，一个只需要按照指定的步骤一步一步操作，一个则需要随时考虑下一步操作，哪个心态更为积极，哪个更为消极，相信不用我多说，大凡做过测试的朋友就一定做过free test也就是不根据用例进行测试，点到哪里测到哪里，这种工作模式，很容易让人情绪烦躁，在情绪不稳定的时候，工作的效率可想而知了，经常遇见的典型的问题是，我这个功能测完了，下个地方又测哪，这个价值是公认的，那么我来说个很多人知道，却没有明确认可的价值，一份好的测试用例不亚于需求的价值，或者说，测试用例实际上是对需求的一种翻译，是整个项目的一个镜像文件，项目经理可以对比需求和测试用例清楚的了解到哪些地方是遗漏的，哪些地方是重点测试了的，而在交接工作时（有新的测试员加入项目组）也可以根据这份用例文档对系统的框架再次有个了解同时也避免了许多重复的工作，正规的流程来讲，测试员设计好测试用例后是需要提交给经理审核的，这个时候用例文档的价值是第一次体现，项目经理结合自己对项目的了解同时从他个人的角度出发和测试员提供的用例文档进行对比，有可能会提出一些你遗漏掉的模块直接的影响就是开始测试时你的用例覆盖面积更广，在最后测试报告时，测试用例的文档也能体现出价值，通过使用的测试用例，对测试的覆盖率进行评估，在管理的角度有一环节，项目风险评估，而测试用例文档就位这个风险评估提供了一份很实用的参考数据，风险评估是每一位经理都应该掌握的一门技术，如果不能做有效的评估，那你所在的项目隐患就是比较严重的了，也许有朋友会说，风险评估不是我该考虑的，是经理考虑的事情，那么我只能重复一下之前提到过的一个核心，测试员的职责，是完善项目，提高项目质量，而不是简单的找BUG 。

  以上单独说了每一种文档的价值体现，那么一份完整的包括了需求，计划，用例，缺陷报告，测试报告的测试文档其价值又体现在哪里，这个问题很简单，体现在具体的项目质量，项目管理等很多方面，其效应远不是1+1=2这么简单，首先从项目管理来讲，文档的完整和价值直接关系着项目经理的工作量，其实现在很多项目经理都平白增加了许多工作量，小的项目经理甚至对软件自己还要测试一次，因为他不清楚哪些地方测了哪些地方没测，重要的地方测试力度是否足够，测试效率是否因为一些可以忽略的功能点而减少，这些没有文档的证明，没有数据的支持是不能够得到保证的，自然也没有办法对项目进行风险评估，而对风险进行评估是项目经理一项很重要的任务，其次，由于文档的不完善引起的工作不明确的问题也有很多，包括测试覆盖面积重复，遗漏面积过多，这个原因也很简单，只是因为项目经理不敢保证测试的结果是否真的符合出口标准，要知道，项目在后期发现大的或者过多的BUG严重影响用户使用的话，项目经理是需要承担相应责任的，归根结底依然还是老问题，没有文档的说明，没有数据的支持，导致项目经理不能全面了解项目的进度和质量以至于不能进行合理的评估。那么从项目质量上来讲，我们来举一个很简单的例子，其实朋友们也可以动手一起参与，首先准备四张扑克牌 各自剪去不一样的面积，每张扑克牌代表了需求，用例，缺陷，实际项目，或者其他的测试文档，那么文档的质量就是扑克牌的质量，我们将四张扑克牌重叠起来，从上下侧面对它进行观察，这个时候我们就会很直接的发现哪个地方有缺漏，哪个地方多余了，这种视觉效果是很直接的，而在这之后我们将扑克牌折叠多次，使扑克牌表面凹凸不平，或者捏成一团，再将他们折叠起来，再来进行观察，这个时候我们就会发现很多地方被折痕掩饰住了，我们很难从中了解到项目的质量，这对我们挖掘文档的价值，通过文档来对项目进行评估照成了很大的不便，也就照成了很多多余的工作量，而这部分的工作量其实是无意义的，可以避免的。
  因为经验有限暂时未接触到其他的测试文档，如果朋友们有自己的意见和看法，也希望拿出来交流交流，共同进步
                                 ---------MR.曾