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

功能测试需求及案例设计指南功能测试需求及案例设计指南上海浦东发展银行总行信息科技总部测试中心2012年8月功能测试需求及案例设计指南2目目录录第第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功能测试需求及案例设计指南3第第1章章概述概述1.1目的目的为提高功能测试工作质量和效率，提升相关人员在测试需求及案例上的设计技能，特制定功能测试需求及案例设计指南。本文主要介绍在银行业务系统测试过程中，就测试需求及案例进行设计与编写的思路、过程及方法，用于指导相关测试人员更好地开展该阶段的测试工作。1.2试用范围试用范围本指南适用于在总分行开展的各类功能测试项目中，参与测试需求或测试案例设计、编写的测试人员查阅参考，其中包括单元、集成、系统或UAT测试人员。1.3定义定义1)软件需求：主要指用户为解决某个问题、或为实现某一目标、要求软件必须满足的条件或能力，包括业务需求、功能需求及非功能需求。业务需求：反映了用户对系统较高层次的目标要求，描述了用户希望产品必须要完成的任务。功能需求：定义了开发人员必须实现的软件功能，包括处理流程、使用场景、业务规则、模型算法、控制逻辑等，使得用户能完成实际操作，从而满足业务需求。非功能需求：是作为对功能需求的补充，它描述了系统展现给用户的行为和执行的操作等。包括产品必须遵从的标准、规范和合约、性能要求、设计或实现的约束条件及质量属性。2)功能点：组成功能模块的一个细化的、特定的测试对象，例如：交易中的一个输入域、业务交易中一个校验规则、报表中的一个指标算法等。3)测试需求：以用户需求为基础，站在第三方测试的角度明确待测系统中需要测试的内容。功能测试需求及案例设计指南44)测试案例：测试案例是为特定目标或特定条件而设计的一组输入值、执行条件和预期结果。它是可以独立进行测试执行的最小单元，是执行具体测试的一个操作指导。1.4相关定义之间的关系相关定义之间的关系软件需求与功能点、功能点与测试需求、测试需求与案例都是一对多的关系。软件需求是基础，功能点是软件需求的分解产物，测试需求是对功能点进行剖析后形成的测试基础，测试案例则是对测试需求的操作细化。软软件件需需求求功功能能点点AA功功能能点点EE测测试试需需求求33功功能能点点FF功功能能点点DD功功能能点点CC功功能能点点BB功功能能点点EE软软件件需需求求测测试试需需求求11测测试试需需求求22测测试试需需求求33测测试试需需求求44测测试试需需求求55测测试试案案例例22测测试试案案例例33测测试试案案例例44测测试试案案例例55测测试试案案例例66测测试试案案例例11图1-软件需求、功能点、测试需求、测试案例关系图第第2章章测试需求分析测试需求分析2.1测试需求分析概述测试需求分析概述2.1.1测试需求测试需求测试需求主要解决“测什么”的问题，即指明被测系统中有哪些功能点需功能测试需求及案例设计指南5要测试。测试需求的主要来源是系统的需求规格说明书，有些无法从需求文档中获得的需求，可通过系统的概要设计或者详细设计文档获得。测试人员依据对软件需求的细化分解来编写测试需求，以覆盖全部已定义的业务流程。同时，测试需求也是设计测试用例的依据，好的测试需求能发现需求中显性和隐性的测试点，从而能更好的指导测试用例的设计，提高被测系统整体功能的覆盖率。2.1.2测试需求分析的必要性测试需求分析的必要性在做一个测试项目之前，首先必须了解测试规模、复杂程度及可能存在的风险，这些都需要通过详细的测试需求来了解。测试需求不明确，只会造成获取的信息不正确，无法对所测系统有一个全面清晰的认识。由此可见，进行测试需求分析是十分必要的，一方面，测试需求分析可以把不直观的需求，转变为直观的需求。对测试范围、功能点对应的所有处理分支和待测试的业务场景进行度量，明确把握测试规模。另一方面，可以把不明确的需求变成明确的需求，明确其功能点对应的输入、处理和输出。2.1.3测试需求分析内容测试需求分析内容为了有效的获取测试对象，需要从测试需求分析开始，测试需求分析可分为以下三部分内容：1)明确需求的测试范围，即确定需求中包括了多少功能点。2)明确功能的业务处理过程，对每一个功能点的输入、处理逻辑和输出进行提取。3)根据用户需求，明确其在特定场景下实际使用时的流程及操作步骤，以明确测试场景。2.1.4测试需求分析与需求分析的区别测试需求分析与需求分析的区别内容内容需求分析需求分析测试需求分析测试需求分析目标目标对实现软件功能作全面的描述；为开发人员提供开发依据；解决“测什么”的问题，指明被测系统中有哪些功能点需要测试。功能测试需求及案例设计指南6对象对象业务需求说明书1)系统需求规格说明书2)系统详细设计说明书分析方法分析方法1)结构化分析法2)Jackson分析法3)面向对象的分析法1)模块分解法2)WBS分析法分析过程分析过程1)提出业务需求2)分析业务需求3)整理和描述软件需求4)评审软件需求1)采集测试需求采集2)分析测试需求分析3)建立测试需求列表4)评审测试需求分析产物分析产物系统需求规格说明书测试需求分析清单2.2测试需求分析过程测试需求分析过程测试需求分析是从软件需求规格说明书出发，对用户需求进行提取和采集，并整理出功能点列表清单，然后逐一对功能点列表清单中的功能点进行分析形成测试需求列表。最后对测试需求组织评审，根据评审结果对其进行确认、修改和调整。其分析流程可见下图所示：软件需求说明书系统详细设计说明书功能点分析测试需求需求采集测试需求分析测试需求评审评审结论测试需求列表输入输出分析过程功能点列表图2-测试需求分析流程图说明：功能点列表原则上应随系统需求规格书等项目文档一起由项目组提供，只有在项目文档未说明及项目组不提供的情况下方由测试人员进行梳理，但需提交项目组确认。功能测试需求及案例设计指南72.2.1测试需求采集测试需求采集测试需求的采集过程是将软件需求中的具有可测性的需求或特征提取出来，并通过列表形式对软件需求进行梳理，形成功能列表清单，列表的内容包括功能模块、功能点编号和功能点描述。在提取软件需求的过程中，可能存在重复和冗余，所以在梳理过程中，可以通过删除、细化及合并的方式对整理的功能列表清单进行调整。功能点列表清单列表示例如下：功能模块功能模块功能点编号功能点编号功能点描述功能点描述由若干个功能点构成的测试对象，能够实现一个完整功能。按一定规范对功能点进行编号组成功能模块内的一个具体的、细化的测试对象，根据使用软件需求的简述作为功能点描述。说明：1)为均衡功能点粒度，对于复杂度高、且有大功能模块的项目，功能模块的划分应按一定的层级展开，即在原有功能模块的基础上再进行2-3层的细化。2)编号规则：在进行测试需求及案例的设计过程中，需要对功能点、测试需求及测试案例进行编号，以上3块内容的编号均采用顺序编号。现对以上3项制定编号规则如下：功能点：FXXX测试需求：RXXX-XXX（其中RXXXXXX-XXX加粗部分的编号为对应的功能点编号）测试案例：TXXX-XXX-XXX（其中TXXX-XXXXXX-XXX-XXX加粗部分为对应的测试需求编号）例1：银保通系统（软件需求）功能模块功能模块功能点编号功能点编号功能点描述功能点描述保险公司信息维护保险公司新增F001组织保险公司新增数据，存入保险公司基本信息表。“操作柜员”和“更新时间”不需要填写，页面自动带入。相同保险公司信息只能存在一条记录。新增成功后，显示“保险公司功能测试需求及案例设计指南8增加成功”；新增失败时，停留当前页面，修改输入项后，可以继续提交新增交易。2.2.2测试需求分析测试需求分析测试需求分析过程是对功能点列表中列出的每一条功能需求细化和分解的过程，以形成可测试的分层描述的测试要点的过程。对功能需求进行细化和分解的分析过程包括：1)通过分析每条功能需求描述中的输入、输出、处理、限制与约束等，给出对应的验证内容。2)通过分析各个功能模块之间的业务顺序，以及各个功能模块之间对传递的信息和数据存在的功能交互，给出对应的验证内容。3)经过分解获得的测试需求必须能够充分覆盖软件需求的各种特征，且每个需求都可以进行单独测试，以保证测试需求的完整性。4)每个测试需求能够使用数量相当的测试用例来实现，即尽量保证测试案例的粒度是均匀的。2.2.3测试需求分析点测试需求分析点根据以往测试需求分析工作的经验累积，发现在进行测试需求时通常可以从以下5个分析点开展测试需求分析工作，其对应的分析粒度亦可参考以下列表中的描述：测试需求分析点测试需求分析点测试需求分析粒度测试需求分析粒度界面展示界面设计合理、内容显示正确性、操作便捷性输入域测试字段类型：数字字符等字段长度字典值边界值测试输入域的可输入性：必输可输输入域间的关联控制其他特殊要求约束条件数据约束条件约束业务处理逻辑1)根据功能点的处理逻辑进行分解，将其对应的所有处理功能测试需求及案例设计指南9分支逐一进行分析与描述，并罗列为：业务处理逻辑1-XXXX业务处理逻辑2-XXXX2)对于类似与第三方的连接超时、队列机制问题等非功能性的处理逻辑，应将其异常响应情况进行分析与描述，并罗列为：非功能性异常处理逻辑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输入域测试-数据类型检查每个输入字段的数据类型是否符合输入接口的要求。功能测试需求及案例设计指南10（描述同上，此处略。）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）凭证号校验不通过，进差错岗，选择错误值记账失败功能测试需求及案例设计指南113）凭证号校验不通过，进差错岗，选择退回前台，前台取消流程4）凭证号校验不通过，进差错岗，选择重新录入，差错授权岗不通过，返差错退回前台取消流程5）凭证号校验不通过，进差错岗，选择重新录入，差错授权岗不通过，返差错退回前台取消流程6）凭证号校验不通过，进差错岗，选择重新录入，差错授权岗不通过，返差错再次录入正确值，授权通过记账成功R001-002业务逻辑处理2-付款人账号不一致电汇凭证发起系统内汇兑：1）付款人账号校验不通过，进差错岗，选择正确值记账成功2）付款账号校验不通过，进差错岗，选择错误值并退前台取消流程3）付款人账号校验不通过，进差错岗，选择退回前台，前台取消流程4）付款人账号校验不通过，进差错岗，选择重新录入，差错授权通过，记账成功5）付款人账号校验不通过，进差错岗，选择重新录入，差错授权不通过，返差错退回前台取消流程6）付款人账号校验不通过，进差错岗，选择重新录入，差错授权不通过，返差错再次录入正确值授权通过记账成功汇兑凭证号合法性校验R001-003业务逻辑处理3-支密不一致电汇凭证发起系统内汇兑“1）支付密码校验不通过，进复核岗，选择正确值，记账成功。2）支付密码校验不通过，进复核岗，选择错误值，记账失败。3）支付密码校验不通过，进复核岗，选择影像模糊，退回前台，前台取消流程。4）支付密码校验不通过，进一次复核岗，选择重新录入正确值，二次复核选择一次复核录入值，记账成功。2.2.4测试需求列表建立测试需求列表建立测试需求列表为软件需求与测试需求的对应关系表。建立测试需求列表是为了将上述经分析、确定的功能需求、测试需求进行汇总并对其进行统一管理及维护。测试需求列表格式如下：功能测试需求及案例设计指南12软件需求软件需求测试需求测试需求功能点功能点编号编号功能点描述功能点描述测试需求测试需求编号编号测试需求名称测试需求名称测试需求描述测试需求描述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-新增失败后修改新增失败后，是否停留当前页面，修改输入项后，是否可以继续提交新增交易。F001组织保险公司新增数据，存入保险公司基本信息表。“操作柜员”和“更新时间”不需要填写，页面自动带入。相同保险公司信息只能存在一条记录。新增成功后，显示“保险公司增加成功”；新增失败时，停留当前页面，修改输入项后，可以继续提交新增交易。R001-012输出结果校验-新增成功失败新增成功后，可以在“保险公司信息浏览”中查询到记录。新增失败后，无法在“保险公司信息浏览”中查询到记录。测试需求列表是需要不断维护的。一方面，在功能需求发生变化，就要对测试需求列表进行更新，将其中与功能需求变更相关的内容进行同步变更。另一方面，随着测试工作的进行，需不断添加新的跟踪内容，对其进行扩展。例如，测试案例设计阶段的测试案例、测试执行阶段的测试结果记录和测试缺陷都可以添加到测试需求列表中。功能测试需求及案例设计指南132.2.5测试需求评审测试需求评审在测试需求分析完成后，应组织需求方、开发方和测试方进行测试需求的评审工作。应分别从测试需求的完整性、准确性角度出发，对测试需求列表中的各项内容进行逐一评审，评审时的关注点如下：1)重点关注功能逻辑、数据定义、接口定义、系统约束等方面的正确性。2)关注是否覆盖需求分析人员遗漏的、系统隐含的需求；3)关注各测试需求之间是否存在歧义和矛盾；4)关注各测试需求描述的详尽程度是否可以作为测试用例设计的依据；5)关注所描述的测试需求内容是否能够得到三方的一致理解。第第3章章测试案例设计测试案例设计3.1测试案例概述测试案例概述测试需求主要是整理测试点，包括界面、输入域、业务处理流程、结果校验等，为测试用例的设计提供测试所需的功能点信息。所以，测试需求是告诉测试人员要测什么，而测试用例是告诉测试人员怎么测，它应包括测试步骤、预期结果、测试数据等。根据测试案例的性质划分，测试案例可以划分为正案例和反案例。正案例：是指按系统功能正常运行的测试用例，即验证系统是否能完成它应该完成的操作。正案例的设计主要依据系统需求规格说明书，详细设计文档等。反案例：则是相对正案例而言的，就指设计异常的测试用例，即验证系统是否对不该完成的操作做出正确控制。反案例的设计主要依赖于测试人员的逆向思维能力及测试经验。例1：数字型输入域的长度测试。功能描述：银保直联系统在新增保险公司时需输入6位“邮编”信息。正案例：输入邮编“200001”。反案例：输入邮编“2000010”。例2：字段必输性测试。功能描述：银保直联系统在新增保险公司时“保险总公司”为必输项。功能测试需求及案例设计指南14正案例：输入正确的保险总公司信息。反案例：保险总公司信息输入为空。3.2测试案例要素测试案例要素根据2011年测试中心发布的上海浦东发展银行信息科技总部功能测试管理规程中的“测试案例的管理方法”已明确，为规范功能测试工作和便于功能测试集中案例库的建立和管理，功能测试案例需包含以下关键要素：案例要素案例要素要点描述要点描述系统名称描述被测系统的名称功能模块由若干个功能点构成的测试对象，能够实现一个完整功能，例如：某一个业务报表功能、某一个业务交易等等功能点组成功能模块的一个细化的、特定的测试对象，例如：交易中的一个输入域、业务交易中一个校验规则、报表中的一个指标算法等。测试需求编号每个测试需求需根据一定编号规则进行编号。测试需求名称描述测试需求行所验证的测试内容。测试需求描述针对测试需求的测试内容进行描述。案例编号每个案例需根据一定编号规则进行编号。测试案例名称描述案例执行所验证的测试点。案例描述针对案例的测试内容进行描述。测试步骤详细描述测试案例的前后步骤，便于测试执行人员操作。案例性质描述案例为正案例还是反案例。预期结果描述案例的预期执行结果测试数据描述执行该案例所需用到的测试数据，包括账号、金额等。案例编写人描述案例编写人员的名称，便于追溯。3.3测试案例设计要点测试案例设计要点设计测试案例的主要是为了寻求系统设计、功能设计的弱点。所以，为保功能测试需求及案例设计指南15证测试案例覆盖度，功能测试应从界面测试、边界值测试、关联测试、错误控制测试、业务逻辑测试、安装测试等测试要点出发开展测试案例设计工作。3.3.1界面测试界面测试3.3.1.1简述简述界面是软件与用户最直接交互的对象，界面的优良直接决定了用户对软件的第一印象。设计良好的界面能够很好的引导用户完成相应的操作，起到向导的作用，同时也能给用户带来良好的用户体验。相反，如果界面设计杂乱无章，会让用户产生抵触心理，即使功能再强大都是不成功的。3.3.1.2测试关注点测试关注点1.1.界面测试界面测试软件的界面展示应该给使用者风格一致、美观协调的感觉，对软件界面的测试要点有：1)界面的排列尽可能的保持简洁清晰，使用户有一目了然的感觉，并应考虑用户的阅读习惯。通常，界面设计过程中，同一窗口中不同功能模块放在不同的框架中展示。2)对于有特殊输入格式要求或需在固定范围内取值的输入域应给操作人员明确的提示。可采用输入域后直接给出示例输入格式或在界面底部设置提示栏给出提示信息相结合的方式。3)界面设计过程中需要考虑用户的使用习惯，设计便于用户操作的界面。2.2.输入域测试输入域测试对界面内的各输入域，测试输入域输入控制的合理性，主要内容有：1)输入域的输入内容类型的控制，如仅可输入字符型内容、输入字符是半角还是全角等；2)输入域的输入内容长度的控制，如控制输入10个字符；3)根据用户权限不同，相应控制输入域的可输入性；4)输入域之间的关联控制。3.3.易用性测试易用性测试功能测试需求及案例设计指南16界面上按钮名称应该用词准确、易于理解，同时要与同一界面上的其他按钮区分，力求用户不用查阅使用帮助的情况下就能进行正确操作，关于易用性测试应关注以下几点：1)完成同一功能或工作的要素应集中放置，减少鼠标移动的距离；2)默认按钮要支持Enter选择操作，即按Enter后自动执行默认按钮对应操作；3)必输的复选框和选项框要有默认选项，并支持Tab键选择；4)界面空间较小、选项数较多时使用下拉框而不用选项框，相反使用选项框。3.3.1.3实例实例例1：关于界面显示的测试。系统：现代支付系统二代-【EI03】汇兑业务-跨境业务个人网银-汇款-汇到浦发银行案例设计：可以从界面展示的合理性、对界面字段的检查设计测试案例。案例要素案例要素案例案例11案例案例22系统名称现代支付系统二代个人网银功能模块EI03-汇兑业务-跨境业务汇款功能点EI03-汇兑业务-跨境业务汇到浦发银行测试需求编号EI03-001HDPF-001测试需求名称界面展示界面展示测试需求描述检查界面的排列、布局符合用户使用习惯，及显示内容正确。检查界面的排列、布局符合用户使用习惯、显示内容正确、备注信息正确、相关按键功能正确。案例编号ZF-EI03-001GRWY-001测试案例名称EI01-界面元素检查EI01-页面元素检查案例描述页面元素显示正确，以输入接口描述为准。包括操作标志业务编号业务类型业务种类扣款资金来源扣款销账序号等。以输入接口描述为准，验证交易界面字段显示正确，同时验证备注信息正确，“帮助”与“返回”键链接正确。功能测试需求及案例设计指南17测试步骤1.进入COP界面2.输入交易码：【EI03】回车3.进入EI03交易界面4.检查页面上的各字段元素。1.登录个人网银2.点击汇款-汇到浦发银行3.进入汇款交易界面4.检查界面上信息案例性质正案例正案例预期结果交易界面显示正确。交易界面显示正确。测试数据无无例2：关于输入域的测试。系统：现代支付系统二代-【EI03】汇兑业务-跨境业务案例设计：应结合输入接口文档，从各输入域字段的内容、长度、权限及联动功能测试需求及案例设计指南18关系等方面来设计测试案例。案例要素案例要素案例案例11案例案例22系统名称现代支付系统二代现代支付系统二代功能模块EI03-汇兑业务-跨境业务EI03-汇兑业务-跨境业务功能点输入域-操作标志输入域-操作标志测试需求编号ZF-EI03-002ZF-EI03-002测试需求名称输入域测试-字典值输入域测试-联动控制测试需求描述检查每个输入字段的字典值是否符合输入接口的要求。检查各个输入域之间的联动控制关系。案例编号ZF-EI03-001ZF-EI03-002测试案例名称输入域-操作标志-字典值输入域-操作标志-联动关系案例描述根据接口文档描述，验证操作标志的字典值为：录入、复核、修改、直通1）“操作标志”选择“录入”时，“业务编号”为不可输入项；2）“操作标志”选择“复核”“修改”或“直通”时，“业务编号”为可输入项。测试步骤1.登陆cop界面，进入【EI03】2.验证“操作标志”可选择4个不同字典值1.登陆cop界面，进入【EI03】2.验证“操作标志”选择不同值时与业务编号的联动关系案例性质正案例正案例预期结果输入域字典值显示正确输入域联动关系正确测试数据无无例3：关于易用性的测试。系统：现代支付系统二代-【EI03】汇兑业务-跨境业务案例设计：以提供简单、易操作、无繁复步骤的操作界面为目标，设计相关测试案例。实例：EI03-汇兑业务-跨境业务交易在选择凭证种类时，需要打两次空格才能显示列表信息，如果不输入两个空格会直接跳过，对用户在使用上造成不便。功能测试需求及案例设计指南193.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条记录。功能测试需求及案例设计指南204)如果输入域或输出域是个有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。3.3.2.3实例实例例1：关于输入项的边界值测试。系统-模块：公司网银功能描述：转账支付功能，与大小额实时支付系统对接，汇款至其他银行机构。转账时需输入转账金额、付款日期、收付款账号等。案例设计：选择正好等于边界值的数据作为正常的测试用例，同时还要选择刚好越过边界值的数据作为不合理的测试用例。案例要素案例要素案例案例11案例案例22系统名称公司网银公司网银功能模块转账支付转账支付功能点跨行支付跨行支付测试需求编号KHZF-001KHZF-002测试需求名称输入域测试-边界值测试输入域测试-边界值测试测试需求描述对每个输入字段的输入数据进行边界值验证。对每个输入字段的输入数据进行边界值验证。案例编号GSWY-ZZZF-001GSWY-ZZZF-001测试案例名称输入域-指定付款日期-边界值测试输入域-转账金额-边界值测试案例描述指定付款日期必须大于等于当前日期（20140516），指定付款日期为20140517转账金额输入项必须大于0，验证转账金额等于0。测试步骤1.登录公司网银2.点击转账支付-跨行转账3.选择付款人账号、汇路4.输入指定付款日期等信息1.登录公司网银2.点击转账支付-跨行转账3.选择付款人账号、汇路4.输入转账金额等信息案例性质反案例反案例预期结果系统提示：指定付款日期必须大于等于当前日期系统提示：转账金额必须大于0测试数据无。无。例2：关于查询结果的记录条数测试。系统-模块：支付网关（管理端）-交易明细查询功能测试需求及案例设计指南21功能描述：在支付网关管理中对每天个人交易进行明细查询。案例设计：对查询结果页面展示记录的条数的边界值测试，尤其注意对涉及翻页展示的边界值测试案例要素案例要素案例案例11案例案例22系统名称支付网关(管理端)支付网关功能模块交易明细查询交易明细查询功能点个人交易查询_当日明细个人交易查询_当日明细测试需求编号JYMX-001JYMX-002测试需求名称输出域测试-边界值测试输出域测试-边界值测试测试需求描述对查询输出结果进行边界值验证。对查询输出结果进行边界值验证。案例编号ZFWG-JYMX-001ZFWG-JYMX-002测试案例名称输出域-当日订单明细-边界值测试输出域-当日订单明细-边界值测试案例描述查询商户当日的订单号信息，每页最多显示10条记录，验证0-10条记录时的查询结果。查询商户当日的订单号信息，每页最多显示10条记录，验证查询记录为10条时，翻页功能是否无效；11条时是否能正常翻页。测试步骤1.登录管理端界面，点击支付网关管理-交易明细查询2.输入商户号，点击提交3.检查查询出的定单信息1.登录管理端界面，点击支付网关管理-交易明细查询2.输入商户号，点击提交3.检查查询出的定单信息案例性质正案例正案例预期结果成功查询商户当日的订单号信息，并正确显示当日订单数据正确显示当日订单数据及翻页功能正确。测试数据无。无。例3：关于导入导出文件的边界值测试。案例1：系统-模块：个人网银-批量汇款功能描述：行内批量汇款文件规定每个文件中所包含的汇款明细不超过100笔。案例设计：对导入文件中的记录数进行边界值测试，分别设计0笔、100笔、功能测试需求及案例设计指南22101笔记录的批量文件进行测试。案例2：系统-模块：公司网银-转账支付功能描述：对查询周期内的批量转账记录进行明细查询并下载，查询周期内的记录显示为单页20条记录。案例设计：对查询记录的下载文件的记录数的边界值测试，分别验证查询结果为0条、1条、20条、21条时的下载情况。案例要素案例要素案例案例11案例案例22系统名称个人网银公司网银功能模块汇款转账支付功能点批量汇款批量转账处理信息查询测试需求编号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条。功能测试需求及案例设计指南23记录数。测试数据无无3.3.3错误控制测试错误控制测试3.3.3.1简述简述错误控制是指系统功能对异常情况的检查和响应。良好的错误控制决定了系统的可用性，并确保系统对错误交易数据的有效判断。错误信息的捕捉和处理是每个系统中必不可少的一部分。在系统使用过程中，用户希望看到的是友好、易懂的错误信息。开发人员希望看到的是信息详细、能便于准确定位问题产生原因的错误提示。3.3.3.2测试关注点测试关注点1.业务逻辑错误控制测试对各类银行系统来说业务逻辑是系统的核心，整个系统都是围绕着业务逻辑设计开发的。在业务逻辑测试时，可以从以下几方面着手验证其错误控制：1)对业务逻辑规定的岗位、角色测试和非规定岗位、角色的错误控制测试。2)对不符合业务逻辑的处理功能的错误控制测试。如违反操作顺序的错误控制测试、对不能进行重复操作的错误控制测试。3)对不符合业务逻辑的误操作的错误控制测试。如误提交不完整的信息的错误控制测试。2.错误信息提示1)遇到各类错误操作，系统是否给出相应的错误信息提示。2)系统在遇到各类错误时给出的错误信息是否简洁、正确、有指导性。3.3.3.3实例实例例1：关于对业务逻辑规定的角色权限的错误控制测试。系统-模块：银基通系统-补录权限复核管理功能描述：只有总行管理员才能通过管理端放开或者关闭某分行（或所有分行）的补录数据权限。功能测试需求及案例设计指南24案例设计：根据业务处理对角色权限的控制，设计相应的正反案例。案例要素案例要素案例案例11案例案例22系统名称银保通直联系统银保通直联系统功能模块系统外交易数据补录系统外交易数据补录功能点补录权限管理补录权限管理测试需求编号BLFH-001BLFH-001测试需求名称业务处理逻辑校验-数据补录业务处理逻辑校验-数据补录测试需求描述数据补录权限的放开及关闭数据补录权限的放开及关闭案例编号YBT_SJBL_001YBT_SJBL_002测试案例名称数据补录权限管理-总行管理员数据补录权限管理-非总行管理员案例描述用总行管理员才能放开或者关闭某分行（或所有分行）的补录数据权限用理财人员和分行管理员进行放开或者关闭补录数据权限测试步骤1.用总行管理员进入“系统参数设置补录权限管理”2.选择或取消补录权限分行表中的分行号3.点击确认1.用非总行管理员进入“系统参数设置补录权限管理”2.选择或取消补录权限分行表中的分行号3.点击确认案例性质正案例反案例预期结果成功进行补录数据权限的设置，提示“数据补录权限配置成功”。系统提示用户权限无法进行此操作。测试数据无。无。功能测试需求及案例设计指南25例2：关于对不符合业务逻辑的误操作的错误控制测试。系统-模块：银保通直联系统-投保单重要信息修改功能描述：针对异联交易中产生的投保单，分行管理员可以对已经终止的投保单进行恢复。或对已经选择的产品的份数、保费、手续费金额或客户卡号进行更改。案例设计：在操作人员进行业务操作时，不可避免会碰到各种各样的误操作，所以在进行案例时就应模拟各种可能出现的误操作场景，验证系统对错误信息输入时的校验能力。案例要素案例要素案例案例