功能测试需求及案例设计指南.docx
《功能测试需求及案例设计指南.docx》由会员分享，可在线阅读，更多相关《功能测试需求及案例设计指南.docx（45页珍藏版）》请在冰豆网上搜索。
功能测试需求及案例设计指南
功能测试需求及案例设计指南
上海浦东发展银行
总行信息科技总部测试中心
2012年8月
第1章概述3
1.1目的3
1.2试用范围3
1.3定义3
1.4相关定义之间的关系4
第2章测试需求分析4
2.1测试需求分析概述4
2.1.1测试需求4
2.1.2测试需求分析的必要性5
2.1.3测试需求分析内容5
2.1.4测试需求分析与需求分析的区别5
2.2测试需求分析过程6
2.2.1测试需求采集7
2.2.2测试需求分析8
2.2.3测试需求分析点8
2.2.4测试需求列表建立11
2.2.5测试需求评审12
第3章测试案例设计13
3.1测试案例概述13
3.2测试案例要素13
3.3测试案例设计要点14
3.3.1界面测试14
3.3.2边界值测试18
3.3.3错误控制测试22
3.3.4关联测试27
3.3.5业务逻辑测试31
3.4测试案例设计技术33
第4章测试场景设计34
4.1场景简述34
4.2测试场景分析34
4.3测试场景组织34
4.4设计实例36
第5章其他说明38
第1章概述
1.1目的
为提高功能测试工作质量和效率，提升相关人员在测试需求及案例上的设计技能，特制定《功能测试需求及案例设计指南》。
本文主要介绍在银行业务系统测试过程中，就测试需求及案例进行设计与编写的思路、过程及方法，用于指导相关测试人员更好地开展该阶段的测试工作。
1.2试用范围
本指南适用于在总分行开展的各类功能测试项目中，参与测试需求或测试案例设计、编写的测试人员查阅参考，其中包括单元、集成、系统或UAT测试人员。
1.3定义
1）软件需求：
主要指用户为解决某个问题、或为实现某一目标、要求软件必须满足的条件或能力，包括业务需求、功能需求及非功能需求。
●业务需求：
反映了用户对系统较高层次的目标要求，描述了用户希望产品必须要完成的任务。
●功能需求：
定义了开发人员必须实现的软件功能，包括处理流程、使用场景、业务规则、模型算法、控制逻辑等，使得用户能完成实际操作，从而满足业务需求。
●非功能需求：
是作为对功能需求的补充，它描述了系统展现给用户的行为和执行的操作等。
包括产品必须遵从的标准、规范和合约、性能要求、设计或实现的约束条件及质量属性。
2）功能点：
组成功能模块的一个细化的、特定的测试对象，例如：
交易中的一个输入域、业务交易中一个校验规则、报表中的一个指标算法等。
3）测试需求：
以用户需求为基础，站在第三方测试的角度明确待测系统中需要测试的内容。
4）测试案例：
测试案例是为特定目标或特定条件而设计的一组输入值、执行条件和预期结果。
它是可以独立进行测试执行的最小单元，是执行具体测试的一个操作指导。
1.4相关定义之间的关系
软件需求与功能点、功能点与测试需求、测试需求与案例都是一对多的关系。
软件需求是基础，功能点是软件需求的分解产物，测试需求是对功能点进行剖析后形成的测试基础，测试案例则是对测试需求的操作细化。
图1-软件需求、功能点、测试需求、测试案例关系图
第2章测试需求分析
2.1测试需求分析概述
2.1.1测试需求
测试需求主要解决“测什么”的问题，即指明被测系统中有哪些功能点需要测试。
测试需求的主要来源是系统的需求规格说明书，有些无法从需求文档中获得的需求，可通过系统的概要设计或者详细设计文档获得。
测试人员依据对软件需求的细化分解来编写测试需求，以覆盖全部已定义的业务流程。
同时，测试需求也是设计测试用例的依据，好的测试需求能发现需求中显性和隐性的测试点，从而能更好的指导测试用例的设计，提高被测系统整体功能的覆盖率。
2.1.2测试需求分析的必要性
在做一个测试项目之前，首先必须了解测试规模、复杂程度及可能存在的风险，这些都需要通过详细的测试需求来了解。
测试需求不明确，只会造成获取的信息不正确，无法对所测系统有一个全面清晰的认识。
由此可见，进行测试需求分析是十分必要的，一方面，测试需求分析可以把不直观的需求，转变为直观的需求。
对测试范围、功能点对应的所有处理分支和待测试的业务场景进行度量，明确把握测试规模。
另一方面，可以把不明确的需求变成明确的需求，明确其功能点对应的输入、处理和输出。
2.1.3测试需求分析内容
为了有效的获取测试对象，需要从测试需求分析开始，测试需求分析可分为以下三部分内容：
1）明确需求的测试范围，即确定需求中包括了多少功能点。
2）明确功能的业务处理过程，对每一个功能点的输入、处理逻辑和输出进行提取。
3）根据用户需求，明确其在特定场景下实际使用时的流程及操作步骤，以明确测试场景。
2.1.4测试需求分析与需求分析的区别
内容
需求分析
测试需求分析
目标
对实现软件功能作全面的描述；
为开发人员提供开发依据；
解决“测什么”的问题，指明被测系统中有哪些功能点需要测试。
对象
《业务需求说明书》
1）《系统需求规格说明书》
2）《系统详细设计说明书》
分析方法
1）结构化分析法
2）Jackson分析法
3）面向对象的分析法
1）模块分解法
2）WBS分析法
分析过程
1）提出业务需求
2）分析业务需求
3）整理和描述软件需求
4）评审软件需求
1）采集测试需求采集
2）分析测试需求分析
3）建立测试需求列表
4）评审测试需求
分析产物
《系统需求规格说明书》
《测试需求分析清单》
2.2测试需求分析过程
测试需求分析是从软件需求规格说明书出发，对用户需求进行提取和采集，并整理出功能点列表清单，然后逐一对功能点列表清单中的功能点进行分析形成测试需求列表。
最后对测试需求组织评审，根据评审结果对其进行确认、修改和调整。
其分析流程可见下图所示：
图2-测试需求分析流程图
说明：
功能点列表原则上应随系统需求规格书等项目文档一起由项目组提供，只有在项目文档未说明及项目组不提供的情况下方由测试人员进行梳理，但需提交项目组确认。
2.2.1测试需求采集
测试需求的采集过程是将软件需求中的具有可测性的需求或特征提取出来，并通过列表形式对软件需求进行梳理，形成功能列表清单，列表的内容包括功能模块、功能点编号和功能点描述。
在提取软件需求的过程中，可能存在重复和冗余，所以在梳理过程中，可以通过删除、细化及合并的方式对整理的功能列表清单进行调整。
功能点列表清单列表示例如下：
功能模块
功能点编号
功能点描述
由若干个功能点构成的测试对象，能够实现一个完整功能。
按一定规范对功能点进行编号
组成功能模块内的一个具体的、细化的测试对象，根据使用软件需求的简述作为功能点描述。
说明：
1）为均衡功能点粒度，对于复杂度高、且有大功能模块的项目，功能模块的划分应按一定的层级展开，即在原有功能模块的基础上再进行2-3层的细化。
2）编号规则：
在进行测试需求及案例的设计过程中，需要对功能点、测试需求及测试案例进行编号，以上3块内容的编号均采用顺序编号。
现对以上3项制定编号规则如下：
功能点：
FXXX
测试需求：
RXXX-XXX（其中RXXX-XXX加粗部分的编号为对应的功能点编号）
测试案例：
TXXX-XXX-XXX（其中TXXX-XXX-XXX加粗部分为对应的测试需求编号）
例1：
银保通系统（软件需求）
功能模块
功能点编号
功能点描述
保险公司信息维护
保险公司新增
F001
组织保险公司新增数据，存入保险公司基本信息表。
“操作柜员”和“更新时间”不需要填写，页面自动带入。
相同保险公司信息只能存在一条记录。
新增成功后，显示“保险公司增加成功”；新增失败时，停留当前页面，修改输入项后，可以继续提交新增交易。
2.2.2测试需求分析
测试需求分析过程是对功能点列表中列出的每一条功能需求细化和分解的过程，以形成可测试的分层描述的测试要点的过程。
对功能需求进行细化和分解的分析过程包括：
1）通过分析每条功能需求描述中的输入、输出、处理、限制与约束等，给出对应的验证内容。
2）通过分析各个功能模块之间的业务顺序，以及各个功能模块之间对传递的信息和数据存在的功能交互，给出对应的验证内容。
3）经过分解获得的测试需求必须能够充分覆盖软件需求的各种特征，且每个需求都可以进行单独测试，以保证测试需求的完整性。
4）每个测试需求能够使用数量相当的测试用例来实现，即尽量保证测试案例的粒度是均匀的。
2.2.3测试需求分析点
根据以往测试需求分析工作的经验累积，发现在进行测试需求时通常可以从以下5个分析点开展测试需求分析工作，其对应的分析粒度亦可参考以下列表中的描述：
测试需求分析点
测试需求分析粒度
界面展示
界面设计合理、内容显示正确性、操作便捷性
输入域测试
•字段类型：
数字/字符等
•字段长度
•字典值
•边界值测试
•输入域的可输入性：
必输/可输
•输入域间的关联控制
•其他特殊要求
约束条件
•数据约束
•条件约束
业务处理逻辑
1）根据功能点的处理逻辑进行分解，将其对应的所有处理分支逐一进行分析与描述，并罗列为：
•业务处理逻辑1-XXXX
•业务处理逻辑2-XXXX
•…………
2）对于类似与第三方的连接超时、队列机制问题等非功能性的处理逻辑，应将其异常响应情况进行分析与描述，并罗列为：
•非功能性异常处理逻辑1-XXXX
•非功能性异常处理逻辑2-XXXX
•…………
输出结果校验
根据输入数据，对每一个业务处理逻辑的输出结果进行正确性校验。
可以简单罗列为：
•输出结果校验-业务处理逻辑1
•输出结果校验-业务处理逻辑2
•…………
●例1：
银保通系统
功能点描述
测试需求编号
测试需求名称
测试需求描述
组织保险公司新增数据，存入保险公司基本信息表。
“操作柜员”和“更新时间”不需要填写，页面自动带入。
相同保险公司信息只能存在一条记录。
新增成功后，显示“保险公司增加成功”；新增失败时，停留当前页面，修改输入项后，可以继续提交新增交易。
R001-001
界面展示
检查界面的排列、布局符合用户使用习惯，及显示内容正确。
R001-002
输入域测试-数据长度
检查每个输入字段的数据长度是否符合输入接口的要求。
字段明细如下：
级别S1
交易方式S1
中文名称S20
中文简称S20
地址S20
邮编S6
法人代表姓名S20
公司电话S20
公司传真S20
公司主页S20
公司E-mailS20
保险总公司S4
英文名称S20
总部所在城市S20
R001-003
输入域测试-数据类型
检查每个输入字段的数据类型是否符合输入接口的要求。
（描述同上，此处略。
）
R001-004
输入域测试-字典值
检查每个输入字段的字典值是否符合输入接口的要求。
（描述同上，此处略。
）
R001-005
输入域测试-可输入性
检查每个输入字段的可输入性是否符合输入接口的要求。
（描述同上，此处略。
）
R001-006
输入域测试-边界值
对每个输入字段的输入数据进行边界值验证。
（描述同上，此处略。
）
R001-007
输入域测试-联动控制
检查“操作柜员”和“更新时间”是否页面自动带入，不需要填写。
R001-008
业务处理逻辑校验1-新增已有信息
检查相同保险公司信息是否只能存在一条记录。
R001-009
业务处理逻辑校验2-新增成功
输入符合接口要求的各字段信息后点击“新增”保存，检查保存是否成功，且提示“保险公司增加成功”。
R001-010
业务处理逻辑校验3-新增失败
输入不符合接口要求的各字段信息后点击“新增”保存，检查保存是否失败。
R001-011
业务处理逻辑校验4-新增失败后修改
新增失败后，是否停留当前页面，修改输入项后，是否可以继续提交新增交易。
R001-012
输出结果校验-新增成功/失败
新增成功后，可以在“保险公司信息浏览”中查询到记录。
新增失败后，无法在“保险公司信息浏览”中查询到记录。
●例2：
业务集中系统
功能点描述
测试需求编号
测试需求名称
测试需求描述
电汇凭证发起系统内汇兑凭证号合法性校验
R001-001
业务逻辑处理1-凭证号不一致
电汇凭证发起系统内汇兑：
1）凭证号校验不通过，进差错岗，选择正确值记账成功
2）凭证号校验不通过，进差错岗，选择错误值记账失败
3）凭证号校验不通过，进差错岗，选择退回前台，前台取消流程
4）凭证号校验不通过，进差错岗，选择重新录入，差错授权岗不通过，返差错退回前台取消流程
5）凭证号校验不通过，进差错岗，选择重新录入，差错授权岗不通过，返差错退回前台取消流程
6）凭证号校验不通过，进差错岗，选择重新录入，差错授权岗不通过，返差错再次录入正确值，授权通过记账成功
R001-002
业务逻辑处理2-付款人账号不一致
电汇凭证发起系统内汇兑：
1）付款人账号校验不通过，进差错岗，选择正确值记账成功
2）付款账号校验不通过，进差错岗，选择错误值并退前台取消流程
3）付款人账号校验不通过，进差错岗，选择退回前台，前台取消流程
4）付款人账号校验不通过，进差错岗，选择重新录入，差错授权通过，记账成功
5）付款人账号校验不通过，进差错岗，选择重新录入，差错授权不通过，返差错退回前台取消流程
6）付款人账号校验不通过，进差错岗，选择重新录入，差错授权不通过，返差错再次录入正确值授权通过记账成功
R001-003
业务逻辑处理3-支密不一致
电汇凭证发起系统内汇兑“
1）支付密码校验不通过，进复核岗，选择正确值，记账成功。
2）支付密码校验不通过，进复核岗，选择错误值，记账失败。
3）支付密码校验不通过，进复核岗，选择影像模糊，退回前台，前台取消流程。
4）支付密码校验不通过，进一次复核岗，选择重新录入正确值，二次复核选择一次复核录入值，记账成功。
2.2.4测试需求列表建立
测试需求列表为软件需求与测试需求的对应关系表。
建立测试需求列表是为了将上述经分析、确定的功能需求、测试需求进行汇总并对其进行统一管理及维护。
测试需求列表格式如下：
软件需求
测试需求
功能点编号
功能点描述
测试需求编号
测试需求名称
测试需求描述
F001
组织保险公司新增数据，存入保险公司基本信息表。
“操作柜员”和“更新时间”不需要填写，页面自动带入。
相同保险公司信息只能存在一条记录。
新增成功后，显示“保险公司增加成功”；新增失败时，停留当前页面，修改输入项后，可以继续提交新增交易。
R001-001
界面展示
检查界面的排列、布局符合用户使用习惯，及显示内容正确。
R001-002
输入域测试-数据长度
检查每个输入字段的数据长度是否符合输入接口的要求。
R001-003
输入域测试-数据类型
检查每个输入字段的数据类型是否符合输入接口的要求。
R001-004
输入域测试-数据字典
检查每个输入字段的字典值是否符合输入接口的要求。
R001-005
输入域测试-可输入性
检查每个输入字段的可输入性是否符合输入接口的要求。
R001-006
输入域测试-联动控制
检查“操作柜员”和“更新时间”是否页面自动带入，不需要填写。
R001-007
输入域测试-边界值
对每个输入字段的输入数据进行边界值验证。
R001-008
业务处理逻辑校验1-新增已有信息
检查相同保险公司信息是否只能存在一条记录。
R001-009
业务处理逻辑校验2-新增成功
输入符合接口要求的各字段信息后点击“新增”保存，检查保存是否成功，且提示“保险公司增加成功”。
R001-010
业务处理逻辑校验3-新增失败
输入不符合接口要求的各字段信息后点击“新增”保存，检查保存是否失败。
R001-011
业务处理逻辑校验4-新增失败后修改
新增失败后，是否停留当前页面，修改输入项后，是否可以继续提交新增交易。
R001-012
输出结果校验-新增成功/失败
新增成功后，可以在“保险公司信息浏览”中查询到记录。
新增失败后，无法在“保险公司信息浏览”中查询到记录。
测试需求列表是需要不断维护的。
一方面，在功能需求发生变化，就要对测试需求列表进行更新，将其中与功能需求变更相关的内容进行同步变更。
另一方面，随着测试工作的进行，需不断添加新的跟踪内容，对其进行扩展。
例如，测试案例设计阶段的测试案例、测试执行阶段的测试结果记录和测试缺陷都可以添加到测试需求列表中。
2.2.5测试需求评审
在测试需求分析完成后，应组织需求方、开发方和测试方进行测试需求的评审工作。
应分别从测试需求的完整性、准确性角度出发，对测试需求列表中的各项内容进行逐一评审，评审时的关注点如下：
1）重点关注功能逻辑、数据定义、接口定义、系统约束等方面的正确性。
2）关注是否覆盖需求分析人员遗漏的、系统隐含的需求；
3）关注各测试需求之间是否存在歧义和矛盾；
4）关注各测试需求描述的详尽程度是否可以作为测试用例设计的依据；
5）关注所描述的测试需求内容是否能够得到三方的一致理解。
第3章测试案例设计
3.1测试案例概述
测试需求主要是整理测试点，包括界面、输入域、业务处理流程、结果校验等，为测试用例的设计提供测试所需的功能点信息。
所以，测试需求是告诉测试人员要测什么，而测试用例是告诉测试人员怎么测，它应包括测试步骤、预期结果、测试数据等。
根据测试案例的性质划分，测试案例可以划分为正案例和反案例。
●正案例：
是指按系统功能正常运行的测试用例，即验证系统是否能完成它应该完成的操作。
正案例的设计主要依据系统需求规格说明书，详细设计文档等。
●反案例：
则是相对正案例而言的，就指设计异常的测试用例，即验证系统是否对不该完成的操作做出正确控制。
反案例的设计主要依赖于测试人员的逆向思维能力及测试经验。
例1：
数字型输入域的长度测试。
功能描述：
银保直联系统在新增保险公司时需输入6位“邮编”信息。
正案例：
输入邮编“200001”。
反案例：
输入邮编“2000010”。
例2：
字段必输性测试。
功能描述：
银保直联系统在新增保险公司时“保险总公司”为必输项。
正案例：
输入正确的保险总公司信息。
反案例：
保险总公司信息输入为空。
3.2测试案例要素
根据2011年测试中心发布的《上海浦东发展银行信息科技总部功能测试管理规程》中的“测试案例的管理方法”已明确，为规范功能测试工作和便于功能测试集中案例库的建立和管理，功能测试案例需包含以下关键要素：
案例要素
要点描述
系统名称
描述被测系统的名称
功能模块
由若干个功能点构成的测试对象，能够实现一个完整功能，例如：
某一个业务报表功能、某一个业务交易等等
功能点
组成功能模块的一个细化的、特定的测试对象，例如：
交易中的一个输入域、业务交易中一个校验规则、报表中的一个指标算法等。
测试需求编号
每个测试需求需根据一定编号规则进行编号。
测试需求名称
描述测试需求行所验证的测试内容。
测试需求描述
针对测试需求的测试内容进行描述。
案例编号
每个案例需根据一定编号规则进行编号。
测试案例名称
描述案例执行所验证的测试点。
案例描述
针对案例的测试内容进行描述。
测试步骤
详细描述测试案例的前后步骤，便于测试执行人员操作。
案例性质
描述案例为正案例还是反案例。
预期结果
描述案例的预期执行结果
测试数据
描述执行该案例所需用到的测试数据，包括账号、金额等。
案例编写人
描述案例编写人员的名称，便于追溯。
3.3测试案例设计要点
设计测试案例的主要是为了寻求系统设计、功能设计的弱点。
所以，为保证测试案例覆盖度，功能测试应从界面测试、边界值测试、关联测试、错误控制测试、业务逻辑测试、安装测试等测试要点出发开展测试案例设计工作。
3.3.1界面测试
3.3.1.1简述
界面是软件与用户最直接交互的对象，界面的优良直接决定了用户对软件的第一印象。
设计良好的界面能够很好的引导用户完成相应的操作，起到向导的作用，同时也能给用户带来良好的用户体验。
相反，如果界面设计杂乱无章，会让用户产生抵触心理，即使功能再强大都是不成功的。
3.3.1.2测试关注点
1.界面测试
软件的界面展示应该给使用者风格一致、美观协调的感觉，对软件界面的测试要点有：
1）界面的排列尽可能的保持简洁清晰，使用户有一目了然的感觉，并应考虑用户的阅读习惯。
通常，界面设计过程中，同一窗口中不同功能模块放在不同的框架中展示。
2）对于有特殊输入格式要求或需在固定范围内取值的输入域应给操作人员明确的提示。
可采用输入域后直接给出示例输入格式或在界面底部设置提示栏给出提示信息相结合的方式。
3）界面设计过程中需要考虑用户的使用习惯，设计便于用户操作的界面。
2.输入域测试
对界面内的各输入域，测试输入域输入控制的合理性，主要内容有：
1）输入域的输入内容类型的控制，如仅可输入字符型内容、输入字符是半角还是全角等；
2）输入域的输入内容长度的控制，如控制输入10个字符；
3）根据用户权限不同，相应控制输入域的可输入性；
4）输入域之间的关联控制。
3.易用性测试
界面上按钮名称应该用词准确、易于理解，同时要与同一界面上的其他按钮区分，力求用户不用查阅使用帮助的情况下就能进行正确操作，关于易用性测试应关注以下几点：
1）完成同一功能或工作的要素应集中放置，减少鼠标移动的距离；
2）默认按钮要支持Enter选择操作，即按Enter后自动执行默认按钮对应操作；
3）必输的复选框和选项框要有默认选项，并支持Tab键选择；
4）界面空间较小、选项数较多时使用下拉框而不用选项框，相反使用选项框。
3.3.1.3实例
●例1：
关于界面显示的测试。
系统：
现代支付系统二代-【EI03】汇兑业务-跨境业务
个人网银-汇款-汇到浦发银行
案例设计：
可以从界面展示的合理性、对界面字段的检查设计测试案例。
案例要素
案例1
案例2
系统名称
现代支付系统二代
个人网银
功能模块
EI03-汇兑业务-跨境业务
汇款
功能点
EI03-汇兑业务-跨境业务
汇到浦发银行
测试需求编号
EI03-001
HDPF-001
测试需求名称
界面展示
界面展示
测试需求描述
检查界面的排列、布局符合用户使用习惯，及显示内容正确。
检查界面的排列、布局符合用户使用习惯、显示内容正确、备注信息正确、相关按键功能正确。
案例编号
ZF-EI03-001
GRWY-001
测试案例名称
EI01-界面元素检查
EI01-页面元素检查
案例描述
页面元素显示正确，以输入接口描述为准。
包括操作标志,业务编号,业务类型,业务种类,扣款资金来源,扣款销账序号等。
以输入接口描述为准，验证交易界面字段显示正确，同时验证备注信息正确，“帮助”与“返回”键链接正确。
测试步骤
1.进入COP界面
2.输入交易码：
【EI03】回车
3.进入EI03交易界面
4.检查
升级会员 