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

1、功能测试需求及案例设计指南上海浦东发展银行总行信息科技总部测试中心2012年8月目录第1章 概述1.1 目的1.2 试用范围1.3 定义1.4 相关定义之间的关系 第2章测试需求分析2.1 测试需求分析概述 2.1.1 测试需求2.1.2 测试需求分析的必要性 2.1.3 测试需求分析内容 2.1.4 测试需求分析与需求分析的区别 2.2 测试需求分析过程 2.2.1 测试需求采集 2.2.2 测试需求分析 2.2.3 测试需求分析点2.2.4 测试需求列表建立2.2.5 测试需求评审第3章 测试案除j设计1 .1测试案例概述32 测试案仞j要素 3.3测试案例设计要点 3.3.1 界面测试3

2、.3.2 边界值则试3.3.3 错误捽制测试334关联测试3.3.5 业务逻辑测试 3A测试案例设计技术 第4章测试场景设计41 场景简述42测试场景分析 4.3测试场景组织 44 设计实例第5章 其他说明 第 1 章 概述1.1 目的为提高功能测试工作质量和效率，提升相关人员在测试需求及案例上的设计技能，特制定功能测试需求及案例设计指南。本文主要介绍在银行业务系统测试过程中，就测试需求及案例进行设计与编写的思路、过程及方法，用于指导相关测试人员更好地开展该阶段的测试工作。1.2 试用范围本指南适用于在总分行开展的各类功能测试项目中，参与测试需求或测试案例设计、编写的测试人员查阅参考，其中包括

3、单元、集成、系统或UAT测试人员。1.3 定义1) 软件需求：主要指用户为解决某个问题、或为实现某一目标、要求软件必须满足的条件或能力，包括业务需求、功能需求及非功能需求。业务需求：反映了用户对系统较高层次的目标要求，描述了用户希望产品必须要完成的任务。功能需求：定义了开发人员必须实现的软件功能，包括处理流程、使用场景、业务规则、模型算法、控制逻辑等，使得用户能完成实际操作，从而满足业务需求。非功能需求：是作为对功能需求的补充，它描述了系统展现给用户的行为和执行的操作等。 包括产品必须遵从的标准、规范和合约、性能要求、设计或实现的约束条件及质量属性。2) 功能点： 组成功能模块的一个细化的、特

4、定的测试对象，例如： 交易中的一个输入域、业务交易中一个校验规则、报表中的一个指标算法等。3) 测试需求：以用户需求为基础，站在第三方测试的角度明确待测系统中需要测试的内容。4) 测试案例：测试案例是为特定目标或特定条件而设计的一组输入值、执行条件和预期结果。它是可以独立进行测试执行的最小单元，是执行具体测试的一个操作指导。1.4 相关定义之间的关系软件需求与功能点、功能点与测试需求、测试需求与案例都是一对多的关系。软件需求是基础，功能点是软件需求的分解产物，测试需求是对功能点进行剖析后形成的测试基础，测试案例则是对测试需求的操作细化。图 1- 软件需求、功能点、测试需求、测试案例关系图第 2

5、 章 测试需求分析2.1 测试需求分析概述2.1.1 测试需求测试需求主要解决“测什么”的问题，即指明被测系统中有哪些功能点需要测试。测试需求的主要来源是系统的需求规格说明书，有些无法从需求文档中获得的需求，可通过系统的概要设计或者详细设计文档获得。测试人员依据对软件需求的细化分解来编写测试需求，以覆盖全部已定义的业务流程。同时，测试需求也是设计测试用例的依据，好的测试需求能发现需求中显性和隐性的测试点，从而能更好的指导测试用例的设计，提高被测系统整体功能的覆盖率。2.1.2 测试需求分析的必要性在做一个测试项目之前，首先必须了解测试规模、复杂程度及可能存在的风险，这些都需要通过详细的测试需求

6、来了解。测试需求不明确，只会造成获取的信息不正确，无法对所测系统有一个全面清晰的认识。由此可见，进行测试需求分析是十分必要的，一方面，测试需求分析可以把不直观的需求，转变为直观的需求。对测试范围、功能点对应的所有处理分支和待测试的业务场景进行度量，明确把握测试规模。另一方面，可以把不明确的需求变成明确的需求，明确其功能点对应的输入、处理和输出。2.1.3 测试需求分析内容为了有效的获取测试对象，需要从测试需求分析开始，测试需求分析可分为以下三部分内容：1) 明确需求的测试范围，即确定需求中包括了多少功能点。2) 明确功能的业务处理过程，对每一个功能点的输入、处理逻辑和输出进行提取。3)根据用户

7、需求，明确其在特定场景下实际使用时的流程及操作步骤，以明确测试 场景。2.1.4 测试需求分析与需求分析的区别内容需求分析测试需求分析目标对实现软件功能作全面的描述； 为开发人员提供开发依据；解决“测什么”的问题，指明被测系统 中有哪些功能点需要测试。对象业务需求说明书1) 系统需求规格说明书2) 系统详细设计说明书分析方法1)结构化分析法2) Jackson分析法3)面向对象的分析法1)模块分解法2) WB吩析法分析过程1)提出业务需求2)分析业务需求3) 整理和描述软件需求4) 评审软件需求1)采集测试需求采集2)分析测试需求分析3) 建立测试需求列表4) 评审测试需求分析产物系统需求规格

8、说明书测试需求分析清单2.2 测试需求分析过程测试需求分析是从软件需求规格说明书出发，对用户需求进行提取和采集，并整理 出功能点列表清单，然后逐一对功能点列表清单中的功能点进行分析形成测试需求列表。 最后对测试需求组织评审，根据评审结果对其进行确认、修改和调整。其分析流程可见 下图所示：图2-测试需求分析流程图说明：功能点列表原则上应随系统需求规格书等项目文档一起由项目组提供，只有在项目 文档未说明及项目组不提供的情况下方由测试人员进行梳理，但需提交项目组确认。2.2.1 测试需求采集测试需求的采集过程是将软件需求中的具有可测性的需求或特征提取出来，并通过 列表形式对软件需求进行梳理，形成功能

9、列表清单，列表的内容包括功能模块、功能点 编号和功能点描述。在提取软件需求的过程中，可能存在重复和冗余，所以在梳理过程 中，可以通过删除、细化及合并的方式对整理的功能列表清单进行调整。功能点列表清 单列表示例如下：功能模块功能点编号功能点描述由若干个功能点构成 的测试对象，能够实 现一个完整功能。按一定规范对功能 点进行编号组成功能模块内的一个具体的、细化的测试 对象，根据使用软件需求的简述作为功能点 描述。说明：1）为均衡功能点粒度，对于复杂度高、且有大功能模块的项目，功能模块的划分应按一 定的层级展开，即在原有功能模块的基础上再进行 2-3层的细化。2）编号规则：在进行测试需求及案例的设计

10、过程中， 需要对功能点、测试需求及测试案 例进行编号，以上3块内容的编号均采用顺序编号。现对以上3项制定编号规则如下： 功能点：FXXX测试需求：RXXX-XXX其中RXXXXXX加粗部分的编号为对应的功能点编号）测试案例：TXXX-XXX-XXX其中TXXX-XXXXXX加粗部分为对应的测试需求编号） 例1 :银保通系统（软件需求）功能模块功能点编号功能点描述保险公司信息维护保险公司新增F001组织保险公司新增数据，存入 保险公司基本信息表。“操作 柜员”和“更新时间”不需要 填写，页面自动带入。相同保 险公司信息只能存在一条记 录。新增成功后，显示“保险公司 增加成功”；新增失败时，停 留

11、当前页面，修改输入项后， 可以继续提交新增交易。2.2.2 测试需求分析测试需求分析过程是对功能点列表中列出的每一条功能需求细化和分解的过程，以 形成可测试的分层描述的测试要点的过程。对功能需求进行细化和分解的分析过程包括：1）通过分析每条功能需求描述中的输入、输出、 处理、限制与约束等，给出对应的验证内容。2）通过分析各个功能模块之间的业务顺序，以及各个功能模块之间对传递的信息和数据 存在的功能交互，给出对应的验证内容。3）经过分解获得的测试需求必须能够充分覆盖软件需求的各种特征，且每个需求都可以进行单独测试，以保证测试需求的完整性。4）每个测试需求能够使用数量相当的测试用例来实现，即尽量保

12、证测试案例的粒度是均 匀的。2.2.3 测试需求分析点根据以往测试需求分析工作的经验累积，发现在进行测试需求时通常可以从以下5个分析点开展测试需求分析工作，其对应的分析粒度亦可参考以下列表中的描述：测试需求分析点测试需求分析粒度界囿展小界面设计合理、内容显示正确性、操作便捷性输入域测试字段类型：数字/字符等字段长度字典值边界值测试输入域的可输入性：必输/可输输入域间的关联控制其他特殊要求约束条件数据约束 条件约束业务处理逻辑1） 根据功能点的处理逻辑进行分解，将其对应的所有处理分 支逐一进行分析与描述，并罗列为：业务处理逻辑1-XXXX业务处理逻辑2-XXXX2）对于类似与第三方的连接超时、队

13、列机制问题等非功能性的处理逻辑，应将其异常响应情况进行分析与描述，并罗 列为：非功能性异常处理逻辑 1-XXXX非功能性异常处理逻辑 2-XXXX输出结果校验根据输入数据，对每一个业务处理逻辑的输出结果进行正确性 校验。可以简单罗列为：输出结果校验-业务处理逻辑1输出结果校验-业务处理逻辑2例1 :银保通系统功能点描述测试需求 编R测试需求名称测试需求描述组织保险公司新增 数据，存入保险公司 基本信息表。“操作 柜员”和“更新时间” 不需要填写，页面自 动带入。相同保险公 司信息只能存在一 条记录。新增成功后，显示 “保险公司增加成功”；新增失败时， 停留当前页面，修改 输入项后，可以继续 提

14、交新增交易。R001-001界囿展小检查界囿的排列、布局符合用 户使用习惯，及显示内容正确。R001-002输入域测试-数据长度检查每个输入字段的数据长度 是否符合输入接口的要求。字 段明细如下：级别S1交易方式S1中文名称S20中文简称S20地址S20邮编S6法人代表姓名S20公司电话S20公司传真S20公司主页S20公司 E-mailS20保险总公司S4英义名称S20总部所在城市S20R001-003输入域测试-数据类型检查每个输入字段的数据类型是否符合输入接口的要求。（描 述同上，此处略。）R001-004输入域测试-字典值检查每个输入字段的字典值是 否符合输入接口的要求。（描 述同上，

15、此处略。）R001-005输入域测试-可输入性检查每个输入字段的可输入性 是否符合输入接口的要求。（描 述同上，此处略。）R001-006输入域测试-边界值对每个输入字段的输入数据进 行边界值验证。（描述同上， 此处略。）R001-007输入域测试-联动控制检查“操作柜员”和“更新时 间”是否贝囿自动带入，小需 要填写。R001-008业务处理逻辑校验1-新增已启信息检查相同保险公司信息是否只 能存在一条记录。R001-009业务处理逻辑校验2-新增成功输入符合接口要求的各字段信 息后点击“新增”保存，检查 保存是否成功，且提示“保险 公司增加成功”。R001-010业务处理逻辑校验3-新增失

16、败输入不符合接口要求的各字段 信息后点击“新增”保存，检 查保存是否失败。R001-011业务处理逻辑校验4-新增失败后修改新增失败后，是否停留当前页 面，修改输入项后，是否可以 继续提交新增交易。R001-012输出结果校验-新增成 功/失败新增成功后，可以在“保险公 司信息浏览”中查询到记录。新增失败后，无法在“保险公 司信息浏览”中查询到记录。例2:业务集中系统功能点 描述测试需 求编号测试需求名称测试需求描述电汇凭 证发起 系统内 汇兑凭 证号合 法性校 验R001-001业务逻辑处理1-凭证号不一 致电汇凭证发起系统内汇兑：1）凭证号校验不通过，进差错岗，选择正确值记账成功2）凭证号

17、校验不通过，进差错岗，选择错误值记账失败3）凭证号校验不通过，进差错岗，选择退回前台，前台取 消流程4）凭证号校验不通过，进差错岗，选择重新录入，差错授 权岗不通过，返差错退回前台取消流程5）凭证号校验不通过，进差错岗，选择重新录入，差错授 权岗不通过，返差错退回前台取消流程6）凭证号校验不通过，进差错岗，选择重新录入，差错授 权岗不通过，返差错再次录入正确值，授权通过记账成 功R001-002业务逻辑处理2-付款人账号 不f电汇凭证发起系统内汇兑：1）付款人账号校验不通过，进差错岗，选择正确值记账成 功2）付款账号校验不通过，进差错岗，选择错误值并退前台 取消流程3）付款人账号校验不通过，进

18、差错岗，选择退回前台，前 台取消流程4）付款人账号校验不通过，进差错岗，选择重新录入，差错授权通过，记账成功5）付款人账号校验不通过，进差错岗，选择重新录入，差 错授权不通过，返差错退回前台取消流程6）付款人账号校验不通过，进差错岗，选择重新录入，差 错授权不通过，返差错再次录入正确值授权通过记账成 功R001-003业务逻辑处理3-支密/、一致电汇凭证发起系统内汇兑“1）支付密码校验不通过，进复核岗，选择正确值，记账成 功。2）支付密码校验不通过，进复核岗，选择错误值，记账失 败。3）支付密码校验不通过，进复核岗，选择影像模糊，退回 前台，前台取消流程。4）支付管码校验不通过，进一次复核冈，

19、选择重新录入正 确值，二次复核选择一次复核录入值，记账成功。2.2.4 测试需求列表建立测试需求列表为软件需求与测试需求的对应关系表。建立测试需求列表是为了将上 述经分析、确定的功能需求、测试需求进行汇总并对其进行统一管理及维护。测试需求 列表格式如下：软件需求测试需求功能点 编R功能点描述测试需 求编号测试需求名称测试需求描述F001组织保险公司新 增数据，存入保 险公司基本信息 表。“操作柜员” 和“更新时间” 不需要填写，页 面自动带入。相 同保险公司信息 只能存在一条记 录。新增成功后，显 示“保险公司增 加成功”；新增 失败时，停留当 前页面，修改输 入项后，可以继R001-001界

20、囿展小检查界囿的排列、布局符合用 户使用习惯，及显示内容正确。R001-002输入域测试-数据长度检查每个输入字段的数据长度 是否符合输入接口的要求。R001-003输入域测试-数据类型检查每个输入字段的数据类型 是否符合输入接口的要求。R001-004输入域测试-数据字典检查每个输入字段的字典值是 否符合输入接口的要求。R001-005输入域测试-可输入性检查每个输入字段的可输入性 是否符合输入接口的要求。R001-006输入域测试-联动控制检查“操作柜员”和“更新时 间”是否贝囿自动带入，小需 要填写。R001-007输入域测试-边界值对每个输入字段的输入数据进 行边界值验证。R001-0

21、08业务处理逻辑校验1-检查相同保险公司信息是否只续提交新增交 易。新增已有信息能存在一条记录。R001-009业务处理逻辑校验 2- 新增成功输入符合接口要求的各字段信 息后点击“新增”保存，检查 保存是否成功，且提示“保险 公司增加成功”。R001-010业务处理逻辑校验3-新增失败输入不符合接口要求的各字段 信息后点击“新增”保存，检 查保存是否失败。R001-011业务处理逻辑校验 4- 新增失败后修改新增失败后，是否停留当前页 面，修改输入项后，是否可以 继续提交新增交易。R001-012输出结果校验-新增成 功/失败新增成功后，可以在“保险公 司信息浏览”中查询到记录。 新增失败后

22、，无法在“保险公 司信息浏览”中查询到记录。测试需求列表是需要不断维护的。一方面，在功能需求发生变化，就要对测试需求 列表进行更新，将其中与功能需求变更相关的内容进行同步变更。另一方面，随着测试 工作的进行，需不断添加新的跟踪内容，对其进行扩展。例如，测试案例设计阶段的测 试案例、测试执行阶段的测试结果记录和测试缺陷都可以添加到测试需求列表中。2.2.5 测试需求评审在测试需求分析完成后，应组织需求方、开发方和测试方进行测试需求的评审工作。 应分别从测试需求的完整性、准确性角度出发，对测试需求列表中的各项内容进行逐一 评审，评审时的关注点如下：2.2.6 注功能逻辑、数据定义、接口定义、系统约

23、束等方面的正确性。2）关注是否覆盖需求分析人员遗漏的、系统隐含的需求；3）关注各测试需求之间是否存在歧义和矛盾；4）关注各测试需求描述的详尽程度是否可以作为测试用例设计的依据；5）关注所描述的测试需求内容是否能够得到三方的一致理解。第3章测试案例设计3.1测试案例概述测试需求主要是整理测试点，包括界面、输入域、业务处理流程、结果校验等，为 测试用例的设计提供测试所需的功能点信息。所以，测试需求是告诉测试人员要测什么， 而测试用例是告诉测试人员怎么测，它应包括测试步骤、预期结果、测试数据等。根据测试案例的性质划分，测试案例可以划分为正案例和反案例。正案例：是指按系统功能正常运行的测试用例，即验证

24、系统是否能完成它应该完成的操作。正案例的设计主要依据系统需求规格说明书，详细设计文档等。反案例：则是相对正案例而言的，就指设计异常的测试用例，即验证系统是否对不该 完成的操作做出正确控制。反案例的设计主要依赖于测试人员的逆向思维能力及测试 经验。例1:数字型输入域的长度测试。功能描述：银保直联系统在新增保险公司时需输入 6位“邮编”信息。正案例：输入邮编“ 200001”。反案例：输入邮编“ 2000010”。例2:字段必输性测试。功能描述：银保直联系统在新增保险公司时“保险总公司”为必输项。正案例：输入正确的保险总公司信息。反案例：保险总公司信息输入为空。3.2 测试案例要素根据2011年测

25、试中心发布的上海浦东发展银行信息科技总部功能测试管理规程 中的“测试案例的管理方法”已明确，为规范功能测试工作和便于功能测试集中案例库 的建立和管理，功能测试案例需包含以下关键要素：案例要素要点描述系统名称描述被测系统的名称功能模块由若干个功能点构成的测试对象，能够实现一个完整功能，例如：某一个业务报表功能、某 一个业务交易等等功能点组成功能模块的一个细化的、特定的测试对 象，例如：交易中的一个输入域、业务交易中 一个校验规则、报表中的一个指标算法等。测试需求编号每个测试需求需根据一定编号规则进行编号。测试需求名称描述测试需求行所验证的测试内容。测试需求描述针对测试需求的测试内容进行描述。案例

26、编号每个案例需根据一定编号规则进行编号。测试案例名称描述案例执行所验证的测试点。案例描述针对案例的测试内容进行描述。测试步骤详细描述测试案例的前后步骤，便于测试执行人员操作。案例性质描述案例为正案例还是反案例。预期结果描述案例的预期执行结果测试数据描述执行该案例所需用到的测试数据，包括账号、金额等。案例编写人描述案例编写人员的名称，便于追溯。3.3 测试案例设计要点设计测试案例的主要是为了寻求系统设计、功能设计的弱点。所以，为保证测试案 例覆盖度，功能测试应从界面测试、边界值测试、关联测试、错误控制测试、业务逻辑 测试、安装测试等测试要点出发开展测试案例设计工作。3.3.1 界面测试1 .3.

27、1.1 简述界面是软件与用户最直接交互的对象，界面的优良直接决定了用户对软件的第一印 象。设计良好的界面能够很好的引导用户完成相应的操作，起到向导的作用，同时也能 给用户带来良好的用户体验。相反，如果界面设计杂乱无章，会让用户产生抵触心理， 即使功能再强大都是不成功的。2 .3.1.2测试关注点3 .界面测试软件的界面展示应该给使用者风格一致、美观协调的感觉，对软件界面的测试要点有：1）界面的排列尽可能的保持简洁清晰，使用户有一目了然的感觉，并应考虑用户的阅读 习惯。通常，界面设计过程中，同一窗口中不同功能模块放在不同的框架中展示。2）对于有特殊输入格式要求或需在固定范围内取值的输入域应给操作

28、人员明确的提示。 可采用输入域后直接给出示例输入格式或在界面底部设置提示栏给出提示信息相结合的方式。3）界面设计过程中需要考虑用户的使用习惯，设计便于用户操作的界面。4 .输入域测试对界面内的各输入域，测试输入域输入控制的合理性，主要内容有：1）输入域的输入内容类型的控制，如仅可输入字符型内容、输入字符是半角还是全角等;2）输入域的输入内容长度的控制，如控制输入10个字符；3）根据用户权限不同，相应控制输入域的可输入性；4）输入域之间的关联控制。5 .易用性测试界面上按钮名称应该用词准确、易于理解，同时要与同一界面上的其他按钮区分，力求用户不用查阅使用帮助的情况下就能进行正确操作，关于易用性测

29、试应关注以下几 点：1）完成同一功能或工作的要素应集中放置，减少鼠标移动的距离；2）默认按钮要支持Enter选择操作,即按Enter后自动执行默认按钮对应操作；3）必输的复选框和选项框要有默认选项，并支持Tab键选择；4）界面空间较小、选项数较多时使用下拉框而不用选项框，相反使用选项框。6 .3.1.3 实例例1:关于界面显示的测试。系统：现代支付系统二代-【EI03】汇兑业务-跨境业务个人网银-汇款-汇到浦发银行案例设计：可以从界面展示的合理性、对界面字段的检查设计测试案例。案例要素案例1案例2系统名称现代支付系统二代个人网银功能模块EI03-汇兑业务-跨境业务汇款功能点EI03-汇兑业务-

30、跨境业务汇到浦发银行测试需求编号EI03-001HDPF-001测试需求名称界囿展小界囿展小测试需求描述检查界面的排列、布局符合 用户使用习惯，及显示内容 正确。检查界囿的排列、布局符合 用户使用习惯、显示内容正 确、备注信息正确、相关按 键功能正确。案例编号ZF-EI03-001GRWY-001测试案例名称EI01-界面兀素检查EI01-页面兀素检查案例描述贝囿兀系显不正确，以输入 接口描述为准。包括操作标 志，业务编号，业务类型，业 务种类，扣款资金来源，扣款 销账序号等。以输入接口描述为准，验证 交易界面字段显示正确，同 时验证备注信息正确，“帮助”与“返回”键链接正确。测试步骤1 .进

31、入COP界面2 .输入交易码：【EI03】回车3 .进入EI03交易界面4 .检查页面上的各字段元 素。1 .登录个人网银2 .点击汇款-汇到浦发银行3 .进入汇款交易界面4 .检查界面上信息案例性质正案例正案例预期结果交易界面显不正确。交易界面显不正确。测试数据无无例2:关于输入域的测试。系统：现代支付系统二代-【EI03】汇兑业务-跨境业务案例设计：应结合输入接口文档，从各输入域字段的内容、长度、权限及联动关系等方 面来设计测试案例。案例要素案例1案例2系统名称现代支付系统二代现代支付系统二代功能模块EI03-汇兑业务-跨境业务EI03-汇兑业务-跨境业务功能点输入域-操作标志输入域-操作

32、标志测试需求编号ZF-EI03-002ZF-EI03-002测试需求名称输入域测试-字典值输入域测试-联动控制测试需求描述检查每个输入字段的字典值是 否符合输入接口的要求。检查各个输入域之间的联动控制 关系。案例编号ZF-EI03-001ZF-EI03-002测试案例名称输入域-操作标志-字典值输入域-操作标志-联动关系案例描述根据接口文档描述，验证操作 标志的字典值为：录入、复核、 修改、直通1) “操作标志”选择“录入”时， “业务编号”为/、可输入项；2) “操作标志”选择“复核” “修 改”或“直通”时，“业务编号” 为可输入项。测试步骤1 .登陆cop界面，进入EI032 .验证“操

33、作标志”可选择 41 .登陆cop界面，进入【EI03】2 .验证“操作标志”选择不同值个不同字典值时与业务编号的联动关系案例性质正案例正案例预期结果输入域字典值显示正确输入域联动关系正确测试数据无无例3:关于易用性的测试。系统：现代支付系统二代-【EI03】汇兑业务-跨境业务案例设计：以提供简单、易操作、无繁复步骤的操作界面为目标，设计相关测试案例。实例：EI03-汇兑业务-跨境业务交易在选择凭证种类时，需要打两次空格才能显示列表 信息，如果不输入两个空格会直接跳过，对用户在使用上造成不便。3.3.2 边界值测试3.3.2.1 简述在功能设计和编码中，常常对与需求说明书中的输入/输出域的边界

34、不够注意，以致 形成一些差错。在设计测试用例时，应选取正好等于、刚刚大于或刚刚小于边界值的测 试数据对边界附近的处理进行测试，就是边界值测试。对边界值的有效测试，可以发现 不少程序的缺陷，提高系统的可靠性。3.3.2.2 测试关注点对于边界值的测试，我们可以从以下几个角度开展测试案例的设计：1）如果输入条件规定了值的范围，可以选择正好等于边界值的数据作为合理的测试用例，同时还要选择刚好越过边界值的数据作为不合理的测试用例。如输入值的范围是1 , 100,可取0, 1, 100, 101等值作为测试数据。2）如果输入条件规定了输入数据的个数，则按最大个数、最小个数、比最小个数少1、比最大个数多1

35、等情况分别设计测试用例。如，一个输入文件可包含1 255条记录， 则可分别设计1条记录、255条记录，0条记录以及256条记录的输入文件的作为测 试用例。3）对每个输出条件分别按照以上原则（1）或（2）确定输出值的边界情况。如某个记录明细 查询页面，每页最多显示15条记录，则分别可以设计1和15条以及0和16条记录。4）如果输入域或输出域是个有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。3.3.2.3 实例例1:关于输入项的边界值测试。系统-模块：公司网银功能描述：转账支付功能，与大小额实时支付系统对接，汇款至其他银行机构。转账时 需输入转账金额、付款日期、收付款账号等。案例设

36、计：选择正好等于边界值的数据作为正常的测试用例，同时还要选择刚好越过边 界值的数据作为不合理的测试用例。案例要素案例1案例2系统名称公司网银公司网银功能模块转账支付转账支付功能点跨行支付跨行支付测试需求编号KHZF-001KHZF-002测试需求名称输入域测试-边界值测试输入域测试-边界值测试测试需求描述对每个输入字段的输入数据进 行边界值验证。对每个输入字段的输入数据进行 边界值验证。案例编号GSWY-ZZZF-001GSWY-ZZZF-001测试案例名称输入域-指定付款日期-边界值 测试输入域-转账金额-边界值测试案例描述,指定付款日期转账金额输入项必须大于0,验证转账金额等于0。测试步骤

37、1 .登录公司网银2 .点击转账支付-跨行转账3 .选择付款人账号、汇路4 .输入指定付款日期等信息1 .登录公司网银2 .点击转账支付-跨行转账3 .选择付款人账号、汇路4 .输入转账金额等信息案例性质反案例反案例预期结果系统提示：指定付款日期必须 大于等于当前日期系统提示：转账金额必须大于 0测试数据无。无。例2:关于查询结果的记录条数测试。系统-模块：支付网关（管理端）-交易明细查询功能描述：在支付网关管理中对每天个人交易进行明细查询。案例设计：对查询结果页面展示记录的条数的边界值测试，尤其注意对涉及翻页展示的边界值测试案例要素案例1案例2系统名称支付网关（管理端）支付网关功能模块交易明

38、细查询交易明细查询功能点个人交易查询当日明细个人交易查询当日明细测试需求编号JYMX-001JYMX-002测试需求名称输出域测试-边界值测试输出域测试-边界值测试测试需求描述对查询输出结果进行边界值验 证。对查询输出结果进行边界值验 证。案例编号ZFWG-JYMX-001ZFWG-JYMX-002测试案例名称输出域-当日订单明细-边界值 测试输出域-当日订单明细-边界值 测试案例描述查询商户当日的订单号信息，每 页最多显示 10条记录，验证 0-10条记录时的查询结果。查询商户当日的订单号信息，每 页最多显布10条记录，验证查 询记录为10条时，翻页功能是 含尢效；11条时是否能正常翻 页。

39、测试步骤1 .登录管埋端界面，点击支付网 关管理-交易明细查询2 .输入商户号，点击提交3 .检查查询出的定单信息1 .登录管埋端界面，点击支付网 关管理-交易明细查询2 .输入商户号，点击提交3 .检查查询出的定单信息案例性质正案例正案例预期结果成功查询商户当日的订单号信 息，并正确显示当日订单数据正确显示当日订单数据及翻页 功能正确。测试数据无。无。例3:关于导入导出文件的边界值测试。案例1:系统-模块：个人网银-批量汇款功能描述：行内批量汇款文件规定每个文件中所包含的汇款明细不超过100笔。案例设计：对导入文件中的记录数进行边界值测试，分别设计0笔、100笔、101笔记录的批量文件进行测

40、试。案例2:系统-模块：公司网银-转账支付功能描述：对查询周期内的批量转账记录进行明细查询并下载，查询周期内的记录显示 为单页20条记录。案例设计：对查询记录的下载文件的记录数的边界值测试，分别验证查询结果为0条、1条、20条、21条时的下载情况。案例要素案例1案例2系统名称个人网银公司网银功能模块汇款转账支付功能点批量汇款批量转账处理信息查询测试需求编号PLHK-001PLZZ-001测试需求名称输入域测试-边界值测试输出域测试-边界值测试测试需求描述对输入字段的输入数据进行边界 值验证。对下载输出结果进行边界值验 证。案例编号GRWY-PLHK-001GSWY-ZZZF-001测试案例名称

41、输入域-批量汇款文件-边界值测 试输出域-批量转账处理信息下载- 边界值测试案例描述批量转账文件上传，批量文件中 的转账总笔数上限为 100条，验 证转账总笔数为 0、100、101条。根据起始日期和终止日期查询批 量转账信息，验证当查询结果是 0条、1条、20条、21条时的下 载文件正确性。测试步骤1.登录个人网银，点击汇款-批量 汇款-批量转账文件上传3 .输入转账笔数、输入总金额4 .选择上传文件，点击提交5 .批量汇款确认1 .登录公司网银，点击转账支付2 .点击批量转账处理信息查询3 .输入起始日期，输入终止日期4 .点击提交，点出查询5 .点击TXT下载，保存义件6 .检查保存义件

42、案例性质正案例正案例预期结果批量文件中为0条记录时，系统 提示：批量文件内容不能为空。批量文件中为100条记录时，系 统提示：转账文件已经成功上传； 批量文件中为101条记录时，系 统提示：转账文件记录超过最大 记录数。下载查询记录为 0条的文件时， 系统提示：显示无相关信息，不 能下载。下载查询记录为1条、20条和21条的记录时，下载文 件中的记录数也应该是对应的1条、20条和21条。测试数据无无3.3.3 错误控制测试3.3.3.1 简述错误控制是指系统功能对异常情况的检查和响应。良好的错误控制决定了系统的可 用性，并确保系统对错误交易数据的有效判断。错误信息的捕捉和处理是每个系统中必 不

43、可少的一部分。在系统使用过程中，用户希望看到的是友好、易懂的错误信息。开发 人员希望看到的是信息详细、能便于准确定位问题产生原因的错误提示。3.3.3.2 测试关注点1 .业务逻辑错误控制测试对各类银行系统来说业务逻辑是系统的核心，整个系统都是围绕着业务逻辑设计开 发的。在业务逻辑测试时，可以从以下几方面着手验证其错误控制：1）对业务逻辑规定的岗位、角色测试和非规定岗位、角色的错误控制测试。2）对不符合业务逻辑的处理功能的错误控制测试。如违反操作顺序的错误控制测试、对 不能进行重复操作的错误控制测试。3）对不符合业务逻辑的误操作的错误控制测试。如误提交不完整的信息的错误控制测 试。2 .错误信

44、息提示1）遇到各类错误操作，系统是否给出相应的错误信息提示。2）系统在遇到各类错误时给出的错误信息是否简洁、正确、有指导性。3.3.3.3 实例例1:关于对业务逻辑规定的角色权限的错误控制测试。系统-模块：银基通系统-补录权限复核管理功能描述：只有总行管理员才能通过管理端放开或者关闭某分行（或所有分行）的补录 数据权限。案例设计： 根据业务处理对角色权限的控制，设计相应的正反案例。案例要素案例1案例2系统名称银保通直联系统银保通直联系统功能模块系统外交易数据补录系统外交易数据补录功能点补录权限管理补录权限管理测试需求编号BLFH-001BLFH-001测试需求名称业务处理逻辑校验-数据补录业务

45、处理逻辑校验-数据补录测试需求描述数据补录权限的放开及关闭数据补录权限的放开及关闭案例编号YBT_SJBL_001YBT_SJBL_002测试案例名称数据补录权限管理-总行管理员数据补录权限管理-非总行管理员案例描述用总行管理员才能放开或者关闭某分行（或所有分行）的补录数据权限用理财人员和分行管理员进行放 开或者关闭补录数据权限测试步骤1 .用总行管理员进入“系统参数 设置一补录权限管理”2 .选择或取消补录权限分行表 中的分行号3 .点击确认1 .用非总行管理员进入“系统参数设置一补录权限管理”2 .选择或取消补录权限分行表中的分行号3 .点击确认案例性质正案例反案例预期结果成功进行补录数据

46、权限的设置， 提示“数据补录权限配置成 功”。系统提示用户权限无法进行此操 作。测试数据无。无。例2:关于对不符合业务逻辑的误操作的错误控制测试。系统-模块：银保通直联系统-投保单重要信息修改功能描述：针对异联交易中产生的投保单，分行管理员可以对已经终止的投保单进行恢复。或对已经选择的产品的份数、保费、手续费金额或客户卡号进行更改。案例设计：在操作人员进行业务操作时，不可避免会碰到各种各样的误操作，所以在进 行案例时就应模拟各种可能出现的误操作场景， 验证系统对错误信息输入时的校验能力案例要素案例1案例2系统名称银保通直联系统银保通直联系统功能模块投保单重要信息修改投保单重要信息修改功能点修改

47、投保卡号修改产品信息测试需求编号XGTBD-001XGCP-001测试需求名称输出结果校验-修改投保卡号 失败输入域测试-可输入性测试需求描述验证在修改投保单卡号相关信 息失败时，错误提示信息正确。检查“份数/档期”字段的可输入 性是否符合输入接口的要求。案例编号YBT_XGKH_001YBT_XGCP_001测试案例名称修改卡号为已挂失/已销户的 借记卡时，交易提示错误信息。“份数/档期”必输项校验案例描述输入需修改新卡号为已挂失/已销户的借记卡当操作人员操作时，未对“份数 / 档期”输入相关信息。测试步骤1 .选择保险公司和填写投保单 号码2 .选择“修改投保卡号”功能 3.修改客户的卡号

48、信息，分行 管理员复核1 .选择保险公司和填写投保单号 码2 .选择“修改投保卡号”功能3 .填写需要修改的信息，分行管 理员复核案例性质反案例反案例预期结果提示报错信息，系统提示：该 卡状态错误。提示报错信息，系统提示：请输 入“份数/档期”。测试数据无。无。注：修改卡号为已销户的卡号例3:对不符合业务逻辑处理功能的错误控制测试。案例1:系统-模块：银保通直联系统-投保单数据同步功能描述：银保直联部分复杂产品需要转保险公司人工核保。在保险公司人工核保通过 后，需与保险公司同步投保单金额、产品及状态信息。在执行人工核保状态同步操作前, 投保单必须是已经成功签约和扣款。案例设计：对不符合正常操作

49、顺序，违反正常操作步骤的操作的错误控制。案例2:系统-模块：银保通直联系统-新保承保功能描述：对可以进行直联新保承保的保险总公司进行新保承保，实时对核保试算，银 行实时扣款。案例设计：对不能进行重复操作的错误控制测试。案例要素案例1案例2系统名称银保通直联系统银保通直联系统功能模块投保单数据同步直联新保承保功能点人工核保状态同步当日撤单测试需求编号RGHB-001DRCD-001测试需求名称业务处理逻辑校验-人工核保 失败业务处理逻辑校验-当日撤单失 败测试需求描述人工核保状态同步操作前，必 须是已经成功签约和扣款的投 保单。一个投保单号做了新保承保之 后，执行当日撤单操作成功后， 不允许再次

50、撤单。案例编号YBT_BDTB_001DRCD_BDXX_001测试案例名称未签约批扣的客户进行人工核 保状态同步操作失败报错。当日撤单后的保单再撤单案例描述用未完成签约和扣款操作的投 保单进行状态同步，提示错误。用已经做了新保承保之后，且当 日撤单成功的投保单号进行再次 撤单，提示错误信息。测试步骤1 .在银保通系统发起直联新保 承保交易，购买产品为复杂广 品，需要转人工核保2 .上传批量同步文件，执行批 处理1 .用理财经理登录银保通系统2 .进入直联新保承保- 当日撤单3 .输入投保卡号4 .输入复核投保单号5 .点击确认案例性质反案例反案例预期结果报错提示“客户未签约”系统提示错误或找

51、不到记录测试数据无无3.3.4关联测试3.3.4.1 简述关联性是指应用与应用之间的关联关系，可分为应用间互相调用关联、应用权限控 制关联、应用上下游数据关联。应用相互调用关联是指平台应用与应用之间通过接口进行程序控制或关联数据传 输，如后台应用与前置类应用之间的数据传送。应用权限控制关联是指一个应用需要通过使用另一个应用提供的具有相关权限的用 户，并只能通过此用户登录方可进行本应用业务处理的关联关系。如内部管理的各应用 需通过统一认证提供的用户进行登录，并通过统一认证应用对该用户进行权限控制。应用上下游关联是指通过上游应用通过特定的传输方式向下游系统提供数据。如平 台报表应用与其上游数据源和

52、数据交换相关应用的关联。3.3.4.2 测试关注点应用与应用之间的关联关系按照关联关系的表现形式不同测试的着重点也不同，可 以通过以下关注点进行测试案例的设计：1 .应用相互调用关联测试关注点1) 验证数据传输格式是否符合相关接口文档的描述，如接口的各个组成字段的长度、 字符类型、字典值、生成格式、通讯协议等。2) 测试数据准备时要考虑关联应用之前关键参数的配置、数据类型、数据长度、业务 约定等；3) 采用模拟器测试时要注意核对应用间相互关联的参数配置是否正确，应用端的展现 是否正确。2 .应用权限控制关联测试关注点1) 根据应用的用户权限控制层级和设置要求，验证权限控制应用的相关角色权限设置

53、 是否正确。2) 在对权限控制应用做修改时，也同时要对相关联应用进行通过性测试，包括权限控 制验证等。3 .应用上下游关联测试关注点1) 上游应用应关注数据源传输的正确性。2) 报表应用应关注对数据源、展现方式及结果的准确性的验证。3.3.4.3 实例例1:对应用权限控制的关联测试系统-系统：业务集中系统-统一认证平台功能描述：在登录业务集中系统时，需要经统一认证平台进行用户验证，只有具有相关 权限的用户方可对登录公文管理系统。对汇兑业务的发起功能也需要统一认证平台的进 行权限控制。案例设计：在登录权限控制验证时应设计有登录及无登录权限的用户进行正反案例的测 试。同时，对相关用户权限控制的有效性进行案例设计。案例要素案例1案例2系统名称业务集中系统业务集中系统功能模块用户登录汇兑业务功能点用户登录控制汇兑业务的操作权限控制测试需求编号YHDL-001H