通常的考核指标涉及这些方面：
　　-  编译失败次数的考核
　　- 外网事故和bug的数量
　　- 测试阶段的bug，特别是基础功能bug和严重bug
　　粗略的列了这么多，其实可以有很多，比如配置文件改错的情况，漏提测文件的次数等等。
　　这里也许有很多的讨论，但是让我们看看一个实际的例子。下图是某个系统的编译失败的情况，在11月份的时候提出要统计并公开（并无惩罚条款）编译失败的情况，包含到开发的团队和个人等明显，12月份开始出现了明显的下降并稳定了。这个图隐藏了一些细节，如果剔除其他因素只看开发代码原因的编译失败则更明显，特别是后面有惩罚机制之后，进一步下降。

　　编译失败大幅的下降一方面是节省了大家的时间，另一方面其实也是提高了版本质量，想想如果有很多的编译失败，而且是到提交测试的阶段，这样的代码质量能好吗？是可能做过自测吗? 有了这样的机制，至少会更仔细一些。
　　对于bug方面其实也是一样，如果开发在乎（或者被迫在乎）外网bug或者被测试发现的bug数量，他写代码的时候一定会更仔细，也会做些简单的自测，让提测的质量更高，提高了整个研发系统的效率，同时也是提升了质量，因为quality must be built in。
　　我个人的经验，作为测试人员几乎同时面对过两个开发团队，一个有上述的考核，一个没有。表现出来的版本质量和对质量的关注完全不一样，而且前者也并没有出现开发和测试的对立，以及测试不敢提bug等负面的情况。
　　3. 对于测试的考核
　　除了对于开发的考核，同样也有对于测试的考核，这样也更加的公平。
　　测试的考核通常考虑下面的指标：
　　- 漏测：数量或者漏测率
　　- 版本的工作量和测试效率
　　- 发布延期的情况
　　如果测试有这样的压力，也需要不断努力去发现更多的bug。
　　说起考核，总有人觉得这不符合智力劳动的情况，或者互联网的作风，其实不太理解为什么会这么觉得，放眼望去，有什么工作不被考核呢，sales要背quota，为什么软件开发和测试不能对自己的工作的质量负责呢？当然，具体的指标如何去定才更合理那是另一个要去考虑的。
　　换个角度来看，适当的压力（不应该导致焦虑和扭曲的做法），其实是让一个人表现好的状态。
　　4. 推动开发的自测
　　这个问题一向是个老大难问题。愿意自测的开发团队你不用太多的推动，不愿意做的推动也很难，或者你无法判断他有没有做自测。而且这方面，通常取决于开发负责人的观念和态度。
　　如果是介于之间的，我们可以做一些事情，比如：
　　- 统计测试阶段的bug中，属于开发可自测发现的比例。通过这个可以看有多少bug是不应该到测试阶段的，以及横行纵向的对比。当然这个标准要自己拿捏。
　　- 给出一个自测的checklist。开发在提交前要完成这个list并正式的给出报告。这个方式我们曾经在一个项目中用过，效果不错，基本功能都通过这个保证了，前提是开发负责人认可。
　　- 有一套自动化验收的用例，可以挂接到自动部署之后或者daily build。前提是我们的自动化要足够的问题，效果才会好。
　　这个阶段除了业务测试的努力，也体现出了QA的价值。这里的QA是指质量管理，有的地方叫SQA，专注在质量度量和研发流程的管理上。
　　到这个阶段，发现事情顺了很多，质量也有更大程度的提升，并有改善额趋势。
　　第三个阶段：推动全面的质量提升
　　到上面第二个阶段，我们发现质量有了一定的提升，但是还是有不少的问题，而且有些问题需要我们把思路和眼界拓宽来看。这里讨论的一些东西可能更适合互联网的产品。
　　这里列一些我们可以去做的事情，受限于个人的经验，可能还很片面。
　　1. 研发流程的梳理
　　其实在阶段2的时候也可能有些团队已经开始做这样的事情，因为在分析质量和效率问题的时候，我们发现很多问题不单纯是代码的问题，可能还涉及研发流程的很多方面，比如：
　　- 需求不清楚
　　- 跨团队的配合问题
　　- 代码版本管理
　　- 技术方面的评审和大家的理解
　　所以整个研发流程的规范和梳理，以及配合对应的需求和版本管理的系统也是非常的必要，实际中发现效果也是比较的明显。而且还有一点体会，在接手一个很混乱的状况时，这样角度的数量和调整比技术方案的引入更重要和切中要点，能从40分到60分，技术是往80分走的过程效果更明显。
　　2. 提交测试前后做的一些事情
　　- 代码的静态扫描
　　这个方法很多的团队都在做，但是实际的效果似乎差别很多，而且ROI也很难说，不过从方法本身来说还是值得去做的，对测试人员也提出来更高的要求。
　　- code review
　　这个开发应该要做，特别是开发间的交叉review，非常的有帮助。不过这个也和自测一样，取决于开发负责人的态度。另外，测试也应该去做，特别是对于diff 代码的review，我们检查做了大概两个月的时间，发现还是非常的有收获。发现了一些黑盒难以发现的问题，以及开发的代码夹带，并且对于这个版本影响范围的评估也更准确。但问题是短期会花费测试更多时间，以及需要测试人员有一定的技术能力。