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

1、功能测试需求及案例设计指南上海浦东发展银行总行信息科技总部测试中心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测试案例

2、概述 .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目的为提高功能测试工作质量和效率， 提升相关人员在测试需求及案例上的设计技能，特制定功能测试需求及案例设计指南。本文主要介绍在银行业务系统测试过程中， 就测试需求及案例进行设计与编写的思路、过程及方

3、法， 用于指导相关测试人员更好地开展该阶段的测试工作。1.2试用范围本指南适用于在总分行开展的各类功能测试项目中，参与测试需求或测试案例设计、编写的测试人员查阅参考， 其中包括单元、 集成、系统或 UAT测试人员。1.3定义1) 软件需求：主要指用户为解决某个问题、或为实现某一目标、要求软件必须满足的条件或能力，包括业务需求、功能需求及非功能需求。业务需求：反映了用户对系统较高层次的目标要求，描述了用户希望产品必须要完成的任务。功能需求：定义了开发人员必须实现的软件功能， 包括处理流程、使用场景、业务规则、模型算法、控制逻辑等， 使得用户能完成实际操作，从而满足业务需求。非功能需求：是作为对功

4、能需求的补充，它描述了系统展现给用户的行为和执行的操作等。包括产品必须遵从的标准、规范和合约、性能要求、设计或实现的约束条件及质量属性。2) 功能点：组成功能模块的一个细化的、特定的测试对象，例如：交易中的一个输入域、业务交易中一个校验规则、报表中的一个指标算法等。3) 测试需求：以用户需求为基础，站在第三方测试的角度明确待测系统中需要测试的内容。4) 测试案例：测试案例是为特定目标或特定条件而设计的一组输入值、执行条件和预期结果。它是可以独立进行测试执行的最小单元，是执行具体测试的一个操作指导。1.4相关定义之间的关系软件需求与功能点、功能点与测试需求、测试需求与案例都是一对多的关系。软件需

5、求是基础， 功能点是软件需求的分解产物， 测试需求是对功能点进行剖析后形成的测试基础，测试案例则是对测试需求的操作细化。功能点 B功能点 A软件需求功能点 C软件需求功能点 F功能点 D功能点 E测试案测试需测试需例1求 1求5测试案测试案例 2测试例 6功能点 E需求 3测试需测试需测试案求2求4例 3测试案测试需测试案例 5求3例4图 1- 软件需求、功能点、测试需求、测试案例关系图第 2 章 测试需求分析2.1 测试需求分析概述2.1.1 测试需求测试需求主要解决 “测什么” 的问题，即指明被测系统中有哪些功能点需要测试。测试需求的主要来源是系统的需求规格说明书，有些无法从需求文档中获得

6、的需求，可通过系统的概要设计或者详细设计文档获得。测试人员依据对软件需求的细化分解来编写测试需求，以覆盖全部已定义的业务流程。同时，测试需求也是设计测试用例的依据，好的测试需求能发现需求中显性和隐性的测试点， 从而能更好的指导测试用例的设计，提高被测系统整体功能的覆盖率。2.1.2 测试需求分析的必要性在做一个测试项目之前， 首先必须了解测试规模、 复杂程度及可能存在的风险，这些都需要通过详细的测试需求来了解。 测试需求不明确， 只会造成获取的信息不正确，无法对所测系统有一个全面清晰的认识。由此可见，进行测试需求分析是十分必要的， 一方面，测试需求分析可以把不直观的需求， 转变为直观的需求。

7、对测试范围、 功能点对应的所有处理分支和待测试的业务场景进行度量， 明确把握测试规模。 另一方面，可以把不明确的需求变成明确的需求，明确其功能点对应的输入、处理和输出。2.1.3 测试需求分析内容为了有效的获取测试对象， 需要从测试需求分析开始， 测试需求分析可分为以下三部分内容：1) 明确需求的测试范围，即确定需求中包括了多少功能点。2) 明确功能的业务处理过程，对每一个功能点的输入、处理逻辑和输出进行提取。3) 根据用户需求，明确其在特定场景下实际使用时的流程及操作步骤，以明确测试场景。2.1.4 测试需求分析与需求分析的区别内容需求分析测试需求分析对实现软件功能作全面的描述；解决“测什么

8、”的问题，指明被测系统目标为开发人员提供开发依据；中有哪些功能点需要测试。对象业务需求说明书1)系统需求规格说明书2)系统详细设计说明书1)结构化分析法1)模块分解法分析方法2)Jackson 分析法2)WBS分析法3)面向对象的分析法1)提出业务需求1)采集测试需求采集分析过程2)分析业务需求2)分析测试需求分析3)整理和描述软件需求3)建立测试需求列表4)评审软件需求4)评审测试需求分析产物系统需求规格说明书测试需求分析清单2.2 测试需求分析过程测试需求分析是从软件需求规格说明书出发，对用户需求进行提取和采集，并整理出功能点列表清单， 然后逐一对功能点列表清单中的功能点进行分析形成测试需

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

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

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

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

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

14、行分析与描述，并罗列为：非功能性异常处理逻辑1-XXXX非功能性异常处理逻辑2-XXXX输出结果校验根据输入数据， 对每一个业务处理逻辑的输出结果进行正确性校验。可以简单罗列为：输出结果校验- 业务处理逻辑1输出结果校验- 业务处理逻辑2例 1：银保通系统测试需求测试需求名称测试需求描述功能点描述编号R001-001界面展示检查界面的排列、布局符合用户使用习惯，及显示内容正确。检查每个输入字段的数据长度是否符合输入接口的要求。字段明细如下：组织保险公司新增级别S1交易方式S1数据，存入保险公司中文名称S20基本信息表。“操作中文简称S20柜员”和“更新时间”地址S20不需要填写，页面自输入域测

15、试 - 数据长度S6R001-002邮编动带入。相同保险公法人代表姓名 S20司信息只能存在一公司电话S20条记录。公司传真S20新增成功后，显示公司主页S20“保险公司增加成公司 E-mailS20功”；新增失败时，保险总公司S4停留当前页面，修改英文名称S20输入项后，可以继续总部所在城市 S20提交新增交易。检查每个输入字段的数据类型R001-003输入域测试 - 数据类型是否符合输入接口的要求。 （描述同上，此处略。）检查每个输入字段的字典值是R001-004输入域测试 - 字典值否符合输入接口的要求。（描述同上，此处略。）检查每个输入字段的可输入性R001-005输入域测试 - 可输

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

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

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

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

20、4 测试需求列表建立测试需求列表为软件需求与测试需求的对应关系表。建立测试需求列表是为了将上述经分析、 确定的功能需求、 测试需求进行汇总并对其进行统一管理及维护。测试需求列表格式如下：软件需求测试需求功能点测试需测试需求描述功能点描述测试需求名称编号求编号组织保险公司新R001-001 界面展示检查界面的排列、布局符合用F001户使用习惯，及显示内容正确。增数据，存入保险公司基本信息表。“操作柜员”和“更新时间”不需要填写，页面自动带入。相同保险公司信息只能存在一条记录。新增成功后，显示“保险公司增加成功”；新增失败时，停留当前页面，修改输入项后，可以继续提交新增交易。R001-002输入域

21、测试 - 数据长度检查每个输入字段的数据长度是否符合输入接口的要求。R001-003输入域测试 - 数据类型检查每个输入字段的数据类型是否符合输入接口的要求。R001-004输入域测试 - 数据字典检查每个输入字段的字典值是否符合输入接口的要求。R001-005输入域测试 - 可输入性检查每个输入字段的可输入性是否符合输入接口的要求。检查“操作柜员”和“更新时R001-006输入域测试 - 联动控制间”是否页面自动带入，不需要填写。R001-007输入域测试 - 边界值对每个输入字段的输入数据进行边界值验证。R001-008业务处理逻辑校验1-检查相同保险公司信息是否只新增已有信息能存在一条记

22、录。输入符合接口要求的各字段信R001-009业务处理逻辑校验2-息后点击“新增”保存，检查新增成功保存是否成功，且提示“保险公司增加成功”。业务处理逻辑校验3-输入不符合接口要求的各字段R001-010信息后点击“新增”保存，检新增失败查保存是否失败。业务处理逻辑校验4-新增失败后，是否停留当前页R001-011面，修改输入项后，是否可以新增失败后修改继续提交新增交易。新增成功后，可以在“保险公R001-012输出结果校验 - 新增成司信息浏览”中查询到记录。功/失败新增失败后，无法在“保险公司信息浏览”中查询到记录。测试需求列表是需要不断维护的。 一方面，在功能需求发生变化， 就要对测试需

23、求列表进行更新， 将其中与功能需求变更相关的内容进行同步变更。 另一方面，随着测试工作的进行，需不断添加新的跟踪内容，对其进行扩展。例如，测试案例设计阶段的测试案例、 测试执行阶段的测试结果记录和测试缺陷都可以添加到测试需求列表中。2.2.5 测试需求评审在测试需求分析完成后， 应组织需求方、 开发方和测试方进行测试需求的评审工作。应分别从测试需求的完整性、 准确性角度出发， 对测试需求列表中的各项内容进行逐一评审， 评审时的关注点如下：1) 重点关注功能逻辑、数据定义、接口定义、系统约束等方面的正确性。2) 关注是否覆盖需求分析人员遗漏的、系统隐含的需求；3) 关注各测试需求之间是否存在歧义

24、和矛盾；4) 关注各测试需求描述的详尽程度是否可以作为测试用例设计的依据；5) 关注所描述的测试需求内容是否能够得到三方的一致理解。第 3 章 测试案例设计3.1 测试案例概述测试需求主要是整理测试点，包括界面、输入域、业务处理流程、结果校验等，为测试用例的设计提供测试所需的功能点信息。 所以，测试需求是告诉测试人员要测什么， 而测试用例是告诉测试人员怎么测， 它应包括测试步骤、 预期结果、测试数据等。根据测试案例的性质划分，测试案例可以划分为正案例和反案例。正案例：是指按系统功能正常运行的测试用例，即验证系统是否能完成它应该完成的操作。正案例的设计主要依据系统需求规格说明书，详细设计文档等。

25、反案例：则是相对正案例而言的，就指设计异常的测试用例，即验证系统是否对不该完成的操作做出正确控制。 反案例的设计主要依赖于测试人员的逆向思维能力及测试经验。例 1：数字型输入域的长度测试。功能描述：银保直联系统在新增保险公司时需输入6 位“邮编”信息。正案例：输入邮编“ 200001”。反案例：输入邮编“ 2000010”。例 2：字段必输性测试。功能描述：银保直联系统在新增保险公司时“保险总公司”为必输项。正案例：输入正确的保险总公司信息。反案例：保险总公司信息输入为空。3.2 测试案例要素根据 2011 年测试中心发布的上海浦东发展银行信息科技总部功能测试管理规程中的“测试案例的管理方法”

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

27、案例的测试内容进行描述。测试步骤详细描述测试案例的前后步骤，便于测试执行人员操作。案例性质描述案例为正案例还是反案例。预期结果描述案例的预期执行结果测试数据描述执行该案例所需用到的测试数据，包括账号、金额等。案例编写人描述案例编写人员的名称，便于追溯。3.3 测试案例设计要点设计测试案例的主要是为了寻求系统设计、功能设计的弱点。 所以，为保证测试案例覆盖度，功能测试应从界面测试、边界值测试、关联测试、错误控制测试、业务逻辑测试、安装测试等测试要点出发开展测试案例设计工作。3.3.1 界面测试3.3.1.1 简述界面是软件与用户最直接交互的对象，界面的优良直接决定了用户对软件的第一印象。设计良好

28、的界面能够很好的引导用户完成相应的操作，起到向导的作用，同时也能给用户带来良好的用户体验。相反，如果界面设计杂乱无章，会让用户产生抵触心理，即使功能再强大都是不成功的。3.3.1.2 测试关注点1. 界面测试软件的界面展示应该给使用者风格一致、 美观协调的感觉， 对软件界面的测试要点有：1) 界面的排列尽可能的保持简洁清晰，使用户有一目了然的感觉，并应考虑用户的阅读习惯。通常，界面设计过程中，同一窗口中不同功能模块放在不同的框架中展示。2) 对于有特殊输入格式要求或需在固定范围内取值的输入域应给操作人员明确的提示。可采用输入域后直接给出示例输入格式或在界面底部设置提示栏给出提示信息相结合的方式

29、。3) 界面设计过程中需要考虑用户的使用习惯，设计便于用户操作的界面。2. 输入域测试对界面内的各输入域，测试输入域输入控制的合理性，主要内容有：1) 输入域的输入内容类型的控制，如仅可输入字符型内容、输入字符是半角还是全角等；2) 输入域的输入内容长度的控制，如控制输入 10 个字符；3) 根据用户权限不同，相应控制输入域的可输入性；4) 输入域之间的关联控制。3. 易用性测试界面上按钮名称应该用词准确、 易于理解，同时要与同一界面上的其他按钮区分，力求用户不用查阅使用帮助的情况下就能进行正确操作， 关于易用性测试应关注以下几点：1) 完成同一功能或工作的要素应集中放置，减少鼠标移动的距离；

30、2) 默认按钮要支持 Enter 选择操作，即按 Enter 后自动执行默认按钮对应操作；3) 必输的复选框和选项框要有默认选项，并支持 Tab 键选择；4) 界面空间较小、选项数较多时使用下拉框而不用选项框，相反使用选项框。3.3.1.3 实例例 1：关于界面显示的测试。系统：现代支付系统二代 - 【 EI03】汇兑业务 - 跨境业务个人网银 - 汇款 - 汇到浦发银行案例设计：可以从界面展示的合理性、对界面字段的检查设计测试案例。案例要素案例 1案例 2系统名称现代支付系统二代个人网银功能模块EI03- 汇兑业务 - 跨境业务汇款功能点EI03- 汇兑业务 - 跨境业务汇到浦发银行测试需求

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

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

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

34、EI03 】 1. 登陆 cop 界面，进入【 EI03 】测试步骤2. 验证“操作标志”可选择 42. 验证“操作标志”选择不同值个不同字典值时与业务编号的联动关系案例性质正案例正案例预期结果输入域字典值显示正确输入域联动关系正确测试数据无无例 3：关于易用性的测试。系统：现代支付系统二代 - 【 EI03】汇兑业务 - 跨境业务案例设计：以提供简单、易操作、无繁复步骤的操作界面为目标，设计相关测试案例。实例： EI03- 汇兑业务 -跨境业务交易在选择凭证种类时，需要打两次空格才能显示列表信息，如果不输入两个空格会直接跳过，对用户在使用上造成不便。3.3.2 边界值测试3.3.2.1 简述在功能设计和编码中，常常对与需求说明书中的输入/ 输出域的边界不够注意，以致形成一些差错。在设计测试用例时，应选取正好等于、刚刚大于或刚刚小于边界值的测试数据对边界附近的处理进行测试，就是边界值测试。 对边界值的有效测试，可以发现不少程序的缺陷，提高