在一个项目中,有很多的人,有很多的不同的职能部门;有的负责测试,有的负责开发,有的负责外场;每年都有很多的人进进出出这个项目、部门,人员变动在人任何一个项目都是非常普遍的情况。如何迅速培养新与员工,是项目管理的一个认真思考的一个问题。

  测试人员的培养方面,我有以下几点的想法:

  1、测试的目的是什么;测试分为单元、集成、系统,还有外场测试、开局测试;单元和集成测试有开发人员来完成了;系统测试由专门的测试人员来进行;而且系统测试是关键的,只有经过严格、系统、全面的、细致的、合理的系统测试,产品才能给客户交付。但是有很多人认为测试是把产品拿过来,随便敲命令可以了,非常的简单。

  其实测试有一套非常明确的理论和指导意见在支持。测试的目的是发现故障;但是如何发现故障,如何测试发现故障,如何按照目标测试发现故障;有的人测试唯故障多少论;这涉及到测试的合理性问题了,难道发现的故障越多,版本越稳定吗?一个项目交付有一个时间的问题,大家不可能给这个项目测试非常多的时间,从项目交付到测试部开始测试,到外场测试、开局测试,到产品商用,都有一个严格的时间规定的;理论上的测试空间是无穷大的,一个测试人员要把所有的测试条目都过完,而且还要反复的过这些测试条码都是不 太可能的;那有一个问题了:如何在有限的时间能完成测试任务;这个测试合理性问题。我认为:认真研究客户使用方法,总结一套实际和可用的测试指导方案,通过系统和循序渐进的培训,来强化测试人员这种测试理解;只有按照客户使用的方法来测试我们的版本,才能发现在商用中出现的问题,才能更好的比较开局故障、商用故障。

  2、测试人员负责的模块的测试;如何开始测试负责模块?理解要测试模块的功能,熟悉模块设计的相关文档,熟悉测试模块的商用场景;其中重要的事要熟悉商用场景,用户是不是要这么使用,是如何使用的。其实一个版本的功能非常多,但是客户真正使用的是功能是其中一部分,其它的都是默认的配置或者基本功能。

  3、新测试人员的讲解;新员工在未转正之前都要进行负责模块的讲解;讲解什么内容?有的是讲如何测试的,有的是讲测试模块设计的相关协议的;我认为关键是谈谈测试心理和理念,多讲解商用环境;如何结合商用环境来铺开测试;尽可能的以商用为中心测试更多的测试案例;如何排列自己的测试顺序。

  ps:唯故障数量论的测试是垃圾。