场景法设计测试用例最佳实践
场景法设计测试用例(以在线购物系统为例)
场景法设计测试用例（以在线购物系统为例）场景法设计测试用例在面向对象的软件开发中,事件触发机制是编程中经常遇到的。
（一）场景法原理现在的软件几乎都是用事件触发来控制流程的。
象GUI软件、游戏等。
事件触发时的情景并形成了场景，而同一事件不同的触发顺序和处理结果就形成了事件流。
这种在软件设计方面的思想可以引入到软件测试中，可以生动地描绘出事件触发时的情景，有利于设计测试用例，同时使测试用例更容易理解和执行。
在测试一个软件的时候，在场景法中，测试流程是软件功能按照正确的事件流实现的一条正确流程，那么我们把这个成为该软件的基本流；而凡是出现故障或缺陷的过程，就用备选流加以标注，这样的话，备选流就可以是从基本流来的，或是由备选流中引出的。
所以在进行图示的时候，就会发现每个事件流的颜色是不同的。
基本流和备选流：如下图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。
备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。
在这个图中，有一个基本流和四个备选流。
每个经过用例的可能路径，可以确定不同的用例场景。
从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：场景 1 基本流场景 2 基本流备选流 1 场景 3 基本流备选流 1 备选流 2 场景 4 基本流备选流 3 场景 5 基本流备选流 3 备选流 1 场景 6 基本流备选流 3 备选流 1 备选流 2场景 7 基本流备选流 4 场景 8 基本流备选流 3 备选流 4 下面是场景法的基本设计步骤:根据说明，描述出程序的基本流及各项备选流根据基本流和各项备选流生成不同的场景对每一个场景生成相应的测试用例对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值（二）场景法例子1、在线购物系统我们都在当当网或china-pub华章网上书店都订购过书籍，整个订购过程为：用户登录到网站后，进行书籍的选择，当选好自己心仪的书籍后进行订购，这时把所需图书放进购物车，等进行结帐的时候，用户需要登录自己注册的帐号，登录成功后，进行结帐并生成订单，整个购物过程结束。
测试用例（场景法）
测试⽤例（场景法）⼀、应⽤场合1、适合使⽤场景法软件界⾯特点：界⾯中有很少（或没有）填写项，所有的操作都是通过⿏标的单击、双击、拖拽等完成 （游戏的测试⾮常适合场景法）2、把⾃⼰当成最终的⽤户，尽可能真实全⾯的模拟⽤户的操作，设计出相应的测试点，⼀般包括两类：（1）模拟⽤户正确的操作、完成主要业务逻辑的动作——验证软件的主要功能是否实现（2）模拟⽤户错误的操作——验证软件错误处理能⼒3、场景法主要基于：（1）业务（需求）层⾯：对所测软件的重要功能、业务逻辑、⾏业背景深⼊理解（2）技术层⾯：基于等价类划分，有效等价类——模拟⽤户正确操作；⽆效等价类——模拟错误操作为什么⽤场景法设计测试⽤例？⼤多数业务软件由后台管理（⽐如：⽤户管理、⾓⾊管理、权限管理等等各种管理）和⼯作流等⼏个部分组成。
终端⽤户，期望软件能够实现业务需求，⽽不是简单的功能的组合。
对于单点功能利⽤等价类、边界值、判定表⽤例设计⽅法能够解决⼤部分问题。
涉及业务流程的软件系统，采⽤场景法⽐较合适。
⼆、核⼼概念场景业务流通常分为基本流、备选流、异常流程1.基本流：基本流表⽰通过业务流程时输⼊都正确，能达到⽬标的流程。
(插卡--》输⼊正确密码--》输⼊⾦额--》取款--》取卡)2.备选流：备选流表⽰通过业务流程时输⼊错误（或者操作错误）导致流程存在反复， 但是经过纠正后仍能达到能达到⽬标的流程.（插卡-->输⼊错误密码--》输⼊正确密码--》输⼊⾦额--》取款--》取卡）3.异常流：异常流表⽰通过业务流程时输⼊错误（或者操作错误）产⽣异常终⽌流程（插卡-->输⼊3次错误密码--》吞卡） .三、使⽤步骤步骤⼀:理解需求，确定业务流程（基本流程、备选流程、异常流程） 例如操作ATM机（1）基本流——正确取款（2）备选流——在取款过程中出现的主要错误 此步骤完全基于业务的理解步骤⼆：绘制流程图，再次确认流程路径根，据基本流和备选流，⽣成场景（熟练后，直接做该步）步骤三：根据业务流程图，抽取测试路径（每⼀路径需含⼀个未⾛过得路径）步骤四：细化路径，利⽤等价类边界值⽅法细化路径，抽取测试⽤例，根据场景，编写⽤例 场景和⽤例并不是⼀⼀对应的关系练习⼀：ATM机取款1、列出主要场景，分析需求找出基本流（正确操作）和备选流（错误操作） .1）输⼊密码，选择⾦额，点击确认，取⾛钞票，成功 .2）密码错误，给出提⽰！2、执⾏测试，把测试过的场景留下证迹（截图）。
测试用例设计--场景法
测试⽤例设计--场景法1、为什么⽤场景法设计测试⽤例？⼤多数业务软件由后台管理（⽐如：⽤户管理、⾓⾊管理、权限管理等等各种管理）和⼯作流等⼏个部分组成。
终端⽤户，期望软件能够实现业务需求，⽽不是简单的功能的组合。
对于单点功能利⽤等价类、边界值、判定表⽤例设计⽅法能够解决⼤部分问题。
涉及业务流程的软件系统，采⽤场景法⽐较合适。
2、什么是场景法？场景业务流通常分为基本流、备选流、异常流程基本流：基本流表⽰通过业务流程时输⼊都正确，能达到⽬标的流程。
(插卡--》输⼊正确密码--》输⼊⾦额--》取款--》取卡)备选流：备选流表⽰通过业务流程时输⼊错误（或者操作错误）导致流程存在反复，但是经过纠正后仍能达到能达到⽬标的流程.（插卡-->输⼊错误密码--》输⼊正确密码--》输⼊⾦额--》取款--》取卡）异常流：异常流表⽰通过业务流程时输⼊错误（或者操作错误）产⽣异常终⽌流程（插卡-->输⼊3次错误密码--》吞卡） .⼀个流程⽤户期望：⼊度唯⼀，出度唯⼀。
每⼀个流程都包含⼀个从未⾛过的流程节点。
3、场景法设计测试⽤例的步骤？步骤⼀:理解需求，确定业务流程（基本流程、备选流程、异常流程）步骤⼆：绘制流程图，再次确认流程路径步骤三：根据业务流程图，抽取测试路径（每⼀路径需含⼀个未⾛过得路径）步骤四：细化路径，利⽤等价类边界值⽅法细化路径，抽取测试⽤例4、场景法设计测试⽤例的优缺点？优点：涉及倒业务流程的业务需求适合⽤场景法缺点：只验证业务流程，不验证单点功能，⼀般先采⽤先⽤等价类，边界值，错误推断，判定表等⽅法对单点功能进⾏验证，验证通过后再采⽤场景法进⾏业务流程的验证。
5、场景法测试⽤例设计⽰例实例⼀：需求：流程图：测试⽤例：(根据流程图抽取路径时最好从最后⼀个判定条件抽取)1-》2-》3-》4-》5-》6-》7：进⼊发送⼦程序，有空闲缓冲写⼊空闲缓冲，写⼊成功启动发送命令，发送消息成功。
1-》2-》8-》10：进⼊发送⼦程序，⽆空闲缓冲发送失败消息。
[生活]场景法测试用例ATM机
![[生活]场景法测试用例ATM机](https://img.taocdn.com/s3/m/2213684e8bd63186bdebbc64.png)
[生活]场景法测试用例ATM机测试用例设计--场景法1. 定义现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。
这种在软件设计方面的思想也可引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有基本流和备选流。
右图中经过用例的每条路径都用基本流和备选流来表示:基本流用黑色表示，是经过用例的最简单的路径。
备选流用不同的彩色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中(如备选流 1 和 3);也可能起源于另一个备选流(如备选流 2)，或者终止用例而不再重新加入到某个流(如备选流 2 和 4)。
1. 应用的范围1) 基本上每个软件都会用到这种方法,因为每个软件后面都有业务的支撑 2) 比较常见的有: 网上购物流程, ATM机取款流程等1. 步骤1) 画出需要测试路径的流程图(一般选择工具Office Visio)2) 分析基本流和备选流3) 根据基本流和备选流设计测试用例1. 案例基本事件流:1、用户向ATM提款机中插入银行卡，如果银行卡是合法的，ATM提款机界面提示用户输入提款密码;参数1 银行密码参数类型字符串参数范围字符串为0,9之间的阿拉伯数字组合，密码长度为6位备注用户输入该银行卡的密码，ATM提款机与MainFrame传递密码，检验密码的正确性。
如果输入密码正确，提示用户输入取钱金额，提示信息为，“请输入您的提款额度”;用户输入取钱金额，系统校验金额正确，提示用户确认，提示信息为“您输入的金额是xxx，请确认，谢谢～”，用户按下确认键，确认需要提取的金额;参数1 取款金额参数类型整数参数范围 50~1500 RMB，单笔取款额最高为1500RMB;每24小时之内，取款的最高限额是4500RMB备注系统同步银行主机，点钞票，输出给用户，并且减掉数据库中该用户帐户中的存款金额。
场景法测试案例设计
场景法测试案例设计那咱得先确定一个要测试的东西，比如说一个简单的在线购物系统吧。
一、场景一：正常购物流程。
1. 场景描述。
小明是个网购达人，他想在这个购物网站上买一件T恤。
2. 测试用例。
用例编号：TC 001。
测试步骤：小明打开购物网站首页。
就像打开宝藏盒子一样，满心期待地等着各种好东西出现。
在搜索框输入“男款T恤”，然后点击搜索按钮。
这就像是在大海里捞针，不过是有目标的捞针。
从搜索结果里挑选一件他喜欢的T恤，点击进入商品详情页。
就像在一群小伙伴里挑出最顺眼的那个。
选择合适的尺码（比如L码）和颜色（比如蓝色）。
这就跟给娃娃挑衣服一样，得选合身又好看的。
点击“加入购物车”按钮，然后查看购物车，确认商品已经在购物车里了。
这就像把挑好的宝贝放进自己的小篮子里，得看看有没有放错。
进入购物车后，点击“结算”按钮。
这时候就像走向收银台准备付钱了。
填写收货地址、联系人姓名（小明）、联系电话。
这就像是告诉快递小哥，“把东西送到这个地方哦”。
选择支付方式，假设是微信支付，然后点击“支付”按钮，完成支付。
就像把钱交给收银员，只不过是在网上交。
预期结果：每一步操作都能顺利进行，没有出现错误提示。
支付成功后，会显示订单已提交成功，并且小明能收到订单确认短信或者邮件。
二、场景二：商品缺货情况。
1. 场景描述。
小红也想在这个网站买一款很热门的女款运动鞋，但是这款鞋可能缺货了。
2. 测试用例。
用例编号：TC 002。
测试步骤：小红打开购物网站，在搜索框输入“女款运动鞋 [品牌名]”，然后点击搜索。
找到她想要的那双鞋，点击进入商品详情页。
选择合适的尺码（比如37码）和颜色（比如白色），然后点击“加入购物车”按钮。
预期结果：如果商品缺货，应该显示“缺货”提示，并且无法加入购物车，会弹出类似“很抱歉，该商品目前缺货，请选择其他商品或者关注补货信息”的提示框。
三、场景三：错误的支付信息。
1. 场景描述。
小刚在购物网站买了一个电子设备，到支付环节的时候，他故意输入错误的支付密码。
场景设计法测试用例
运用场景法进行A TM提款的测试用例设计
1、根据说明，描述出程序的基本流及各项备选流
基本流：客户打开账户登录管理页面，输入了账号和密码，如不成功则显示不成功且无法进入界面，如成功进入账户管理，可选择进行提款，转账存款等操作，次过程收admin 银行系统管理员的控制，A TM操作员可以获得开启系统ATM机权限，次过程同样受到银行系统管理员admin的控制。
备选流1：客户进入个人账户时输入账号密码有误，无法进入账号信息页面。
备选流2：客户进入个人账户时输入账号密码无误时仍无法进入账号信息页面，跳转有误
备选流3：客户进入提款功能时，因客观余额不足无法提款。
备选流4：客户进入提款功能时，余额不足显示出错，仍无法提款。
备选流5：客户进入转款功能时，因客观余额不足无法转账。
备选流6：客户进入转款功能时，因收款方账号不合法（查封）无法转账。
备选流7：客户进入存款功能时，因客观现钞ATM验钞系统检测不合法，无法实现存款
备选流8：客户进入存款功能时，现金验收无误，系统无法实现存款
备选流9：银行系统管理员admin对客户的提款功能监控失效
备选流10：ATM操作员无法开启系统
备选流11：银行系统管理员admin对ATM操作员的操作失效。
2、根据基本流和各项备选流生成不同的场景
场景1：
场景2：
……
场景n：。
使用场景法设计测试用例
使⽤场景法设计测试⽤例场景法是通过描述流经⽤例的路径来确定的过程，这个流经过程要从⽤例开始到结束遍历其中所有的基本流和备选流。
场景法就是根据这些基本流和备选流的流经过程设计测试⽤例。
⽬前的软件⼏乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，⽽同⼀事件不同的触发顺序和处理结果形成事件流。
这种在软件设计⽅⾯的思想也可被引⼊到软件测试中，⽣动的描绘出事件触发时的情景，有利于测试设计者设计测试⽤例，同时测试⽤例也更容易被理解和执⾏。
提出这种测试思想的是Rational公司。
下⾯使⽤⽹上购物系统的购物场景举例说明。
（1）场景描述⽤户进⼊⽹上购物系统⽹站进⾏购物，选好物品后进⾏购买，这时需要使⽤账号登录，登录成功后付款，交易成功后⽣成订单，完成此次购物活动。
（2）使⽤场景法设计测试⽤例①确定基本流和备选流事件基本流 登录⽹上购物系统⽹站，选择物品，登录账号，付钱交易，⽣成订单备选流1账号不存在备选流2账号或密码错误备选流3 账号余额不⾜备选流4 ⽤户账户没有钱备选流5⽤户退出系统②根据基本流和备选流来确定场景场景1-成功购物基本流场景2-账号不存在基本流备选流1场景3-账号或密码错误基本流备选流2场景4-账号余额不⾜基本流备选流3场景5=⽤户账号没有钱基本流备选流4③设计⽤例对每个场景都要做测试⽤例，可以使⽤矩阵（表格）来管理⽤例。
⽤⾏表⽰各个测试⽤例，列表⽰测试⽤例的信息。
⾸先将测试⽤例的ID、条件、涉及的数据元素以及预期结果列在矩阵中，然后将这些数据确定下来，填写在表格中。
下表中，“有效”表⽰这个条件必须是有效的才可执⾏基本流，⽽“⽆效”⽤于表⽰这种条件下将激活所需备选流。
“不适⽤”表⽰这个条件不适⽤测试⽤例。
测试⽤例ID 场景/条件账号密码⽤户账号余额预期结果1场景1：成功购物有效有效有效成功购物2场景2：账号不存在 ⽆效不适⽤不适⽤提⽰账号不存在3场景3：账号或密码错误（账号正确密码错误）有效⽆效不适⽤提⽰账号或密码错误，返回基本流步骤34场景3：账号或密码错误（账号错误密码正确）⽆效有效不适⽤提⽰账号或密码错误，返回基本流步骤35场景4：⽤户账号余额不⾜ 有效有效⽆效提⽰⽤户账号余额不⾜请充值6场景5：⽤户账号没有钱有效有效⽆效提⽰账号余额请充值④设计上表测试⽤例数据，填⼊下表测试⽤例ID 场景/条件账号密码⽤户账号余额预期结果1场景1：成功购物wangsh password193成功购物2场景2：账号不存在 song不适⽤不适⽤提⽰账号不存在3场景3：账号或密码错误（账号正确wangsh666666不适⽤提⽰账号或密码错误，3密码错误）wangsh666666不适⽤返回基本流步骤34场景3：账号或密码错误（账号错误密码正确）song password不适⽤提⽰账号或密码错误，返回基本流步骤35场景4：⽤户账号余额不⾜ wangsh password2提⽰⽤户账号余额不⾜请充值6场景5：⽤户账号没有钱wangsh password0提⽰账号余额请充值。
场景法测试用例ATM机
测试用例设计--场景法1.定义现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。
这种在软件设计方面的思想也可引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有基本流和备选流。
右图中经过用例的每条路径都用基本流和备选流来表示:基本流用黑色表示，是经过用例的最简单的路径。
备选流用不同的彩色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1 和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2 和4）。
1.应用的范围1)?????? 基本上每个软件都会用到这种方法,因为每个软件后面都有业务的支撑2)?????? 比较常见的有: 网上购物流程, ATM机取款流程等1.步骤1)????? 画出需要测试路径的流程图(一般选择工具Office Visio)2)????? 分析基本流和备选流3)????? 根据基本流和备选流设计测试用例1.案例基本事件流：1、用户向ATM提款机中插入银行卡，如果银行卡是合法的，ATM提款机界面提示用户输入提款密码；用户输入该银行卡的密码，ATM提款机与MainFrame传递密码，检验密码的正确性。
如果输入密码正确，提示用户输入取钱金额，提示信息为，“请输入您的提款额度”；用户输入取钱金额，系统校验金额正确，提示用户确认，提示信息为“您输入的金额是xxx，请确认，谢谢！”，用户按下确认键，确认需要提取的金额；系统同步银行主机，点钞票，输出给用户，并且减掉数据库中该用户帐户中的存款金额。
用户提款，银行卡自动退出，用户取走现金，拔出银行卡，ATM提款机界面恢复到初始状态；备选事件流(考虑可能失败的地方)：1.在基本事件流1中：a)???????? 如果插入无效的银行卡，那么，在ATM提款机界面上提示用户“您使用的银行卡无效！”，3秒钟后，自动退出该银行卡。
场景设计法设计测试用例
场景设计法设计测试用例嘿，朋友们！今天咱们来唠唠这个场景设计法设计测试用例，就像厨师做菜得有个菜谱一样，测试用例就是软件测试的“菜谱”。
你想啊，软件就像一个神秘的大盒子，里面装满了各种奇奇怪怪的小玩意儿。
场景设计法呢，就像是拿着放大镜，一点一点去探索这个大盒子里每个角落的宝贝。
比如说，一个购物软件，那简直就是一个超级大集市。
这个集市里有琳琅满目的商品，就像天上的星星一样多。
我们设计测试用例的时候，就得想象自己是一个超级挑剔的顾客，从进入这个集市（打开软件）开始，就到处挑刺儿。
登录页面就像这个集市的大门，要是密码输错了，它可不能像个傻大门一样随便就开了，得像个忠诚的卫士一样把你拦住。
这时候我们的测试用例就像是给这个卫士出难题的捣蛋鬼，故意输错各种密码，看它是不是能坚守岗位。
再说说搜索功能，那简直就是这个集市里的寻宝地图。
我们输入关键词搜索商品的时候，要是搜出来的东西乱七八糟，就像从海里捞出来一堆石头，而不是我们想要的珍珠，那可不行。
测试用例这个时候就变成了一个严谨的鉴定师，输入各种奇葩的关键词，看这个寻宝地图是不是真的那么靠谱。
购物车功能呢，就像是我们的小推车。
要是我们把东西放进去，它突然就消失了，那就像小推车突然有个黑洞把东西都吞了一样恐怖。
测试用例得像个小侦探，仔细检查把东西放进购物车、修改数量、删除商品等各种操作，不能让这个小推车出乱子。
支付环节更是重中之重，就像在集市里结账的时候，要是这个过程像坐过山车一样忽上忽下，一会儿成功一会儿失败，那可就把顾客吓得够呛。
测试用例就像一个铁面无私的收银员，各种支付方式都要测试一遍，不能让任何一个漏洞溜过去。
还有商品详情页面，那得像个商品的小传记一样详细准确。
要是里面的信息错误百出，就像一个人的简历全是瞎编的一样可笑。
测试用例要像个认真的校对员，仔细核对每个商品详情里的内容。
软件的各个功能之间的交互也很重要，就像集市里各个摊位之间要和谐共处一样。
如果一个操作导致整个软件像多米诺骨牌一样全倒了，那可就乱套了。
软件测试用例 场景法 流程案例
软件测试用例场景法流程案例下载温馨提示:该文档是我店铺精心编制而成，希望大家下载以后，能够帮助大家解决实际的问题。
文档下载后可定制随意修改，请根据实际需要进行相应的调整和使用，谢谢!并且，本店铺为大家提供各种各样类型的实用资料，如教育随笔、日记赏析、句子摘抄、古诗大全、经典美文、话题作文、工作总结、词语解析、文案摘录、其他资料等等，如想了解不同资料格式和写法，敬请关注!Download tips: This document is carefully compiled by theeditor.I hope that after you download them,they can help yousolve practical problems. The document can be customized andmodified after downloading,please adjust and use it according toactual needs, thank you!In addition, our shop provides you with various types ofpractical materials,such as educational essays, diaryappreciation,sentence excerpts,ancient poems,classic articles,topic composition,work summary,word parsing,copy excerpts,other materials and so on,want to know different data formats andwriting methods,please pay attention!软件测试用例设计：场景法的流程实践在软件开发过程中，测试是确保产品质量的关键环节。
测试用例设计-场景法
测试用例设计-场景法（个人见解与学习）目录1、引言 (3)2、基本测试 (3)2.1、测试优缺点 (3)2.2、黑盒功能测试分解法 (3)2.3、个人简介篇 (3)3、场景法用例 (4)1、什么是场景法？ (4)2、场景法特点 (4)3.1、基本流 (6)3.2、分支流 (6)3.3、验证流 (7)3.4、异常 (7)3.4.1、个人简介 (7)4、场景法用例设计 (7)文档中红色字体的为理解的重点黄色背景的为个人简介和思路同时提出：这里只是说明一组方法。
具体如何使用，可以结合自己的标准来做。
1、引言文档属于个人的见解，个人看法。
因为我当时看到同样的一个项目，一个软件需求。
就是使用方法不一样；我们就写的用例覆盖率就出现了这么多的偏差。
2、基本测试如按照如下的方法去分解：功能测试、界面测试、性能测试、安全测试、数据库测试等等测试2.1、测试优缺点能够按照软件的功能块，一组一组的来做相应的模块测试。
但对整体业务场景考虑的不是很好，可能遗漏模块A与模块B之间的用例，因为该方法是从软件本身出发。
实际做测试时需要考虑的不是软件本身，还有对应的系统场景等情况。
不容易做回归测试，一旦回归需要考虑到用例的回归量。
后续测试时间会很长。
2.2、黑盒功能测试分解法✓在任何情况下都必须使用边界分析发，经验表明用这种方法设计出的测试用例发现程序错误的能力最强（边界法）✓必要时用等价类划分方法补充一些测试用例（等价类法）✓用错误推测法再追加一些测试用例（错误推测法）✓如果程序的功能说明中含有输入条件的组合情况，则已开始可选用因果图法（因果图法）✓对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例（功能图）其实这个经验就是方法，以上是一套方法。
2.3、个人简介篇上面的做法其实需要我们前期对功能的分解细密，在后期考虑到执行或者回归的时候。
安排妥当，不然每次回归或者执行测试都需要执行那么多用例，人员安排上不行，时间上也是不允许。
基于已有的购物经验,利用场景法为购买业务流程设计测试
基于已有的购物经验,利用场景法为购买业务流程设计测试以下是购买业务流程的场景设计和测试：场景一：购买电脑1. 场景设计：用户需要购买一台能够满足办公、娱乐、学习等各种需求的电脑。
用户选择进入电脑品牌官网进行浏览，查看有哪些款式和配置可以选择。
用户挑选出一款心仪的电脑并加入购物车。
在结算时，用户需要选择支付方式，并填写收货地址及联系方式等信息。
用户确认订单后，系统显示订单信息和支付金额，并提示用户进行支付。
用户完成支付后等待确认收货。
2. 测试用例：- 用户可以正常进入官网浏览电脑。
- 用户可以添加想购买的电脑到购物车中。
- 用户可以正常选择支付方式。
- 用户可以填写正确的收货地址和联系方式。
- 用户可以成功确认订单信息和支付金额。
- 网站可以正确显示订单信息和支付金额。
- 用户可以在规定时间内收到电脑。
场景二：购买衣服1. 场景设计：用户需要购买一件适合自己的衣服，用户打开购物网站并在分类中选择衣服、颜色、款式等筛选条件，展示符合用户需求的衣服，用户通过选择衣服、加入购物车等方式确定想要购买的衣服。
在结算时，用户选择支付方式，并填写收货地址及联系方式等信息。
用户确认订单后，系统显示订单信息和支付金额，并提示用户进行支付。
用户完成支付后等待确认收货。
2. 测试用例：- 用户可以正常进入网站并浏览衣服。
- 用户可以通过筛选找到自己想要的衣服。
- 用户可以将自己想要的衣服添加到购物车。
- 用户可以正常选择支付方式。
- 用户可以填写正确的收货地址和联系方式。
- 用户可以成功确认订单信息和支付金额。
- 网站可以正确显示订单信息和支付金额。
- 用户可以在规定时间内收到衣服。
场景三：购买食品1. 场景设计：用户需要购买一些食品，用户打开购物网站并在分类中选择食品、品牌、口味等筛选条件，展示符合用户需求的食品，用户通过选择食品、加入购物车等方式确定想要购买的食品。
在结算时，用户选择支付方式，并填写收货地址及联系方式等信息。
测试用例设计方法场景法
测试用例设计方法场景法场景法是一种测试用例设计方法，它基于软件系统在特定场景下的行为来设计和执行测试用例。
这种方法侧重于模拟用户在真实世界中使用系统的场景，以确保系统在这些场景中能够按照预期工作。
以下是场景法的基本步骤：识别基本流和备选流：基本流：描述软件产品或系统按照正常逻辑顺序执行的一系列操作，通常代表用户顺利完成某项任务或达到某个目标的流程。
备选流（异常流）：描述用户在与系统交互过程中可能遇到的异常或错误条件，以及系统对这些异常的处理方式。
定义场景：根据基本流和备选流，定义不同的使用场景。
每个场景代表一种特定的用户行为或系统状态。
场景通常包括正常场景（描述基本流）和异常场景（描述备选流）。
设计测试用例：为每个场景设计测试用例，确保每个场景都被充分测试。
测试用例应该包括场景的描述、预置条件（触发场景所需的系统状态或用户行为）、操作步骤和预期结果。
执行测试用例：按照测试用例的描述，模拟用户与系统交互，执行测试。
验证系统是否按照预期工作，并记录实际结果。
分析测试结果：比较实际结果与预期结果，判断测试是否通过。
如果测试未通过，分析原因，并可能需要修改测试用例或修复系统中的问题。
场景法的优点在于它基于实际使用场景设计测试用例，能够更好地模拟用户行为，并发现系统在实际使用中可能遇到的问题。
此外，场景法还可以帮助测试人员更好地理解系统功能和业务流程，提高测试效率。
例如，对于一个在线购物系统，可以使用场景法设计以下测试用例：正常场景：用户浏览商品、添加到购物车、结算、支付并成功收到商品。
异常场景：用户添加商品到购物车后，购物车中的商品数量不正确。
用户在结算时遇到支付失败的问题。
用户收到的商品与订单不符。
每个场景都可以设计一个或多个测试用例，以确保系统在这些场景下的行为符合预期。
给出场景设计测试用例面试题
给出场景设计测试用例面试题
当面试应聘者时，你可以设计一些关于场景的测试用例，以评估其分析、设计和执行测试的能力。
以下是一些示例：
1. 社交媒体应用：假设你正在测试一款社交媒体应用，测试的主要目标是确保用户能够轻松地创建和编辑个人资料、发布状态更新、上传和查看照片和视频，以及与其他用户互动。
请设计一份测试用例，以覆盖这些功能的主要方面。
2. 在线购物网站：假设你正在测试一个在线购物网站，该网站允许用户浏览商品、将商品添加到购物车、下订单、查看订单状态和历史记录。
请设计一份测试用例，以确保网站的所有功能都能正常工作。
3. 银行应用程序：假设你正在测试一个银行应用程序，该应用程序允许用户查看账户余额、转账、查看交易记录和账单等。
请设计一份测试用例，以确保应用程序的所有功能都能正常工作，并且安全性得到保障。
4. 在线支付系统：假设你正在测试一个在线支付系统，该系统允许用户在网站或应用上完成支付。
请设计一份测试用例，以确保系统能够处理各种支付场景，包括信用卡支付、银行转账和第三方支付方式等。
5. 视频会议系统：假设你正在测试一个视频会议系统，该系统允许用户加入和退出会议、共享屏幕、使用聊天功能和视频通话等。
请设计一份测试用例，
以确保系统能够处理各种会议场景，包括大型和小型会议、远程和本地参与者等。
对于每个场景，要求应聘者详细描述他们将如何设计和执行测试用例，以验证系统的功能、性能和安全性。
同时，可以询问他们如何处理复杂场景和异常情况，以及如何与开发团队和其他利益相关者合作。
用场景法设计激活的测试用例
用场景法设计激活的测试用例你有没有想过，为什么那些看起来简单的程序，常常在用起来的时候总会让人“吃个哑巴亏”？哎呀，你觉得问题不大，但一旦遇到错误，才知道这“小问题”把你害得有多惨。
是不是？你总以为一切都按部就班地运行着，结果给你一个“系统崩溃”的提示，就跟热锅上的蚂蚁一样，急得抓耳挠腮，特别是那种“高山仰止”的bug，总是隐藏得很深，稍微不留神就能把你给整“死”。
不过，咱说这些，归根结底还是想说，很多问题其实能在你一开始的时候，就通过激活测试给发现了。
别看这名字听起来有点“高大上”，其实它的原理简单得很，简单到让你想笑的程度。
简单来说，激活测试就是通过模拟用户使用场景，来看看软件在各种情况下会不会出问题。
哎呀，别觉得这只是个技术活，实际上它和我们日常生活有异曲同工之妙。
比如，你去超市买东西，假设你挑了几种水果，结果在结账的时候，系统突然崩溃，支付不成功。
你有没有想过，开发人员平时做测试时，肯定得考虑到这个情景：用户能不能顺利完成支付？这个就是场景法的一种应用。
说白了，场景法就是让开发者站在用户的角度，模拟各种真实的使用情况，避免他们“做梦都没想到”的情况发生。
想象一下，如果你在写代码时，一直觉得自己是个天才，忽略了可能发生的小问题，那么你的软件就可能像一个精致的泡沫一样，美丽却不堪一击。
要说这测试用例，其实也就像是我们生活中的“万事起头难”。
一开始做场景测试的时候，可能没有什么方向感，感觉自己像个瞎子摸鱼。
但渐渐地，你就会发现，这个方法可真是让人眼前一亮。
你得设想所有用户的行为，不管是正常的，还是他们的“意外之举”。
比如说，你的程序很正常地执行了一次登录，结果用户突然按下了返回按钮。
这种情况下，程序会不会崩溃？答案是，可能会。
怎么避免？就是写个测试用例，模拟这种情况，然后看看程序能不能“扛得住”。
比如，能不能优雅地退出，能不能保持之前的状态，能不能提示用户“慢点儿，别急”。
这种测试，用场景法来说就是“精确打击”，根本不容有失。
场景分析法实例
1.例子描述
下图所示是ATM例子的流程示意图。
2.场景设计：下表所示是生成的场景。
表3-8 场景设计
3.用例设计
对于这7个场景中的每一个场景都需要确定测试用例。
可以采用矩阵或决策表来确定和管理测试用例。
下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。
本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。
表3-9 测试用例表
测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据，如表3-10所示。
表3-10 测试用例表。
场景法测试用例
场景法测试用例
正文:
场景法是软件测试中常用的一种测试方法，它通过模拟真实的使用场景来测试软件的功能和性能。
在这种测试方法中，测试人员会根据实际使用情况，设计一系列的测试用例，以覆盖不同的场景和用户行为。
在测试用例的创建过程中，首先需要明确测试的目标和需求。
例如，一个电子商务网站的测试目标可能是验证用户登录功能的正确性和
稳定性，以及确认购物车功能是否正常工作。
然后，测试人员会根据这些目标，针对不同的场景设计相应的测试用例。
以电子商务网站为例，可以设计以下几个场景来测试用户登录功能：
1. 正常登录场景：用户输入正确的用户名和密码，登录成功。
2. 密码错误场景：用户输入正确的用户名但是错误的密码，登录失败，系统提示密码错误。
3. 用户名不存在场景：用户输入不存在的用户名，登录失败，系统提示用户名不存在。
4. 用户名为空场景：用户没有输入用户名，登录失败，系统提示用户名不能为空。
5. 密码为空场景：用户没有输入密码，登录失败，系统提示密码不能为空。
除了上述场景外，还可以设计其他一些特殊场景的测试用例，如：1. 高并发场景：模拟多个用户同时登录系统，测试系统的并发处理能力。
2. 长时间使用场景：模拟用户长时间使用系统，测试系统的稳定性和性能。
3. 异常操作场景：模拟用户在登录过程中进行异常操作，如中断网络连接，测试系统的容错能力。
在设计场景法测试用例时，需要考虑尽可能多的使用场景，以覆盖不同的用户行为和系统状态。
通过这种方法创建的测试用例可以更全面地测试软件的功能和性能，并发现潜在的问题和风险，提供给开发人员进行修复和改进。
应用场景测试用例
应用场景测试用例在智能出行的赛道上，应用场景测试用例大显神通“工欲善其事，必先利其器”，这句话放在当今科技日新月异的智能出行领域尤为贴切。
一款优秀的自动驾驶汽车，犹如一匹千里马，而应用场景测试用例，就是那把磨砺它的砺石，让其在复杂多变的真实环境中驰骋自如。
设想一下，在灯火阑珊的城市街头，一辆无人驾驶汽车正在面临一场“实战演练”。
此时，应用场景测试用例扮演的角色就如同一位严苛且充满智慧的教练，它设计了一系列贴近现实生活的挑战：“红绿灯路口突发行人横穿马路”、“施工路段临时改道”、“极端天气下能见度骤降”……这些详尽入微的应用场景测试用例，正是为了确保无人车在任何可能遇到的情况中都能做出准确、及时且安全的决策。
“哎呀，前方突然冒出个小朋友骑着滑板车闯红灯！”在这个模拟测试案例中，无人车必须迅速识别并预判风险，执行紧急制动。
通过反复的测试和优化，车辆的算法得以不断迭代升级，使其在实际行驶中能够应对这种突如其来的情景，切实保障行人和其他道路使用者的安全。
再者，“雾锁深秋，能见度几乎为零”的极端气候测试场景，对于无人车而言，就像是闯进了一个迷宫。
这时，应用场景测试用例要求无人车依赖雷达、激光雷达以及高精度地图等多重感知技术，实现精准定位与路径规划，即使在视线受限的情况下也能安全行驶。
此外，面对“早晚高峰拥堵，车流如织”的城市路况，应用场景测试用例亦毫不手软。
它考验无人车在复杂交通环境中的跟车距离控制、车道变换策略以及对周围车辆行为的预测能力，助力其在拥挤的城市路网中游刃有余地穿梭前行。
总而言之，应用场景测试用例作为智能出行领域的“幕后英雄”，以其独特的创新性和实用性，持续推动着自动驾驶技术的发展和完善。
它们不仅考验了无人驾驶汽车的技术性能，更在每一次的成功应对中累积起公众对无人驾驶的信任与期待。
而这一个个生动鲜活的应用场景测试用例，无疑是对“实践出真知，磨砺显锋芒”这一至理名言的最佳诠释。
场景法设计测试用例最佳实践
典型功能实例——测试场景图
15 场景法设计测试用例实践
典型功能实例——描述事件流
16 场景法设计测试用例实践
典型功能实例——描述事件流
17 场景法设计测试用例实践
典型功能实例——场景确立
18 场景法设计测试用例实践
Thanks!
19 场景法设计测试用例实践
测试场景的制作步骤
1. 绘制测试场景图
【工具】：纸和笔、visio、word... 【范例】：请参考本简报中的范例 【要点】：参考本简报中“基本流和备选流的识别原则”
事件流是一个事件及其所引发的后续处理 事件流不是步骤，不要用流程图的习惯来画场景图
2. 描述事件流
【工具】：execl 【模板】：场景设计模板之“二、功能流程设计参考” 【目标】：分解事件的后续步骤，精化步骤的描述，从而增强对测试用例设计的指导性
着眼于贯穿于多个功能之间的 用户工作流程
目标是提炼多个系统可以共用的 测试方法和手段。
着眼于用户在单一功能执行时的 互动体验
4 场景法设计测试用例实践
典型业务提取实例
典型业务 语音主叫业务流程 语音被叫业务流程
即时消息业务流程 语音多方会议
V网伴侣业务和其它电 信业务叠加(主叫)
5 场景法设计测试用例实践
业务说明
主叫方呼叫→振铃→被叫方接听通话→挂断。 分支流程为通话不能建立，以及第三方呼入等。
是对主叫业务流程的补充，将振铃方式（同振、 顺振）、接听方式（手机接听、V客户端接听） 组合到应用场景之中。
两个或更多用户利用V网伴侣进即时消息会话的 业务流程。
涵盖多方语音会议建立、邀请与会者、删除与会 者、禁止发言允许发言等功能的语音会议业务 流程。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2010.8
本讲内容
什么是场景设计法 典型业务与典型功能 典型业务实例——V网伴侣语音通话业务流程 典型功能实例——网信白名单导入功能 测试场景的制作步骤
1 场景法设计测试用例实践
什么是场景设计法
事件触发时的情景便形成了场 景
不同的事件，其触发和处理结
果就形成事件流
左图中，直黑线表示基本流，
基本流 备选流
E3：被叫方正在通话
E2：被叫方未振铃
忙音，A挂机结束
B.02：被叫B振铃
E5：被叫方无应答
E4：被叫方主动拒接
提示被叫方关机或不在服务 区，A挂机结束
E6：语音信箱留言
长时间无应答，A留言后，挂 机结束
长时间无应答，A挂机结束
B.03：被叫B接听
提示被叫方关机或不在服务 区，A挂机结束
典型业务实例——描述事件流
10 场景法设流
11 场景法设计测试用例实践
典型业务实例——描述事件流
12 场景法设计测试用例实践
典型业务实例——场景确立
13 场景法设计测试用例实践
基本流和备选流的识别原则
一个业务只存在一个基本流 基本流只有一个起点，一个终点 基本流是主流，备选流是支流 备选流可以起始于基本流，也可以起始于其它的备 选流。 备选流的终点，可以是一个流程出口，也可以是回 到基本流，还可以是汇入其它的备选流。 备选流汇合时，谁汇合到谁，取决于流量大小也即 该流程出现的可能性大小，小的汇入大的。 如果在流程图中出现了两个不相上下的基本流，一 般需要把它们分别当做一个业务看待。
V网伴侣做主叫叠加12593业务、17951业务、 17950业务、家庭网业务、88套餐业务、飞信业 务、多方通话业务、移动总机做分机业务等业 务。
典型功能提取实例
典型功能 固定密码登陆 动态密码登陆 注销 即时发送 管理员管理 模糊匹配 EAD接口管理
白名单导入
功能说明 网信平台使用固定密码登陆系统 网信平台使用动态密码登陆系统
测试场景的制作步骤
1. 绘制测试场景图
【工具】：纸和笔、visio、word... 【范例】：请参考本简报中的范例 【要点】：参考本简报中“基本流和备选流的识别原则”
事件流是一个事件及其所引发的后续处理 事件流不是步骤，不要用流程图的习惯来画场景图
2. 描述事件流
【工具】：execl 【模板】：场景设计模板之“二、功能流程设计参考” 【目标】：分解事件的后续步骤，精化步骤的描述，从而增强对测试用例设计的指导性
E7：第三者C呼叫A，A不
理，继续进行AB通话
B.04：通话进行
E8：呼叫保持AB，接听C后，AC
结束后继续AB通话
E9：B于等待期间挂断
9 场景法设计测试用例实践
E10：呼叫保持超时
B于等待期挂断，AC通话 结束后无法继续AB通话。
通话结束，双方挂断电 话，置用户A/B状态为空
闲，终止
呼叫保持超时，AC通话结 束后无法继续AB通话。
是经过用例的最简单的路径
备选流用不同的色彩表示，一
个备选流可能从基本流开始， 在某个特定条件下执行，然后 重新加入基本流中（如备选流1 和3）；也可能起源于另一个备 选流（如备选流2），或者终止 用例而不再重新加入到某个流 （如备选流2和4）
2 场景法设计测试用例实践
典型业务与典型功能
典型业务
典型业务偏重于大的业务流程，目的是用业务流把各个孤立的功 能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能 细节忽视业务流程要点的错误倾向。 例：v网伴侣平台中，语音通话典型业务流程就把语音通话、同 振顺振、语音留言、呼叫保持、呼叫转移这些功能都串到一起来
3. 总结场景摘要
【工具】：execl 【模板】：场景设计模板之“一、场景设计” 【目标】：标识各场景，并给予准确且概要性的描述，以统一各方面的认识和用语
8 场景法设计测试用例实践
典型业务实例——测试场景图
V网伴侣语音通话主叫业务流程
V网伴侣用户A espace在线
B.01：输入电话号码 呼叫
E1：从通讯录选择被叫者 呼叫
网信平台注销
网信即时发送 网信平台管理员添加、修改、删除、锁定、解锁 简述模糊匹配规则 EAD接口添加、修改、删除、审核、暂停、恢 复、调用 文件格式检查，导入失败文件大小限制，白名单 数据行异常
6 场景法设计测试用例实践
制作测试场景的要点
对业务的理解 对用户需求的把握 从用户的角度出发进行设计
7 场景法设计测试用例实践
业务说明
主叫方呼叫→振铃→被叫方接听通话→挂断。 分支流程为通话不能建立，以及第三方呼入等。
是对主叫业务流程的补充，将振铃方式（同振、 顺振）、接听方式（手机接听、V客户端接听） 组合到应用场景之中。
两个或更多用户利用V网伴侣进即时消息会话的 业务流程。
涵盖多方语音会议建立、邀请与会者、删除与会 者、禁止发言、允许发言等功能的语音会议业务 流程。
典型功能
典型功能就是可能在多个系统中出现的共通功能 如何识别典型功能？
• 根据产品经理自己的知识来判断即可，一个系统可以贡献几个典型 功能就可以了，不要求全部识别，但要求不要重复。
3 场景法设计测试用例实践
典型业务与典型功能——区分
典型业务
粒度
粒度较粗
典型功能
偏重于细节
目标 着眼点
目标是将孤立的功能点串起 来，让测试人员充分理解业务 需求。
14 场景法设计测试用例实践
典型功能实例——测试场景图
15 场景法设计测试用例实践
典型功能实例——描述事件流
16 场景法设计测试用例实践
典型功能实例——描述事件流
17 场景法设计测试用例实践
典型功能实例——场景确立
18 场景法设计测试用例实践
Thanks!
19 场景法设计测试用例实践
着眼于贯穿于多个功能之间的 用户工作流程
目标是提炼多个系统可以共用的 测试方法和手段。
着眼于用户在单一功能执行时的 互动体验
4 场景法设计测试用例实践
典型业务提取实例
典型业务 语音主叫业务流程 语音被叫业务流程
即时消息业务流程 语音多方会议
V网伴侣业务和其它电 信业务叠加(主叫)
5 场景法设计测试用例实践