发布时间 : 星期日 文章ISO软件开发文档模板_测试计划编写指南_软件测试面试必备更新完毕开始阅读
用心、精心、决心、匠心
测试计划编写指南
1.
介绍
测试计划编写指南有两类潜在的受众。首先，测试负责人使用它作为指导方针编写测试计划。测试计划编写完成后，将作为整个团队（包括开发人员和测试人员）沟通的基础。
测试项目开始时，应该完成测试计划的大部分内容。项目开始后，由于测试情况有变化，可能导致测试计划文档变化。如果文档有明显的变化，必须在文档中添加变更历史来记载这些变化。
1.1
文档目的
测试计划在策略和方法的高度说明如何计划、组织和管理测试项目。测试计划包含足够的信息使测试人员明白项目需要做什么是如何运作的。另外，清晰的文档结构能使任何一个读者在浏览计划的前面几页后，就能对项目有一个大概的认识。测试计划只是测试的一个框架，很多细节需要跟开发人员或其他人员沟通，因此计划不包括测试用例的细节和系统功能的详细信息。
1.2
文档摘要
这一节主要说明测试计划中重要的和可能有争议的问题。本节的主要目的是将这些信息传递给那些可能不会通读整个测试计划文档的人员（比如经理或开发项目的负责人）。 提示和技巧：
在写这一节时，考虑一下你的计划在那些地方可能会引起反对。这个计划跟以前的计划相比，有什么不同的地方。测试项目与系统开发计划的关系等。 使用列表的格式，可以将问题按重要程度罗列出来，然后在后面的章节中再对这些问题进行详细说明，这样就能让对这些问题有重要影响的人员知道问题的所在。
1.3
文档历史和变更
[作者] – [日期] – [文档的当前状态，上版本以来所作的主要变化]
2. 2.1
背景
系统视图和目标
系统视图对测试人员了解自己需要做什么是非常重要的。测试项目负责人应积极与系统设计人员或开发人员沟通，以取得相关资料。系统目标是帮助实现系统视图的
呕心沥血整理word5
用心、精心、决心、匠心
重要指标。系统视图和目标对实现整个项目计划来说是至关重要的。测试人员必须知道系统是做什么并且帮助项目实现这种目标。在计划中包括系统视图和目标后，要确保所有的测试人员都知道项目和系统的目标。
通常情况下视图和项目计划都是模糊的。模糊的目标必须通过成员的努力转换成可衡量和实现的东西。没有固定的视图和目标，你将无法完成部分任务。而且，你会发现很难将对产品的认识向别人转述。 提示和技巧：
2.2
为什么视图对客户是重要的？ 你如何向客户表达这种视图？
你将做什么来保证你是在向实现视图的方向前进?
在你回答这些问题之后，你就可以将视图转换成测试导向的目标？
联系方式
列出项目参与人员的联系方式包括 E-mail 和电话。
2.3 3.
相关信息保存的位置 测试服务器的相关信息 测试文档保存的位置 测试工具保存的位置
质量目标
围绕软件质量，有几种不同的说法。第一个是质量是一种绝对的标准，对所有的系统必须等同处理。事实上，质量是相对的而且是和产品相关的概念。例如，多媒体产品的质量目标倾向于精美的表示和适当的内容，而应用系统可能倾向于易用性、健壮性和适用于不同的任务。质量目标可能是动态的。在项目进行过程中，会由于市场压力、新的机会和功能改变而重新设定质量目标。
另一种有关软件质量的说法是，定义和衡量系统质量是测试部门一个部门的事。实际上，建立质量标准是所有职能部门共同努力的结果。测试、开发、系统使用部门、用户教育、系统支撑必须为建立和维护系统的质量标准做出自己的贡献。每个部门必须对自己最了解的部分做出相应的质量定义。例如，测试和开发部门对系统质量的衡量标准主要是健壮性和正确性。 用户部门可能对易用性方面比较熟悉。
最后，质量不仅是衡量系统的功能或性能是否正常。对系统来说，在开发过程中尽早建立全面的质量标准与系统的及时发布是一样重要的。质量目标是一个强有力的
呕心沥血整理word6
用心、精心、决心、匠心
工具，应该在系统开发过程中尽早建立。一个定义准确的质量目标在以后的产品开发过程中帮助决策。例如，系统是否能够正式发行？在代码完成后，应该修复那些缺陷？在系统完成后那种类型的测试是最合适的。
4. 4.1
测试策略 整体策略
本节的目的是说明计划中使用的基本的测试过程。 提示和技巧：
是否使用里程碑技术和在测试过程中验证每个模块？或者是什么都不做，只是普通的测试而已。
测试人员是否在项目开发初期就开始工作？或者测试人员只在系统开发完后，才开始测试。
测试范围
4.2
测试部门可能对应该做什么测试觉得很迷惑。本节试图对这些问题做一些规定。通常说明什么是要测试的，什么是不要测试的是非常重要的。明确规定这些问题后，测试人员对该做什么有一个清晰的认识。 提示和技巧：
5.
需要特别测试那些部分？
那些部分不需要测试，为什么？
测试人员是否需要测试内容以及相关部分？ 是否要验证每个模块的稳定性？
测试方法
下面几节将说明测试计划的核心部分。如果将项目比做游戏，这些内容将是攻关秘籍。它们提供在整个测试过程中，每一个步骤的详细说明。每一节会就测试的不同方面做详细的说明。这一部分的主要读者是测试人员，因为计划主要是为了规定如何进行测试。
5.1
里程碑技术
里程碑技术将项目的运行分成不同的阶段，在项目过程中提供检查工作进展状态的方法。即使只有一个里程碑，也要在这里说明。在说明中，要列出通过和继续往下走的标准。 1. 计划阶段
呕心沥血整理word7
用心、精心、决心、匠心
2. 开发阶段 3. 稳定阶段
5.2
测试文档（测试用例）
测试用例需要列出彻底测试一个功能模块所需的详细步骤。使用测试用例的主要目的是避免完成了所需的测试内容而不仅仅是走过场。 提示和技巧：
通常可以定义测试用例模板，这样每个测试用例都有同样的格式。就像测试用例的格式一样，可以用不同的办法来编写测试用例。这些方法的主要区别是用例的详细程度。在极端的情况下，用例的每一步都详细列出，这样的话，能保证运行测试用例的人员在做同样的事情，而且容易实现自动执行。但对于用例编写人员来说，意味着庞大的工作量，他必须考虑每一个步骤。当功能发生变化时，维护这样的测试用例是非常困难的。
另一种极端的情况是非常概要的测试用例。这些用例是非常宽泛的，只提供简洁的描述说明需要做什么。让测试人员决定如何实现，以及使用那些数据来测试。大多数的专业测试人员赞同于一个折中的方案，并倾向于提供较为详细的步骤。
5.3
测试实施过程
本节的目的说明在测试过程中测试部门在接受测试系统时应执行什么检查。这一节有助于其他部门（开发部门、用户教育部门）了解在发布测试系统时应做些什么。保持测试系统相对稳定是非常重要的。
5.3.1
测试系统接受条件
本节的目的说明在测试过程中测试部门在接受测试系统时应执行什么检查。 提示和技巧：
谁负责建立测试系统，如何保持测试系统和开发系统之间的同步。 在开发人员提交新程序时，如何检查代码的质量。
开发部门是否需要运行简单的用例，验证系统是否正常，如果验证失败，需要采取什么行动。
需要做什么测试验证测试系统是稳定的。 同步的间隔时间。
当项目进展到不同阶段时，是否需要更新这些规则。
呕心沥血整理word8