近来工作挺忙， 因此也都没什么时间总结了。当然，忙的这段时间我也发现了自己工作中的诸多问题，今天偷闲上来总结一下。
在这之前，我对测试工作的观点是，熟悉业务加上熟练的技术能力就能很好的完成大部分测试工作，通过这次项目的追赶，我突然感觉到这之中有太多的不合理性，毕竟测试有很多不确定性，而且每个人的测试思路不一样，很容易忽略和遗漏很多测试点，这样下来测试的覆盖度降低了很多，到最后产品上线的时候肯定有很多问题，所以还是不能靠感觉和思路来做事，因为到最后没人代理你承担责任。所以这里关于测试设计，我也想谈谈自己的一些观点，以帮助和指导我之后的工作方向。
通常情况下，项目开始的时候，需求人员会将一堆所谓需求文档分散到开发和测试人员手中，此时也就是说让测试前期介入到项目进展中。当然这个时候，我们会有很多很多的问题需要跟需求确认，因为一堆零散的需求文档就足以说明他们是如何草率，但每到项产品交付的时候，这个时候就是开发和测试人员最痛恨需求人员的时候，因为他们前期的需求不明确，让我们白白辛苦并浪费了这么多时间。但对于测试来说，在这个过程中其实就起到了承上启下的作用，因为只有测试人员才会不厌其烦的去与需求人员周旋，而开发这个时候自认为只要加工完就ok了，而测试不能向任何人说ok，不然我们的工作就变得毫无意义了。所以说，测试工作就是一项去深入理解需求，正确引导开发向着最正确的轨道行驶，可见伟大，嘿嘿！
首先，从需求文档中，我们从中抽象出基本功能，得到一个测试人员能够理解的文档，这样我们就知道我们大致要测试那些功能点了；
其次，再从需求文档中提取出业务流程，并与需求人员深入沟通，画出业务流程图；
第三，通过以上两点成果，输出一份初步的测试计划，包括测试目标、范围，以及测试内容、测试流程、测试方法和测试工具，最主要全面列举测试覆盖范围，比如对于客户端软件最后要进行系统平台测试，包括windows 7/Vista（32/64bit）等；安装卸载测试、杀毒软件的覆盖测试等等；如web页面要执行浏览器兼容性测试等；
最后，就要注重测试思路的总体连贯性，“先正常，后异常”，保证正常情况下的功能能走通，异常情况下近可能的去覆盖。
可能这里要说还应该完成测试case的设计，以及评审，至最后的完善归档，不过并不是所有的项目都会有大量的时间留给测试人员，这也就是产品测试和项目测试的区别所在。如果时间充足的情况下，设计详细的case，以及评审，那当然是最完整的流程了。这里主要谈到的测试对象是项目测试，通常都是时间非常紧急，留给测试的时间很短，无暇顾及完成软件测试流程，那么就需要找到更合适自己以及项目的方法和流程来完成。
本文转自一米一阳光博客园博客，原文链接： http://www.cnblogs.com/candle806/archive/2011/06/20/2085479.html ，如需转载请自行联系原作者
