功能测试需求与案例设计的指南

. 功能测试需求及案例设计指南浦东开展银行总行信息科技总部 测试中心2012年8月目 录第 1 章概述31.1目的31.2试用围31.3定义31.4相关定义之间的关系4第 2 章测试需求分析42.1测试需求分析概述42.1.1测试需求42.1.2测试需求分析的必要性52.1.3测试需求分析容52.1.4测试需求分析与需求分析的区别52.2测试需求分析过程62.2.1测试需求采集72.2.2测试需求分析82.2.3测试需求分析点82.2.4测试需求列表建立112.2.5测试需求评审12第 3 章测试案例设计133.1测试案例概述133.2测试案例要素133.3测试案例设计要点143.3.1界面测试143.3.2边界值测试183.3.3错误控制测试223.3.4关联测试273.3.5业务逻辑测试313.4测试案例设计技术33第 4 章测试场景设计344.1场景简述344.2测试场景分析344.3测试场景组织344.4设计实例36第 5 章其他说明38第 1 章 概述1.1 目的为提高功能测试工作质量和效率，提升相关人员在测试需求及案例上的设计技能，特制定功能测试需求及案例设计指南。本文主要介绍在银行业务系统测试过程中，就测试需求及案例进展设计与编写的思路、过程及方法，用于指导相关测试人员更好地开展该阶段的测试工作。1.2 试用围本指南适用于在总分行开展的各类功能测试项目中，参与测试需求或测试案例设计、编写的测试人员查阅参考，其中包括单元、集成、系统或UAT测试人员。1.3 定义1) 软件需求：主要指用户为解决某个问题、或为实现某一目标、要求软件必须满足的条件或能力，包括业务需求、功能需求及非功能需求。l 业务需求：反映了用户对系统较高层次的目标要求，描述了用户希望产品必须要完成的任务。l 功能需求：定义了开发人员必须实现的软件功能，包括处理流程、使用场景、业务规那么、模型算法、控制逻辑等，使得用户能完成实际操作，从而满足业务需求。l 非功能需求：是作为对功能需求的补充，它描述了系统展现给用户的行为和执行的操作等。包括产品必须遵从的标准、规和合约、性能要求、设计或实现的约束条件及质量属性。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) 评审测试需求分析产物系统需求规格说明书测试需求分析清单理程X66666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666662.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 l 例1：银保通系统功能点描述测试需求编号测试需求名称测试需求描述组织保险公司新增数据，存入保险公司根本信息表。“操作柜员和“更新时间不需要填写，页面自动带入。一样保险公司信息只能存在一条记录。新增成功后，显示“保险公司增加成功；新增失败时，停留当前页面，修改输入项后，可以继续提交新增交易。R001-001界面展示检查界面的排列、布局符合用户使用习惯，及显示容正确。R001-002输入域测试-数据长度检查每个输入字段的数据长度是否符合输入接口的要求。字段明细如下：级别 S1交易方式S1中文名称S20中文简称S20地址 S20 S6法人代表S20公司S20公司 S20公司主页S20公司E-mailS20保险总公司S4英文名称S20总部所在城市S20R001-003输入域测试-数据类型检查每个输入字段的数据类型是否符合输入接口的要求。描述同上，此处略。R001-004输入域测试-字典值检查每个输入字段的字典值是否符合输入接口的要求。描述同上，此处略。R001-005输入域测试-可输入性检查每个输入字段的可输入性是否符合输入接口的要求。描述同上，此处略。R001-006输入域测试-边界值对每个输入字段的输入数据进展边界值验证。描述同上，此处略。R001-007输入域测试-联动控制检查“操作柜员和“更新时间是否页面自动带入，不需要填写。R001-008业务处理逻辑校验1-新增已有信息检查一样保险公司信息是否只能存在一条记录。R001-009业务处理逻辑校验2-新增成功输入符合接口要求的各字段信息后点击“新增保存，检查保存是否成功，且提示“保险公司增加成功。R001-010业务处理逻辑校验3-新增失败输入不符合接口要求的各字段信息后点击“新增保存，检查保存是否失败。R001-011业务处理逻辑校验4-新增失败后修改新增失败后，是否停留当前页面，修改输入项后，是否可以继续提交新增交易。R001-012输出结果校验-新增成功/失败新增成功后，可以在“保险公司信息浏览中查询到记录。新增失败后，无法在“保险公司信息浏览中查询到记录。l 例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 测试案例概述测试需求主要是整理测试点，包括界面、输入域、业务处理流程、结果校验等，为测试用例的设计提供测试所需的功能点信息。所以，测试需告诉测试人员要测什么，而测试用例是告诉测试人员怎么测，它应包括测试步骤、预期结果、测试数据等。根据测试案例的性质划分，测试案例可以划分为正案例和反案例。l 正案例：是指按系统功能正常运行的测试用例，即验证系统是否能完成它应该完成的操作。正案例的设计主要依据系统需求规格说明书，详细设计文档等。l 反案例：那么是相对正案例而言的，就指设计异常的测试用例，即验证系统是否对不该完成的操作做出正确控制。反案例的设计主要依赖于测试人员的逆向思维能力及测试经历。例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 实例l 例1：关于界面显示的测试。系统：现代支付系统二代-【EI03】汇兑业务-跨境业务 个人网银-汇款-汇到浦发银行案例设计：可以从界面展示的合理性、对界面字段的检查设计测试案例。案例要素案例1案例2系统名称现代支付系统二代个人网银功能模块EI03-汇兑业务-跨境业务汇款功能点EI03-汇兑业务-跨境业务汇到浦发银行测试需求编号EI03-001HDPF-001测试需求名称界面展示界面展示测试需求描述检查界面的排列、布局符合用户使用习惯，及显示容正确。检查界面的排列、布局符合用户使用习惯、显示容正确、备注信息正确、相关按键功能正确。案例编号ZF-EI03-001GRWY-001测试案例名称EI01-界面元素检查EI01-页面元素检查案例描述页面元素显示正确，以输入接口描述为准。包括操作标志,业务编号,业务类型,业务种类,扣款资金来源,扣款销账序号等。以输入接口描述为准，验证交易界面字段显示正确，同时验证备注信息正确，“帮助与“返回键正确。测试步骤1.进入COP界面2.输入交易码：【EI03】回车3.进入EI03交易界面4.检查页面上的各字段元素。1.登录个人网银2.点击汇款-汇到浦发银行3.进入汇款交易界面4.检查界面上信息案例性质正案例正案例预期结果交易界面显示正确。交易界面显示正确。测试数据无无l 例2：关于输入域的测试。系统：现代支付系统二代-【EI03】汇兑业务-跨境业务案例设计：应结合输入接口文档，从各输入域字段的容、长度、权限及联动关系等方面来设计测试案例。案例要素案例1案例2系统名称现代支付系统二代现代支付系统二代功能模块EI03-汇兑业务-跨境业务EI03-汇兑业务-跨境业务功能点输入域-操作标志输入域-操作标志测试需求编号ZF-EI03-002ZF-EI03-002测试需求名称输入域测试-字典值输入域测试-联动控制测试需求描述检查每个输入字段的字典值是否符合输入接口的要求。检查各个输入域之间的联动控制关系。案例编号ZF-EI03-001ZF-EI03-002测试案例名称输入域-操作标志-字典值输入域-操作标志-联动关系案例描述根据接口文档描述，验证操作标志的字典值为：录入、复核、修改、直通1“操作标志选择“录入时，“业务编号为不可输入项；2“操作标志选择“复核“修改或“直通时，“业务编号为可输入项。测试步骤1.登陆cop界面，进入【EI03】2.验证“操作标志可选择4个不同字典值1.登陆cop界面，进入【EI03】2.验证“操作标志选择不同值时与业务编号的联动关系案例性质正案例正案例预期结果输入域字典值显示正确输入域联动关系正确测试数据无无l 例3：关于易用性的测试。系统：现代支付系统二代-【EI03】汇兑业务-跨境业务案例设计：以提供简单、易操作、无繁复步骤的操作界面为目标，设计相关测试案例。实例：EI03-汇兑业务-跨境业务交易在选择凭证种类时，需要打两次空格才能显示列表信息，如果不输入两个空格会直接跳过，对用户在使用上造成不便。3.3.2 边界值测试3.3.2.1 简述在功能设计和编码中，常常对与需求说明书中的输入/输出域的边界不够注意，以致形成一些过失。在设计测试用例时，应选取正好等于、刚刚大于或刚刚小于边界值的测试数据对边界附近的处理进展测试，就是边界值测试。对边界值的有效测试，可以发现不少程序的缺陷，提高系统的可靠性。3.3.2.2 测试关注点 对于边界值的测试，我们可以从以下几个角度开展测试案例的设计：1) 如果输入条件规定了值的围，可以选择正好等于边界值的数据作为合理的测试用例，同时还要选择刚好越过边界值的数据作为不合理的测试用例。如输入值的围是1，100，可取0，1，100，101等值作为测试数据。2) 如果输入条件规定了输入数据的个数，那么按最大个数、最小个数、比最小个数少1、比最大个数多1等情况分别设计测试用例。如，一个输入文件可包含1255条记录，那么可分别设计1条记录、255条记录，0条记录以及256条记录的输入文件的作为测试用例。3) 对每个输出条件分别按照以上原那么(1)或(2)确定输出值的边界情况。如某个记录明细查询页面，每页最多显示15条记录，那么分别可以设计1和15条以及0和16条记录。4) 如果输入域或输出域是个有序集合，那么应选取集合的第一个元素和最后一个元素作为测试用例。3.3.2.3 实例l 例1：关于输入项的边界值测试。系统-模块：公司网银功能描述：转账支付功能，与大小额实时支付系统对接，汇款至其他银行机构。转账时需输入转账金额、付款日期、收付款账号等。案例设计：选择正好等于边界值的数据作为正常的测试用例，同时还要选择刚好越过边界值的数据作为不合理的测试用例。案例要素案例1案例2系统名称公司网银公司网银功能模块转账支付转账支付功能点跨行支付跨行支付测试需求编号KHZF-001KHZF-002测试需求名称输入域测试-边界值测试输入域测试-边界值测试测试需求描述对每个输入字段的输入数据进展边界值验证。对每个输入字段的输入数据进展边界值验证。案例编号GSWY-ZZZF-001GSWY-ZZZF-001测试案例名称输入域-指定付款日期-边界值测试输入域-转账金额-边界值测试案例描述指定付款日期必须大于等于当前日期20140516，指定付款日期为20140517转账金额输入项必须大于0，验证转账金额等于0。测试步骤1. 登录公司网银2. 点击转账支付-跨行转账3.选择付款人账号、汇路4.输入指定付款日期等信息1.登录公司网银2.点击转账支付-跨行转账3.选择付款人账号、汇路4.输入转账金额等信息案例性质反案例反案例预期结果系统提示：指定付款日期必须大于等于当前日期系统提示：转账金额必须大于0测试数据无。无。l 例2：关于查询结果的记录条数测试。系统-模块：支付网关管理端-交易明细查询功能描述：在支付网关管理中对每天个人交易进展明细查询。案例设计：对查询结果页面展示记录的条数的边界值测试，尤其注意对涉及翻页展示的边界值测试案例要素案例1案例2系统名称支付网关(管理端)支付网关功能模块交易明细查询交易明细查询功能点个人交易查询_当日明细个人交易查询_当日明细测试需求编号JYMX-001JYMX-002测试需求名称输出域测试-边界值测试输出域测试-边界值测试测试需求描述对查询输出结果进展边界值验证。对查询输出结果进展边界值验证。案例编号ZFWG-JYMX-001ZFWG-JYMX-002测试案例名称输出域-当日订单明细-边界值测试输出域-当日订单明细-边界值测试案例描述查询商户当日的订单号信息，每页最多显示10条记录，验证0-10条记录时的查询结果。查询商户当日的订单号信息，每页最多显示10条记录，验证查询记录为10条时，翻页功能是否无效；11条时是否能正常翻页。测试步骤1.登录管理端界面，点击支付网关管理-交易明细查询2.输入商户号，点击提交3.检查查询出的定单信息1.登录管理端界面，点击支付网关管理-交易明细查询2.输入商户号，点击提交3.检查查询出的定单信息案例性质正案例正案例预期结果成功查询商户当日的订单号信息，并正确显示当日订单数据正确显示当日订单数据及翻页功能正确。测试数据无。无。l 例3：关于导入导出文件的边界值测试。案例1：系统-模块：个人网银-批量汇款功能描述：行批量汇款文件规定每个文件中所包含的汇款明细不超过100笔。案例设计：对导入文件中的记录数进展边界值测试，分别设计0笔、100笔、101笔记录的批量文件进展测试。案例2：系统-模块：公司网银-转账支付功能描述：对查询周期的批量转账记录进展明细查询并下载，查询周期的记录显示为单页20条记录。案例设计：对查询记录的下载文件的记录数的边界值测试，分别验证查询结果为0条、1条、20条、21条时的下载情况。案例要素案例1案例2系统名称个人网银公司网银功能模块汇款转账支付功能点批量汇款批量转账处理信息查询测试需求编号PLHK-001PLZZ-001测试需求名称输入域测试-边界值测试输出域测试-边界值测试测试需求描述对输入字段的输入数据进展边界值验证。对下载输出结果进展边界值验证。案例编号GRWY-PLHK-001GSWY-ZZZF-001测试案例名称输入域-批量汇款文件-边界值测试输出域-批量转账处理信息下载-边界值测试案例描述批量转账文件上传，批量文件中的转账总笔数上限为100条，验证转账总笔数为0、100、101条。根据起始日期和终止日期查询批量转账信息，验证当查询结果是0条、1条、20条、21条时的下载文件正确性。测试步骤1.登录个人网银，点击汇款-批量汇款-批量转账文件上传3.输入转账笔数、输入总金额4.选择上传文件,点击提交5.批量汇款确认1.登录公司网银，点击转账支付2.点击批量转账处理信息查询3.输入起始日期，输入终止日期4.点击提交，点击查询5.点击TXT下载，保存文件6.检查保存文件案例性质正案例正案例预期结果批量文件中为0条记录时，系统提示：批量文件容不能为空。批量文件中为100条记录时，系统提示：转账文件已经成功上传；批量文件中为101条记录时，系统提示：转账文件记录超过最大记录数。下载查询记录为0条的文件时，系统提示：显示无相关信息，不能下载。下载查询记录为1条、20条和21条的记录时，下载文件中的记录数也应该是对应的1条、20条和21条。测试数据无无3.3.3 错误控制测试3.3.3.1 简述 错误控制是指系统功能对异常情况的检查和响应。良好的错误控制决定了系统的可用性，并确保系统对错误交易数据的有效判断。错误信息的捕捉和处理是每个系统中必不可少的一局部。在系统使用过程中，用户希望看到的是友好、易懂的错误信息。开发人员希望看到的是信息详细、能便于准确定位问题产生原因的错误提示。3.3.3.2 测试关注点1. 业务逻辑错误控制测试对各类银行系统来说业务逻辑是系统的核心，整个系统都是围绕着业务逻辑设计开发的。在业务逻辑测试时，可以从以下几方面着手验证其错误控制：1) 对业务逻辑规定的岗位、角色测试和非规定岗位、角色的错误控制测试。2) 对不符合业务逻辑的处理功能的错误控制测试。如违反操作顺序的错误控制测试、对不能进展重复操作的错误控制测试。3) 对不符合业务逻辑的误操作的错误控制测试。如误提交不完整的信息的错误控制测试。2. 错误信息提示1) 遇到各类错误操作，系统是否给出相应的错误信息提示。2) 系统在遇到各类错误时给出的错误信息是否简洁、正确、有指导性。3.3.3.3 实例l 例1：关于对业务逻辑规定的角色权限的错误控制测试。系统-模块：银基通系统-补录权限复核管理功能描述：只有总行管理员才能通过管理端放开或者关闭某分行或所有分行的补录数据权限。案例设计： 根据业务处理对角色权限的控制，设计相应的正反案例。案例要素案例1案例2系统名称银保通直联系统银保通直联系统功能模块系统外交易数据补录系统外交易数据补录功能点补录权限管理补录权限管理测试需求编号BLFH-001BLFH-001测试需求名称业务处理逻辑校验-数据补录业务处理逻辑校验-数据补录测试需求描述数据补录权限的放开及关闭数据补录权限的放开及关闭案例编号YBT_SL_001YBT_SL_002测试案例名称数据补录权限管理-总行管理员数据补录权限管理-非总行管理员案例描述用总行管理员才能放开或者关闭某分行或所有分行的补录数据权限用理财人员和分行管理员进展放开或者关闭补录数据权限测试步骤1.用总行管理员进入“系统参数设置补录权限管理2.选择或取消补录权限分行表中的分行号3.点击确认1.用非总行管理员进入“系统参数设置补录权限管理2.选择或取消补录权限分行表中的分行号3.点击确认案例性质正案例反案例预期结果成功进展补录数据权限的设置，提示“数据补录权限配置成功。系统提示用户权限无法进展此操作。测试数据无。无。l 例2：关于对不符合业务逻辑的误操作的错误控制测试。系统-模块：银保通直联系统-投保单重要信息修改功能描述：针对异联交易中产生的投保单，分行管理员可以对已经终止的投保单进展恢复。或对已经选择的产品的份数、保费、手续费金额或客户卡号进展更改。案例设计：在操作人员进展业务操作时，不可防止会碰到各种各样的误操作，所以在进展案例时就应模拟各种可能出现的误操作场景，验证系统对错误信息输入时的校验能力。案例要素案例1案例2系统名称银保通直联系统银保通直联系统功能模块投保单重要信息修改投保单重要信息修改功能点修改投保卡号修改产品信息测试需求编号XGTBD-001XGCP-001测试需求名称输出结果校验-修改投保卡号失败输入域测试-可输入性测试需求描述验证在修改投保单卡号相关信息失败时，错误提示信息正确。检查“份数/档期字段的可输入性是否符合输入接口的要求。案例编号YBT_XGKH_001YBT_XGCP_001测试案例名称修改卡号为已挂失/已销户的借记卡时，交易提示错误信息。“份数/档期必输项校验案例描述输入需修改新卡号为已挂失/已销户的借记卡当操作人员操作时，未对“份数/档期输入相关信息。测试步骤1.选择保险公司和填写投保单2.选择“修改投保卡号功能3.修改客户的卡号信息，分行管理员复核1.选择保险公司和填写投保单2.选择“修改投保卡号功能3.填写需要修改的信息，分行管理员复核案例性质反案例反案例预期结果提示报错信息，系统提示：该卡状态错误。提示报错信息，系统提示：请输入“份数/档期。测试数据无。无。注: 修改卡号为已销户的卡号l 例3：对不符合业务逻辑处理功能的错误控制测试。案例1：系统-模块：银保通直联系统-投保单数据同步功能描述：银保直联局部复杂产品需要转保险公司人工核保。在保险公司人工核保通过后，需与保险公司同步投保单金额、产品及状态信息。在执行人工核保状态同步操作前，投保单必须是已经成功签约和扣款。案例设计：对不符合正常操作顺序，违反正常操作步骤的操作的错误控制。案例2：系统-模块：银保通直联系统-新保承保功能描述：对可以进展直联新保承保的保险总公司进展新保承保，实时对核保试算，银行实时扣款。案例设计：对不能进展重复操作的错误控制测试。案例要素案例1案例2系统名称银保通直联系统银保通直联系统功能模块投保单数据同步直联新保承保功能点人工核保状态同步当日撤单测试需求编号RGHB-001DRCD-001测试需求名称业务处理逻辑校验-人工核保失败业务处理逻辑校验-当日撤单失败测试需求描述人工核保状态同步操作前，必须是已经成功签约和扣款的投保单。一个投保单号做了新保承保之后，执行当日撤单操作成功后，不允许再次撤单。案例编号YBT_BDTB_001DRCD_BDXX_001测试案例名称未签约批扣的客户进展人工核保状态同步操作失败报错。当日撤单后的保单再撤单案例描述用未完成签约和扣款操作的投保单进展状态同步，提示错误。用已经做了新保承保之后，且当日撤单成功的投保单号进展再次撤单，提示错误信息。测试步骤1.在银保通系统发起直联新保承保交易，购置产品为复杂产品，需要转人工核保2.上传批量同步文件，执行批处理1.用理财经理登录银保通系统2.进入直联新保承保-当日撤单3.输入投保卡号4.输入复核投保单号5.点击确认案例性质反案例反案例预期结果报错提示“客户未签约系统提示错误或找不到记录测试数据无无3.3.4 关联测试3.3.4.1 简述 关联性是指应用与应用之间的关联关系，可分为应用间互相调用关联、应用权限控制关联、应用上下游数据关联。 应用相互调用关联是指平台应用与应用之间通过接口进展程序控制或关联数据传输，如后台应用与前置类应用之间的数据传送。 应用权限控制关联是指一个应用需要通过使用另一个应用提供的具有相关权限的用户，并只能通过此用户登录方可进展本应用业务处理的关联关系。如部管理的各应用需通过统一认证提供的用户进展登录，并通过统一认证应用对该用户进展权限控制。 应用上下游关联是指通过上游应用通过特定的传输方式向下游系统提供数据。如平台报表应用与其上游数据源和数据交换相关应用的关联。3.3.4.2 测试关注点应用与应用之间的关联关系按照关联关系的表现形式不同测试的着重点也不同，可以通过以下关注点进展测试案例的设计：1. 应用相互调用关联测试关注点1） 验证数据传输格式是否符合相关接口文档的描述，如接口的各个组成字段的长度、字符类型、字典值、生成格式、通讯协议等。2） 测试数据准备时要考虑关联应用之前关键参数的配置、数据类型、数据长度、业务约定等；3） 采用模拟器测试时要注意核对应用间相互关联的参数配置是否正确，应用端的展现是否正确。2. 应用权限控制关联测试关注点1） 根据应用的用户权限控制层级和设置要求，验证权限控制应用的相关角色权限设置是否正确。2） 在对权限控制应用做修改时，也同时要对相关联应用进展通过性测试，包括权限控制验证等。3. 应用上下游关联测试关注点1） 上游应用应关注数据源传输的正确性。2） 报表应用应关注对数据源、展现方式及结果的准确性的验证。3.3.4.3 实例l 例1：对应用权限控制的关联测试系统-系统：业务集中系统-统一认证平台功能描述：在登录业务集中系统时，需要经统一认证平台进展用户验证，只有具有相关权限的用户方可对登录公文管理系统。对汇兑业务的发起功能也需要统一认证平台的进展权限控制。案例设计：在登录权限控制验证时应设计有登录及无登录权限的用户进展正反案例的测试。同时，对相关用户权限控制的有效性进展案例设计。案例要素案例1案例2系统名称业务集中系统业务集中系统功能模块用户登录汇兑业务功能点用户登录控制汇兑业务的操作权限控制测试需求编号YHDL-001HDYW-001测试需求名称输入域测试-权限控制约束条件-柜员操作权限测试需求描述检查用户登录时“用户名输入域的权限控制，否是与统一验证平台关联。网点人民币结算业务中经办角色能发起业务集中系统的汇兑业务。案例编号YHDL_001CZQX_001测试案例名称用户登录权限控制柜员操作权限案例描述验证业务集中系统的登录功能的用户控制，只有经统一认证平台认证过的用户才可以成功登录。非经办角色不能发起业务集中系统的汇兑业务控制测试步骤1.填写登录信息。2.验证用户控制正确性。1.填写登录信息。2.发起汇兑业务。案例性质正案例反案例预期结果登录权限控制正确。用户操作权限报错。测试数据无无l 例2：对上下游应用关联的报表测试系统-系统：网银支付网关-电子银行综合管理平台功能描述：由支付平台执行个人支付交易，电子银行综合管理平台在取得相关交易明细后汇总成“支付网关交易统计表后，供相关人员查阅。案例设计：对于上游系统产生交易数据，下游系统生成数据报表的测试，应用注重报表的核对，保证数据源正确性。案例要素案例1案例2系统名称网银支付网关网银支付网关功能模块个人支付个人支付联调测试功能点执行个人支付交易后，电子银行综合管理平台在取得相关交易明细后汇总成“支付网关交易统计表执行个人支付交易后，电子银行综合管理平台在取得相关交易明细后汇总成“支付网关交易统计表测试需求编号GRZF-001GRZF-001测试需求名称业务逻辑处理-联调测试业务逻辑处理-联调测试测试需求描述验证与电子银行综合管理平台之间上下游数据传输及报表展现正确。验证与电子银行综合管理平台之间上下游数据传输及报表展现正确。案例编号ZFPT_LTCS_001ZFPT_LTCS_002测试案例名称个人支付交易统计报表验证个人支付交易统计报表验证案例描述在支付平台执行个人支付交易后，在电子银行综合管理平台下载“支付网关交易统计表，验证报表样式、字段、翻页等辅助功能正确。在支付平台执行个人支付交易后，在电子银行综合管理平台下载“支付网关交易统计表，验证报表数据正确性。测试步骤1.在支付平台发起假设干个人支付交易。2. 电子银行综合管理平台验证交易统计表辅助功能正确。1.在支付平台发起假设干个人支付交易。2. 电子银行综合管理平台验证交易统计表数据的正确性。案例性质正案例正案例预期结果上下游报表数据正确上下游报表数据正确测试数据无无3.3.5 业务逻辑测试3.3.5.1 简述业务逻辑是业务实际处理的流程，系统根据实际需求，将复杂的业务处理过程变成一个完整的系统流程，实现业务逻辑的程序化、系统化。因此，业务逻辑的测试为系统的流程测试，是将所有的业务功能组合在一起的测试。特别是银行系统的流程繁多且复杂，如果系统中的某一个流程有纰漏，极有可能造成严重的经济损失，所以做好业务逻辑测试非常重要。3.3.5.2 测试关注点在实际的业务逻辑测试过程，测试人员可以主要从以下两块开展测试。1. 子流程测试先对流程中的子流程功能进展测试，包括正常数据和异常数据。在子流程功能确认正确后，再对整个流程进展通过性验证。子流程测试要点如下：1） 对子流程的控制条件测试。2） 对子流程的处理功能测试。3） 对错误数据的处理功能测试。4） 模拟模块中所有存在的输入条件，对输出结果的进展核对测试。5） 根据模块中所有存在输出结果，检查是否能正确输出预计的结果。 采用子流程分割测试的可以对流程中的各模块的功能可以同时测试，而且流程中的后续模块测试，不受前面模块功能的影响。这种流程分割将一个复杂的流程处理，按其功能实现过程，分割成多个“黑盒模块进展测试，以到达最大程度减少模块之间的关联而造成的对测试的约束，大大提高测试效率。2. 全流程测试 在对各个模块逐个进展测试后那么要进展全面的流程测试，这样是为了测试该业务逻辑的所有可能流程，主要测试要点有：1） 对流程中调用的对外接口的测试；2） 对流程中的各入口条件进展测试，验证其处理逻辑、错误控制等。3） 对主要的流程进展逻辑正确性验证，再覆盖多个流程分支的全流程测试。4） 对流程中涉及的批量调度测试，尽可能排除批量跑断或无法调度的问题；3.3.5.3 实例l 例1：业务逻辑测试系统：额度管理系统功能描述：授信额度的管理流程是额度管理系统中提供的审批机制。该管理流程，提供以下功能：额度的生成、额度的使用、额度的维护、额度的监控。案例设计：根据该审批流程的特点，应该采取以下几种方式进展验证并设计测试案例。1） 子流程测试：在根本跑通了正常交易数据后，就可以对每个子流程进展详细测试。这时候把流程分割额度生成、额度使