上海浦东发展银行

总行信息科技总部 测试中心

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测试需求分析与需求分析的区别

测试需求分析是从软件需求规格说明书出发，对用户需求进行提取和采集，并整理出功能点列表清单，然后逐一对功能点列表清单中的功能点进行分析形成测试需求列表。最后对测试需求组织评审，根据评审结果对其进行确认、修改和调整。其分析流程可见下图所示： 

图2-测试需求分析流程图

说明：

    功能点列表原则上应随系统需求规格书等项目文档一起由项目组提供，只有在项目文档未说明及项目组不提供的情况下方由测试人员进行梳理，但需提交项目组确认。

2.2.1测试需求采集

测试需求的采集过程是将软件需求中的具有可测性的需求或特征提取出来，并通过列表形式对软件需求进行梳理，形成功能列表清单，列表的内容包括功能模块、功能点编号和功能点描述。在提取软件需求的过程中，可能存在重复和冗余，所以在梳理过程中，可以通过删除、细化及合并的方式对整理的功能列表清单进行调整。功能点列表清单列表示例如下：

1)为均衡功能点粒度，对于复杂度高、且有大功能模块的项目，功能模块的划分应按一定的层级展开，即在原有功能模块的基础上再进行2-3层的细化。

2)编号规则：在进行测试需求及案例的设计过程中，需要对功能点、测试需求及测试案例进行编号，以上3块内容的编号均采用顺序编号。现对以上3项制定编号规则如下：

功能点：FXXX

测试需求：RXXX-XXX（其中RXXX-XXX加粗部分的编号为对应的功能点编号）

测试案例：TXXX-XXX-XXX（其中TXXX-XXX-XXX加粗部分为对应的测试需求编号）

例1：银保通系统（软件需求）

测试需求分析过程是对功能点列表中列出的每一条功能需求细化和分解的过程，以形成可测试的分层描述的测试要点的过程。对功能需求进行细化和分解的分析过程包括：

1)通过分析每条功能需求描述中的输入、输出、处理、与约束等，给出对应的验证内容。

2)通过分析各个功能模块之间的业务顺序，以及各个功能模块之间对传递的信息和数据存在的功能交互，给出对应的验证内容。 

3)经过分解获得的测试需求必须能够充分覆盖软件需求的各种特征，且每个需求都可以进行单独测试，以保证测试需求的完整性。

4)每个测试需求能够使用数量相当的测试用例来实现，即尽量保证测试案例的粒度是均匀的。

2.2.3测试需求分析点

根据以往测试需求分析工作的经验累积，发现在进行测试需求时通常可以从以下5个分析点开展测试需求分析工作，其对应的分析粒度亦可参考以下列表中的描述：

测试需求列表为软件需求与测试需求的对应关系表。建立测试需求列表是为了将上述经分析、确定的功能需求、测试需求进行汇总并对其进行统一管理及维护。测试需求列表格式如下： 

2.2.5测试需求评审

在测试需求分析完成后，应组织需求方、开发方和测试方进行测试需求的评审工作。应分别从测试需求的完整性、准确性角度出发，对测试需求列表中的各项内容进行逐一评审， 评审时的关注点如下：

1)重点关注功能逻辑、数据定义、接口定义、系统约束等方面的正确性。

2)关注是否覆盖需求分析人员遗漏的、系统隐含的需求；

3)关注各测试需求之间是否存在歧义和矛盾；

4)关注各测试需求描述的详尽程度是否可以作为测试用例设计的依据；

5)关注所描述的测试需求内容是否能够得到三方的一致理解。

第 3 章  测试案例设计

3.1测试案例概述

测试需求主要是整理测试点，包括界面、输入域、业务处理流程、结果校验等，为测试用例的设计提供测试所需的功能点信息。所以，测试需求是告诉测试人员要测什么，而测试用例是告诉测试人员怎么测，它应包括测试步骤、预期结果、测试数据等。

根据测试案例的性质划分，测试案例可以划分为正案例和反案例。

●正案例：是指按系统功能正常运行的测试用例，即验证系统是否能完成它应该完成的操作。正案例的设计主要依据系统需求规格说明书，详细设计文档等。

●反案例：则是相对正案例而言的，就指设计异常的测试用例，即验证系统是否对不该完成的操作做出正确控制。反案例的设计主要依赖于测试人员的逆向思维能力及测试经验。

例1：数字型输入域的长度测试。

功能描述：银保直联系统在新增保险公司时需输入6位“邮编”信息。

正案例：输入邮编“200001”。

反案例：输入邮编“2000010”。

例2：字段必输性测试。

功能描述：银保直联系统在新增保险公司时“保险总公司”为必输项。

正案例：输入正确的保险总公司信息。

反案例：保险总公司信息输入为空。

3.2测试案例要素

根据2011年测试中心发布的《上海浦东发展银行信息科技总部功能测试管理规程》中的“测试案例的管理方法”已明确，为规范功能测试工作和便于功能测试集中案例库的建立和管理，功能测试案例需包含以下关键要素：

设计测试案例的主要是为了寻求系统设计、功能设计的弱点。所以，为保证测试案例覆盖度，功能测试应从界面测试、边界值测试、关联测试、错误控制测试、业务逻辑测试、安装测试等测试要点出发开展测试案例设计工作。

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】汇兑业务-跨境业务

      个人网银-汇款-汇到浦发银行

案例设计：可以从界面展示的合理性、对界面字段的检查设计测试案例。

系统：现代支付系统二代-【EI03】汇兑业务-跨境业务

案例设计：应结合输入接口文档，从各输入域字段的内容、长度、权限及联动关系等方面来设计测试案例。

系统：现代支付系统二代-【EI03】汇兑业务-跨境业务

案例设计：以提供简单、易操作、无繁复步骤的操作界面为目标，设计相关测试案例。

实例：EI03-汇兑业务-跨境业务交易在选择凭证种类时，需要打两次空格才能显示列表信息，如果不输入两个空格会直接跳过，对用户在使用上造成不便。

3.3.2边界值测试

3.3.2.1简述

在功能设计和编码中，常常对与需求说明书中的输入/输出域的边界不够注意，以致形成一些差错。在设计测试用例时，应选取正好等于、刚刚大于或刚刚小于边界值的测试数据对边界附近的处理进行测试，就是边界值测试。对边界值的有效测试，可以发现不少程序的缺陷，提高系统的可靠性。

3.3.2.2测试关注点

    对于边界值的测试，我们可以从以下几个角度开展测试案例的设计：

1)如果输入条件规定了值的范围，可以选择正好等于边界值的数据作为合理的测试用例，同时还要选择刚好越过边界值的数据作为不合理的测试用例。如输入值的范围是[1，100]，可取0，1，100，101等值作为测试数据。

2)如果输入条件规定了输入数据的个数，则按最大个数、最小个数、比最小个数少1、比最大个数多1等情况分别设计测试用例。如，一个输入文件可包含1—255条记录，则可分别设计1条记录、255条记录，0条记录以及256条记录的输入文件的作为测试用例。

3)对每个输出条件分别按照以上原则(1)或(2)确定输出值的边界情况。如某个记录明细查询页面，每页最多显示15条记录，则分别可以设计 1和15条以及0和16条记录。

4)如果输入域或输出域是个有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。

3.3.2.3实例

●例1：关于输入项的边界值测试。

系统-模块：公司网银

功能描述：转账支付功能，与大小额实时支付系统对接，汇款至其他银行机构。转账时需输入转账金额、付款日期、收付款账号等。

案例设计：选择正好等于边界值的数据作为正常的测试用例，同时还要选择刚好越过边界值的数据作为不合理的测试用例。

系统-模块：支付网关（管理端）-交易明细查询

功能描述：在支付网关管理中对每天个人交易进行明细查询。

案例设计：对查询结果页面展示记录的条数的边界值测试，尤其注意对涉及翻页展示的边界值测试

案例1：

系统-模块：个人网银-批量汇款

功能描述：行内批量汇款文件规定每个文件中所包含的汇款明细不超过100笔。

案例设计：对导入文件中的记录数进行边界值测试，分别设计0笔、100笔、101笔记录的批量文件进行测试。

案例2：

系统-模块：公司网银-转账支付

功能描述：对查询周期内的批量转账记录进行明细查询并下载，查询周期内的记录显示为单页20条记录。

案例设计：对查询记录的下载文件的记录数的边界值测试，分别验证查询结果为0条、1条、20条、21条时的下载情况。

3.3.3.1简述

    错误控制是指系统功能对异常情况的检查和响应。良好的错误控制决定了系统的可用性，并确保系统对错误交易数据的有效判断。错误信息的捕捉和处理是每个系统中必不可少的一部分。在系统使用过程中，用户希望看到的是友好、易懂的错误信息。开发人员希望看到的是信息详细、能便于准确定位问题产生原因的错误提示。

3.3.3.2测试关注点

1.业务逻辑错误控制测试

对各类银行系统来说业务逻辑是系统的核心，整个系统都是围绕着业务逻辑设计开发的。在业务逻辑测试时，可以从以下几方面着手验证其错误控制：

1)对业务逻辑规定的岗位、角色测试和非规定岗位、角色的错误控制测试。

2)对不符合业务逻辑的处理功能的错误控制测试。如违反操作顺序的错误控制测试、对不能进行重复操作的错误控制测试。

3)对不符合业务逻辑的误操作的错误控制测试。如误提交不完整的信息的错误控制测试。

2.错误信息提示

1)遇到各类错误操作，系统是否给出相应的错误信息提示。

2)系统在遇到各类错误时给出的错误信息是否简洁、正确、有指导性。

3.3.3.3实例

●例1：关于对业务逻辑规定的角色权限的错误控制测试。

系统-模块：银基通系统-补录权限复核管理

功能描述：只有总行管理员才能通过管理端放开或者关闭某分行（或所有分行）的补录数据权限。

案例设计： 根据业务处理对角色权限的控制，设计相应的正反案例。

系统-模块：银保通直联系统-投保单重要信息修改

功能描述：针对异联交易中产生的投保单，分行管理员可以对已经终止的投保单进行恢复。或对已经选择的产品的份数、保费、手续费金额或客户卡号进行更改。

案例设计：在操作人员进行业务操作时，不可避免会碰到各种各样的误操作，所以在进行案例时就应模拟各种可能出现的误操作场景，验证系统对错误信息输入时的校验能力。

●例3：对不符合业务逻辑处理功能的错误控制测试。

案例1：

系统-模块：银保通直联系统-投保单数据同步

功能描述：银保直联部分复杂产品需要转保险公司人工核保。在保险公司人工核保通过后，需与保险公司同步投保单金额、产品及状态信息。在执行人工核保状态同步操作前，投保单必须是已经成功签约和扣款。

案例设计：对不符合正常操作顺序，违反正常操作步骤的操作的错误控制。

案例2：

系统-模块：银保通直联系统-新保承保

功能描述：对可以进行直联新保承保的保险总公司进行新保承保，实时对核保试算，银行实时扣款。

案例设计：对不能进行重复操作的错误控制测试。

3.3.4.1简述

    关联性是指应用与应用之间的关联关系，可分为应用间互相调用关联、应用权限控制关联、应用上下游数据关联。

    应用相互调用关联是指平台应用与应用之间通过接口进行程序控制或关联数据传输，如后台应用与前置类应用之间的数据传送。

    应用权限控制关联是指一个应用需要通过使用另一个应用提供的具有相关权限的用户，并只能通过此用户登录方可进行本应用业务处理的关联关系。如内部管理的各应用需通过统一认证提供的用户进行登录，并通过统一认证应用对该用户进行权限控制。

    应用上下游关联是指通过上游应用通过特定的传输方式向下游系统提供数据。如平台报表应用与其上游数据源和数据交换相关应用的关联。

3.3.4.2测试关注点

应用与应用之间的关联关系按照关联关系的表现形式不同测试的着重点也不同，可以通过以下关注点进行测试案例的设计：

1.应用相互调用关联测试关注点

1）验证数据传输格式是否符合相关接口文档的描述，如接口的各个组成字段的长度、字符类型、字典值、生成格式、通讯协议等。

2）测试数据准备时要考虑关联应用之前关键参数的配置、数据类型、数据长度、业务约定等；

3）采用模拟器测试时要注意核对应用间相互关联的参数配置是否正确，应用端的展现是否正确。

2.应用权限控制关联测试关注点

1）根据应用的用户权限控制层级和设置要求，验证权限控制应用的相关角色权限设置是否正确。

2）在对权限控制应用做修改时，也同时要对相关联应用进行通过性测试，包括权限控制验证等。

3.应用上下游关联测试关注点

1）上游应用应关注数据源传输的正确性。

2）报表应用应关注对数据源、展现方式及结果的准确性的验证。

3.3.4.3实例

●例1：对应用权限控制的关联测试

系统-系统：业务集中系统-统一认证平台

功能描述：在登录业务集中系统时，需要经统一认证平台进行用户验证，只有具有相关权限的用户方可对登录公文管理系统。对汇兑业务的发起功能也需要统一认证平台的进行权限控制。 

案例设计：在登录权限控制验证时应设计有登录及无登录权限的用户进行正反案例的测试。同时，对相关用户权限控制的有效性进行案例设计。

系统-系统：网银支付网关-电子银行综合管理平台

功能描述：由支付平台执行个人支付交易，电子银行综合管理平台在取得相关交易明细后汇总成“支付网关交易统计表”后，供相关人员查阅。

案例设计：对于上游系统产生交易数据，下游系统生成数据报表的测试，应用注重报表的核对，保证数据源正确性。

3.3.5.1简述

    业务逻辑是业务实际处理的流程，系统根据实际需求，将复杂的业务处理过程变成一个完整的系统流程，实现业务逻辑的程序化、系统化。因此，业务逻辑的测试为系统的流程测试，是将所有的业务功能组合在一起的测试。特别是银行系统的流程繁多且复杂，如果系统中的某一个流程有纰漏，极有可能造成严重的经济损失，所以做好业务逻辑测试非常重要。

3.3.5.2测试关注点

在实际的业务逻辑测试过程，测试人员可以主要从以下两块开展测试。

1.子流程测试

先对流程中的子流程功能进行测试，包括正常数据和异常数据。在子流程功能确认正确后，再对整个流程进行通过性验证。子流程测试要点如下：

1）对子流程的控制条件测试。

2）对子流程的处理功能测试。

3）对错误数据的处理功能测试。

4）模拟模块中所有存在的输入条件，对输出结果的进行核对测试。

5）根据模块中所有存在输出结果，检查是否能正确输出预计的结果。

    采用子流程分割测试的可以对流程中的各模块的功能可以同时测试，而且流程中的后续模块测试，不受前面模块功能的影响。这种流程分割将一个复杂的流程处理，按其功能实现过程，分割成多个“黑盒”模块进行测试，以达到最大程度减少模块之间的关联而造成的对测试的约束，大大提高测试效率。

2.全流程测试

   在对各个模块逐个进行测试后则要进行全面的流程测试，这样是为了测试该业务逻辑的所有可能流程，主要测试要点有：

1）对流程中调用的对外接口的测试；

2）对流程中的各入口条件进行测试，验证其处理逻辑、错误控制等。

3）对主要的流程进行逻辑正确性验证，再覆盖多个流程分支的全流程测试。

4）对流程中涉及的批量调度测试，尽可能排除批量跑断或无法调度的问题；

3.3.5.3实例

●例1：业务逻辑测试

系统：额度管理系统

功能描述：授信额度的管理流程是额度管理系统中提供的审批机制。该管理流程，提供以下功能：额度的生成、额度的使用、额度的维护、额度的监控。

案例设计：根据该审批流程的特点，应该采取以下几种方式进行验证并设计测试案例。

1）子流程测试：在基本跑通了正常交易数据后，就可以对每个子流程进行详细测试。这时候把流程分割额度生成、额度使用、额度维护、额度监控，把每个子流程当作一个“黑盒”，考虑该“黑盒”的所有输入输出情况。

●入口的测试：例如，额度生成流程，“信息录入”就是一个入口，该入口包括各种形式的入口，从客户类型上可以分为：公司客户、中小企业客户、金融客户；从流程上包括额度的申请/测算，审查、审批和最终认定过程。一个入口就代表了一个流程大类，所以要考虑各方面的入口，只有流程入口设计并覆盖全面了，才能保证在测试上不会有遗漏。

●出口的测试：例如，额度在审查审批阶段分别有分行、支行、总行的审核。每个环节又根据客户类型、额度种类有不同的审核节点。所以，出口的案例设计要重点关注每个节点状态更新的准确性。

2）全流程测试：把在各子流程考虑到的输入输出情况连接起来，做完整业务流程的测试。例如，在额度生效后进行业务申请，额度出账后进行额度的维护，然后对额度进行监控，把这些情况连成一个流程来测试。

3.4测试案例设计技术

测试案例设计技术可分为等价类划分法、边界值分析法、因果图法和场景法，这4种案例设计技术的具体方法可参见《功能测试通用测试技术指南》。

第 4 章  测试场景设计

4.1场景简述

场景是从用户的角度来描述系统的行为，反映用户希望的系统运行方式。它是由一系列相关活动组成，是展现系统预期的使用过程。场景可以看作是用户需求的内容，完全站在用户的视角来描述用户与系统的交互。因此，基于用户使用场景的测试，我们称之为场景测试。

4.2测试场景分析

由场景的定义我们可以看出，放在具有的具体业务含义的背景下执行测试案例，更易于判断系统功能的正确性。特别是某些场景经不同组合后，同步或异步执行更能进一步验证系统功能的健壮性和稳定性。

所以，进行场景分析时，首先要明确用户的各种使用场景。场景是一个迭代细化的过程，它需要有清晰、明确的发生背景，何时会发生，从用户的角度出发，描述用户希望做什么，与系统的交互行为，以及用户对出现问题的反应。

然后，根据已明确的使用场景，对测试场景进行组织。一个测试场景会涉及到不同的功能点、不同的测试需求及测试案例，且可能仅会涉及到各个功能的一部分处理流程。因此，需通过控制执行顺序、条件控制、串行或并行处理来组合出有效的测试场景，并以此说明多个功能之间的信息流是如何进行流转的。

4.3测试场景组织

执行场景的组织是基于功能点、测试需求及测试案例展开的。它是根据用户的实际使用组织执行顺序的，然后根据每一执行步骤的执行内容选择相应的测试需求，每一步骤中的测试案例则是场景的具体操作。由此就形成了模拟用户实际使用操作的执行场景。由下图可以看出执行场景是如何组织的。

说明：

1)银行系统就是将复杂的业务处理过程变成一个完整的系统流程，因此，在对系统流程进行测试时需要反向的模拟用户在真实情况下的业务处理过程来验证业务流程的正确性，此时就需要通过组织场景来实现。

2)执行场景是组合式的，它可以由一个测试需求下多个测试案例组成，也可以由多个需求下的多个测试案例组成。如下图所示。其中，最简单的场景就是单案例执行的，它是场景的一种特殊情况。为避免错误的认为不能组织进场景的案例都应视作是单案例执行场景，所以场景需以多案例的组合式为前提。

3)测试执行结果以测试案例最终执行结果为准，只有在场景中测试案例均执行通过后，才能认为该场景的测试通过。只有在所有测试案例执行通过后，才能认为该系统的功能基本满足业务需求。

4.4设计实例

●例1

系统：中国移动一点接入代缴移动话费项目

场景说明： 

柜面签约：受理客户请求，选择“中国移动代缴费”中间业务，输入手机号码，提交签约交易。

柜面签约查询：输入签约序号，客户账号类型、等信息查询柜面签约情况。

柜面签约修改：可以通过柜面签约查询后，联动修改签约信息。

柜面解约：可通过柜面签约查询联动解约，也可以通过直接发起解约交易。

测试场景设计：

系统：二代支付系统

场景说明： 

汇兑业务是指承兑行将客户持交的一定款项汇至他行的收款人。汇兑业务有两种操作方式，一种是通过录入、复核；另一种是通过直通方式进行。然后，在完成相关的汇兑交易后对其生成的报文和来帐报文进行校验。

测试场景设计：

     本指南内容是信息科技总部测试中心根据过去两年的实践和总结, 同时借鉴测试领域相关专业知识整理而成，其具体内容由信息科技总部负责解释。随着后续测试实施项目的不断增多和测试经验的不断积累，测试中心会对本指南的内容进行进一步完善。

     如需了解信息科技总部功能测试实施规范和流程， 请参阅《上海浦东发展银行信息科技总部功能测试管理规程》（浦银科技〔2011〕28号）。 

 联系人：信息科技总部测试中心

） 

）  下载本文