本系列文章将带大家全面了解全链路测试，从全链路测试介绍、为什么要做全链路测试、全链路测试与其他测试区别、如何实施全链路性能测试这四大部分进行展开。

企业级的全链路测试对测试用例的覆盖度要求比传统测试高，在测试的过程中会涉及到不同系统之间的连接关系和数据流关系。平时我们做得比较多的是项目级的测试。所谓的项目级就是一个项目一个项目地完成测试，项目与项目之间偶尔会有一些关联，大多数时候都没有。在测试的过程中会通过挡板的方式去做相应的处理，并没有真实地把系统与系统之间的关联性关系、业务数据关系串联到一起。

我们今天讲的这个话题，也可以供测试人员做一个职业规划的参考，很多人在迷茫的时候会问我，接下来要什么？工作这么多年，一直都在做功能测试，一直点点点，怎样才能突破瓶颈？

产品经理和业务人员他们对整个产品的业务线理解地比较透彻，在某个产品领域上的深度也会比我们测试人员更加深入，他们对全链路业务流转环节之间的关系会比我们理解地更透彻。我们作为测试人员，应该怎样突破瓶颈呢？

首先我们在做全链路测试的时候，用例不仅仅要覆盖得广，还要覆盖得深。在测试领域，我们慢慢地就可以成为一个业务专家了。我工作这13年来，早期在我的团队中虽然没有做全链路的想法，但是我会要求他们用这种思维方式去做事，深化大家的专业能力。

首先我们通过两个典型案例介绍一下什么是全链路测试。

案例1：打车系统

18年的时候，有个朋友的公司接了一个打车系统的项目，当时他们对这个系统的了解如下图所示，有司机端和打车端，包括怎样对接、支付、调价、抢单等内容。  

我们在测试的过程中，要把整个业务关联在打车的手机号和银行卡的钱最终如何分账分佣到各个平台上去这两个方面。为什么要重视这块内容呢？因为如果单纯测试这个系统，通过这张图大家都知道该怎么测，但是作为平台的老板，提供这个平台为了什么？肯定是为了盈利。
那我们在测试过程中就要考虑到，用户打车花了100块钱，平台分账完之后，平台分佣了多少？通过银行卡到银行，银行是不是也要抽取一定的分佣？司机是不是还要拿到一部分钱？整个链路过程中我们就要测试它的钱的分账有没有合理性，数据的有效性和正确性有没有保障？

偏差哪怕只有1块钱，但对于一个全国性的平台，积累下来会是一个很大的数据。所以在测试的过程中我们要“精打细算”，把系统的调价、发单、结算等各个环节都要做好测试，这些是正向的思维。

还有一些是逆向思维的思路，比如说我们平时打车时，我们下单后司机迟到了，我们会取消订单，是否产生费用？或者在订单发单的过程中，使用了优惠政策，或者我们的钱提前存到平台钱包中的情况下，平台会怎样去结算。

比如说我们充值100元抵110元，平台在分账分佣的过程中，怎么去对平账务？因为这其中有10块钱是作为虚拟货币被消费了，不可能由老板掏10块钱放到财务中。虚拟货币的使用过程中，账务应该要怎么平摊。这个问题不论是这类打车平台，还是电商，都是经常会遇到的一个问题。

在全链路测试的过程中，不管是产品经理还是测试人员，我们都应该将这些业务场景都考虑进去。不仅仅只考虑用户怎样打车、怎样结算。

案例2：电商平台

接下来为大家介绍一个全链路业务场景中的网购案例，这也是我们生活中必不可少的一个场景。

网上购物从买家在APP下单，到最终买家收货，一次完整交易的数据流要经过很多系统（APP、ERP系统、仓储系统、物流配送系统、门店自提终端）。这些系统之间通过调用接口串成一条条链路，交易数据在链路上进行流转。

我们在测试过程中肯定会遇到各种问题，在不同的系统之间如何去定位问题？首先我们要知道问题在哪？怎么样去分析场景有没有覆盖到？下面我就把全链路测试的场景给大家展开介绍一下。

电商全链路业务交易流

上面这张图就是全链路的一些内容。首先开始下单，我们购买商品的时候，可能会有打折活动，比如说买2件打9折，买5件打8折等等。然后在购买的过程中库存是否充足，还会有限购、限量的情况。这是我们商城前端会提示的一些信息。

下单完成之后，会到另一个系统，也就是订单系统。在订单系统中我们要看库存、订单等等，生成订单后，订单状态会变成待支付或者已支付。

待支付、已支付环节又会涉及到订单是否要取消？或者买三件退两件等场景。

库存系统有哪些场景呢，比如前面说的买三件退两件，就会导致库存增加，交易金额要退款。

退款的过程中会出现什么问题呢，比如说有满100送10块的活动，那在买三件退两件时，是不是要按比例扣一部分的钱，优惠的钱要怎么分摊掉。

以上这些也是我以前帮一家电商公司去梳理的一些业务场景。也是上面这张图中展示的。

在支付系统，第一方面是商家的电商平台里面有了新增的余额，其次，用户通过银行卡或者其他支付方式进行支付，在支付过程中可能会遇到卡内余额不足，有些不能用信用卡去透支等问题。我们都需要对这些内容进行模拟。

这一块属于第三方接口，但是我们在平台上也要看看这种情况出现后系统的反馈，避免出现明明第三方平台支付失败了，但是我们这边却显示支付成功。

下单完成之后，有时候有些多个商品的订单可能会被取消其中几个商品，取消之后是不是还能够正常发货？再有一点是，a同学和b同学同时买了同一个东西，但是地点不一样，这样的情况会不会产生串单的问题？

前几天我有一个朋友他的公司就出现了一个类似的问题。是一个类似于百度网盘这样的项目，任务之间串掉了，我上传的测试文档会和别人上传的文档串掉。

在全链路的非功能压测过程中，在网络频繁度比较高的时候，会很容易出现这种串单的情况。所以我们全链路测试过程中不仅要测试它的功能，还要测试它的性能，以及一些其他的非功能性测试。

以上就是电商平台的测试过程中会遇到的一些问题，我们把这些内容串在一起，就是下面这张图。

一次完整交易的数据流要经过很多系统，这些系统之间通过接口调用串成一条条链路，交易数据在链路上进行流转。而对整个链路进行的测试称之为全链路测试，全链路测试可分为全链路功能测试和全链路性能测试。

首先在app端，我们要做功能测试与性能测试。然后是后台管理系统、支付、仓储与服务环节，最后是物流配送和菜鸟驿站，这样一个完整的交易流中的每一个环节都需要进行相应的测试。

一个完整交易的数据流要流转到很多系统，图里画出的只是一个基础的系统，其实真实的系统还会更复杂一些。我们测试人员在测试的时候会分开每个环节进行测试，或者先测接口，接口测通了之后再进行全链路测试。在整个测试的过程中，我们要用全链路的方式去考虑它的业务流。

作为管理人员，我们要把全链路功能测试和全链路性能测试都要规划进去。这也是我们接下来要讲的，为什么要做全链路测试，怎么去做全链路测试敬请大家继续关注。