O ISO 软件开发全套文档_ _ 测试计划编写指南_ _
测试打算编写指南
版本 <1.0>
修订历史记录
日期
版本
说明
作者
<2002/9/04> <1.0> 创建 Century
名目
1.
介绍 5
1.1
文档目的 5
1.2
文档摘要 5
1.3
文档历史和变更 5
2.
背景 5
2.1
系统视图和目标 5
2.2
联系方式 6
2.3
相关信息储存的位置 6
3.
质量目标 6
4.
测试策略 6
4.1
整体策略 6
4.2
测试范畴 6
5.
测试方法 6
5.1
里程碑技术 7
5.2
测试文档〔测试用例〕 7
5.3
测试实施过程 7
5.3.1
测试系统同意条件 7
5.3.2
测试时刻表 7
5.4
稳固时期测试 8
5.4.1
稳固时期摘要 8
5.4.2
测试遍数 8
5.4.3
项目终止 8
5.5
自动测试策略 8
5.6
集成测试策略 8
5.7
内容测试 8
5.8
性能测试和压力测试 9
5.9
兼容性测试 9
6.
测试组织 9
6.1
测试团队结构 9
6.2
功能划分 9
7.
资源需求 10
7.1
培训需求 10
7.2
硬件需求 10
7.3
软件需求 10
7.4
办公空间需求 10
8.
时刻进度安排 10
9.
缺陷处理 10
9.1
数据库治理 10
9.2
缺陷处理过程 11
10.
测试过程操纵 11
10.1
缺陷数据分析 11
10.2
测试工作周报 11
11.
风险分析 11
12.
系统公布 11
测试打算编写指南
1. 介绍
测试打算编写指南有两类潜在的受众。第一，测试负责人使用它作为指导方针编写测试打算。测试打算编写完成后，将作为整个团队〔包括开发人员和测试人员〕沟通的基础。
测试项目开始时，应该完成测试打算的大部分内容。项目开始后，由于测试情形有变化，可能导致测试打算文档变化。假如文档有明显的变化，必须在文档中添加变更历史来记载这些变化。
1.1 文档目的
测试打算在策略和方法的高度说明如何打算、组织和治理测试项目。测试打算包含足够的信息使测试人员明白项目需要做什么是如何运作的。另外，清晰的文档结构能使任何一个读者在扫瞄打算的前面几页后，就能对项目有一个大致的认识。测试打算只是测试的一个框架，专门多细节需要跟开发人员或其他人员沟通，因此打算不包括测试用例的细节和系统功能的详细信息。
1.2 文档摘要
这一节要紧说明测试打算中重要的和可能有争议的问题。本节的要紧目的是将这些信息传递给那些可能可不能通读整个测试打算文档的人员〔比如经理或开发项目的负责人〕。
提示和技巧：
在写这一节时，考虑一下你的打算在那些地点可能会引起反对。那个打算跟往常的打算相比，有什么不同的地点。测试项目与系统开发打算的关系等。
使用列表的格式，能够将问题按重要程度排列出来，然后在后面的章节中再对这些问题进行详细说明，如此就能让对这些问题有重要阻碍的人员明白问题的所在。
1.3 文档历史和变更
[作者] – [日期] – [文档的当前状态，上版本以来所作的要紧变化] 2. 背景
2.1 系统视图和目标
系统视图对测试人员了解自己需要做什么是专门重要的。测试项目负责人应积极与系统设计人员或开发人员沟通，以取得相关资料。系统目标是关心实现系统视图的重要指标。系统视图和目标对实现整个项目打算来说是至关重要的。测试人员必须明白系统是做什么同时关心项目实现这种目标。在打算中包括系统视图和目标后，要确保所有的测试人员都明白项目和系统的目标。
通常情形下视图和项目打算差不多上模糊的。模糊的目标必须通过成员的努力转换成可衡量和实现的东西。没有固定的视图和目标，你将无法完成部分任务。而且，你会发觉专门难将对产品的认识向别人转述。
提示和技巧：
什么缘故视图对客户是重要的？ 你如何向客户表达这种视图？ 你将做什么来保证你是在向实现视图的方向前进? 在你回答这些问题之后，你就能够将视图转换成测试导向的目标？
2.2 联系方式
列出项目参与人员的联系方式包括 E-mail 和
。
2.3 相关信息储存的位置
测试服务器的相关信息 测试文档储存的位置 测试工具储存的位置 3. 质量目标
围绕软件质量，有几种不同的说法。第一个是质量是一种绝对的标准，对所有的系统必须等同处理。事实上，质量是相对的而且是和产品相关的概念。例如，多媒体产品的质量目标倾向于精美的表示和适当的内容，而应用系统可能倾向于易用性、健壮性和适用于不同的任务。质量目标可能是动态的。在项目进行过程中，会由于市场压力、新的机会和功能改变而重新设定质量目标。
另一种有关软件质量的说法是，定义和衡量系统质量是测试部门一个部门的事。实际上，建立质量标准是所有职能部门共同努力的结果。测试、开发、系统使用部门、用户教育、系统支撑必须为建立和爱护系统的质量标准做出自己的奉献。每个部门必须对自己最了解的部分做出相应的质量定义。例如，测试和开发部门对系统质量的衡量标准要紧是健壮性和正确性。
用户部门可能对易用性方面比较熟悉。
最后，质量不仅是衡量系统的功能或性能是否正常。对系统来说，在开发过程中尽早建立全面的质量标准与系统的及时公布是一样重要的。质量目标是一个强有力的工具，应该在系统开发过程中尽早建立。一个定义准确的质量目标在以后的产品开发过程中关心决策。例如，系统是否能够正式发行？在代码完成后，应该修复那些缺陷？在系统完成后那种类型的测试是最合适的。
4. 测试 策略
4.1 整体策略
本节的目的是说明打算中使用的差不多的测试过程。
提示和技巧：
是否使用里程碑技术和在测试过程中验证每个模块？或者是什么都不做，只是一般的测试而已。
测试人员是否在项目开发初期就开始工作？或者测试人员只在系统开发完后，才开始测试。
4.2 测试范畴
测试部门可能对应该做什么测试觉得专门困惑。本节试图对这些问题做一些规定。通常说明什么是要测试的，什么是不要测试的是专门重要的。明确规定这些问题后，测试人员对该做什么有一个清晰的认识。
提示和技巧：
需要专门测试那些部分？ 那些部分不需要测试，什么缘故？ 测试人员是否需要测试内容以及相关部分？ 是否要验证每个模块的稳固性？ 5. 测试方法
下面几节将说明测试打算的核心部分。假如将项目比做游戏，这些内容将是攻关秘籍。它们提供在整个测试过程中，每一个步骤的详细说明。每一节会就测试的不同方面做详细的说明。这一部分的要紧读者是测试人员，因为打算要紧是为了规定如何进行测试。
5.1 里程碑技术
里程碑技术将项目的运行分成不同的时期，在项目过程中提供检查工作进展状态的方法。即使只有一个里程碑，也要在那个地点说明。在说明中，要列出通过和连续往下走的标准。
1. 打算时期 2. 开发时期 3. 稳固时期
5.2 测试文档〔测试用例〕
测试用例需要列出完全测试一个功能模块所需的详细步骤。使用测试用例的要紧目的是幸免完成了所需的测试内容而不仅仅是走过场。
提示和技巧：
通常能够定义测试用例模板，如此每个测试用例都有同样的格式。就像测试用例的格式一样，能够用不同的方法来编写测试用例。这些方法的要紧区别是用例的详细程度。在极端的情形下，用例的每一步都详细列出，如此的话，能保证运行测试用例的人员在做同样的情况，而且容易实现自动执行。但关于用例编写人员来说，意味着庞大的工作量，他必须考虑每一个步骤。当功能发生变化时，爱护如此的测试用例是专门困难的。
另一种极端的情形是专门概要的测试用例。这些用例是专门宽泛的，只提供简洁的描述说明需要做什么。让测试人员决定如何实现，以及使用那些数据来测试。大多数的专业测试人员赞同于一个折中的方案，并倾向于提供较为详细的步骤。
5.3 测试实施过程
本节的目的说明在测试过程中测试部门在同意测试系统时应执行什么检查。这一节有助于其他部门〔开发部门、用户教育部门〕了解在公布测试系统时应做些什么。保持测试系统相对稳固是专门重要的。
5.3.1 测试系统同意条件 本节的目的说明在测试过程中测试部门在同意测试系统时应执行什么检查。
提示和技巧：
谁负责建立测试系统，如何保持测试系统和开发系统之间的同步。
在开发人员提交新程序时，如何检查代码的质量。
开发部门是否需要运行简单的用例，验证系统是否正常，假如验证失败，需要采取什么行动。
需要做什么测试验证测试系统是稳固的。
同步的间隔时刻。
当项目进展到不同时期时，是否需要更新这些规那么。
5.3.2 测试时刻表 在系统的不同时期，需要打算在什么时候应得到什么样的测试系统。
提示和技巧：
测试系统多长时刻更新一次〔每日，每周一次或多次，在什么时刻，预备好代码〕？ 当项目进展到不同时期时，是否需要更新这些规那么。
5.4 稳固时期测试
5.4.1 稳固时期摘要 在代码完成到系统最后发行之前为系统稳固时期。在系统稳固时期需要对系统的各个部分进行最后的检查。能够建立一个检查重点列表，逐项进行检查。
5.4.2 测试遍数 在稳固化测试时期至少要运行一遍完整的测试和一个简短的测试。前者用于发觉错误，后者用于验证发行版本。
5.4.3 项目终止 在系统投入使用的时候，最后应作的测试安排。
5.5 自动测试策略
在测试过程中，能够适当考虑使用自动测试策略。自动测试不是保证产品质量的万能药，不能保证发觉软件的缺陷。自动测试有它的长处和短处，要充分考虑系统特性、时刻安排、测试人员的编程体会和能够使用的自动化工具。
使用自动化技术要紧目的是发觉系统缺陷，提高测试用例的运行效率和对系统进行快速检测。测试自动化跟系统本身的特性相关，假如系统要紧是数值运算，能够对结果进行简单判定，使用自动化技术的效率就高，否那么系统要紧是跟内容相关，自动化测试的效率就比较低。
提示和技巧：
自动化的目标是什么。
你如何衡量这些目标。
在测试中，是否实行代码覆盖，分支覆盖和功能覆盖。
哪些部分能够自动化？自动化程度有多高。
使用什么自动化工具？是否开发新的自动化工具？ 5.6 集成测试策略
集成测试有两个范畴。一个是系统内部各个功能模块的交互作用，各种可能的组合是专门多的，表现为系统有丰富多彩的表现。另外一种集成是测试系统与相关系统的集成。
提示和技巧：
用户关心内容在何时如何与系统功能交互作用？如何样测试？ 典型的用户情形是什么？ 有哪些可能的逻辑组合？ 类似功能的逻辑是否一致？ 是否有相同的界面？ 菜单命令是否一致？ 5.7 内容测试
关于系统来说，总有些内容部分需要测试，例如关心等。关于网站来说，文字说明也是相当重要的。内容测试的第一步确实是将内容部分标识出来，再确定谁来实施测试。
提示和技巧
假如内容只是一些关心文件，用户教育部门会编写和验证这些内容。假如系统是以内容为主的，拥有上百万的文字、千个链接以及不计其数的图片，在这种情形下需要使用由编辑、校对和测试人员组成
的小组来负责内容测试。
与内容提供者确定〝什么是内容的缺陷〞。幸免显现模糊的问题，比如〝读起来有点问题〞或者〝太文绉绉〞。
哪些内容需要测试。
如何将内容测试与其他工作分开。
是否使用自动测试〔比如超链接测试〕。
假如使用自动测试，区分那些内容无法使用自动测试，哪些部分能够保证能自动测试。
5.8 性能测试和压力测试
在性能测试中，执行不同的测试，并进行记时，然后将这些数据与往常的数据进行对比。现在的系统多是 C/S 架构或 B/S 架构，需要测试系统对多个用户的并发响应能力，一样情形下能够使用软件在一台机器上模拟几千个客户端进行压力测试来衡量这些指标。
提示和要点：
系统和竞争对手的系统相比有多快。这可能是一个质量指标，比如〝比竞争对手 X 快〞。
与往常的系统进行相比。比如〝在增加新功能后是否跟往常一样快甚至更快些。〞 假如没有可比性，能够使用合理速度来进行衡量，但这种数据必须经确认。
需要衡量哪些性能，能够在测试打算中，指定重点领域，在实际测试过程中，在进行具体确定。
是否有行业标准可在测试中使用。
在什么时候执行性能测试？假如需要进行代码优化，需要尽早进行性能测试，如此代码修改带来的负面阻碍比较小。
性能测试是否跟硬件平台相关。需要确定在何种硬件平台下进行性能测试。
在性能测试中，有几个指标需要注意，如 CPU 使用率内存使用率以及磁盘吞吐率等，如此能确定系统的瓶颈在哪。是否能进行优化。
5.9 兼容性测试
关于 C/S 架构的系统来说，需要考虑客户端支持的系统平台。关于 B/S 架构的系统来说需要考虑用户端扫瞄器的版本。
提示和技巧：
确定主流的客户端扫瞄器版本。
决定支持哪些版本的扫瞄器。
在什么平台上做开发和测试，在那些平台上进行兼容性测试。
6. 测试组织
6.1 测试团队结构
这一节说明测试团队的结构和项目测试人员的数量。
提示和技巧
查看开发打算确定那些功能需要最多资源。
确定需要多少测试人员。
多少人做自动测试，是哪些人。
6.2 功能划分
这一节说明系统能够分成那些模块，分别由谁负责。
提示和技巧：
系统的那些常用功能需要测试。
是不是需要测试系统的所有功能。
是不是需要与开发部门在功能方面对应一致。
7. 资源需求
7.1 培训需求
本节说明项目测试人员需要哪些培训。
提示和技巧：
关于新手需要先介绍测试系统，假如测试人员比较熟悉该系统，那么需要说明新系统的功能。
是否进行自动测试。...