经常听到有人发出“计划没有变化大”、“计划赶不上变化”之类的感慨，说这话的人肯定是没有做过计划或者是没有认真的做过计划的同志。计划和变化本来就是相辅相成的，没有计划，变化从何谈起！有变化则恰恰证明了计划的重要性。
在软件项目过程中，为什么有的项目做的井井有条、按部就班、忙而不乱，而有的项目却是一团乱麻、主次不分、经常需要“救火”，到头来，有的项目能够分期分批的交付工作成果，最终实现工作目标，而有的项目却迟迟交不出东西，或者，交出的产品质量严重不符，与项目目标相去甚远。当然，这是两个极端，更为常见的则是项目存在不同程度的延期、超支和质量上不去的问题。为什么会造成这样的结果呢？有人说是项目管理的问题，没错，但究其根源，则是项目计划出了问题！
军队中常说的一句话就是“一切行动听指挥”，用在项目上，可以演变为“一切活动看计划”。项目计划就是所有项目活动的指南，重视计划、推进计划，才能使项目始终沿着既定的轨道运转，也只有这样，才能最终实现项目目标。计划不一定非得做的美观漂亮、规范严谨，关键是计划的实际可操作性，否则，再完美的计划也将形同摆设，毫无用处。制订计划是项目过程中首要的工作，计划的成功制订意味着项目已经成功了一半。因此，对于那些拿来工作就急着做、没有计划性的项目是不应被提倡的。对于规模很小的项目来说，这种“敏捷”的做法也许会取得成功，但始终是昙花一现，几乎没有参考价值。项目不管大小，哪怕只有一个人，也要制定计划，不同规模的项目，计划的规模也会不同，但只要切合实际的去进行计划，后面的工作就不至于是无根之水，放任自流了。
通过实际项目的经验表明，进度计划、质量计划、风险计划、测试计划、配置管理计划以及沟通计划是项目计划中比较重要、对实际工作也比较有指导意义的几个子计划。其中，进度计划是所有计划的基础，它确定了项目的时间范围，它让你知道在哪个时间应该完成哪项工作；质量计划则告诉你这项工作是否已经完成，是否满足要求；风险计划将会告诉你完成这项工作可能出现的障碍，应如何解决；测试计划将会告诉你如何循序渐进的发现工作中存在的漏洞，是否可以交工；配置管理计划将会为你列举一下这项工作将由哪些部分组成，哪些是关键的，哪些是可变的；沟通计划将告诉你在做这项工作的过程中你要跟哪些对象共事，应如何跟他们协调一致。
当然，计划也不是一蹴而就的，任何人也没有料事如神的本事，它是一个由宏观到微观、由粗到细逐渐分解逐渐细化的过程。开始，它可能只会告诉你要做哪几件事（里程碑），后来逐渐告诉你每件事有哪些活动（目标分解），然后再告诉你每项活动应该怎么去做（具体工作流程）。执行计划的过程就象是拆锦囊，每到一个路口，就拆开一个锦囊，里面告诉你如何往下走。
前面提到了好的计划就等于项目成功了一半，那么另一半是什么呢？是控制。控制就是对计划的执行情况进行监控，当变化来袭的时候，能够化解之。变化其实并不可怕，怕就怕在事先没有计划。失去计划就等于失去了发现变化并解决变化的依据，那么，变化就真的成了“隐型杀手”，令你防不胜防。
认识到计划的重要性，就应该坚定的执行它。在计划推进的过程中，难免会有阻力，摇摆不定、甚至屈服是个大忌，计划的执行与控制没有捷径，唯有坚持到底，才能获得成功。
说了这么多关于计划的重要性，那么我们软件测试的计划该如何建立呢？在编写测试计划的时候我们要注意那些呢？
Ø 第一阶段的工作：编写测试计划
测试计划是依据项目制定的，如果没有对项目进行一个全面的细致的分析制定出来的计划也就是所谓的纸上谈兵，自然会使得我们的目标发生偏离。所以在进行编写测试计划的时候要对当前的项目情况进行一个全面的了解，身为测试组长，至少要考虑到以下几个方面：
a) 对软件产品的理解。
b) 对项目的特点了解。如手机项目我们前期测试的时候由于是demo版本所以覆盖的机型少，测试的工作量也就会相对比较少，一旦后期进行大批量的机型覆盖的时候，测试的工作量会呈现翻倍的趋势，所以在计划的时候我们要充分考虑该项目的特点以便在指定计划的时候更合理，更有效。
c) 测试进度的安排。
d) 测试的策略。针对当前的项目我们要选择更合适的策略去执行，在规定的时间内，规定的环境下实现规定的功能。由于各个方面都是有限的，采用好的测试策略可以减少测试工作量的，提高测试的执行效率，所以选择一个好的测试策略很重要。
e) 人的安排。
f) 测试资源。在建立计划前先进行资源调查，以确定目前可用的资源状况。（其中包括物件的资源和测试的人力资源）
g) 风险分析。针对项目进行风险分析，要关注影响范围和重要性比较大的风险问题，因为其关系到项目的成败。同时要建立风险预防措施，以便在风险到来之前进行有效的预防和规避。
h) 了解测试人员的技术分布情况，必要时要进行提前培训。
下面我们来细说一下关于测试计划制定的时候需要考虑的这6个问题：
Ø 对软件产品的理解。
我们要测试什么，产品有哪些功能要求以及非功能性要求，这些肯定是要弄清楚的。
a) 对于新开发的项目因为需求有可能不是完整的，所以这个时候对于需求的理解要去了解类似的项目或者产品进行借鉴，借鉴的目的是增加产品的全面性理解。
b) 对于历史版本，我们要完全依赖与我们的经验和总结。
c) 对于没有涉及过的产品，我们只能从最简单的需求或以用户为导向来进行了解。没有该类型产品经验只能去发现问题再寻求解决办法。
Ø 测试进度的安排
从现实情况来看，测试的进度是软件研发进度的一部分，所以一般在研发进度的大框架确定以后再去制定测试的进度的。在研发的进度框架内，关于测试的进度安排往往都是很粗糙的。所以，我们还需要进行细化。在考虑测试进度安排的时候，下列因素都是我们需要考虑的：
a) 软件系统将要实现的功能有哪些？
b) 软件产品的规模
c) 软件产品的复杂程度。
d) 客户对软件产品的要求的严格性。
e) 人员的技术水平以及分布状况。
f) 产品需要支持的平台。
g) 是否存在潜在的其他隐藏要求。
Ø 测试策略
所谓的测试策略就是我们在进行测试的时候采用什么方式去做。我们主要可以从以下几个方面进行入手：
a) 是做手工测试还是自动化测试？如果做自动化测试需要什么条件，有什么样的安排？
b) 是做黑盒测试还是白盒测试。如果做白盒测试需要什么条件，有什么样的安排？
c) 需求做性能测试吗？需要怎么样的准备？
d) 需要做安全性测试吗？如何做？需要做什么准备。
e) 对国际化测试是否存在要求？
f) 对运行的平台和硬件是否有要求？
Ø 对人员的安排
a) 人力资源是否具备满足测试的能力。
b) 给合适的人安排合适的事情。
c) 对产品和技术比较了解。
d) 能够保持高效持续性的工作状态。尽量不会存在巨大变动，包括长期请假，婚嫁，产假等。
e) 工作安排有不同，要鼓励能力和经验稍微差一些的同事多学习。
f) 适当的给技术和学习能力比较好的员工可以进行自我挑战的工作。
Ø 测试环境
a) 测试环境要独立不能在开发的环境下进行测试。
b) 要尽量模拟与用户的实际使用环境接近的环境。如果环境差距太大，测试的成果将不准确，也就会存在偏差。
c) 无毒的干净的环境，非必要的情况下尽量不使用公网进行挂载。网速，病毒，组网结构等都会对测试的结果和进度产生很大的影响。
d) 一轮测试结束后一定要重新部署新环境，切记使用覆盖更新。以避免因为更新不完成造成测试结果不准确。
Ø 风险分析
所谓的风险分析，就是我们自己揣测，在以后的产品测试过程中，可能会遇到的问题是什么，存在哪些困难。一旦发现存在某种风险的时候，最好在制定测试计划的时候将其列出来进行讨。有的时候风险没有具体的措施去应对，列出来就当作是给自己提个醒。例如
a) 软件产品中什么模块容易出现质量问题，如何应对？
b) 在这样的测试安排下，可能会出出现什么样的问题？
c) 在测试团队形成的过程中会出现什么样的问题？
d) 在测试环境搭建方面会出现什么样的问题？
e) 测试资源方面是否存在问题？
f) 测试工作的质量方面，可能会遇到什么样的问题？
g) 性能测试和安全性测试方面有什么样的难度,可能会遇到什么样的问题？
h) 如果需求频繁变化，我们应当如何应对？
i) 如果团队不稳定中途有人离职，如何应对？
Ø 第二阶段的工作：测试计划评审。
大部分的人在设计计划以后往往都觉得是自己深思熟虑的，但是个人的理解总会有局限性，希望经过评审得到反馈以实现改进的目的。测试计划是项目研发计划的一部分，多多少少会与开发组，公司管理层存在一定的关系，以免测试在执行的时候遇到很大的阻力。
Ø 准备评审会
a) 确定参加会议的项目干系人。一般需要开发组长，资深开发工程师，项目经理，部门经理和产品经理等。
b) 准备幻灯片。把测试计划中主要的部分摘出来做成幻灯片。
c) 确定会议室。
d) 提前发通知。
e) 准备好讨论的问题，抛出问题。
