由于软件测试工作需要每个成员都需要有高度的责任感、全身心投入，我们就必须通过良好的管理方法和一系列激励措施，在测试小组中保持高昂的士气和动力。比如，可采用一．些管理形式土做那些代替组织团队不能做的事情：使测试小组的成员相信，测试部门经理和更上层的经理重视他们的工作和贡献，尊重他们的想法，并且当他们需要帮助时，
1、表扬和奖励
表扬和奖励仍然是激励测试人员最主要的一种形式，甚至采用积极的方式去帮助测试人员改正缺点，而不用批评或责备方式。表扬的形式多种，一封E-mail是简单的方式，虽然没有一点物质刺激，但还是有作用的。当然也川以设置一系列奖励项目，如：
· 发现bug最多的人员被授予bug王。
· 晶有价值bug(MVB)。
· 优秀测试计划。
· 最有价值测试用例。
· 季度优秀员工。
· 季度优秀新员工。
2、站在测试小组一边
我们曾经提过，目前国内还存在一些误区，认为测试工作地位要低一些，做编程更具有技某性和挑战性。我们或许小能改变这种不正确的观念，并且在相关政策上，这种错误的看法从某种程度上也得到体现。然而，町以采取一些办法，把这种想法对测试小组的消极影响降低到虽低。
首先要使测试人员坚信，他们的想法和建议能够得到足够的尊重，因为他们最了解产品，对产品的每一项功能都很清楚，所以对产品提出的建议一般都具有针对性、有极高价值。
其次，要保护测试人员。编程人员是可以犯错误的，因为程序中有错误是正常的，没错误是不正常的，程序中的错误有测试人员来把守，但测试人员不能犯错误，如果某个测试人员漏掉某一个bug，可能会让用户碰到，问题会变得很严重。也就是说，某个测试人员发现1000个bug，结果漏掉一个严重bug，最后得到的评价就是不好的，可能是前功尽弃。而按照科学研究表明，发现的bug越多，潜在的、束发现的bug可能性也会越大。所以，测试人员往往受到不公正的对待，需要被保护。当面对别人对你测试小组成员进行愤怒的攻击时，不管这个倒霉的测试人员犯了什么错误，不要公开地批评和指责他。然而，作为测试部]的经理，却应该承认存在的问题，可以说：“是的，我或许能够把工作做得更好。我想是在评审报告时出现了失误，但是让我们再讨论一下这个错误。”这样会有助于测试人员的情绪稳定。
此外，不管测试人员犯了什么样的错误，都不应该干扰对他们从事的正确事情的注意力。如果在一个令人不快的错误报告中缺乏隔离步骤，但是这个错误是不町否认的，那么就不要让人们忽视这个事实。如果一个测试人员的性格，不适应严重性逐渐增强的问题，那么应该把注意力转回到问题本身上来。应该和在场的测试人员一起做这件事情。在公开的场合中，应该明确地支持你的组员，然后在这件事情过去和反应平静之后，找一个机会，私下同大家做必要的交流工作。通过展示在受攻击时表现的这种团结，或者在私下处理他们的失误，你将在你的员工中建立真正的忠诚信念。
3、提高士气
提高士气可以从以下几个方面去做：
· 薪水。如果测试工程师的薪金标准低于公司中其他工程师的水平，就应该和人 资源部一起努力，争取使具有同等职责、经验、学历的人得到同等水平的薪水。如果存在不合理的情况，就没法做些薪水调查，帮助解决实际存在的问题。
· 职务。开发人员的职务可能比测试人员的职务有更高的等级和威望，这种不公平的现象也应该得到消除，即使小能消除，也要朝这个方向努力。也可以设置测试人员专业系列职务，建立一套认证体系，这些专业系列职务包括初级测试工程师、测试工程师、资深测试工程师、丰任测试工程师、项目组长、项目经理、产品经 理、质量经理、质量总监等。
· 工作时间。由于软件测试的特殊性，可能加班的时间会多些，这就要求测试经理多为测试人员争取额外补偿和其他的利益，或指出这样做的不公平性，设法制订一个更合理的项目日程表，改进工作方法，提高工作效率。
· 培训机会。由于测试任务重、或者认识上的误区(如觉得测试技术性低，没必要参加培训)，测试人员很少有机会参加一些重要的培训。作为测试经理，就应该做好培训_颅锋，设法创造机会，垒少让那些优秀的测试人员去参加非常有用、有吸引力的软件测试技术绒项H管理等方而的会议。
4、支持合理的工作方式
山于软件测试的特殊性，不切实际的进度安排和软件开发前期丁作没做好，结果所有被延误的叫间会压向测试阶段，测试所需要的时间被挤鹾，从而造成测试人员加班比较常见的现象。所以，要帮助他们建立有效的、合理的工作方式，保缓解被挤压的时间所带来的压力，并且注意关心测试小组成员的成长。
在软件测试中，常用的方法有：
· 白天创建、编辑测试脚本，在下班前启动白动测试脚本，让系统晚上自动运行测试，第二天早上拿到结果。
· 调节各人休息时间表，保证测试每周7天都能执行测试，充分利用测试机器和其他资源，对每个测试人员依然每剧_[作5天。
· 将测试工作进行分解、细化，一部分人(2～3个人比较好，至少包括测试项目组K)可以先进八某个测试项目，设计测试计划、测试用例、建立环境等。
· 项目计划或产品功能的变化，对测试影响要比开发大，事先要对这些风险进行充分估计，在估计测试时间时，要留有定的余地。
