对于大部分研发团队，测试资源总是处于紧张的状态。一些项目经理，测试经理也常常抱怨，测试人员配比总是低于常规的比例。那么怎么安排测试资源，特别是在时间有限的情况下，以及在不能增加测试人手的情况下?作为管理者，怎样才能发挥测试团队的最大效率?

答案很简单： 各司其职，各尽其责。

通过激发测试队员的积极性充分发挥各自潜能，并培养团队协作氛围增加团队精神，工作上步调一致，来最大程度的发挥团队效能。不同测试阶段采取不同测试策略，例如测试过程中出现定位效应、审丑疲劳和同化现象可采取交叉测试来规避;鼓励创新，不断变化测试方法来提升测试效率;尽量让每个人做不同的事情减少重叠和内耗，在专长上面要有互补性，充分发挥各自特长。

开发人员与测试人员怎么配比才合适？实际这里没有一个恰当的固定值。一个研发团队，开发、测试的人手配比不是简简单单3:1或者5:1一概而论。这个主要根据公司的成本考虑，具体来说就是与开发人员、测试人员的素质息息相关。在谷歌的核心研发团队，根据了解，开发测试人员配比是10:1!而在常见的企业中，大部分配比都是3:1，然而在微软可能又是1:3!所以，大部分企业可以死心了，如果仅仅是为了做一个东西炒作一个题材、概念，那么就不要想像谷歌那样去要求测试，那到时可能没人能做下来。

当然，如果想追求用户的极致体验，也可以像微软那样去配比，但这个成本不是浮躁的企业能够承受的^_^所以一个研发团队开发、测试的人员配比，要根据所招开发人员、测试人员的素质来进行合理的配比，万万不可一刀切，否则后面要不开发团队很闲，要不测试团队很闲。

当测试人员有限，而研发团队多条业务线同时进行时，应该怎么调配人员?是一测试人员专门负责一业务线，还是测试人员统一调度安排，哪个有空就抽调哪个?这也是研发团队中项目经理或者测试经理觉得困难的问题。实际没有那么复杂，主要根据业务的周期和复杂度来决定。业务复杂度高、周期长的，至少得有一个人专项负责，最好有两人能够熟悉该业务。如果该业务清闲时，则腾出该专项负责人进行其它业务的测试，忙时也可以根据其它业务线的情况抽调其它人加入测试。两个人熟悉业务，同时保证了专项测试人员流失时，对这块业务的衔接测试。

为什么复杂度高、周期长的业务需要专人负责?这也是一个很简单的问题：真实经历，所在测试人员技能素质都差不多的情况下，如果谁能更多的发现问题，同时能更多的提出些建设性的优化意见，主要与这个人员对某块业务的熟悉度有关。这也是为什么我们经常会看到招人，需要有多少某个行业的经验原因，这样的测试人员才能更快入手测试。

测试计划不如变化，开发交付物延期，测试时间不能变更，测试人员不能增加的情况下又该怎么调配人员呢?相信这个问题在现实中，大家都会碰到。同样，这里有一些解决办法。

首先要尽早的介入测试(这里主要指测试实施的接入时间，不是我们常说的需求、计划设计等阶段的接入)，最好加入集成测试，即当开发做好一个接口，或者模块时，就应该介入测试。不要等着所有东西出来再测，这样不能在前面就发现开发人员的一些坏习惯，让其后续避免，导致所负责的东西在测试时问题不断，也导致后面测试时间压缩后没有更多的应对措施。

其次，应该标出测试功能模块的优先级，在时间不足的情况下应尽量保证优先级高的部分能够充分测试。在业务复杂，周期长的项目，最好准备一些基础测试用例，这样才能避免我们在时间紧的情况下出现遗漏，避免事故的发成(血的经验和教训)。最后就是，尽可能争取内部资源了，比如可能闲置的设计团队、产品团队等。这里需要我们测试梳理一套可行的测试工作规范，里面应涵盖测试的内容，用例的设计，缺陷的管理，测试通过的准入、准出标准等。这样通过简单的培训，即可让争取到的内部资源尽快的投入测试，做一些基本面的测试工作。让专业测试人员放更多精力在核心的功能、业务、性能乃至安全测试上。

最后，在安排人员上，还应该因人而异，即根据每个人的情况安排到合适的测试中去。每个人都很难做到样样精通，如果通过合理的安排，让每个人献出自己的最大能力，那么势必会事半功倍。否则会事倍功半，同时打击了人员的积极性，最终导致黯然离场。所以，一个测试人员是否能获得他人的认可，也与上面管理者是否有根据该测试员情况所作出的合理工作安排有关。

测试人手的安排没有想象的那么困难，首先要看开发人员、测试人员的素质，其次更多需要靠管理者的智慧去解决。

每个人有自己的专长，要把专长保持好并不断创新，要互相取长补短，多向资历老的同事学习，多问多记多总结。业精于勤，测试虽然辛苦但也是有趣的。

最后，给测试经理/主管的意见和建议：识人善用，充分发挥队员各自优势，并为队员提供适度的宽松环境和自主的时间支配，这样组员积极性会高，团队效率会高。要做组员的坚强后盾，当工作中遇到问题时，能为他们提供支持和帮助，并把自己的知识尽可能的转移给组员，促进下属成长，自己从中解放出来思考更多问题。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/69940641/viewspace-2652241/，如需转载，请注明出处，否则将追究法律责任。