在一个项目中，有很多的人，有很多的不同的职能部门；有的负责测试，有的负责开发，有的负责外场；每年都有很多的人进进出出这个项目、部门，人员变动在人任何一个项目都是非常普遍的情况。如何迅速培养新与员工，是项目管理的一个认真思考的一个问题。
就测试人员的培养方面，我有以下几点的想法：
1、测试的目的是什么；测试分为单元、集成、系统，还有外场测试、开局测试；单元和集成测试有开发人员来完成了；系统测试就由专门的测试人员来进行；而且系统测试是最关键的，只有经过严格、系统、全面的、细致的、合理的系统测试，产品才能给客户交付。但是有很多人认为测试就是把产品拿过来，随便敲命令就可以了，非常的简单。
其实测试有一套非常明确的理论和指导意见在支持。测试的目的是发现故障；但是如何发现故障，如何测试发现故障，如何按照目标测试发现故障；有的人测试唯 故障多少论；这就涉及到测试的合理性问题了，难道发现的故障越多，版本就越稳定吗？一个项目交付有一个时间的问题，大家不可能给这个项目测试非常多的时 间，从项目交付到测试部开始测试，到外场测试、开局测试，到产品商用，都有一个严格的时间规定的；理论上的测试空间是无穷大的，一个测试人员要把所有的测 试条目都过完，而且还要反复的过这些测试条码都是不 太可能的；那有一个问题了：如何在有限的时间能完成测试任务；这个就测试合理性问题。我认为：认真研究客户使用方法，总结一套实际和可用的测试指导方案， 通过系统和循序渐进的培训，来强化测试人员这种测试理解；只有按照客户使用的方法来测试我们的版本，才能发现在商用中出现的问题，才能更好的比较开局故 障、商用故障。
2、测试人员负责的模块的测试；如何开始测试负责模块？理解要测试模块的功能，熟悉模块设计的相关文档，熟悉测试模块的 商用场景；其中最重要的事要熟悉商用场景，用户是不是要这么使用，是如何使用的。其实一个版本的功能非常多，但是客户真正使用的是功能是其中一部分，其它 的都是默认的配置或者基本功能。
3、新测试人员的讲解；新员工在未转正之前都要进行负责模块的讲解；讲解什么内容？有的是讲如何测试 的，有的是讲测试模块设计的相关协议的；我认为关键是谈谈测试心理和理念，多讲解商用环境；如何结合商用环境来铺开测试；尽可能的以商用为中心测试更多的 测试案例；如何排列自己的测试顺序。
ps：唯故障数量论的测试是垃圾。
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/