标签：
近半年以来，我们部门大大小小的测试项目也做了不少。对于如何组织测试工作，各个测试组长/测试负责人都积极发挥着自己的主观能动性，为提高测试质量和测试效率而积极思考。
但是，唯一有个问题让一些组织者绞尽脑汁，那就是：如何让自己的工作能尽量小的偏离自己的预定计划目标，从而提高自己测试计划的有效性呢？对于这个问题，我有一点自己的想法，可供参考。
由于测试计划是一个测试项目必不可少的项目管理性文档。它或简单或复杂，其目的都是为了让项目能在预先计划好的轨迹上运作，以尽量减少测试工作的过大投 入，从而拉大投入成本与软件利润的比差，达到项目的最大收益。除了这个主要原因外，制定测试计划还有一些附加原因，也就是：
1）让测试工作尽量的可视化和可控化。
2）为更好的对测试团队的工作能力有更真实的考核（即，执行者在预定的时间和环境下完成任务的能力和质量）。
3）为测试的过程改进工作提供依据。
4）软件开发流程中必要的文档。
可见测试计划的必要性。既然他是必要的，而且目的也说的很清楚了。那么我们不能把自己制定的测试计划当成一纸空文，而应该把他更好的利用起来，以真正的体现它的价值所在。
下面是我对如何提高其利用率的几点建议：
1、不要过渡的依赖于测试计划模板。
现状：
我们在拿到一个测试项目以后，我们一般的做法是：先看文档；然后根据文档分析系统功能；然后在要求的时间里就开始写计划了。写测试计划的过程是边想边写， 好像都不知道该写些什么好。有的人就干脆把其他项目的测试计划拿来，修改一下进度表和人员表，增删一些测试方法等就完了事。我们做测试计划的目的几乎就成 了应付检查，不在于使用。
建议：
我们通过分析需求和系统功能，我们就应该对如何计划测试工作胸有成竹了。制定测试计划，我们必须先要做好以下几件事情（那是我们制定计划的时候所必须的东西）：
a）确定测试范围。
b）根据测试项目的工作强度和难度来组织测试人员。
c）根据项目所提供的各项数据以及成员能力，评估风险，时间和资源消耗。
d）根据质量保证计划以及项目所提供的数据资料，确定可行的测试方案（必要的话，还需对测试方案的可行性和风险性进行审查，使实施的风险可控化。）
e）在预计的测试时间段里，根据制定的测试方案确定时间进度。
f）测试过程中，对测试版本的控制（大型的项目，应该考虑附加《配制计划》）
当我们把这些事情做好后，我们就可以正式的拟定测试计划文档了。在计划文档中写清楚测试的对象、范围，测试的时间、进度，测试所需要的人力和物力，测试方案说明，测试工作的各项标准定义，测试的风险评估以及预防措施等。
尤其在确定时间的进度时，最好不要把时间刚好排满，要在时间的后期留有一个缓冲时间段，以应对意外突发事件。
2、重把测试计划的审核关。
现状：
一个测试计划文档生成后，还不能算是完成计划工作了，还必须对计划进行评审，将其合法化。那么我们公司的评审者到底评审些什么呢？他们拿到要评审的计划 书，就主要关注一下文档的书写结构（看目录），再看看进度安排和实施方案，但就是不提出该实施方案在这个预定的进度中能否可行，以及风险评估是否合理，可 能在他们的评审检查项里就缺少“对计划可信性和可行性的检查”以及“计划方案实施的风险性”的考虑。
建议：
计划是拿来实施的，不是拿来当摆设的。计划是否可行，是否行之有效，实施的风险是否可控制等等问题是我们在检查的时候必须考虑的。如果我们只是在文档字面 上去检查那些文字错误的东西，是否太不负责任了呢？试问，如果在通过这样的计划评审后，在实施中，遇到风险过大等诸多问题，这个责任是谁来担呢？
所以我们检查计划，字面错误这种不痛不痒的问题几乎可以忽略它，这个计划能不能用才是关键。所以，我们应该主要检查：
1）我们测试的对象是什么？
2）在什么环境下实施我们的测试工作？
3）我们的测试所要花费的时间、经费和资源（最好还是不要超出预算的为好，不然可能老板不支持我们的工作，反倒是个麻烦了！嘿嘿）？
4）制定的实施方案是否可行性？
5）制定的实施方案所担当的风险系数有多高？
6）是否还有更好的可降低风险的实施方案？
7）我们的测试工作以什么样的来衡量我们的工作成绩？（甚至是对工作的奖惩办法等）
8）是否有对于工作风险的控制方案。
9）工作中，任务交代的是否够清楚？以免让执行者随意瞎搞，导致对其测试工作不可控。
10）项目成员对这个要测试的对象的理解程度有多深？
11）测试人员的组织和管理方案是否可靠？
......
3、测试计划不是一纸空文。
现状：
一个很让人怀疑其可行性的测试计划通过之后，下一步工作就是把它放到共享服务器上，供项目管理部检查，最后——结束了。直到项目结项的时候，才把这个都快 “发霉”的计划文档翻出来，准备结项工作。而且对于计划中没有完成的任务也不怎么提（因为大家都在担心一个问题：如果提出来，结不了项，怎么办？）。因为 我们似乎都是很尽职的在发扬“扬长避短”的“优良”作风。
建议：
QA人员必须严格按制定的计划进行过程检查工作。一旦发现实施的计划与预定的计划有出入。应及时通报相关人员，了解其偏离计划的原因，尽快处理好计划实施不到位的问题。
4、实行计划跟踪。
现状：
计划中编写的时间进度表，在真正的实施中是很少用的。每个时间段里要生成什么工作成果，要评审什么文档，项目管理部似乎也在关心。但他们似乎只关心成果数 量，而工作成果质量工作似乎被项目管理工作所取代了（QA被项目部同化了）。试问，一个项目真正是想要十几个甚至更多的没有实际意义的文档，还是要一个高 质量的可使用的文档呢？对于这个问题，似乎走入了一个面子工程的地步（过程进行的风风火火，结果是一塌糊涂）。比如：在评审各项工作成果的时候，只检查字 面的东西，而对于这个工作成果到底是不是这个项目的工作成果他们也不怎么怀疑？难怪很多项目文档描述的东西和实际开发出来的东西对不上号呢！（如：SRM 系统）
建议：
对于在计划中提到的各阶段必须生成的工作成果是否存在的问题，项目管理部也必须严格监督。而最重要的工作成果质量问题，应该由QA人员组织评审人员进行评 审。如果工作成果评审未通过，坚决不能启动下一阶段的工作（但如果时间不充裕的话，为了不耽误下一阶段工作的如期进行，可以提前准备下阶段的资料）。不能 因为时间紧迫，而放宽对工作成果质量的检查。
5、计划变更，必须可控（如：变更的风险性审查和变更通知等）。
现状：
当计划实施过程中，需要变动计划的时候，根本不走变更流程，直接由经理修改了事。他们的理由是：走变更流程太麻烦，很浪费时间，怕拖延计划进度。如果项目 顺利完成到好，但如果项目出现任何闪失，那就在这个责任问题上，可能会激化各部门之间的矛盾。而且修改过的计划即不通过评审，也不加以通知报告了，不知情 的人还在努力的在原计划中奋斗工作着呢！有可能导致项目就此失去项目管理部的控制（难怪项目管理部的项目管理控制工作是如此的困难）。
建议：
对计划中的重大变动问题，必须向项目管理部提出变动申请。项目管理部必须对该申请进行严格审核，考虑其变动的风险性问题，而不能一有申请来，就通通的给通 过了。通过审核的申请，就可以修改计划了，计划在做出相应变动修改之后，必须进行再次评审通过才可生效。再次评审通过后的计划，必须及时替换原有计划文 件，并通知所有项目成员按新的计划实施。
6、定期在报告中汇报计划执行情况。
现状：
在计划实施过程中，执行者们很少有自觉写工作日志或阶段工作报告的习惯。
建议：
在每个阶段结束后，应该向管理部门提交一份关于该阶段的计划任务完成情况的报告。管理部应严格审查该阶段的工作汇报，及时处理工作所遇到的问题，以避免问题在以下的阶段中继续扩散或延续。
7、当计划无法继续实施时，及时通报相关人员（不能擅自自定义计划）。
现状：
在计划实施过程中，遇到无法在现有的环境下继续执行计划时，经理开始想办法另辟蹊径了，从而放弃原方案，开辟一条新道路给大家走。可能直到结项的那一天， 项目管理部才发现我们实际所做的工作于我们的原计划上有很大的出入。（难怪项目管理部对我们测试甚至整个项目的计划实施管理控制上，像个局外人呢！）
建议：
在计划实施过程中，遇到无法在现有的环境下继续执行计划时，不能擅自调整计划方案，应该及时通报上级管理部门，以便及时处理计划方案调整的问题。对于计划 方案的调整，必须通知其他相关人员，做好调整工作。加强各个部门的沟通。以免项目失控。
以上是几点关于测试计划的实施有效性问题的微薄见解，希望以此引起相关人员/部门的重视，并做出更好的方案，以完善此方面的问题。而对于其中提到的各项审 查的检查项等问题的定义，在以后的工作中，再继续加以完善。也希望公司的每个人都为了以后更好的做好项目而积极努力。
转载：http://www.uml.org.cn/Test/201109084.asp
标签：
原文地址：http://www.cnblogs.com/zhangyublogs/p/5194293.html
