软件测试工作的三个阶段(2)

　　常常做的事情可以从下面几个方面来看：

　　1. 做质量数据的统计和分析

　　收集的数据很多，常见的有：

　　- 外网的bug情况，包括事故，及影响的程度

　　- 测试阶段的bug数量，分布(按系统，团队，开发个人)，严重程度，bug的类别等维度

　　- bug的横向跨团队和系统的对比，纵向的和历史情况对比

　　- 版本发布的情况，代码变更行数的情况

　　从这些数据的收集中就能发现很多问题，比如问题集中在哪里，哪些模块，哪些人，哪些类别等等，以及有没有改善。

　　2. 问题的追溯和对于开发的考核

　　这个方面也许有一些争议，但是我还是觉得这个是一个很重要的方法。光靠观念和自觉是不够的，必需要有一定的反馈机制，就好比交规一定是配合着扣分和罚款等手段，否则记录闯红灯有什么意义呢?而且现实的来说，这些方法起到约束的作用，也是一种心理暗示，要做自己做的东西负责，也便于养成好的习惯。

　　通常的考核指标涉及这些方面：

　　- 编译失败次数的考核

　　- 外网事故和bug的数量

　　- 测试阶段的bug，特别是基础功能bug和严重bug

　　粗略的列了这么多，其实可以有很多，比如配置文件改错的情况，漏提测文件的次数等等。

　　这里也许有很多的讨论，但是让我们看看一个实际的例子。下图是某个系统的编译失败的情况，在11月份的时候提出要统计并公开(并无惩罚条款)编译失败的情况，包含到开发的团队和个人等明显，12月份开始出现了明显的下降并稳定了。这个图隐藏了一些细节，如果剔除其他因素只看开发代码原因的编译失败则更明显，特别是后面有惩罚机制之后，进一步下降。

　　编译失败大幅的下降一方面是节省了大家的时间，另一方面其实也是提高了版本质量，想想如果有很多的编译失败，而且是到提交测试的阶段，这样的代码质量能好吗?是可能做过自测吗? 有了这样的机制，至少会更仔细一些。

　　对于bug方面其实也是一样，如果开发在乎(或者被迫在乎)外网bug或者被测试发现的bug数量，他写代码的时候一定会更仔细，也会做些简单的自测，让提测的质量更高，提高了整个研发系统的效率，同时也是提升了质量，因为quality must be built in。

　　我个人的经验，作为测试人员几乎同时面对过两个开发团队，一个有上述的考核，一个没有。表现出来的版本质量和对质量的关注完全不一样，而且前者也并没有出现开发和测试的对立，以及测试不敢提bug等负面的情况。

　　3. 对于测试的考核

　　除了对于开发的考核，同样也有对于测试的考核，这样也更加的公平。

　　测试的考核通常考虑下面的指标：

　　- 漏测：绝对数量或者漏测率

　　- 版本的工作量和测试效率

　　- 发布延期的情况

　　如果测试有这样的压力，也需要不断努力去发现更多的bug。

　　说起考核，总有人觉得这不符合智力劳动的情况，或者互联网的作风，其实不太理解为什么会这么觉得，放眼望去，有什么工作不被考核呢，sales要背quota，为什么软件开发和测试不能对自己的工作的质量负责呢?当然，具体的指标如何去定才更合理那是另一个要去考虑的。

　　换个角度来看，适当的压力(不应该导致焦虑和扭曲的做法)，其实是让一个人表现最好的状态。

　　4. 推动开发的自测

　　这个问题一向是个老大难问题。愿意自测的开发团队你不用太多的推动，不愿意做的推动也很难，或者你无法判断他有没有做自测。而且这方面，通常取决于开发负责人的观念和态度。

　　如果是介于之间的，我们可以做一些事情，比如：

　　- 统计测试阶段的bug中，属于开发可自测发现的比例。通过这个可以看有多少bug是不应该到测试阶段的，以及横行纵向的对比。当然这个标准要自己拿捏。

　　- 给出一个自测的checklist。开发在提交前要完成这个list并正式的给出报告。这个方式我们曾经在一个项目中用过，效果不错，基本功能都通过这个保证了，前提是开发负责人认可。

原文转自：http://blog.csdn.net/superqa/article/details/21485737