如何快速做跨业务测试?

当业务任务多且人力资源不充足的情况下,不同业务的同学可能需要去不同的业务进行临时支援,可能在时间方面有长有短,但是如何迈出第一步是很多人需要关心的一件事。

本文以实际跨业务测试经验(订单业务测试人员如何测试售后业务),讲述在两周内如何快速的上手售后业务并进行需求测试,写下此篇文章作为经验分享。

如何快速做跨业务测试?

在转业务之前,我在交易订单促销回收单业务,那么先简单介绍一下订单业务。其目的在于了解一下订单和售后之间的关系。

订单涵盖的内容非常广泛,从商品加购,再到确认下单页,再到下单,整个订单流程,包括正向订单流程以及逆向订单流程等多场景。外部对接B2C,C2C,B2B,POP,3C等诸多业务。内部对接基础服务,商品,支付,物流,仓储,售后等业务。日常测试中,可能也或多或少的了解了售后的一些后台操作步骤或流程。从而对测试售后业务基础流程上有一定的了解。

开始前

1、思考将要测试的方向

在开始去其他业务之前,首先得想清楚去了之后主要的测试方向是什么。因为每个大业务间有不同小模块,一个人可能负责多个方向的事务。在短短的几天之内根本没办法了解全部的内容,那么只有统观全局视野,给自己定下一个个小的目标,逐个击破,以点破面,最后了解整个业务。

2、了解业务范围

那么这个阶段的第一步了解业务系统,可能是很多人需要思考的一个难题。

跨业务之间的确有很多的不同点,由字面意思来解释的话,那么最大的区别在于业务不同,如何了解业务也是最关键的一步。在我这里,其实最简单的方法就是看业务梳理,以及业务流程图。将自己作为一个新人来看,快速了解业务内容。其次还要以目录结构的维度去熟悉有哪些关联内容。

如何快速做跨业务测试?

3、上手体验业务流程加以发散

当我知道我要测试售后时,首先要了解的当然是售后流程,其实刚开始也不一定要了解的相当全面,只是在心里有一个大致的图就行,这个图可以理解为系统模块图。以B2C售后为例,那么在我脑海中的图也就是售后的一个大致流程,以及这些模块儿分布在哪些系统中,售后都与谁进行交互。

如B2C售后流程核心流程如下几个步骤:

1) 在转转app商详首页挑选一个喜欢的手机,创建订单支付成功后生成订单号。

2) 订单发货后,透出申请售后的按钮,用户点击按钮后在转转app申请售后,同时也可以进行取消,再次申请的时候,又生成了新的售后单号。那么这个时候我们就知道了,订单号和售后单号为一对多的关系。

3) 客服进行接入操作,将该售后单进行领取,并根据实际情况进行审核通过。比如在商品还没有实际出库前,可进行快速关闭出库操作并操作退款,如果已出库,则操作审核售后通过。

4) 客服通知用户寄出,并创建发货单,同时对接物流信息。

5) 商品到达了售后站点,工作人员进行扫描收货,生成用于追踪快件流向的散货单,对每个快件生成质检单。

6) 判责后进行确认方案,最后处理钱货归属的问题。

7) 确认完成后,通知订单做相应的操作,如订单关单,或者是退款或者是维修等操作。

8) 最后将售后机器进行散货,也就是交接给质检中心仓库。

经历以上步骤从而达到一个闭环操作。

如下图所示就是极速退款与正常售后退款的流水信息:

如何快速做跨业务测试?

最后再来一张售后退款完结的图:

如何快速做跨业务测试?

在转转App里体验每一步的操作里,又可以进行发散思维思考,如非B2C售后,可能由第三方进行审核是否通过售后申请,还有比如说用户取消售后,可能要进行关闭售后单的操作以及物流恢复等操作,只要能串起来这些步骤,那么当你真正介入这个业务中,你也能在复杂多变的需求中,找到最直接的路。了解到大概的流程之后,那么就要去熟悉更细致的模块,细致到如何操作,如何配置等。

当实际体验了整个流程之后,对整个流程也就有了一个初步的认识,再去看业务沉淀和相关文档的时候,也就不那么的陌生。

进行中

当拿到一个需求的时候,需要以需求内容去实际分析。通过项目的整个流程去熟悉新的业务,其实在不同的业务,项目的整体流程是大致相同的。那么最重要的是关注差异点。作为一个QA的角色去分析拆解需求。

在我这里主要是分为两类的需求:

第一类,以前有类似需求,新增需求为类似模式,增加类似链路,不仅要关注新增内容,那么还要关注以前老的流程,同时还要保障历史数据兼容。

第二类,完全新增类型,那么此时就需要深入了解需求内容,包括对一些异常场景以及接口数据存储的方面思考。

接下来就为大家介绍一下我在这两种不同需求中是如何做的。

1、复用模式型

第一种一般来说比较简单,模式复用型,那么需要了解的主要有以下几个方面的内容:

历史文档梳理总结 首先是原来这种模式下的需求文档,包括该需求的历史性的一些梳理文档,以及该需求的迭代性需求文档,还可以参考UI图。

原有测试用例查看 一般情况下,某一类的需求都会有之前的一些测试用例,这些测试用例包括当时需求的详细描述,详细操作步骤,我们要做的就是找到原有的测试用例,如果能找到当时测过类似需求的QA最好,讲一讲踩过哪些坑,怎么搭建测试环境,准备测试数据等。

原始bug拆解 还有一点很重要的是关注这些迭代或者最早版本需求的bug,了解到需求容易出现缺陷的地方进行着重关注。对一个没有接触过该项目的人来说,就不会那么容易被忽略掉。

配置与兼容 对于历史配置性的东西同样需要关注,可参照原有的技术文档或者测试方案去关注到,这一部分内容也是不可或缺的一部分,可减少测试中的或者冒烟中排查问题的时间占比。

2、新需求介入

对于和原有的需求内容没有相关联类型的需求,那么需要考虑到哪些内容在当前业务有类似的案例。

寻找差异点 比如售后时有仓储收货和不需要仓储收货这两种场景,他们的区别在哪里,新开发的这个功能有没有和原有功能有重合点,并且这两种模式对于后端的数据存储的差异项在哪里,这些都是需要我们来关注的。

介入技术实现 如何去了解,最快的方式肯定是看技术实现,在需求设计阶段,可以找开发了解整个技术实现,让开发同学列出哪些地方需要着重关注,并发表自己的看法,把自己带入到用户的层面,去反向提问开发或产品同学,如果我想以某种方式去干,会不会流程发生阻塞,或者说数据异常的场景。

明确目标 同时还需要明确自己目前做的是什么,要朝什么方向去做。并提前列出自己的计划,一点一点的去落实到位。包括不限于编写测试方案等。

结束

其实在不同业务之间变更的只是业务而已,所以我们以往的经验同样适用于各个业务。只要合理拆分任务,对拆分各个模块逐一而解,那么整个系统在你眼里可能只是一堆零件而已。按照需求进行组装,那么你将会很快熟悉并快速上手。

文章源自公众号  转转QA



留言