全链路测试

2019-08-01 本文已影响34人 gaby666

全链路测试概念

在项目开发过程中或多或少的会基于开源库写过一些单元测试，类似 Java 的 Juint 等。大分部情况下，程序员对系统的测试都只在系统的内部进行。但我们知道，一次完整的数据流不可能只在一个系统内流转。比如淘宝从买家下单到最终被收货，这一次完整交易的数据流要经过很多系统（ERP系统、仓库系统、配送系统、末端系统等）。这些系统之间通过调用串成一条条链路，交易数据在链路上进行流转。而对整个链路进行的测试称之为全链路测试，全链路测试可分为全链路功能测试和全链路性能测试。

image

为什么需要全链路测试

只在系统内部做单元或者逻辑测试只能测试本系统内是否存在问题（当然测试是不能发现所有问题的），并不能知道整个链路是否有功能或者性能上的问题。所以我们需要跳出系统对整个链路进行测试，防止在大促的时候出现问题。下面以自己的亲身经历来说明为什么需要全链路测试。

一次数据的流转也需要经过很多系统，很符合全链路的定义。数据流程主要如下：

Agent 采集数据->接入系统->分发系统->一次分析系统->二次分析系统->工单系统

系统的链路大致如上所示，可以看到数据从 agent 采集到最终发工单给用户要经过很多系统。由于我们做的系统与安全有关，对数据的完整性要求很高，所以必须要保证整个链路上不能丢失数据。为了保证整个链路的可靠性，需要对链路的可用性进行测试。由于对于线上质量测试的不重视，部门对链路采用最简单的拨测方式进行测试。流程如下：

1.定时在测试机上用脚本构造有效的工单数据，一般在早中晚定时用脚本跑一次或者几次。

2.链路上涉及到的系统上报自己的日志到存储系统，方便后续定位。同时继续扭转数据到下一个系统。

3.查看最终是否能正确发出工单，如果没有测试工单转（4），否则结束此次拨测。

4.人工去日志存储系统进行日志查询，找:到有问题的系统，再深入系统定位问题。

以上方法简单粗暴但存在很多弊端，比如:

1.各种数据只能靠人工写不同的脚本在 agent 上构造数据，导致测试数据种类和数量非常有限。

2.出了问题需要人工一步步的查看链路中哪个系统没有上报日志，再去系统定位导致排查效率低。

3.每天只定时跑几次拨测存在一定的随机性，如果次数太多脚本又不好管理。

4.真实数据和测试数据混在一起，只能通过白名单进行最后的工单过滤。

但即便如此，拨测也提供了全链路测试的一种手段。如果没有拨测，全链路功能的可用性更无法预知。只能说拨测是全链路测试的一个雏形，离真正的全链路测试系统还有一定的距离。全链路测试需要一个系统化的平台，只要链路中的各个系统都接入平台，即可对系统内和系统间的链路进行测试。一个理想的全链路压测平台应该为开发和测试提供从数据构造、用例管理、全链路场景组织、协助测试结果分析等一站式服务。