在现在的公司里，常常会听到开发测试比这个词。这个词也许很多老大的理解是：开发人员个数和测试人员个数的比例。一次高P开会的时候，我记得一个技术团队的老大曾经说过，开发测试比嘛，当然是越高越好。
那好，作为一名一线的测试人员，我想谈谈我对开发测试比的一个理解。
首先，我要问，为什么要有测试呢？测试的目的是什么？
记得有一本书里曾经说，有一个硬件人员转去做软件，他写的代码从来都没有bug，后来有人问他为什么写代码没bug，他很惊讶地问：怎么？还可以有bug吗？
为什么硬件人员认为不能有bug呢？因为硬件的bug是非常昂贵的。一个芯片一旦投产，出现bug的话产品就废了，一个bug的损失就是几百万，一个bug就可能毁了一个产品，所以bug是坚决不能有的。
但是软件是可以有bug的，不同的软件产品，bug的价格不一。比如通信产品，一个用户bug的价格从几万到几十万不等，我记得当初我们公司还跟软银签过合同，如果用户bug超过一定数量，他们就拒绝和我们续约。
但是facebook和google就不一样了，他们的产品本身就是免费的，能用就行，有bug可以提，不提就忍着。就好像我们现在的穿梭巴士一样，有的坐就坐，挤不上就打车回家，免费了你还想怎么样？但也不尽然，互联网产品竞争太激烈，用户体验决定一切。马化腾好像就说过，只要我们的产品比别人快，用得比别人爽，我就不担心没有市场。所以bug也不是免费的，bug的价值虽然不能直接换算成钱，但是也不会太便宜。
电商的产品虽然本身是免费的，但是涉及到交易，涉及到钱，bug也不会太便宜。淘宝一次系统故障，有可能就会给卖家带来上亿的损失。这个又和facebook和google不可同日而语了。
所以，大家都不会反对，我们仍然是需要测试的，因为软件产品会有bug，而bug不是免费的。测试的目的就是防止bug被遗漏到用户那边。测试工作是不可缺少的，这个应该不难达成共识。
那么，下面的问题就是，该谁来做测试？是否需要专职的测试人员？
这个涉及到开发是否能测试自己的产品的问题。答案是，可以的。但是开发人员的水平参差不齐，好的开发人员其实是可以做到零bug的，但是在项目压力的情况下，零bug很难做到。这个大家可以在《人件》这本书里看到详细的论述。
我们来看看谁可以做测试呢？
首先，可以让开发本人来做测试。一个人可以既做开发，又做测试。甚至测试驱动开发，没写代码前先写测试代码。
其次，用pair-working来减少bug的产出，一个人写代码，一个人在旁边看。看的人可以指出写的人的错误，通过review的方式来防止错误产生。
还有一个办法是开发互相测试，我开发的软件让别人来测。
最后就是雇佣专职测试，由测试来把控质量，给开发提bug，让开发修复bug，这是我们目前的方式。
选择谁来做测试，是否需要专职的测试，主要看的是投入和产出。
那么，是让测试人员做测试节省成本，还是让开发做测试节省成本呢？
开发和测试是两种思维，简单地说，开发是构造，测试是破坏，一个人能够同时拥有两种思维模式，并且非常客观地测试自己的产品，还是很难得的。
另外，一个产品的最终质量取决于团队中最差的那个人，我们不能预期每一个人都是最好的开发。而一个人如果写的代码比较差的话，也很难预期这个人能发现自己的代码错误。
所以，让开发来测试自己的产品，存在的风险取决于开发的水平和开发的质量意识。开发水平高，质量意识强，项目压力小的情况下，是靠谱的。
pair-working我曾经推广过一阵子，但是这个受限于两个人的关系，关系好的人pair-working的效果好，关系一般的人是很难进行pair-working的。难以大范围推广。
相互测试，比开发自测更好一些，一般针对较简单、风险小的产品，可以采取这种方式。但是开发往往更重视创造，不重视破坏，这是一种思维惯性。
如果从公司节省成本的角度来思考，让开发做测试并不合算，所以一般上规模的公司都会有专职测试，所谓术业有专攻，测试人员可以花更少的时间发现更多的问题。测试人员的经验和敏锐的感觉，以及各种测试技术的使用，都会节约公司的成本。我之前在的通信公司，一个有经验有水平的测试人员可以发现比一般测试人员多几倍甚至几十倍的问题。
我觉得每个公司，每个产品都可以有自己最好的模式，选择模式需要考虑人员组成（比如开发人员的水平），bug的风险，公司的规模，项目的压力等等。没有一定的好与不好。开发人员和测试人员的比例，不是越高越好，也不是越低越好。让开发做测试，未必就是划算的，这就好像让短跑的人去参加长跑比赛一样。单纯地看开发测试比，唯数据论，一刀切，是不合理的，甚至会得不偿失。一线的测试这样想，一线的开发也是这样想的。
本文出自：http://debbie.blog.51cto.com/2754849/1208360
