第十二回测试驱动开发 作为一名研发人员，与测试人员打交道的机会是非常多的。

    研发人员与测试人员是制约与被制约的关系。

    可惜的是研发是被测试制约，原因很简单：测试人员决定了研发人员出活的质量好坏（从根本原因上说，质量的好坏都是研发人员做的，测试人员只是检验，从而让其更好）。

    测试人员的日常工作就是负责测试研发人员开发的产品是不是可用的，这就好比一个厨师炒了一盘菜，有专门的品菜员来尝你炒的好不好吃，品完了再给客人上桌（当然现实中可能没有这回事）。

    如果这个品菜员发现你辣椒放多了，那你就完了，弄不好一个月的菜都白炒了。

    如果品菜员没有发现辣椒放多了，而客人吃的时候发现辣椒放多了，吃完了直打喷嚏，并因此大发雷霆，甚至叫人把店砸了，那问题就严重了。

    这时候这个严重的问题导致品菜员和厨师要各打50大板，这50大板是各打各的没有任何关系，甚至厨师那边如果不打，品菜员这边也不管，他只挨他的打就是了，也就是厨师与品菜员是属于不同的考评体系。

    因此每个合格的品菜员在品菜的时候都想尽了一切办法，千方百计挑毛病。

    研发与测试的关系就是厨师与品菜员的关系，这时候你知道了品菜员有多么关键，因为如果一盘不合格的菜上了桌，吃出问题麻烦就大了。

    因此品菜员大权在握决定了厨师炒菜的好坏。

    说研发一直被测试欺负一点也不为过，因为品菜员是菜品质量的最后一道关，他放过去菜就上桌了。

    对于产品来说，测试是产品的最后一道关，如果他没发现问题，产品就往外卖了，如果用户这时候发现问题，后果可想而知。

    因此测试可以对研发进行制约，提出质量上的各种要求，研发不服可以上诉，但是研发自己不具备对测试提出的问题拍板的权力，他只有解释的权力。

    这就是著名的测试驱动研发模型，简单来说就是测试说了算，他说这里有问题要改，研发就要改，如果研发说不改，可以说服测试，但测试有拒绝的权力^56书库 .shubao2./class12/1.html，如果研发仍坚持不改，那就要上诉。

    如果测试说不改（这种情况基本不存在，从上面可以理解测试人员对产品质量的要求要远高于研发，这就好比如果品菜员觉得这盘菜炒得好，那厨师可能不管真好还是假好，马上上桌，所以品菜员一定要把握菜品的整体质量），那研发一般默认。

    所以研发人员受测试人员的制约。

    我在学习完三周两天之后就开始正式上岗工作了。

    在日常的工作中我们主要做两件事情：第一件事情是处理测试人员测试出来的问题或我们自己发现的问题，第二件事情是做新的开发。

    事实上新开发不常有，因此我们平时主要处理测试人员反馈过来的缺陷，也叫问题单。

    即测试人员发现问题后，将问题描述清楚，提一张单到研发这里（这张单一直存在，直到问题被解决才能关闭，保证了问题一旦发现就会被解决，不会丢失），研发开始看着单排查哪里错了进行修改。

    下面我们来介绍一下问题单这个新鲜事物，因为除了开发新特性，我们平常就是在处理问题单。

    </p>