一个好的测试策略应根据各个测试阶段需要包含的各种测试类型(如是否需要、安装测试等)，分析各类测试的重点及难点，结合系统的特点、功能的优先级及难易程度，确定每个类型的测试目标、方法、完成标准及特殊事项。此外，测试策略中要体现测试所需的时间。

　　四、测试计划的变更

　　应对测试计划制定完成后，常见的问题是测试计划本身出现变更，使其变更的原因有项目需求、版本以及测试资源的变更等。有的变更是计划内的，例如需求、版本的变更；有的变更是计划外的，例如硬件设备的延期到货等等。这些变更不仅会影响到测试过程的正常进行，而且，如若处理不当，会造成极大的人力、物力和时间浪费。因此，在测试计划中要充分考虑对各种变更的控制。

　　1．项目计划的变更

　　项目计划的变更一般所涉及都是日程变更。当项目计划出现变更时，由于软件产品的交付期是既定的，因而不得不采取一些有效的方法，压缩执行测试的时间。为了应对此变更，在确保测试质量的前提下，适当地调整测试计划的测试策略和范围是一种主要方法。调整的目的是重新确定不重要的测试部分，调换测试的次序和减少测试规模，力求在限定时间内做重要部分的测试。为弥补其不足，可以把忽略部分的测试内容留给确认测试或现场测试。此外，其他的应对办法包括：减少进入测试的阻力，例如降低测试计划中系统测试准入准则；分步提交测试，例如改成迭代方式增量测试；减少回归测试的要求，例如开发人员实时修改，在测试计划中对缺陷修复响应时间和过程进行约定；缺陷进行局部回归而不是重新全部测试等。

　　2．需求的变更

　　项目进行过程中不可避免的是需求的变更。在制定测试计划时，如果项目需求处于动态变化中，则需要在测试用例章节进行说明。在实际工作中，测试用例和测试数据往往没有进行区分，因而当需求发生变化时，设计的数据作废了。因此，对于一个需求动态的项目，必须在计划中对因需求变更而造成的测试方式的变化加以说明。可采用用例和数据分离、流程和界面分离的设计方式，待需求确定后，再细化测试设计；此外，好制定一个变更周期的约定，定义变更的大频度和重新测试的界限。测试计划从一定程度上能够降低不可预期的需求变化造成的投入损失。

　　3．产品版本的变更

　　对于测试产品版本的变更，除了部分是由于需求变更而造成的外，修改缺陷引发的问题应在章节中增加测试产品版本更新管理的章节，在此章节明确更新周期和暂停测试的原则。例如，小版本的产品更新不能多于每天三次，一个相对大的版本其变更不能每周多于1次，紧急发布产品于何种类型的修改或变更，由谁负责统一维护和同步更新测试环境等。测试计划通常制定了准人和准出准则，但还应考虑测试暂停的情况，例如产品错误发布或者服务器数据更新。暂停时如果测试经理不进行跟踪，可能发生测试组等待测试而没人通知继续测试的情况，造成测试资源的浪费。因此，增加更新周期和暂停测试原则是很有必要的。

　　4．测试资源的变更

　　测试资源的变更是测试组内部测试资源不足或者与其他测试项目的测试时间冲突时，测试部门不能安排更多的人力和足够时间参与测试。在测试计划中的控制方法与测试日程变更相类似。为了排除这种风险，除缩减测试规模等方法以外，需要保证的资源还必须在测试计划中人力资源和测试环境一栏明确，否则，必须将这个问题作为风险记录。

　　五、结束语

　　通过对以上内容的分析，能更加清晰地认识制定测试计划的目的、依据和内容；并结合实际测试经验，总结了制定测试计划的方法；明确了导致测试计划变更的主要原因和应对办法。尽管测试的每一个步骤都是独立的，但测试计划起到了搭建测试框架结构的作用。专业的测试活动必须以一个好的测试计划作为基础，因此，测试计划作为测试活动的起始步骤和重要环节，应得到相关部门和人员的重视。