软件测试计划的制定及常见问题的分析
传统的软件开发模型认为：软件测试是软件生命周期后期的一项阶段性任务¨j。随着人们对软件质量的日益重视，软件测试的地位也变得越来越重要，测试过程也从一个相对独立的步骤转变为紧密嵌套在软件开发整个周期中的重要过程。软件测试计划，作为软件项目计划的子计划，必须在项目启动初期进行规划，它是指导软件测试开展的重要前提。在实际测试计划规划过程中，常常会遇到一些问题，例如：为什么一定要制定测试计划?测试计划的依据有哪些?测试计划的关键内容有哪些?测试计划出现变更怎么办?等等，这些问题都直接地影响着测试计划的制定，从而影响到整个测试工作的顺利完成。
一、制定测试计划的目的
很多人认为软件测试是写好测试用例，然后逐条地执行，发现缺陷才是测试的目的。制定测试计划既浪费了时间也看不到成效，为什么一定要制定测试计划呢?测试计划是软件测试中重要的步骤之一，在软件开发的前期对软件测试做出清晰、完整的计划，不仅对整个测试起到关键性的作用，而且，对开发人员的开发工作、整个项目的规划和项目经理的审查都有辅助性作用。
制定测试计划的目的，主要是明确测试背景、测试目的、风险分析、所需资源、任务安排和进度等。即将需求和总体设计分解成可测试、应该测试、推迟测试和无法测试等范围，对每个范围制定测试的策略和方法，制定发布程序和停止测试的标准，确定测试风险，准备测试所需要的环境和资源，制定测试进度和任务安排等。因此，测试计划是对整个测试过程的组织、资源、原则等的规定和约束，是指导整个测试过程的导航灯。
二、制定测试计划的依据
测试计划的制定通常以软件开发计划和需求规格说明书为重要依据l2J。软件开发计划是软件项目的总体规划，可从中对项目的开发背景、条件和限制，以及产品的开发进度和接口、运行平台和应用领域、主要的功能模块和特点等有所了解。从而明确测试背景和测试目的、所需的资源和进度安排等。需求规格说明书更加详细地介绍了系统所有需要实现的业务l生能、接口及其他特f生的要求。因此，在制定测试计划前，应充分熟悉开发计划和需求规格说明书，完整地提取测试计划所需的信息，为制定测试计划作充分的准备。
三、测试计划的内容
在得到项目开发计划和需求规格说明书后，通常会参照测试计划模板，开始具体制定测试计划。一般而言，在测试计划中应该清晰地描述测试状态判定标准、项目开发信息和测试任务细节等。
1．测试状态判定标准
在测试计划中，有的内容不具有项目特性。即不论是何项目，该部分内容变化不大，其主要内容为测试开始／完成／延迟／继续等测试状态的判定标准。一般一个企业有一个统一的标准。例如：当致命缺陷数或严重缺陷数达到一定值的时候，无论是什么情况，该版本都应返回研发。再如：终止测试发布程序的标准均为执行完所有测试用例、缺陷完全修改、无遗留缺陷。当然，判定标准也不是始终一成不变的，当遇到特殊项目(如规定紧急发布产品)时，测试延迟或终止的标准会有变动。
2．项目开发信息
测试计划中，还有一些内容是因具体的项目开发计划而明确的内容，主要包括测试目标、项目概述、术语、参考资料以及测试阶段进度等，这些内容在测试计划中不需要也不可以作变动。
3．测试任务细节
在实际制定测试计划时，需要重点规划的是测试范围和测试方法策略。
(1)测试范围在测试范围中，需要明确具体测试的项目、性能测试点及指标、测试项目的优先级等J。这需要列出所有要测试的功能项，凡是没有出现在这个清单里的功能项都被排除在测试范围之外。此外，还有界面测试，如对于一些用户界面、菜单的结构、窗体的设计是否合理等；从软件系统整体性考虑，要确保数据流在软件运行中从一个模块流到另一个模块过程的正确性。
(2)测试策略测试策略是针对每一个测试项目所制定的测试重点和标准，考虑其受模块、整体结构、系统结构、版本、性能、配置和安装等因素的影响，如何公正、客观地开展测试的方法。同时还要考虑到安装的其他软件对正在测试的软件会造成的影响；一些外界环境的影响，也需要对软件进行一些特殊的测试；过去测试中经常出现的问题等。为对产品可靠性测试中异常断电及恢复功能制定的测试策略。
一个好的测试策略应根据各个测试阶段需要包含的各种测试类型(如是否需要、安装测试等)，分析各类测试的重点及难点，结合系统的特点、功能的优先级及难易程度，确定每个类型的测试目标、方法、完成标准及特殊事项。此外，测试策略中要体现测试所需的时间。
四、测试计划的变更
应对测试计划制定完成后，常见的问题是测试计划本身出现变更，使其变更的原因有项目需求、版本以及测试资源的变更等。有的变更是计划内的，例如需求、版本的变更；有的变更是计划外的，例如硬件设备的延期到货等等。这些变更不仅会影响到测试过程的正常进行，而且，如若处理不当，会造成极大的人力、物力和时间浪费。因此，在测试计划中要充分考虑对各种变更的控制。
1．项目计划的变更
项目计划的变更一般所涉及都是日程变更。当项目计划出现变更时，由于软件产品的交付期是既定的，因而不得不采取一些有效的方法，压缩执行测试的时间。为了应对此变更，在确保测试质量的前提下，适当地调整测试计划的测试策略和范围是一种主要方法。调整的目的是重新确定不重要的测试部分，调换测试的次序和减少测试规模，力求在限定时间内做重要部分的测试。为弥补其不足，可以把忽略部分的测试内容留给确认测试或现场测试。此外，其他的应对办法包括：减少进入测试的阻力，例如降低测试计划中系统测试准入准则；分步提交测试，例如改成迭代方式增量测试；减少回归测试的要求，例如开发人员实时修改，在测试计划中对缺陷修复响应时间和过程进行约定；缺陷进行局部回归而不是重新全部测试等。
2．需求的变更
项目进行过程中不可避免的是需求的变更。在制定测试计划时，如果项目需求处于动态变化中，则需要在测试用例章节进行说明。在实际工作中，测试用例和测试数据往往没有进行区分，因而当需求发生变化时，设计的数据作废了。因此，对于一个需求动态的项目，必须在计划中对因需求变更而造成的测试方式的变化加以说明。可采用用例和数据分离、流程和界面分离的设计方式，待需求确定后，再细化测试设计；此外，好制定一个变更周期的约定，定义变更的大频度和重新测试的界限。测试计划从一定程度上能够降低不可预期的需求变化造成的投入损失。
3．产品版本的变更
对于测试产品版本的变更，除了部分是由于需求变更而造成的外，修改缺陷引发的问题应在章节中增加测试产品版本更新管理的章节，在此章节明确更新周期和暂停测试的原则。例如，小版本的产品更新不能多于每天三次，一个相对大的版本其变更不能每周多于1次，紧急发布产品于何种类型的修改或变更，由谁负责统一维护和同步更新测试环境等。测试计划通常制定了准人和准出准则，但还应考虑测试暂停的情况，例如产品错误发布或者服务器数据更新。暂停时如果测试经理不进行跟踪，可能发生测试组等待测试而没人通知继续测试的情况，造成测试资源的浪费。因此，增加更新周期和暂停测试原则是很有必要的。
4．测试资源的变更
测试资源的变更是测试组内部测试资源不足或者与其他测试项目的测试时间冲突时，测试部门不能安排更多的人力和足够时间参与测试。在测试计划中的控制方法与测试日程变更相类似。为了排除这种风险，除缩减测试规模等方法以外，需要保证的资源还必须在测试计划中人力资源和测试环境一栏明确，否则，必须将这个问题作为风险记录。
五、结束语
通过对以上内容的分析，能更加清晰地认识制定测试计划的目的、依据和内容；并结合实际测试经验，总结了制定测试计划的方法；明确了导致测试计划变更的主要原因和应对办法。尽管测试的每一个步骤都是独立的，但测试计划起到了搭建测试框架结构的作用。专业的测试活动必须以一个好的测试计划作为基础，因此，测试计划作为测试活动的起始步骤和重要环节，应得到相关部门和人员的重视。
