经常听到有人发出“计划没有变化大”、“计划赶不上变化”之类的感慨，说这话的人肯定是没有做过计划或者是没有认真的做过计划的同志。计划和变化本来就是相辅相成的，没有计划，变化从何谈起！有变化则恰恰证明了计划的重要性。

　　在软件项目过程中，为什么有的项目做的井井有条、按部就班、忙而不乱，而有的项目却是一团乱麻、主次不分、经常需要“救火”，到头来，有的项目能够分期分批的交付工作成果，最终实现工作目标，而有的项目却迟迟交不出东西，或者，交出的产品质量严重不符，与项目目标相去甚远。当然，这是两个极端，更为常见的则是项目存在不同程度的延期、超支和质量上不去的问题。为什么会造成这样的结果呢？有人说是项目管理的问题，没错，但究其根源，则是项目计划出了问题！

　　军队中常说的一句话就是“一切行动听指挥”，用在项目上，可以演变为“一切活动看计划”。项目计划就是所有项目活动的指南，重视计划、推进计划，才能使项目始终沿着既定的轨道运转，也只有这样，才能最终实现项目目标。计划不一定非得做的美观漂亮、规范严谨，关键是计划的实际可操作性，否则，再完美的计划也将形同摆设，毫无用处。制订计划是项目过程中首要的工作，计划的成功制订意味着项目已经成功了一半。因此，对于那些拿来工作就急着做、没有计划性的项目是不应被提倡的。对于规模很小的项目来说，这种“敏捷”的做法也许会取得成功，但始终是昙花一现，几乎没有参考价值。项目不管大小，哪怕只有一个人，也要制定计划，不同规模的项目，计划的规模也会不同，但只要切合实际的去进行计划，后面的工作就不至于是无根之水，放任自流了。

　　通过实际项目的经验表明，进度计划、质量计划、风险计划、测试计划、配置管理计划以及沟通计划是项目计划中比较重要、对实际工作也比较有指导意义的几个子计划。其中，进度计划是所有计划的基础，它确定了项目的时间范围，它让你知道在哪个时间应该完成哪项工作；质量计划则告诉你这项工作是否已经完成，是否满足要求；风险计划将会告诉你完成这项工作可能出现的障碍，应如何解决；测试计划将会告诉你如何循序渐进的发现工作中存在的漏洞，是否可以交工；配置管理计划将会为你列举一下这项工作将由哪些部分组成，哪些是关键的，哪些是可变的；沟通计划将告诉你在做这项工作的过程中你要跟哪些对象共事，应如何跟他们协调一致。

　　当然，计划也不是一蹴而就的，任何人也没有料事如神的本事，它是一个由宏观到微观、由粗到细逐渐分解逐渐细化的过程。开始，它可能只会告诉你要做哪几件事（里程碑），后来逐渐告诉你每件事有哪些活动（目标分解），然后再告诉你每项活动应该怎么去做（具体工作流程）。执行计划的过程就象是拆锦囊，每到一个路口，就拆开一个锦囊，里面告诉你如何往下走。

　　前面提到了好的计划就等于项目成功了一半，那么另一半是什么呢？是控制。控制就是对计划的执行情况进行监控，当变化来袭的时候，能够化解之。变化其实并不可怕，怕就怕在事先没有计划。失去计划就等于失去了发现变化并解决变化的依据，那么，变化就真的成了“隐型杀手”，令你防不胜防。

　　认识到计划的重要性，就应该坚定的执行它。在计划推进的过程中，难免会有阻力，摇摆不定、甚至屈服是个大忌，计划的执行与控制没有捷径，唯有坚持到底，才能获得成功。

　　说了这么多关于计划的重要性，那么我们软件测试的计划该如何建立呢？在编写测试计划的时候我们要注意那些呢？

　　● 第一阶段的工作：编写测试计划

　　测试计划是依据项目制定的，如果没有对项目进行一个全面的细致的分析制定出来的计划也就是所谓的纸上谈兵，自然会使得我们的目标发生偏离。所以在进行编写测试计划的时候要对当前的项目情况进行一个全面的了解，身为测试组长，至少要考虑到以下几个方面：

　　a）对软件产品的理解。

　　b）对项目的特点了解。如手机项目我们前期测试的时候由于是demo版本所以覆盖的机型少，测试的工作量也就会相对比较少，一旦后期进行大批量的机型覆盖的时候，测试的工作量会呈现翻倍的趋势，所以在计划的时候我们要充分考虑该项目的特点以便在指定计划的时候更合理，更有效。

　　c）测试进度的安排。

　　d）测试的策略。针对当前的项目我们要选择更合适的策略去执行，在规定的时间内，规定的环境下实现规定的功能。由于各个方面都是有限的，采用好的测试策略可以减少测试工作量的，提高测试的执行效率，所以选择一个好的测试策略很重要。

　　e）人的安排。

　　f）测试资源。在建立计划前先进行资源调查，以确定目前可用的资源状况。（其中包括物件的资源和测试的人力资源）

　　g）风险分析。针对项目进行风险分析，要关注影响范围和重要性比较大的风险问题，因为其关系到项目的成败。同时要建立风险预防措施，以便在风险到来之前进行有效的预防和规避。

　　h）了解测试人员的技术分布情况，必要时要进行提前培训。