每个公司应该都有考核机制，对于开发和测试的考核实际上很难量化，通常来讲大的方向就是开发所负责模块的bug数，对于测试来讲就是测出来的bug数，但这真的有效吗？这也许对开发有约束力，理论上开发是能够自己控制bug数的，如果从产生的bug数来评判开发的绩效还算有效，这样开发自然就会把代码写得更加认真。但如果根据测试测出来的bug数来评判测试的绩效，就假设测试为了自己的绩效瞎测怎么预防？
单纯地根据bug数来评判开发和测试的绩效，我认为显然不合适。这会导致开发写代码时小心翼翼没问题，但测试就可能会不可避免的测一些莫名其妙的bug，bug多了测试的绩效高了，同时开发的绩效不就低了么？当然实际当中显然也不会根据这一个维度来评判绩效。
很多时候开发和测试的关系仅是零和博弈。
开发和测试存在目的是什么？开发是为了实现客户的需求，测试是为了保证软件的质量。两者应该是合作共赢的关系，不是零和博弈，不是此消彼长，不是你胜我败。开发和测试实际上是很矛盾的，两者既对立又统一。
毫无疑问开发和测试应该是对立的，如果因为开发过多干涉测试的工作，那这个工作根本无法开展，软件质量根本无法保障，测试岗位的设立毫无意义。两者不存在上下级关系，开发应不惧怕测试测出来的bug，同时测试应“多”测出bug，这个“多”并不是数量上的多，而是质量上的多。开发的代码有质量之说，我想说的是bug的质量也是一个测试水平的体现。开发不能把测试当做大爷一样来对待，测试更不能把自己摆在大爷的位置。
开发和测试的关系同样也是统一的。我认为测试的职责或者测试的成就感不是来自于测出bug，而是能协助开发找出问题并且定位问题。这里的协助并无主次的关系，对于出现bug地方的代码实现测试也许不懂，开发也许也懒得听测试的意见，这个时候并不是测试要和开发一起去寻找代码实现上的问题，而是和开发一起梳理功能的逻辑有无问题，测试以测试的经验和专业技能协助开发。两者统一关系的体现在这个软件是共同的结晶，并不是开发一方的成果，目的都是为了软件能更快更好的发布。
我想在计算机类的专业里，开发和测试两个方向就类似高中时期的理科和文科。很大部分在高中数学不行或者成绩不行就选择文科认为简单，计算机类的专业里稍微有点“志气”的学生也会选择做开发而不会选择做测试，测试的标签就是简单 ，当然这个现象和类比也许并不准确。
测试人员在测试的时候应有一定的专业素养，测试不能毫无逻辑，毫无规划的一通乱测，这有个好听的名字——探索性测试。举个例子：
测试：“出问题啦！某某某快来看啊！”
开发：“怎么操作的？”
测试：“我就点了哪儿就出现这个了啊。”
开发：“那等等，我看下后台日志，你再操作一下。”
测试：“怎么不能复现了啊，刚刚我就是这么点的啊。”
开发：“……”
这个场景常见，如果这个bug本身就是偶现的bug那还说得过去。如果问测试怎么操作的，测试一脸懵逼的说：“我不知道，我忘了。但是你这个有问题就是bug。”这得多花多少开发的时间去排查这个问题啊，不是不让你测，是让你有套路有思路的测，这是对于测试自身素养问题。
同样对于开发人员也是一样的，自测是一个很好的习惯，抛开开发的代码能力，这是对于开发人员最基本的素养。举个例子：
开发内心：“终于做完这个功能了，不测了，反正有测试，让他们去测，测出问题再改。”
很大部分的bug是因为开发自身没有做好自测，单元测试并不是在每个公司每个项目每个模块都有，甚至很多开发人员几年工作经验也不知道怎么编写单元测试。认为自己的工作就是写代码，检验功能是否完善是否有bug的工作应该交给测试去做。
对于开发和测试素养的问题我想这是在理想状态下，或者只存在理论上。实际上开发测试鱼龙混杂、参差不齐、滥竽充数都有可能。但对于开发和测试关系万万不可将开发和测试放在对立面，同样应考虑他们是统一的，矛与盾缺一不可，合作共赢而不是零和博弈。如何维系两者的关系也是一个很值得研究的问题。
