樊宇：大家好！我来自京东物流，京东物流原来是京东集团下面的，今年独立出来了。
我先给大家讲一个链路的场景，可能我们很多人都有订飞机票的经历，比如说你可能在订票网站订票，这个信息会传到航空公司订票系统里。但是现在为了提高用户体验性，一站式服务，你订完这个飞机票以后可能又有一个接送客人直接到你入住地的地方，就是类似于O2O的业务，然后到地方以后还可以订一个酒店。大家想一下这个场景，这里可能涉及到四家公司，这四家公司每一个公司上面至少有一个系统。大家可以想一下这个系统按照现在传统观念是如何做测试的。今天我给大家讲的就是基于刚才那个场景来做的，主要是分三部分，第一部分就是系统间测试的状况，第二个就是如何进行链路测试，第三部分是自动化的链路测试。然后我们想一下刚才的场景，实际上可以更复杂一些，你坐飞机过去还要回来，回来以后要从酒店出发到机场，机场再倒航班，这是有一个回来的过程。相当于有一个逆向的过程。
假如说你就是航空公司测试工程师，你每天就是负责第三方系统订票介入的接口。可能今天有一个新订单，新的来自于第三方的订单，可能由某一个O2O服务，或者是一个路边小摊，甚至可能是有一个黄牛开始突然做这种机票了也可能，要给黄牛预留一个接口。
今天你可能没有在公司，来我们云测大会了，这时候想让你生成一个数据，你不在的话比较麻烦，他又不懂你的系统，只会操作自己的下单系统，对航空公司系统不太熟悉。大家想一下是不是平时工作当中有很多这样的场景？包括部门间的测试，还有不同组织架构之间测试都有这种情景。我们链路测试本来就是解决这个目的的。
我们看一下，我们现在组织结构是这样的，开发和测试很多是分开的，开发项有不同开发部门，测试有不同测试部门。比如开发一部对应测试一部，测试团队对应多个开发部门，不同系统当中有不同的应用。他们有一个对应的关系，不是一对一的对应关系。
这个流程比较复杂，想一下刚才说的流程，比如订机票可以在网站直接选到哪的机票下单，不需要用他提供订的服务，可以去打出租车叫滴滴，酒店可以不用他的自己订，相当于没有后面的流程，或者他提供酒店比较便宜，整个一套下来给你一千块钱，如果自己又打车又怎么样需要1500块钱，这样省了500块钱还省心，这相当于全流程的，整个流程都走，自己选的流程相当于走流程2或者下面这个。
我们系统当中的测试很复杂的，我们可能平时测试时候只是测试我们系统内部的，比如某一个系统，可能测你的航空公司内部的订票系统，或者说第三方下单的系统，或者说叫车的系统。只是公司内部或者系统内部的流程，我们平时测试时候不管是单元测试、接口测试还是传统UI测试都是针对系统内部的。系统外部的测试是没有办法解决的。我刚才说的情节，比如说参加云测大会你没有在公司，让他跑测试就跑不了，需要等你下周一回到公司再做测试我们这个技术方案就解决了沟通方面的问题。
这个就是我们现在的一些现状和我刚才说的差不多。如果你要想做一个全链路全流程的测试难度很大，特别是跨组织结构跨公司那种，比如说你是订票公司，不能让人家一个O2O的这种叫车软件公司跟你一起做整体的测试，还得有一个酒店，比如说携程，让携程直接参与这种测试，这个工作量很大的，不管沟通成本还是周期都很大的。
然后再一个是说我们现在这种测试都是自己造的数据为主，比如说刚开始那个例子，新加了第三方订单，然后下了一个订单，从北京到上海的飞机，模拟了用户信息造了一个可能OK没有问题，但实际情况用户可能不是这个，可能是特殊的航空公司，可能数据和你数据不一样这就会有问题。
第三条，这是以人为定制的为主，这个在测试管理上来讲，我们认为定制的有什么问题呢，就是测试覆盖率比较低，就是业务覆盖率会很低，因为测试场景和数据是假设的，这也是链路测试需要解决的一个问题。
那如何做好一个链路测试？这个相当于系统监测的方法，上一个系统可能是第三方订单，下一个订单写进去，写到这个表里，然后告诉你的航空公司订票系统，告诉他开始跑自动化测试了然后跑完以后再到下一个环节这样跑这是基于人工方式或者半自动方式。
然后再看一下我们现在的方案，我们现在的方案就是利用数据库触发器实现的，有些公司比如说一些银行系统可能还在用触发器，比如说写入数据以后可以执行一些动作，我这个创新灵感也基于这个，这个测试数据一般都是新数据，比如说新下一个航空订票数据，可能是新订单，就是以新增数据去触发数据库执行。数据库执行触发器，触发器调用shell，shell发起Http请求，，这个自动化测试借助Http请求跑自动化测试，这就是链路测试的一个方法论。
我后面还有比较详细的解释，两个系统链条，写入一个系统把B系统写入就会执行B系统自动化，A写的话就会执行A的数据这是一个循环的过程。比如说上系统下了订单，订单可以直接写入订单接口数据，通过订单接口写进去，然后还可以通过消息队列去写到这里，然后我们还可以直接写入订单数据，这相当于我们平时测试时候造的数据。最后我们通过触发器去执行Http请求，这就是我们大概执行的时序图。
这就是我们示意图，假如说我们前面是下订单的，假如说有三个环节，选航班，支付、输入个人信息，后面是说航空公司内部的订单处理，后面假设可能是你的假设系统例如入住系统，不同系统可能环节和流程是不一样的。如果我们用传统自动化测试的话，我们可能会把订单1订单2订单3这三个类型作为三个场景进行测试，整个流程就变成线性测试，线性测试耦合性比较大的。
看一下我们自动化的测试方法。自动化测试以线上历史数据，我们前面说了自己造的数据可能有问题，以web形式部署测试化用例这和传统测试自动化不一样，传统的测试自动化是写脚本嵌入到工具或框架里执行，我们是写独立的，独立可以运行的那种。这个可以接触web请求可以一直在那运行。
流程第一个触发节点是会进行用例查询，然后根据历史数据，状态选择下一个结点，我后面会详细说一下。
线上历史数据是这样的，从开始到终止，订单终止的话还会走一个流程，这就是一个真实数据，如果平时造数据测试的话不会考虑到这样一个一直走到头，这会提高测试覆盖率。
我们为什么说是以数据库触发器来做呢，这样我们可以不用关心到你这个订单是谁下给我的，比如说我们刚才举的例子订票系统，可能有很多第三方订单，也可能有一些航空公司自己直属的订票系统，不管从什么地方下单，最后可能下到我们系统里，这个系统里肯定会有专门的接受订单数据表，可能多个数据表，至少有一个表是代表我这里可以写数据的，平时我们测试时候造数据大家会意识到，一般都是数据库，写数据库已经触发到这个执行了，我们就不考虑数据从哪触发了，就肯定能触发。
我们再回到刚才说的场景，比如今天没有在公司。有系统测试负责人找你帮助测试一下订单流转这块，因为你是被动触发的，只需要直接用他们的系统直接运行，运行后数据会写到你系统数据库表里，比如说订单入库的表，触发器发起http请求，然后自动化测试用例接收http请求以后直接把你自动化运行起来。然后我们再继续说一下，回到这个问题，我们为什么以应用形式部署呢？就是说可以跟被测系统一样的，你可以想一下自动部署，我们很多项目有自动部署系统，因为你自动化测试用例也可以独立应用，可以享受这个待遇，例如可以通过单元测试这些工具检查你自动化测试脚本有没有什么问题。而且你测试时候也很方便，自己起一个tomcat就可以了，自己直接get一个请求就可以了。
这块我要说一下为了减少系统耦合度，我们这边设计的是不传参数的，只传Url，这边触发器接触到以后就会判断，因为你已经接收http请求时，说明系统表中已经有新增数据了，接收请求方法就会直接做你后台方法查询符合条件的数据，就这个表里写数据了，就会查询这个表里数据是什么类型的，还是刚才例子，比如不同第三方下单，这个标识可能是不一样的，这个流程只是处理某一个类型的标识，你就去查询不同标识走不通流程。这边这个就是另外一个流程处理的，然后整个流程大概就是这样的。
那个就是我们刚才的外部流程，这个是内部流程，这会先查询所有的订单历史数据，查完数据逐条进行自动化测试。这边就是一开始上游的系统，会判断你流程走向，比如说像订单那个，比如说订单输入的是什么东西，比如说是周转的还是其他的，就是不同的类型，这可能UI有不同操作，就通过这个类型触发不同操作，当然接口测试就会从不同接口入参或者类型进行方法调用。最后执行相关自动化测试，这个和我们传统自动化测试差不多，这块可以复用的。
测试会有一些检查点，这个检查点是跟历史数据做一个检查点，就比如说还是我们刚才例子，比如说这个订单可能选的是一个叫车服务，可能叫的是滴滴首都机场到现在的五洲大酒店，正常应该是生成这个订单，后来发现生成不是这个订单那说明测试可能有问题，可能前面有一个环节有问题了，就是通过历史数据来判断的。
这个思想就和我们做的搜索测试有点类似。最后根据这个状态直接到下一个状态，中间有一个时效数据标记出来，最后我们根据这个流程转到下一个结点做测试，最后直到所有测试都完事就结束内部流程了。
这个也比较好理解，因为是通过触发器，一般触发器来说是这样的，触发器本身由于安全考虑是不能发起web的http请求的，需要在触发器中调用shell，并在shell里做这web请求，我们这边做web请求很多时候是为了方便使用和部署，直接加到DNS或者手动配Host方式，这样代码里只要写域名就可以了，不需要指定IP了。
这个是我们未来的发展方向，这个比较麻烦一些。再就是链路测试缺失一些环节可能导致系统有一些问题。比如说我刚才说的例如自己，中间可能要缺少一个叫车环节，你正常业务直接到酒店，但是你可能没有叫车系统，测试环境没有叫车系统可能有一些问题，再就是对历史数据订单进行聚类就可以减少自动化测试的时间，因为历史数据比较大，可能我们测试覆盖率的话就是用其中20%或者30%就可以了，这块我们还需要考虑一下。
我今天分享的内容就是这么多，大家有什么问题吗？
提问：您刚才讲对于不同测试案例三个订单那块我没有听明白，您是怎么解决的，怎么通过链路来解决，因为以前我们会视为三个不同案例或者场景，您再解释一下。
樊宇：假如说这是一个系统，这是三个系统。每个系统里最开始订单生成相当于入口的数据，比如说这是下订单系统，这下一个订单以后会往这里写数据，至少有一个数据表里写的，你写数据表里就建一个触发器，这个触发器会发起Http请求然后触发这个系统的自动化测试。这个系统完事以后会往这个系统里写，会触发这个系统里触发器，你写数据过程不是自动化测试脚本的事情，是被测系统做的事情。
提问：那其实在每一个环节都设一个触发器？
樊宇：不用每个环节都触发，系统内部就不用了。
提问：订单2我理解是在第五个流程或者说在中间跳过某些流程，您是怎么让订单2也能自动的用那个？
樊宇：这个实际上可以并行的，不用人工去写，可能不同的类型。比如说一个海航的数据是订单1，你会往海航系统写数据，国航的往国航里写数据，不同类型往不同的里写数据的。
提问：所以是相当于接口的连接处设置触发器。
樊宇：被测系统做触发器，如果要进行被测系统之间数据转换测试话的，需要在你的系统那里做触发器了。你写完数据它就开始做测试执行！
本文来自：2018中国首届云测试峰会，举办方：Testin 云测
Testin，让应用更有价值：www.testin.cn
网友评论