软件测试工程师必备：掌握场景分析法快速设计测试用例！

软件测试工程师必备：掌握场景分析法快速设计测试用例！

　　充电宝软件,胎动软件,办公看图软件在传统测试中，测试人员通过业务场景、业务规则和已有的测试经验设计测试案例。各条测试案例具有独立性，每条测试案例针对一个固定的业务场景下的具体分支进行验证。然而，这种设计方式常常不能反映“真实的生产环境”（即软件或系统真正对客提供服务运营的环境，以下简称“生产环境”）的当前情况、用户使用习惯以及各种不同业务场景下所衍生延伸出来的复杂关联关系，导致无法有针对性地对被测系统进行测试，更无法达到应有的测试深度。

　　在传统案例设计方法中，大部分测试案例都归属同一业务场景下，一个固定的业务场景对应一条或者多条测试案例。这种设计方法将一个个场景看成孤岛，彼此之间缺少逻辑关联或程序层面的内在联系。当项目规模较大，多个测试部门协同编写测试案例开展测试时这种“孤岛”效应越发明显。在生产环境下，如果单独执行场景“X”和场景“Y”的案例，都没有问题。而在执行场景“Y”案例之后再执行场景“X”的案例，程序却会报错。

　　单交易场景测试案例：一支单独交易发生的场景不同，前置条件不同，输入的数据不同而产生的测试案例。

　　多交易场景测试案例：多支交易发生的场景不同，交易间的逻辑、顺序不同而产生的测试案例。

　　场景业务流指不同的输入选择和不同的交易顺序组合产生的业务流程。场景业务流通常分为三种：基本流、备选流、异常流。

　　基本流：表示通过业务流程时所有的输入和选择都正确，最终能达到目标的流程。

　　备选流：表示通过业务流程时有部分或全部的输入错误（或者操作错误）导致流程存在反复，但通过系统逻辑的自行纠正仍能最终达到目标的流程。

　　异常流：异常流表示通过业务流程时输入或选择产生的错误（或操作错误）无法通过系统自动纠正达到目标，而是异常终止的流程（举例：银行卡插入ATM—输入3次错误的密码—ATM吞卡）。

　　场景案例的设计者需要将自己当成用户，尽可能的全面模拟用户的不同情况下的操作，设计对应的测试点。

　　（1）模拟用户完成主业务逻辑流程的操作，即正确操作——验证软件系统的主体功能是否实现。

　　（2）模拟用户错误操作（包括错误地输入数据和错误的操作流程）——验证软件的自主纠错功能是否实现。

　　做场景案例设计，最重要的是想到一些特定的、特殊的场景。设计贴近生产活动的场景案例才能最大可能的模拟生产活动，测出关键缺陷。下面几种方法渠道可以帮助获取真实、特殊的场景。

　　（1）技术类异常流：系统底层程序出现问题时，上层程序应该有相应的判断处理逻辑。举例：涉及到多系统之间的通信，如报错“通信异常”或“超时未返回”，应该有对应的处理逻辑。

　　（3）研读业务制度，规则。这里的业务制度不是需求说明书，而是最新的人行发文，法律法规（比如最新的资管新规等）。理解明晰制度，才能发现程序、甚至是需求说明书的逻辑漏洞。

　　3．异常流：异常流表示通过业务流程时输入错误数值（比如退金金额等）产生异常终止流程。

　　步骤二：绘制流程图，再次确认流程路径。根据基本流、备选流和异常流，生成场景。

　　步骤三：根据流程图，提取测试路径（每条测试路径需至少包含一条未走过的路径）

　　步骤四：对路径进行细化，通过边界值等价类等方法细化路径，根据场景编写测试案例，场景和测试案例不一定是完全映射关系。

　　资金保付迎合互联网交易市场发展的需要，以大型银行为保障，将交易各方纳入资金管控体系，实现资金流、信息流、物流的有效融合，从而形成互联网交易平台的金融服务综合解决方案。入金：钱从买家账户到银行保付账户（类似于支付宝的功能）。出金：前从银行保付账户进入卖家账户。退金：退货时钱从银行保付账户退回到买家账户。

　　步骤四：细化路径，抽取测试用例。由于篇幅限制，退金场景选取1条案例举例。

　　上述编写案例针对的是退金一支交易，是单交易场景，而项目涉及退金、入金、出金、子合约签约、解约以及四种渠道，涉及的场景更为复杂，我们称之为多交易场景。多交易场景的案例设计方法步骤是一样的，具体步骤如下。

　　基本流：子合约签约-收款白名单增加-入金（本行到本行）-日终跑批生成对账单-对账单正确-确认订单-出金-子合约解约。

　　步骤四：细化路径。抽取测试用例。由于篇幅所限，下面以场景1举例完成测试案例的设计。

　　场景案例测试方法打通了不同交易场景之间的壁垒，解决了传统测试案例难以有效覆盖全部隐性测试点的难题。通过对项目背景的理解和对客户特征的剖析，可以有针对性地选择一些特殊案例加入到测试案例中，删掉冗余重复的案例，节省测试资源，降低业务场景测试成本，进而高效地提高测试效率，保障软件程序能安全、快捷、高质量地投产。