在传统测试中，测试人员通过业务场景、业务规则和已有的测试经验设计测试案例。各条测试案例具有独立性，每条测试案例针对一个固定的业务场景下的具体分支进行验证。然而，这种设计方式常常不能反映“真实的生产环境”（即软件或系统真正对客提供服务运营的环境，以下简称“生产环境”）的当前情况、用户使用习惯以及各种不同业务场景下所衍生延伸出来的复杂关联关系，导致无法有针对性地对被测系统进行测试，更无法达到应有的测试深度。
在传统案例设计方法中，大部分测试案例都归属同一业务场景下，一个固定的业务场景对应一条或者多条测试案例。这种设计方法将一个个场景看成孤岛，彼此之间缺少逻辑关联或程序层面的内在联系。当项目规模较大，多个测试部门协同编写测试案例开展测试时这种“孤岛”效应越发明显。在生产环境下，如果单独执行场景“X”和场景“Y”的案例，都没有问题。而在执行场景“Y”案例之后再执行场景“X”的案例，程序却会报错。
二、场景案例设计方法
（一）核心概念
1.1、场景案例设计方法：
场景：特定情景下的主体活动。
金融场景：特定情景下的金融功能实现方式。
测试场景：金融场景下的回归特定金融功能实现方式的验证。
测试场景案例设计：在特定的测试场景下，面向用户的测试案例设计。
测试场景案例分为单交易场景和多交易场景。
单交易场景测试案例：一支单独交易发生的场景不同，前置条件不同，输入的数据不同而产生的测试案例。
多交易场景测试案例：多支交易发生的场景不同，交易间的逻辑、顺序不同而产生的测试案例。
1.2、场景业务流的划分
场景业务流指不同的输入选择和不同的交易顺序组合产生的业务流程。场景业务流通常分为三种：基本流、备选流、异常流。
基本流：表示通过业务流程时所有的输入和选择都正确，最终能达到目标的流程。
备选流：表示通过业务流程时有部分或全部的输入错误（或者操作错误）导致流程存在反复，但通过系统逻辑的自行纠正仍能最终达到目标的流程。
异常流：异常流表示通过业务流程时输入或选择产生的错误（或操作错误）无法通过系统自动纠正达到目标，而是异常终止的流程（举例：银行卡插入ATM—>输入3次错误的密码—>ATM吞卡）。
基本流、备选流和异常流如下图所示：
图1基本流、备选流和异常流关系图
基本流和不同的备选流、异常流组合形成不同的场景，如下表所示。
表1基本流、备选流和异常流组合场景表
（二）场景案例设计方法的特点
场景案例的设计者需要将自己当成用户，尽可能的全面模拟用户的不同情况下的操作，设计对应的测试点。
（1）模拟用户完成主业务逻辑流程的操作，即正确操作——验证软件系统的主体功能是否实现。
（2）模拟用户错误操作（包括错误地输入数据和错误的操作流程）——验证软件的自主纠错功能是否实现。
做场景案例设计，最重要的是想到一些特定的、特殊的场景。设计贴近生产活动的场景案例才能最大可能的模拟生产活动，测出关键缺陷。下面几种方法渠道可以帮助获取真实、特殊的场景。
（1）技术类异常流：系统底层程序出现问题时，上层程序应该有相应的判断处理逻辑。举例：涉及到多系统之间的通信，如报错“通信异常”或“超时未返回”，应该有对应的处理逻辑。
（2）与一线柜员进行研讨，虚心请教，弥补短板。
（3）研读业务制度，规则。这里的业务制度不是需求说明书，而是最新的人行发文，法律法规（比如最新的资管新规等）。理解明晰制度，才能发现程序、甚至是需求说明书的逻辑漏洞。
（四）场景案例设计步骤
单交易场景和多交易场景的设计步骤相同。具体步骤如下：
步骤一：研读业务需求，确定业务流程（基本流、备选流、异常流）
例如：资金保付产品的退金交易。
1．基本流：退金成功。
2．备选流：在退金过程中出现的分支路径。
3．异常流：异常流表示通过业务流程时输入错误数值（比如退金金额等）产生异常终止流程。
步骤二：绘制流程图，再次确认流程路径。根据基本流、备选流和异常流，生成场景。
步骤三：根据流程图，提取测试路径（每条测试路径需至少包含一条未走过的路径）
步骤四：对路径进行细化，通过边界值等价类等方法细化路径，根据场景编写测试案例，场景和测试案例不一定是完全映射关系。
三、案例实战：资金保付项目场景案例设计
资金保付迎合互联网交易市场发展的需要，以大型银行为保障，将交易各方纳入资金管控体系，实现资金流、信息流、物流的有效融合，从而形成互联网交易平台的金融服务综合解决方案。入金：钱从买家账户到银行保付账户（类似于支付宝的功能）。出金：前从银行保付账户进入卖家账户。退金：退货时钱从银行保付账户退回到买家账户。
（一）单交易场景：资金保付项目退金交易案例：
步骤一：确定业务流程
基本流：农行对农行入金后，再退金，退金成功。
备选流1：退金走二代渠道，退金成功
备选流2：退金走银联渠道，退金成功
备选流3：退金时，订单根据费用分拆。
备选流4：退金时，订单费用是扣除，还是退回。
备选流5：订单未确认时，就退金。退金成功。
异常流1：退金金额不符，退金失败。
步骤二：绘制流程图
图2单交易场景流程图
步骤三：抽取测试路径
表2单交易场景测试路径（节选前7个场景）
步骤四：细化路径，抽取测试用例。由于篇幅限制，退金场景选取1条案例举例。
表3单交易场景测试案例
（二）多交易场景：资金保付项目子合约签约联机全流程案例：
上述编写案例针对的是退金一支交易，是单交易场景，而项目涉及退金、入金、出金、子合约签约、解约以及四种渠道，涉及的场景更为复杂，我们称之为多交易场景。多交易场景的案例设计方法步骤是一样的，具体步骤如下。
基本流：子合约签约->收款白名单增加->入金（本行到本行）->日终跑批生成对账单->对账单正确->确认订单->出金->子合约解约。
备选流1：入金走超网渠道
备选流2：入金走二代渠道
备选流3：退金走二代渠道
备选流4：退金时，走农行对农行。
备选流5：对账单错误，退金。
备选流6：确认订单后，退金。
异常流1：子合约签约->出金。
异常流2：子合约签约->退金。
异常流3：入金完成->子合约解约。
异常流4：入金完成->再次重复签约。
资金保付项目交易级案例场景-联机签约
图3多交易场景流程图
根据基本流和备用流确定场景：
表4多交易场景测试路径（节选前8个场景）
步骤四：细化路径。抽取测试用例。由于篇幅所限，下面以场景1举例完成测试案例的设计。
表5多交易场景测试案例（节选）
四、结语
场景案例测试方法打通了不同交易场景之间的壁垒，解决了传统测试案例难以有效覆盖全部隐性测试点的难题。通过对项目背景的理解和对客户特征的剖析，可以有针对性地选择一些特殊案例加入到测试案例中，删掉冗余重复的案例，节省测试资源，降低业务场景测试成本，进而高效地提高测试效率，保障软件程序能安全、快捷、高质量地投产。