软件测试的步骤之软件测试计划
软件项目的测试计划是描述测试目的、范围、方法和软件测试的重点等的文档。对于验证软件产品的可接受程度编写测试计划文档是一种有用的方式。详细地测试计划可以帮助测试项目组之外的人了解为什么和怎样验证产品。它非常有用但是测试项目组之外的人却很少去读它。软件测试计划作为软件项目计划的子计划，在项目启动初期是必须规划的。在越来越多公司的软件开发中，软件质量日益受到重视，测试过程也从一个相对独立的步骤越来越紧密嵌套在软件整个生命周期中，这样，如何规划整个项目周期的测试工作；如何将测试工作上升到测试管理的高度都依赖于测试计划的制定。测试计划因此也成为测试工作的赖于展开的基础。《ANSI/IEEE软件测试文档标准829-1983》将测试计划定义为：“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。”软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
目标
当今任何商业软件都包含了丰富的功能，因此，软件测试的内容千头万绪，如何在纷乱的测试内容之间提炼测试的目标，是制定软件测试计划时首先需要明确的问题。测试目标必须是明确的，可以量化和度量的，而不是模棱两可的宏观描述。另外，测试目标应该相对集中，避免罗列出一系列目标，从而轻重不分或平均用力。根据对用户需求文档和设计规格文档的分析，确定被测软件的质量要求和测试需要达到的目标。编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确。
作用
一个好的测试计划可以起到如下作用：
1、避免测试的“事件驱动”；
2、使测试工作和整个开发工作融合起来；
3、资源和变更事先作为一个可控制的风险。
要求
软件项目的测试计划是描述测试目的、范围、方法和软件测试的重点等的文档。对于验证软件产品的可接受程度编写测试计划文档是一种有用的方式。详细地测试计划可以帮助测试项目组之外的人了解为什么和怎样验证产品。它非常有用但是测试项目组之外的人却很少去读它。
依据特定的项目，在一个测试计划中可能包括下面项目：
1、标题；
2、软件标识，包括版本/发布版本号；
3、目录；
4、文档的目的和阅读人群；
5、测试的对象；
6、软件产品概述；
7、相关文档列表，例如需求规格、设计文档和其它测试计划等；
8、有关的标准和法规；
9、可追溯的需求；
10、有关的命名约定和标识约定；
11、软件项目的相关的所有部门和成员/联系信息/职责；
12、测试项目组和人员/联系信息/职责；
13、假设和依赖；
14、项目风险分析；
15、测试优先级和重点；
16、范围和测试限制；
17、测试描述－根据测试类型、特征、功能、过程、系统、模块等分类；
18、输入等价类分类描述、边界值分析、错误分类；
19、测试环境－软、硬件、操作系统、其它需要的软件、数据配置、与其它系统的接口；
20、测试环境有效性分析－测试环境的不同和产品系统对测试有效性的影响；
21、测试环境建立和配置问题；
22、软件移植性考虑；
23、软件配置管理过程；
24、测试数据建立需求；
25、系统日志描述/错误日志/其它的能力和工具，例如屏幕捕获工具、这对于描述bug和报告bug 是很有用的；
26、讨论任何测试人员用来发现bug或跟踪bug的硬件、软件工具；
27、测试自动化－采用的理由和描述；
28、采用的测试工具、包括版本、补丁等；
29、测试脚本/测试代码维护过程和版本控制；
30、跟踪和解决－工具和步骤 31、用于项目的测试度量标准；
32、报告需求和测试交付产品；
33、软件入口和出口标准；
34、初期确定的测试周期和标准；
35、测试暂停和重启标准；
36、人员分配；
37、人员岗前培训；
38、测试地点/场所；
39、测试项目组之外可用的资源和他们的作用、职责、交付、联系人和协调等问题；
40、与所有权相关的级别、分类、安全和许可问题；
41、公开的一些问题。
具体要求
编写软件测试计划要避免一种不良倾向是测试计划的“大而全”，无所不包，篇幅冗长，长篇大论，重点不突出，既浪费写作时间，也浪费测试人员的阅读时间。“大而全”的一个常见表现就是测试计划文档包含详细的测试技术指标、测试步骤和测试用例。最好的方法是把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。测试资源的变更是源自测试组内部的风险而非开发组风险，当测试资源不足或者冲突，测试部门不可能安排如此多的人手和足够时间参与测试时，在测试计划中的控制方法与测试时间不足相类似。没有测试经理愿意承担资源不足的测试工作，只能说公司本身是否具备以质量为主的体系或者项目经理对产品质量的重视程度如何决定了对测试资源投入的大小，最终产品质量取决因素不仅仅在于测试经理。为了排除这种风险，除了象时间不足、测试计划变更时那样缩减测试规模等等方法以外，测试经理必须在人力资源和测试环境一栏标出明确需要保证的资源，否则，必须将这个问题作为风险记录。
5W规则
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。为了使“5W”规则更具体化，需要准确理解被测软件的功能特征、应用行业的知识和软件测试技术，在需要测试的内容里面突出关键部分，可以列出关键及风险内容、属性、场景或者测试技术。对测试过程的阶段划分、文档管理、缺陷管理、进度管理给出切实可行的方法。
就通常软件项目而言，基本上采用“瀑布型”开发方式，这种开发方式下，各个项目主要活动比较清晰，易于操作。整个项目生命周期为“需求－设计－编码－测试－发布－实施－维护”。然而，在制定测试计划时候，有些测试经理对测试的阶段划分还不是十分明晰，经常性遇到的问题是把测试单纯理解成系统测试，或者把把各类型测试设计（测试用例的编写和测试数据准备）全部放入生命周期的“测试阶段”，这样造成的问题是浪费了开发阶段可以并行的项目日程，另一方面造成测试不足。
相应阶段可以同步进行相应的测试计划编制，而测试设计也可以结合在开发过程中实现并行，测试的实施即执行测试的活动即可连贯在开发之后。值得注意的是：单元测试和集成测试往往由开发人员承担，因此这部分的阶段划分可能会安排在开发计划而不是测试计划中。
评审更新机制
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。测试计划包含多方面的内容，编写人员可能受自身测试经验和对软件需求的理解所限，而且软件开发是一个渐进的过程，所以最初创建的测试计划可能是不完善的、需要更新的。需要采取相应的评审机制对测试计划的完整性、正确性、可行性进行评估。例如，在创建完测试计划后，提交到由项目经理、开发经理、测试经理、市场经理等组成的评审委员会审阅，根据审阅意见和建议进行修正和更新。测试计划改变了已往根据任务进行测试的方式，因此，为使测试计划得到贯彻和落实，测试组人员必须及时跟踪软件开发的过程，对产品提交测试做准备，测试计划的目的，本身就是强调按规划的测试战略进行测试，淘汰以往以任务为主的临时性。在这种情况下，测试计划中强调对变更的控制显得尤为重要。
计划变更
变更来源于以下几个方面：
1、项目计划的变更；
2、需求的变更；
3、测试产品版本的变更；
4、测试资源的变更。
测试风险
测试阶段的风险主要是对上述变更所造成的不确定性，有效的应对这些变更就能降低风险发生的几率。要想计划本身不成为空谈和空白无用的纸质文档，对不确定因素的预见和事先防范必须做到心中有数。对于项目计划的变更，除了测试人员及时跟进项目以外，项目经理必须认识到测试组也是项目成员，因此必须把这些变更信息及时通知到项目组，使得整个项目得到顺延。项目计划变更一般涉及都是日程变更，令人遗憾的是，往往为了进度的原因，交付期限是既定的，项目经理不得不减少测试的时间，这样，执行测试的时间就被压缩了。在这种情况下，测试经理常常固执的认为进度缩减的唯一的方法就是向上级通报并主观认为产品质量一定会下降，这种做法和想法不一定是正确的。
目标
当今任何商业软件都包含了丰富的功能，因此，软件测试的内容千头万绪，如何在纷乱的测试内容之间提炼测试的目标，是制定软件测试计划时首先需要明确的问题。测试目标必须是明确的，可以量化和度量的，而不是模棱两可的宏观描述。另外，测试目标应该相对集中，避免罗列出一系列目标，从而轻重不分或平均用力。根据对用户需求文档和设计规格文档的分析，确定被测软件的质量要求和测试需要达到的目标。编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确。
作用
一个好的测试计划可以起到如下作用：
1、避免测试的“事件驱动”；
2、使测试工作和整个开发工作融合起来；
3、资源和变更事先作为一个可控制的风险。
要求
软件项目的测试计划是描述测试目的、范围、方法和软件测试的重点等的文档。对于验证软件产品的可接受程度编写测试计划文档是一种有用的方式。详细地测试计划可以帮助测试项目组之外的人了解为什么和怎样验证产品。它非常有用但是测试项目组之外的人却很少去读它。
依据特定的项目，在一个测试计划中可能包括下面项目：
1、标题；
2、软件标识，包括版本/发布版本号；
3、目录；
4、文档的目的和阅读人群；
5、测试的对象；
6、软件产品概述；
7、相关文档列表，例如需求规格、设计文档和其它测试计划等；
8、有关的标准和法规；
9、可追溯的需求；
10、有关的命名约定和标识约定；
11、软件项目的相关的所有部门和成员/联系信息/职责；
12、测试项目组和人员/联系信息/职责；
13、假设和依赖；
14、项目风险分析；
15、测试优先级和重点；
16、范围和测试限制；
17、测试描述－根据测试类型、特征、功能、过程、系统、模块等分类；
18、输入等价类分类描述、边界值分析、错误分类；
19、测试环境－软、硬件、操作系统、其它需要的软件、数据配置、与其它系统的接口；
20、测试环境有效性分析－测试环境的不同和产品系统对测试有效性的影响；
21、测试环境建立和配置问题；
22、软件移植性考虑；
23、软件配置管理过程；
24、测试数据建立需求；
25、系统日志描述/错误日志/其它的能力和工具，例如屏幕捕获工具、这对于描述bug和报告bug 是很有用的；
26、讨论任何测试人员用来发现bug或跟踪bug的硬件、软件工具；
27、测试自动化－采用的理由和描述；
28、采用的测试工具、包括版本、补丁等；
29、测试脚本/测试代码维护过程和版本控制；
30、跟踪和解决－工具和步骤 31、用于项目的测试度量标准；
32、报告需求和测试交付产品；
33、软件入口和出口标准；
34、初期确定的测试周期和标准；
35、测试暂停和重启标准；
36、人员分配；
37、人员岗前培训；
38、测试地点/场所；
39、测试项目组之外可用的资源和他们的作用、职责、交付、联系人和协调等问题；
40、与所有权相关的级别、分类、安全和许可问题；
41、公开的一些问题。
具体要求
编写软件测试计划要避免一种不良倾向是测试计划的“大而全”，无所不包，篇幅冗长，长篇大论，重点不突出，既浪费写作时间，也浪费测试人员的阅读时间。“大而全”的一个常见表现就是测试计划文档包含详细的测试技术指标、测试步骤和测试用例。最好的方法是把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。测试资源的变更是源自测试组内部的风险而非开发组风险，当测试资源不足或者冲突，测试部门不可能安排如此多的人手和足够时间参与测试时，在测试计划中的控制方法与测试时间不足相类似。没有测试经理愿意承担资源不足的测试工作，只能说公司本身是否具备以质量为主的体系或者项目经理对产品质量的重视程度如何决定了对测试资源投入的大小，最终产品质量取决因素不仅仅在于测试经理。为了排除这种风险，除了象时间不足、测试计划变更时那样缩减测试规模等等方法以外，测试经理必须在人力资源和测试环境一栏标出明确需要保证的资源，否则，必须将这个问题作为风险记录。
5W规则
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。为了使“5W”规则更具体化，需要准确理解被测软件的功能特征、应用行业的知识和软件测试技术，在需要测试的内容里面突出关键部分，可以列出关键及风险内容、属性、场景或者测试技术。对测试过程的阶段划分、文档管理、缺陷管理、进度管理给出切实可行的方法。
就通常软件项目而言，基本上采用“瀑布型”开发方式，这种开发方式下，各个项目主要活动比较清晰，易于操作。整个项目生命周期为“需求－设计－编码－测试－发布－实施－维护”。然而，在制定测试计划时候，有些测试经理对测试的阶段划分还不是十分明晰，经常性遇到的问题是把测试单纯理解成系统测试，或者把把各类型测试设计（测试用例的编写和测试数据准备）全部放入生命周期的“测试阶段”，这样造成的问题是浪费了开发阶段可以并行的项目日程，另一方面造成测试不足。
相应阶段可以同步进行相应的测试计划编制，而测试设计也可以结合在开发过程中实现并行，测试的实施即执行测试的活动即可连贯在开发之后。值得注意的是：单元测试和集成测试往往由开发人员承担，因此这部分的阶段划分可能会安排在开发计划而不是测试计划中。
评审更新机制
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。测试计划包含多方面的内容，编写人员可能受自身测试经验和对软件需求的理解所限，而且软件开发是一个渐进的过程，所以最初创建的测试计划可能是不完善的、需要更新的。需要采取相应的评审机制对测试计划的完整性、正确性、可行性进行评估。例如，在创建完测试计划后，提交到由项目经理、开发经理、测试经理、市场经理等组成的评审委员会审阅，根据审阅意见和建议进行修正和更新。测试计划改变了已往根据任务进行测试的方式，因此，为使测试计划得到贯彻和落实，测试组人员必须及时跟踪软件开发的过程，对产品提交测试做准备，测试计划的目的，本身就是强调按规划的测试战略进行测试，淘汰以往以任务为主的临时性。在这种情况下，测试计划中强调对变更的控制显得尤为重要。
计划变更
变更来源于以下几个方面：
1、项目计划的变更；
2、需求的变更；
3、测试产品版本的变更；
4、测试资源的变更。
测试风险
测试阶段的风险主要是对上述变更所造成的不确定性，有效的应对这些变更就能降低风险发生的几率。要想计划本身不成为空谈和空白无用的纸质文档，对不确定因素的预见和事先防范必须做到心中有数。对于项目计划的变更，除了测试人员及时跟进项目以外，项目经理必须认识到测试组也是项目成员，因此必须把这些变更信息及时通知到项目组，使得整个项目得到顺延。项目计划变更一般涉及都是日程变更，令人遗憾的是，往往为了进度的原因，交付期限是既定的，项目经理不得不减少测试的时间，这样，执行测试的时间就被压缩了。在这种情况下，测试经理常常固执的认为进度缩减的唯一的方法就是向上级通报并主观认为产品质量一定会下降，这种做法和想法不一定是正确的。