我们知道开发人员与测试人员在某种程度上可以说是冤家对头，因为开发总是认为我做的产品是完美无缺的，没有Bug的，但是测试总是想方设法给你挑刺，因而产生了“矛盾”。很多公司对开发的绩效评估里就有一条是每千行代码产生的Bug量，当然是越少越好了，但是对于测试的绩效评估也有一条平均每天提交的Bug量，所以表明上看起来这种矛盾真的是无法避免的，因为大家都要“混饭”吃的。

　　但是大家其实心里都很清楚，一个产品不可能没有Bug的，或多或少，或大或小，总是会有Bug存在，不然微软也不会这样经常发布补丁了，连微软这种级别的公司都会Bug，所以对于Bug的存在，我们大可以泰然处之。

　　虽然可以泰然处之，但是对于Bug我们还是需要很重视，因为既然产生Bug，总是某一方面没有想到或者是想错了，所以我是建议可以通过对Bug分布进行分析，找出哪些地方特别容易出Bug，然后在开发过程中特别注意。对于我们公司而言，之前说过了我们是用TechExcel DevSuite 系统来管理，所以我们在开发中会加入几个强制检查项，比如说是否兼容不同数据库，是否支持不同语言，是否考虑过不同浏览器，开发在完成代码如果不检查这几项的话，是无法把开发任务直接交给测试来测的，这样就可以从某种程度上避免一些Bug的产生。

　　不过即使避免了总还是会有一些Bug会被找到的，呵呵，没有Bug还要测试干嘛呀？在很多公司里测试人员的数量都大于开发人员的，像微软这种公司，可能是2：1的关系，为什么需要这么多测试呢？

　　第一方面，当然是他们的产品太大了，太复杂了

　　第二方面，一个产品的质量光靠开发是不行的，因为开发虽然能把产品做出来，也可能可以用，但是他们可能没法考虑其他一些方面，比如用户体验上，比如压力测试上，比如不同语言下的应用，甚至是不同操作系统下的应用等等，这些方面光靠开发可能没法想全，甚至即使想全了也做了，你能保证在哪些环境就一定不出问题吗，毕竟开发编程总是在一个环境下的编的，他编完即使自己测了一下也不可能把所有环境下都测过的。

　　第三方面，因为一个产品/一个功能需要在很多外在环境下测试（操作系统，数据库，浏览器，网络），另外一个功能需要测试点又很多（正常输入，非正常输入，临界，压力值等），所以即使是一个功能，需要测试的地方就很多，何况产品大功能多的了。而且，我们知道一个人再强，他能想到的测试点总是有限的，所以我还需要另外的人对一个已经测过的功能点进行再次验证测试 （关于这个方面，由于我们公司是用DevSuite 方案中的 DevTest 工具来管理测试覆盖面的，所以稍微可以减少一些测试人员配置）。另外对于一个开发来讲，由于功能点是他做的，所以别人发现了问题让他修，其实他是可以修起来很快，代码都轻车熟路的，所以如果一个测试配一个开发的话，可能发现的Bug量无法让开发完全忙起来，从领导角度说这个比较浪费成本的。

　　所以考虑到这些原因，一般大公司就会有很多的测试人员了，当然现在的情况又有不少改变了，随着自动化测试的引入，需要人工的地方会相对减少，所以有不少公司开始减少纯手工测试的活，但是做过开发的人也知道，如果一个产品很复杂，光靠自动化测试是远远不够的，所以呢，我相信手工测试还会在很长时间内存在，至少在我能看到的范围呢，好像还没法用自动化测试来代替。

　　不过在国内的话，我接触到的大多数软件公司里，对测试人员的配置都不太多，当然我不认为他们是忽视软件质量，他们可能认为功能做出来了，开发直接测一下就好了，测试人员的话只要最后综合跑一下就Ok了。我相信这个是怎么保证软件质量的一种认知的观念问题，我认为这样就可以保证产品质量，你认为那样才可以保证质量，大家各有说法，但是从我们公司的角度来说，我们还是比较看重质量的，可能也跟我们公司背景有关吧，外企，跟国外比较接轨。所以我们公司现在的开发与测试配置是大于1：1的，不过比微软还是差一点。

　　介绍了一下测试的必要性，再回过头来继续说开发与测试的“矛盾”，其实这个矛盾从本质上来说是由于绩效管理时过分强调了开发人员造成的Bug，而这个“过分强调”又必须是测试人员一定要强调的。所以呢，矛盾就开始产生了，开发说，这个不是Bug，或者说我不能重现，还说，你干嘛老是提Bug，是不是对我有啥不满的。久而久之，“矛盾”产生了，激化了，产品质量下降了......