Category Hierarchy

上节课,我们说到状态迁移法。

有个疑问:

你找来找去,找的就是这几个路径。把线捋直,有什么用?就要介绍业务流程测试。放到我们具体的业务流程里来看,这些路径是干什么用的?

1 业务流程测试

1.1 流程图介绍

流程图是对过程、算法、流程的一种图像表示,在技术设计、交流及商业简报等领域有广泛的应用。 通常用一些图框来表示各种类型的操作,在框内写出各个步骤,然后用带箭头的线把它们连接起来,以表示执行的先后顺序。用图形表示算

法,直观形象,易于理解。有时候也被称之为输入-输出图。

 

要求:

1. 我们需要知道常见的5种形状,以及5种形状带来的含义。

2. 给你一个流程图,你要知道它各自有什么含义。

流程图常见的5种形状及其含义:(这个一定要知道)

1. 椭圆:开始/结束

2. 箭头:路径,流程的走向

3. 平行四边形:数据的输入/输出

4. 长方形:处理/步骤/过程

5. 菱形:判定/判断

理解:

长方形:从起点到终点之间需要经历的步骤,或者需要经历流程的节点。(状态迁移树里的长方形就表示节点,流程图的节点。表示你要进行什么操作或者什么处理。)

1.2 绘制流程图

绘制原则:

1. 不要漏掉流程路径

2. 先有判断,再有判断结果

3. 推荐讲主业务流程放在最中间,便于阅读

理解:

1. 不要漏掉流程路径

刚才状态迁移图里面,它们有4条路线,这4条路线是不能少的。

2. 先有判断,再有判断结果

你先要有菱形,根据菱形的是或否,去选择对应的处理。

3. 推荐讲主业务流程放在最中间,便于阅读

出于易用性的考虑,最长的线或者称主路线放在最中间

 

 

 

缺陷跟踪流程,这个图,要时刻映在脑子里。

注意:提交缺陷和关闭缺陷是椭圆,代表开始和结束。

 

把最长的放在中间。提交缺陷到关闭缺陷的一条路线。

提交缺陷作为一个开始也没有关系,测试人员发现一个bug,他会提交到系统里面去。先分配给开发负责人,开发负责人分配给指定开发工程师。开发工程师会对bug进行判断:

1. 判定是否重复?是重复,直接关闭缺陷。不是,往下走。

2. 判定是否是bug?不是bug,直接关闭,是,往下走。

3. 判定是否推迟处理?需要立即处理,往下走。不需要立即处理,等到以后的版本,继续处理缺陷。

开发进行修改缺陷,修改缺陷以后,测试需要进行一个回归测试。结果呢?就会有通过还是不通过。通过,测试就关闭缺陷。如果回归测试不通过的话,测试就继续指派给开发进行修改,等他修改完了以后,又进行回归测试。

关闭的缺陷,再后续的版本中再次出现,就不需要提重复bug,指派给开发进行修改。

核心:6条线路。

1. 是否重复     是,关闭缺陷。

2. 是否重复     否,往下走,主线路。

3. 是否bug      否,关闭缺陷。

4. 是否bug      是,往下走,主线路。

5. 是否推迟     是,延迟处理。

6. 是否推迟     否,往下走,主线路。

7. 是否修改完成     是,关闭缺陷(主线路)

8. 是否修改完成     否,处理缺陷(在禅道里测试:开发问题没有解决,点击激活

9. 关闭缺陷,重新打开,提交缺陷。(在禅道里:关闭后缺陷再次出现—>重新打开)

 

流程图我们也有了。你有没有发现流程这个路线和状态迁移图这个路线,其实就是一回事。只是一会儿,我们在业务流程测试里的时候,我们再把这个状态(状态迁移图)再补进去,作为我们预期结果里重要的一个点。

1.3 业务流程测试

1. 业务流程测试的关注点:

1)关注点在核心业务是否能够跑通

2)重点不是关注单个功能模块的细节点

理解:

业务流程测试,涉及到多个功能。跑的时候,实际上保证它的路线过就完事了。至于说,我这个地方选择的是哪一种方式登陆,跑业务流程测试,只要选择一种登陆方式就可以了。从头跑到尾,从开始跑到结束。

在经过购物车的时候,你发现咋这个bug又出现了,我是不是要在这停下来,做购物车详细测试呢?不需要,还没到那个时候,重点不是关注单个功能模块的细节点。

这是我们冒烟测试才能达到这个目的。

 

2. 业务流程测试的价值:

1)客户角度:对客户最有价值的是业务的实现,不是单功能模块的质量

2)测试人员角度:分配任务往往是针对功能模块划分,业务流程的测试容易遗漏

 

3. 进行业务流程测试的时机:

1)上线前进行业务流程测试的确认

2)单功能模块基本可用的情况下,尽早进行(冒烟测试)

理解:1)上线前进行业务流程测试的确认

一般来说,因为你涉及到多个功能模块,一定是要等这些模块都开发完,才可以开展相关业务流程测试。上线,说明交给你真实用户去使用了。那上线之前,需要去进行业务流程测试的确认。

理解:2)单功能模块基本可用的情况下,尽早进行(冒烟测试)

现在,一般来说互联网的开发模式,它会优先把一条最基本的线路流程先实现。后面在这个业务流程线上,去不断丰富叠加单个模块的功能,这种情况下面,针对这个流程线的测试,我们应该越早越好。

我们为什么会有冒烟测试?在冒烟测试里面,带出来的这个业务流程,因为针对互联网这个快速交互模式,它都基于一个小的快速流程,先去做,做完以后,在这上面不断去叠加,不断去丰富它的功能,所以它始终保证这个流程的正确性,

会把冒烟测试,引入对业务流程的测试。

1.4 业务流程测试用例设计

1. 需求分析,明确流程

2. 画出流程图

3. 编写测试用例,一条路径对应一条测试用例

  路径比较多时,可以对所测业务路径设置优先级

理解:

明确流程,指的是找到流程节点,步骤也好,操作也好,来明确流程。

这3个步骤,在讲解场景法的时候,就说过了。

怎么设置优先级?

在讲这个缺陷,这个占比,哪种情况占比高低有提过,比如说,正常情况下面,你提交bug到正常关闭这条路线,是一个比例最高,它可能会占到70%左右,实际上这句话就是告诉你,这条路线你得重点关注,重点去测试,这就是它一个高优

先级的一个体现,判定为否可以理解为异常情况。异常用例当然要比你中间核心业务流程用例,优先级要低,这是一个基本套路。

2 tpshop业务流程测试

2.1 绘制tpshop下单流程

什么叫业务流程?

实际上就是解决业务特性里面描述的那句话。比如说,我们这个tpshop的业务特性就是说,这是一个电子商务网站,实现了在线购物这个平台,人家可以买东西这个操作,它实现了这个业务流程。

先完成前台下单流程,下单完成,再看后台发货流程。可以分开写业务流程测试用例。

前台

假设这里已经注册了账号,第一步从登陆开始。

1.登陆

2. 选商品

在浏览商品的时候,系统需要有商品的展示的页面。可以在首页,可以在列表页,也可以在详情页,不管是在哪个页面,实际上放在功能模块,都是围绕这个商品来设计的。可以理解为是第2个大的操作步骤。

 

 3. 加入购物车

 4. 支付

我的购物车,去结算

我要确认是不是我买的东西。信息,价格,合计,甚至优惠券,是不是抢购的,节省金额,都是在我的购物车里面展示出来。

 

我的购物车,填写核对订单,提交订单

核对一下地址,需不需要开发票,要不要优惠券,可以在这里进行信息的维护和确认。

我的购物车,成功提交订单,确认支付方式。

这个时候,已经有订单了。需要给钱了,选择支付方式(这个系统只支持货到付款。)

5. 生成订单,等待收货

点击上面的订单详情,可以看到订单里,待发货。

 

把这个下单的过程简单明了的描述出来,用流程图,显示最基本的,按照这个图,对照系统点一点,再找找有没有其他路线。

 注意:

2. 选商品,不管是列表页还是详情页,都是选择商品这个模块。

3. 加入购物车后,也可以继续购物,这里讲最简单的一条。

4. 支付,你觉得支付比较重要,可以把支付方式都罗列出来,也可以不罗列。

如果支付没有成功,可以再去支付一下,或者换个支付方式。

 

在这基础之上,还可以:

1. 待支付,可以取消订单。

2. 不加入购物车,立即购买。

选择商品——支付

3. 要确认有没有收货地址,不然也不会让你往下执行。

4. 开始——选择商品——登陆——加入购物车

选择商品之前一定要登陆吗?游客也可以在商场里面逛的。在支付之前加个登陆的确认。

5.加入购物车,继续购物

6.我的购物车,继续购物。

 

前台下单的流程,实际上就是根据流程图。先把路径给找好了,比如说:1——2——3——4.1——5。这是一条路线。这条路线,实际上就是测你核心的通过支付宝下单成功。

细节点1:用例标题

这时候,用例标题就不是像之前写的什么条件,什么结果。你会发现这里测试用例标题,写的东西都是经历过模块的东西。这个标题不可能写的特别清楚,

第一种方式:描述了一下流程的这个路线。比如第一个:购买流程测试:登陆==》挑选商品 ==》加入购物车 ==》支付方式(货到付款)==》生成订单

第二种方式:通过流程的路线,我对关键点进行描述。比如:选择货到付款能够正常下单。

这个时候,就没有明确清晰的结果了,它对的是流程,它只要关注是成功还是不成功,就好比,我们关注的是整体功能的正确还是不正确,而不会关注单个功能的细节点,它们是一套逻辑。

细节点2:优先级

他们这些流程用例,优先级基本上是在p0级。

p0——p1 ——p2 —— p3(p0是最高的,由高到低。)

除非是异常的,比如第二条测试用例你可以把优先级调低一点,这里调到p1也是可以的。

第一条测试用例:正常流程测试

 

这个用例标题和测试步骤是高度的吻合。你可以理解用例标题内容是横着排的,测试步骤内容是竖着排的。测试步骤,你加点文字也行,不加文字也行。

测试步骤里:怎么确定这个订单有没有生成。预期结果里可以看到:我的订单中确认当前订单的状态为【提交订单】。它是一步一步的确认结果。 

看是不是提交订单,待发货的状态。

这个预期结果写的不是特别好,你就写一个能正常生成订单也行。

这个业务流程里,用例标题,测试步骤,预期结果没有办法像前面要求的那么苛刻,因为它这个说的都是笼统宏观层面上的东西。

这个业务流程测试用例,实际上就是确认这个路线(测试步骤),确认这个路线的结果(预期结果)。

这个测试步骤,实际上在流程图里已经说的很清楚了。

第二条测试用例:异常类测试用例

支付的时候,网络异常了。这种情况下面,你肯定支付失败,给出相应的提示消息。这是第二条测试用例。

 

第一条测试用例,第二条测试用例,我哪知道它们都是从哪来的?我们一定要在写用例之前,看这里面有几条路线。

Case01:1——2——3——4——4.3——5(这是第一条测试用例)

Case02:1——2

Case03:1——2——3——4——4.1——5

Case04:1——2——3——4——4.2——5

Case05:1——2——3——4——4.4——5

....

我们转化为测试用例的时候,只需要把路线摆清楚就行了,就能测到这条业务流程的走向。

第2个,登陆失败了。case02:1——2。1走到2就走不下去了,原因是发生异常,走的是否这个分支。

问题:那需不需要这样一条测试路线呢?1——2——1——2——3——4——5?

理解:1 登陆,失败了。需不需要重新走到1,走2,走3,走到后面去,需不需要呢?

不需要。因为后面的(1——2——3——4——5)在case01已经测过了。你绕来绕去,不就是为了能登陆成功往下走吗?完整的那条线,case01已经走过了,这样的异常没必要绕圈,那如果你要绕圈,那绕几次比较合适呢?

 

多种分支的情况,是需要考虑的:4.1    4.2    4.3     4.4。可以理解为一条条测试用例。

Case01:1——2——3——4——4.1——5

Case02:1——2——3——4——4.2——5

Case03:1——2——3——4——4.3——5

Case04:1——2——3——4——4.4——5

找到多条路径,你就有多少条excel里的业务流程测试用例。比前面用例简单多了,但非常重要。

难点:就是画流程图,以及梳理过程。

前面的还有补充,一补充,图就变大了,路线就变多了,难度在这。

重点:画图——找路线——写用例。 

2.2 绘制tpshop发货流程

后台一般给管理员用,或者卖家来用。需要一个订单的确认。

后台发货流程:

 

理解:是否需要重设付款状态?

付款的信息需要调整的地方,你们私下约定。面上走的是199,老姐妹给你9.9。或者是说你没有收到,只是系统上显示收到了。这种情况,都有可能重置付款状态。

不重置,真正收到了人家的付款。就等着人家收货验货了。

实际走一下流程:

前面已经走到这一步了,我们可以去【订单详情】去看一下。

可以看到待发货,提交订单。可以去【订单中心】去看一下。

 看下标注的两单都是货到付款,我们截一下它的订单编号。

 

点击上面订单的【查看详情】,后面这一段怎么走下去啊?这就是我们要说的后台发货流程。后台发货流程,不是买东西的人操作了,是卖东西的人,管理员这样的角色去操作。那在哪儿啊?

前面的操作都在前台。现在要去后台系统里面呢去操作了。localhost/admin

系统——订单——订单列表。

可以找到前面讲的那两个订单。可以看到,初始的状态:

订单状态:待确认       支付状态:未支付      发货状态:未发货

查看第一条订单,点击【查看】

 就会跳到订单详情页面

按照我们的流程,应该去确认订单。

 订单详情页面,可以备注,点击确认。

回去看一定,订单状态由【待确认】变为【已确认】

 来到流程里面,已确认过了,是否发货?

再回到后台系统里面。第一个订单,点击【查看】

你可以从【发货单】或者【去发货】。这两个地方都可以发货,去的地方是一样的。

点击【去发货】。

需要输入一下,配送单号:1111111111,点击【确认发货】

 

 

 流程图里,确认发货,发货状态:未发货,要变为已发货。

 

回到后台订单列表,第一条订单,发货状态:已发货。

一边点,实际上就是一边测。测试需要关注的地方,状态的变化,迁移的过程,因为你经历过这些状态,这些文字背后,涉及到具体的操作,直白点,就是金钱的交易。不能把状态标错,如果已经发货了,状态为未发货,会有经济损失。

接着流程走到了这一步,是否收到买家的货款?

回到订单列表里,假设我已经收到了买家的钱了。这个过程就是,快递公司已经送货上门去了,你验货了,也给我打款了。下面这个【付款】是指卖家收到付款了。或者说平台把钱打给卖家了。

点击【付款】

那支付状态:由【未支付】变为【已支付】

来到流程图,先验也行,后验也行。平台都有7天无理由换货。验不验无所谓。你看需不需要改。

按照这个流程,我也收到了款项了,你后面是否需要重设付款状态?你需不需要改?也不需要改。那这个时候,你可以确认去收货,或者你可以先收货,你不选择货到付款吗?你先开箱验货,再给钱,或者先给钱,再开箱验货。这个都无所

谓。这个大的电商平台,有7天无理由包退包换,谁先谁后,你也不是很在意。

上面一段话的理解:

1  卖家需要在后台点击【付款】,确认收到买家的货款。

2   买家是选择货到付款,拿到货。有两种方式(第一种,你先开箱验货,再给钱,第二种,先给钱,再开箱验货。)

按流程图里,是先给钱,卖家确认收款。买家再确认收货。

但是给钱和验货的先后顺序是不一定的。有可能他先开箱验货,再付款。但是快递员等他验货完了,肯定要他付钱,快递员才能走。买家肯定付完钱拿到货才会点击确认收货。所以总的来说,行动上还是卖家先收款,买家后收货。

但是卖家点击收款,和买家点击收货的这两个操作顺序是不一定的。这个先后顺序,谁先谁后,你也不是很在意。

再来到流程第5步:买家已付款确认收货。

回到前台这个订单,刷新一下,状态在变。

买家点击【确认收货】,因为都送到了家门口了。

 

 

回到后台,刷新一下。这条订单,就变为【已收货】,之前是【已确认】。所以【已收货】是买家来确认的。

流程走到这就没有了,其实还可以评价。

在前台,订单中心,点击【评价】 。

因为是两个商品,在一单下的。继续点击【评价】

评价星星,内容,点击【提交】

这个单里还有一个商品,你还可以继续评价。

评价完,这个订单就没有什么操作了,买卖双方都没有什么操作了。

刷新一下后台,订单列表,订单状态为:已完成。

这一类的测试,还没说测试用例的设计。只是说明测试过程中,你需要关注的地方,这些用例的话,就是我们流程一画,把预期结果一写,在流程图里一比对,状态:

订单状态:待确认——已确认——已收货——已完成

发货状态:未发货——以发货

支付状态:未支付——已支付

这个是不能乱的,字是不能乱的,顺序也是不能乱的。后台发货流程,前后台拼到了一起,才是完整的购买流程。从你登陆进去,到收到你的这个货物。

问题:是不是收款后发货?

都可以,不同的平台不同的设计,比如:京东,你可以选择货到付款。货到付款后,你先开箱验货,再给钱,或者先给钱,再开箱验货。都可以。

小本买卖的话,必须先打款再发货,各种操作都有,真的有用京东或者淘宝,比这个复杂的多。

2.3 设计tpshop业务流程测试用例

严格意义上是,先设计测试用例,然后再执行用例,点点。但是这里为了更容易理解,先带着来走了一下操作系统,走完以后,再看测试用例长什么样子。

测试用例这里,其他的没什么好讲的。重点是:预期结果,必须明确。

因为针对后台系统,就是管理各种数据的。这里就是管理订单的,怎么标示你的订单,经过你的操作,都发生了什么改变,预期结果,状态必须明确。

这一开始的预期结果是从需求文档里来的。

比如抢购的需求文档,类似这样的文字描述,状态是怎么变化的。那么测试,经过流程操作以后,就有了预期结果。订单这一块应该也是有的。只是订单的需求是没这么清楚的。

重点:预期结果,放在状态的变化里面。

 

转载请注明出处:http://www.xjzhisheng.com/article/20230304/614781.html