测试方案.docx
《测试方案.docx》由会员分享，可在线阅读，更多相关《测试方案.docx（16页珍藏版）》请在冰豆网上搜索。
测试方案
产品名称Productname
密级Confidentialitylevel
产品版本Productversion
Total7pages共7页
XXX测试方案
Preparedby
拟制
Name+ID
姓名+工号
Date
日期
yyyy-mm-dd
Reviewedby
评审人
Date
日期
yyyy-mm-dd
Approvedby
批准
Date
日期
yyyy-mm-dd
Authorizedby
签发
Date
日期
yyyy-mm-dd
（TST01T04V2.0/IPD-PTMV2.0/forinternaluseonly）
（TST01T04V2.0/IPD-PTMV2.0/仅供内部使用）
修订记录
日期
修订版本
描述
作者
目录
1概述7
1.1被测对象概述7
1.2测试方案概述8
2测试需求9
3XX部件XX特性测试设计10
3.1测试对象分析10
3.2测试设计策略分析11
3.3详细测试方法12
3.3.1xx子特性测试设计12
3.3.2xx子特性测试设计13
3.3.3xx子特性测试设计13
3.4自动化测试设计14
3.5测试规程设计14
3.6测试组网分析14
3.7测试环境分析15
3.7.1测试环境设备15
3.7.2测量仪器和仪表15
3.7.3测试器件和材料15
3.7.4测试工具15
3.7.5其它需求16
4XX特性测试设计16
5XX特性测试设计16
6XX应用XXE2E场景测试设计16
6.1测试对象分析18
6.2测试设计策略分析19
6.3E2E操作场景分析20
6.3.1如：
基于终端用户的E2E操作场景分析（请根据实际情况修改）20
6.3.2如：
基于终端用户的E2E操作场景分析（请根据实际情况修改）21
6.3.3如：
基于终端用户的E2E操作场景分析（请根据实际情况修改）21
6.4自动化测试设计21
6.5测试规程设计22
6.6测试组网分析22
6.7测试环境分析22
6.7.1测试环境设备22
6.7.2测量仪器和仪表23
6.7.3测试器件和材料23
6.7.4测试工具23
6.7.5其它需求23
7XX应用YYE2E场景测试设计24
8附录24
8.1测试用例设计列表24
××测试方案
本说明中：
蓝色字体为说明性文字，
黑色字体为测试方案文档实际写作时必需部分。
红色字体为业务与软件测试部在优化模板时增加的说明。
本测试方案可以分为多个层次，包括版本级的总体系统测试方案、特性级测试方案。
在使用本文档模板时根据要求进行相应写作。
不同阶段的测试方案，如系统测试方案、集成测试方案、单元测试方案，由于其差异性过大，不适合使用同一种测试方案文档模板。
关键词：
摘要：
缩略语清单：
对本文所用缩略语进行说明，要求提供每个缩略语的英文全名和中文解释。
参考资料清单：
请在表格中罗列本文档所引用的有关参考文献名称、作者、标题、编号、发布日期和出版单位等基本信息。
如果以下文件存在，必须在本部分说明该文档为参考文档，如果该文档不存在，则应明确说明（在多层次的测试方案中，每个低层次的测试方案都必须说明其高一级的测试方案是其参考文档）：
需求规格说明书
对应阶段的开发设计文档
对应的测试方案，用例，规程等测试文档
相关标准
涉及到的测试要素的必要说明
参考资料清单
名称
作者
编号
发布日期
查阅地点或渠道
出版单位（若不为本公司发布的文献，请填写此列）
定制说明：
本测试方案模板为业务与软件系统测试的通用模板，允许产品测试项目根据自己的需要进行适当的定制：
1、允许对章节进行细分。
对模板中已有的章节，产品可以自己扩展子章节，以约束产品测试方案需要包含的内容。
2、允许自行扩展章节。
对模板中没有的章节，产品可以自己扩展，以适应项目对测试方案的内容要求。
3、凡是章节标题以“XX”开头的，均表示可以自由增加或删减同级别、同内容的章节。
4、允许删除附录部分的“测试用例设计列表”
5、允许修改“3.6测试组网分析”章节的位置，该章节允许移动到“3.3详细测试方法”之前。
6、允许“3.1测试对象分析”、“3.6测试组网分析”章节内容出现在“XX子特性测试设计”的子章节中。
但本章节不允许删除，需要在“3.1测试对象分析”、“3.6测试组网分析”中说明具体的内容在各个子测试特性的章节中。
7、不允许删除模板中其它已有章节或修改章节顺序。
1概述
测试文档的概述建议包括两个部分，被测对象概述和测试方案概述。
被测对象概述是对“被测对象”本身情况说明，目的在于让读者对被测对象有一个基本的认识。
测试方案概述是对“测试方案”文档的说明，目的在于让读者对测试方案总体思路和文档结构有一个基本的认识。
测试方案在整个测试分析设计过程中，起到的是一个承上启下的作用，测试分析（产品测试规格分析、特性测试需求分析）的输出是测试项目，而用例的编写还需要组网方式、输入条件、输出结果、观察点、处理过程等信息；测试项目细化成用例还需要明确具体的测试点，这些就是测试方案的内容。
因此，测试方案承载的是设计思想和测试方法，用例设计和编写仍需在形成的测试规格、测试项目的基础上进行，结合测试方案中的设计思想、测试方法进行具体化。
1.1被测对象概述
被测对象概述是对“被测对象”本身情况说明，目的在于让读者对被测对象备有一个基本认识。
其内容建议包括：
（1）被测对象的历史背景；
（2）被测对象（版本/特性）的市场定位和市场应用说明；
（3）概括说明被测对象实现架构/处理流程；
（4）限制和其他特殊说明。
概述部分描述特性的背景，包括特性的主要外在功能表现，开发本特性的背景，特性主要的应用场景等。
这部分的描述主要是让阅读者尽快抓住特性的核心内容，了解对于这个特性，需要首要保证的、最基本的是哪些内容。
举例：
XX平台SOAPAdapter特性的概述：
SOAPAdapter是XX平台上，以Adapter形式存在的组件之一。
主要是为XX平台提供通用的SOAP接入能力：
XX平台外部的客户端可以通过SOAPAdapter访问XX平台内部的服务；XX平台内部的客户端也可以通过SOAPAdapter来访问XX平台外部的服务。
无论是哪个方向的服务请求，对于XX平台及其服务、外部系统都没有额外的开发量。
概述包含内容的分析：
主要外在表现：
是一个Adapter；有一个SOAP接口；能够实现XX平台内部服务和SOAP服务请求之间的转换。
背景：
XX平台产品需要一个“通用”的SOAP接入方式
主要应用场景：
和外部SOAP服务/客户端的交互。
1.2测试方案概述
测试方案概述是对“测试方案”文档的说明，目的在于让读者对测试方案总体思路和文档结构有一个基本的认识。
其内容建议包括：
（1）测试文档写作目的说明，如提供总体测试方案、提供全面特性测试方案、提供组网业务验证测试方案；
（2）测试思路概要说明，说明测试设计的主要方法和思路；
（3）测试文档内容说明，说明本测试文档的包括主要内容，文档框架；
（4）限制和其他特殊说明。
2测试需求
本节需要考虑“测试需求分析”工作的要求。
按照测试需求分析的工作流程，产品/版本需求首先经过测试分析，转化成测试需求规格，再进行测试需求规格的分解分配工作，然后按照分解分配后的测试需求规格进行对应测试方案和用例写作；其中，总体测试方案对应为整个版本的测试需求，具体特性测试方案对应分解后的相应测试需求或相应的设计需求。
如果对被测对象已完成了测试需求分析工作，本节应该描述针对产品/版本需求的测试分析转化而来的测试需求规格的跟踪关系。
如果没有进行测试需求分析工作，则本部分的测试需求按照以前文档写作方式进行，仍然为产品包/设计需求中对应部分，并建议增加下面的测试需求说明：
（1）稳定性测试需求说明；
（2）组网测试需求说明；
（3）极限测试和压力测试需求说明；
（4）实际业务验证需求说明；
下面表格可供参考:
表1XX测试的需求跟踪矩阵表
设计文档
需求编号
需求规格描述
《XX需求规格说明书》
《XX设计说明书》
列出本产品/版本/特性对应的测试规格（测试点），范围包括
1、特性的新增子特性或功能点
2、规格实现方案中影响到的已有、新增特性点
3、规格、特性之间需要组合测试的内容
4、规格和测试类型组合的内容。
这部分内容确定了针对这个产品/版本/特性的所有测试内容，后面的分析和细化都是从这里开始的。
大的测试范围上有没有遗漏，将主要是考量这部分内容。
3继承特性测试设计
结合版本情况，针对基线特性进行继承性分析，根据分析结果给出TMSS上基线用例的继承准则。
4XX特性测试设计
如果测试文档属于总体测试方案，则多个特性可以分别使用不同的“xx特性测试设计”标题进行分别说明。
如果测试文档属于特性测试方案，则在同一个“测试设计”标题下写作即可。
4.1测试对象分析
简要分析被测试对象的框架和结构，作为后面测试设计的依据。
内容可以包括：
（1）被测对象结构；
（2）被测特性处理流程；（3）和其他特性关系；（4）组网应用方式；等等。
测试对象的“外部环境”分析，包括以下内容：
1、和测试特性相关的外部（产品外部）模块，以及与每个外部模块间的连接方式；数据交换形式、协议；进行哪些数据交换
2、和测试特性相关的内部（产品内部）模块/特性，以及与每个模块/特性间的关系。
如果特性的实现需要另外的模块/特性为其准备数据；特性的功能完成后，另外的模块/特性表现将受到影响（结果验证必须通过另外的模块/特性表现进行）；特性由另外的模块/特性驱动；特性的实现需要使用其他模块/特性的功能的时候，我们认为这些“另外的模块/特性”是测试特性的相关模块/特性。
3、典型功能的实现过程中，和各外部、内部模块/特性间的信息、数据交互过程。
这部分描述的目的是：
使测试者了解为什么采用后面设计的这种测试组网，要完成本规格/特性的测试需要对哪些部分进行哪些操作，如何准备数据、如何触发功能、如何获得输出信息。
测试对象的“内部实现”分析，包括以下内容：
1、被测试特性从数据配置到功能实现的全过程实现，拉通特性实现的各个环节。
2、对于采用了成熟模块的特性，哪些部分是新开发的，哪些是成熟模块实现的。
3、功能实现中的处理过程、输出信息各遵循哪些规范
4、以下作为辅助分析：
被测试特性的关键算法。
5、主要功能实现的特性级别的流程图，或者模块/子系统时序图、交互图。
6、主要功能实现过程中对信息、数据的处理过程。
包括有哪些预置数据、输入数据、进行哪些处理、有哪些输出数据等。
7、各个输入的范围是什么，对处理的性能是否有指标要求。
这部分描述的目的是：
使测试者了解，在测试过程中用例通过与否的判断依据是什么，用例执行中有哪些观察点。
以及哪些应该重点测试，哪些不用测试。
4.2测试设计策略分析
测试策略分析重点阐述被测对象的测试用例设计原则和思路，比如采用什么样的测试用例设计方法，包括正交法、边界值法、等价类划分法等等，同时还可包括：
（1）测试重点分析；
（2）测试难点和解决方法/替代测试方案；（3）测试相关因素影响分析和对应策略，如测试环境和仪器限制，相类产品的测试经验借鉴，测试裁剪分析等。
基于前面的分析，在这里首先明确的划定测试的具体内容：
1、基本验证项是哪些。
即特性的典型功能，这些项目应该是贯穿各个相关子系统的。
2、设计思路。
测试设计的思路包括但不限于：
按照处理流程，覆盖所有分支；按照输入数据，覆盖输入数据量、数据类型及其组合；按照输出数据，覆盖输出数据量、数据类型及其组合；按照外部接口，覆盖触发条件及其组合；按照外部接口，覆盖返回值及其组合。
3、覆盖原则。
哪些子特性要全面测试；哪些子特性只做功能验证；哪些子特性要关注性能；哪些需要考虑稳定性；哪些子特性不必专门测试，只在测试其他特性是顺便验证即可；哪些子特性间需要做组合。
4、可借鉴的经验或者设计指导。
对于每一类特性、实现技术在部门内部形成测试关注点/重点的库，在具体特性的测试中借鉴。
例如WEB类有安全性测试的经验；后台程序测试设计指导；用户界面测试设计指导；网管告警、统计测试设计指导……
其次描述测试方法。
如果产品有测试解决方案的，这里可以直接引用测试解决方案中的测试方法，再加上一些特殊的说明。
测试方法的内容包括：
1、用例触发和驱动的工具、操作方法
2、观察点数据获取的工具、操作方法
3、输入数据构造和输入的工具、操作方法
4、输出数据获取的工具、操作方法
5、环境数据设置和取得的工具、操作方法。
4.3详细测试方法
对每个测试特性的子特性单独进行说明，如果该测试特性没有子特性，可以不必再分子特性描述；
建议每个测试设计包括两方面内容：
（1）测试用例的设计方法说明；
（2）测试用例的大致内容说明，比如，××特性主要采用等价类划分法进行测试用例设计，其等价类包括A、B、C，测试用例必须包括X、Y、Z功能点，它们公共的输入条件是×××，他们公共的观察点是XXX。
。
。
。
对“测试需求”中的每个测试规格分别分析。
此外如果测试方法有特殊的地方，也在这里做说明。
对于有专门测试设计指导书的特性，这里的分析可以省略，测试用例直接参考指导书进行。
对于测试用例大致内容的描述，建议分成三方面：
正常功能、功能组合、异常测试。
这里主要描述测试的目的、用例覆盖的点。
不用列出具体的用例标题。
除了输入条件、观察点，还建议说明公共的预置条件，对这个子测试测试的数据规划（包括数据库表结构、数据记录的特征、定制哪些规则等）
子特性编号规则：
测试类型.业务名称.模块名称.XXX
说明：
测试类型：
如ST代表系统测试，BBIT代表联调测试，SDV代表系统设计验证，SIT代表系统集成测试等。
部件或应用名称：
如ND/IM/CALLAS，139/VV/SMART等
模块名称：
如NDMC/NDSC
测试类型：
FUNC代表功能，PERF代表性能，DFX代表可测试性、可维护性等
用例编号后续在子特性编号后扩展形成，举例：
子特性编号：
SDV.ND.NDMC.FUNC.001
该子特性后续用例编号为：
SDV.ND.NDMC.FUNC.001.00X~00Y
注：
可任选如下两种表格方式之一：
方式一：
子特性编号
SDV.ND.NDMC.FUNC.001
正常功能测试点
根据子特性分析结果对测试点进行描述，不需要细化到用例级，但需要分析、输出需要测试的点、输入的条件以及预期的结果。
根据子特性分析结果对测试点进行描述，不需要细化到用例级，但需要分析、输出需要测试的点、输入的条件以及预期的结果。
异常功能测试点
网络异常、DB异常（如锁表）、部件网元异常等
功能组合测试点
如果有子特性间的组合测试，则需要在这里进行分析，输出组合测试点。
参数说明
控制此功能的业务级参数说明
业务表
说明此功能使用到的业务表
是否内存表
□Yes□No
可能包括多个表
□Yes□No
实现情况
□新增□修改□继承
测试类型
□功能测试□大数据量□代码Review
各测试版本可自行分析修改，性能在独立的测试规格中描述，此处可不包括
测试说明
可以针对测试情况进行说明，例如：
是否首轮不测试，
方式二：
子特性编号
SDV.ND.NDMC.FUNC.001
测试点
检查点
正常功能测试点
异常功能测试点
网络异常、DB异常（如锁表）、部件网元异常等
功能组合测试点
参数说明
控制此功能的业务级或用户级参数说明
业务表
说明此功能使用到的业务表
是否内存表
□Yes□No
可能包括多个表
□Yes□No
实现情况
□新增□修改□继承
测试类型
□功能测试□大数据量□代码Review
各测试版本可自行分析修改，性能在独立的测试规格中描述，此处可不包括
测试说明
可以针对测试情况进行说明，例如：
是否首轮不测试，
5XX特性测试设计
如果测试文档属于总体测试方案，则多个特性可以分别使用不同的“xx特性测试设计”标题进行分别说明。
如果测试文档属于特性测试方案，则在同一个“测试设计”标题下写作即可。
5.1测试对象分析
同3.1要求
5.2测试设计策略分析
同3.2要求
5.3详细测试方法
同3.3要求
方式一：
子特性编号
SDV.ND.NDMC.FUNC.001
正常功能测试点
根据子特性分析结果对测试点进行描述，不需要细化到用例级，但需要分析、输出需要测试的点、输入的条件以及预期的结果。
根据子特性分析结果对测试点进行描述，不需要细化到用例级，但需要分析、输出需要测试的点、输入的条件以及预期的结果。
异常功能测试点
网络异常、DB异常（如锁表）、部件网元异常等
功能组合测试点
如果有子特性间的组合测试，则需要在这里进行分析，输出组合测试点。
参数说明
控制此功能的业务级或用户级参数说明
业务表
说明此功能使用到的业务表
是否内存表
□Yes□No
可能包括多个表
□Yes□No
实现情况
□新增□修改□继承
测试类型
□功能测试□大数据量□代码Review
各测试版本可自行分析修改，性能在独立的测试规格中描述，此处可不包括
测试说明
可以针对测试情况进行说明，例如：
是否首轮不测试，
方式二：
子特性编号
SDV.ND.NDMC.FUNC.001
测试点
检查点
正常功能测试点
异常功能测试点
网络异常、DB异常（如锁表）、部件网元异常等
功能组合测试点
参数说明
控制此功能的业务级或用户级参数说明
业务表
说明此功能使用到的业务表
是否内存表
□Yes□No
可能包括多个表
□Yes□No
实现情况
□新增□修改□继承
测试类型
□功能测试□大数据量□代码Review
各测试版本可自行分析修改，性能在独立的测试规格中描述，此处可不包括
测试说明
可以针对测试情况进行说明，例如：
是否首轮不测试，
6网上问题反向测试设计
在特性测试设计分析完成之后，根据继承性分析策略，需要对本方案描述部件或应用进行网上问题回溯，反向设计，形成测试方案设计输入，确保基础版本网上问题在新版本中不再发生。
注：
首次版本本章节不涉及。
网上问题编号
问题简述
测试点
检查点
7自动化测试设计
对各测试子特性的自动化测试实现要素进行分析与提炼。
如果产品有测试解决方案的，这里可以直接引用测试解决方案中的自动化策略。
此外视情况补充以下内容：
1、哪些测试规格，或者哪些部分实现自动化测试
2、自动化测试的组网。
3、自动化测试工具分析选择。
选择的自动化测试工具能够全面的：
触发和驱动用例；获取观察点数据；构造和输入测试输入数据；获取输出数据；设置和取得环境数据。
4、自动化测试辅助业务/服务的框架结构、接口定义、实现描述。
5、自动化测试辅助数据的表结构设计、字段含义等。
6、自动化用例测试脚本的内容结构。
8测试规程设计
描述多个测试用例的操作序列的设计思路，例如，利用状态转移图表述多个测试用例的操作迁移。
一般我们并不希望测试用例之间有任何的关系。
测试规程设计也可以描述哪部分用例先测试，哪些后测试。
9测试组网分析
测试中的所有用到的测试组网图应放在此处，并且应该清楚描述不同的组网图分别运用于哪些测试子特性项目。
测试对象在测试组网图中的位置应符合需求规格说明书的要求。
测试组网图，组网图绘制的要素：
1、明确区分被测试部分和测试辅助部分
2、明确表现物理实体和子系统的关系
3、明确表现内部子系统之间的关系
4、明确表现被测试系统和外部模块的关系和协议
9.1测试环境分析
测试环境分析是根据本阶段的测试目标，从不同角度明确本阶段的各种测试环境因素，包括：
环境需求、被测对象特殊要求、测试工具要求、测试代码要求、测试数据要求等。
测试环境分析必须确保对测试子特性需求规格的跟踪与覆盖。
以下列出了建议应考虑的各种测试要求因素，实际的测试要求因素不限于以下几个方面，可以进行裁剪。
9.1.1测试环境设备
这部分描述测试组网中所需要的测试设备、对接设备、用户终端等，根据情况包括测试设备的单板种类和数量需求描述。
9.1.2测量仪器和仪表
确定所需测试仪器和设备的要求。
指定仪表仅需写明型号即可，非指定仪表需给出测量精度要求等。
仪表需给出足够的信息，如测试中使用AM8e，则可用如下格式表达：
功能名称生产厂家仪器型号
呼叫分析仪AmeriteAM8e
生产厂家如有缩略语，则用缩略语表示，如HP，W&G等。
如果不需要仪表，请注明“手工测试”。
9.1.3测试器件和材料
这部分描述测试组网中特殊电缆、光纤、光纤连接器材料和器件等。
9.1.4测试工具
在此处列出对于测试工具的需求，测试工具包括自主开发，商用，二次开发的测试工具等。
9.1.5其它需求
确定需要的特殊测试技能要求，其他特殊工具，确定其他任何测试需要（如，测试环境空间大小的需求等），确定对测试小组来说目前还没有但是将来测试执行时必需的需要和要求。
例如：
数据需求：
为执行各测试项目需要在测试前预先设置的数据，避免测一项改一次数据，特别是在自动化测试中，或者仪器测试中需要定义的测试套和测试数据库。
在系统测试过程中,可以明确对测试组网环境的组网数据的需求和数据设定规范，以确保环境数据的规整性，并且达到组网环境能够对实际运行环境的最大程度的仿真和条件覆盖。
10附录
任何其他本测试方案相关的附录内容。
10.1测试用例设计列表
这部分不是必须的内容，一般有专门的测试用例文档的，无需在这里附用例设计表，可删除本章节。
升级会员 