当业务任务多且人力资源不充足的情况下，不同业务的同学可能需要去不同的业务进行临时支援，可能在时间方面有长有短，但是如何迈出第一步是很多人需要关心的一件事。
本文以实际跨业务测试经验（订单业务测试人员如何测试售后业务），讲述在两周内如何快速的上手售后业务并进行需求测试，写下此篇文章作为经验分享。
在转业务之前，我在交易订单促销回收单业务，那么先简单介绍一下订单业务。其目的在于了解一下订单和售后之间的关系。
订单涵盖的内容非常广泛，从商品加购，再到确认下单页，再到下单，整个订单流程，包括正向订单流程以及逆向订单流程等多场景。外部对接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