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

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

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

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

　　测试报告的使用应该是在一些中型偏大的公司，这些公司大多已经过了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天得时间要测完整个系统，这种情况其实来不及设计测试用了的，但是高强度的工作也让我逐渐体会到测试用例的好处，其实很简单，当你了解测试用例是怎么回事的时候再让你高强度的不写用例进行测试，你的感受就会特别深，这个项目的经理再最初安排任务时说“你们先了解下业务，用例就不要写了，以前我们用过，没什么效果”当时我还很奇怪，怎么会用例没有效果呢，直到我看见他们所谓的用例，只能说那样的用例真的是没什么价值，这组用例只是简单的对每个功能按钮做了测试，根本就不能称之为用例，当然格式还是很规范的，可惜里面却是些没有价值的内容。