先问一个问题，BUG是怎么出来的。估计会有很多人回答，是测试人员测出来的。如果测试人员连BUG都测试不出来，那还叫啥测试人员了。再继续深入问下去，如果BUG本身不存在，测试人员能测出来吗？这个时候的答案应该是“不能”吧。换个角度讲，测试人员只是使BUG浮出了水面，使一些人（开发人员、项目经理等）知道了他的存在。

　　继续问，BUG是怎么出来的？或者说BUG是怎么产生的？是什么原因使他深藏在地下？

　　暂时抛下这个问题，先回顾一下项目的生命周期，简单点儿说，是有了一个想法想做些东西出来，一直到这个东西出炉投入使用，简单的划分可以分为这几个阶段。需求获取、产品设计、实现、测试。

　　项目目标：摊子想支多大，产品要达到一个什么样的标准。

　　需求获取：有了想法之后会设定用户群，也有可能是反过来的。接下来是获取用户的使用（如果你足够厉害，不怕一下子被拍死，可以自己闭门造车也可以），即需求调研。用户的使用环境、使用场景、使用目的。。。。。恨不得自己能钻进用户的大脑，把用户想要的，不想要的，所有的一切一切都弄出来，但是这是不可能的，有的时候用户真正想要的东西可能是一，但是他表达的可能是二，获取的过程中可能理解的是三，结果偏差了，有可能回来后整理的时候遗漏了，结果丢失了，还有可能自己没思考，用户说什么是什么了，结果用户拿到产品使用后说这个样子的不是我想要的，那个那个样子的才是我想要的，。。。。。结果的结果，完蛋了。

　　产品设计：得到了用户想用什么，怎么用，达到什么样的目的。需求获取人员高兴了乐的屁颠屁颠的向公司反馈，然后设计人员开始设计（流程设计、UI测试、架构设计。。。），等会儿，先别高兴的太早，再静下来想一下，需求获取人员向设计人员传达的与用户向他讲述的有偏差吗？如果有，那可能会失之毫厘，谬之千里，按照这样的设计实现出来的产品不被用户血骂那怪了。假设需求人员向设计人员传达的与用户要求的是没有偏差的，设计人员按照这样的要求来进行设计。设计人员怎样设计能清晰明了表达出用户的真实想法。如果一味的追求完美、高口味，时尚，可用户去偏偏是一群土老冒，产品拿出去给人用了，结果还是挨骂。不管“界面设计的有多完美”、“交互设计有多易用”、“架构设计有多良好”，用户用着不顺手，不习惯，那用户是不买帐，一群设计师们在家骂娘也没用。

　　产品实现：在很多人眼里这是一个至关重要的环节，如果没有开发人员，没人把想法做成实物。事实确实是这样的，但是开发人员总会有个很大的硬伤，喜欢沉浸在自己的世界里，喜欢说一些只能开发人员才能吃得懂的语言，自然，他们也把这些“良好的习惯”带到了实现上。实现时考虑正向流程，逆向和异常很少考虑，有人对此提出异议，他们会说，谁没事儿会这样用呀，操作还没完成呢，突然中断不做了。如果界面上的说明性文字由开发人员自己来定，那结果可能是外星文字，别人看不懂是什么意思。

　　流程管理：在一个流程比较规范，而且执行的比较好的团队，那你是幸运的。但不幸的是，这只是一种假设，这样的环境太少太少，更多的是有流程无执行，或者啥都没有，大家闭着眼睛做吧，东西应该是什么样子的，不知道，现在做到哪里了，不有关系，做到什么程度了，不知道。。。。。。。只知道下周一要交给用户使用，周一交付什么呀？呵呵，你懂的。

　　测试：对于测试有两个极端的看法，一是测试的啥用都没有，这戳戳点点的活，是人都会做。另一种看法是有了测试的，产品质量有了保证，结果产品投放到市场，反馈回来了问题，然后说，测试的怎么连这个都没测出来？对测试态度从天堂转到了地狱。说的极端点，测试不能对产品质量负责。测试只是一种验证和确认。保证软件以正确的方式做了这件事（do it  right）和软件做了你希望的事（do the right thing）。

　　产品生命周期：投入市场的产品已经过了他的生命期，这个产品像一个老人，还一定要让用户买帐，那不问题多多怪了。

　　总结一下，乱七八糟的说了这么说，想说的是每一个环节都会引入BUG，如果各个环节不能紧密相扣，后依靠测试来BUG不是测试出来的，想要依靠测试来保证质量是不可能的。

　　在公司里，如果你是一名测试人员，当产品提交测试时，某个领导笑着对你说，XXX啊，一定好好测测，多多找BUG出来，别让客户投诉呀。听到这话的时候，请你的心先哆嗦哆嗦，这不是什么好事，测试以外的环节他们可能没有好好处理，后把宝压在了你的身上，你离背黑锅不远了。

　　如果你是一处于领导层，你的手下有一个很好的测试团队，你认为你这个项目组做出来的产品的质量有保证了，当你有这种想法的时候，也请你的心先哆嗦哆嗦，先看看其他的团队，项目的各个环节、公司的内部环境、外部环境等等。