名词解释:

【Web系统】:本文中的web系统指的是基于B/S结构的事务处理系统。Web系统一般分为前端ui和后端业务处理模块两部分。
【后台Server】:本文中的后台server泛指与web系统的后端业务处理模块进行数据交互的模块。

1 web与server接口背景描述

web系统的后台模块数据交互,通常有多种方式:数据库、文件、socket接口、web service等方式。本文主要讨论的是web系统与server模块的socket的接口的类型、测试关注点和常用工具。

web与server模块的socket接口有简单有复杂,简单的可能只有一个id的查询,复杂的可能需要批量的增删改查。它们有共有的功能,也有各自独立的功能,下文将就web与server接口中遇到的不同问题,从web测试角度进行分析。

需要说明的是,本文的主要目的是从大的方面讲述web与server接口测试需要检查的点和可能存在问题的地方,其中任何一个问题都可以放大为一个专题,所以本文限于篇幅不做过细的剖析。

2 接口测试关注点

在一个项目中,QA会从需求、设计、开发、测试、上线等阶段一直跟进。因此对于web与server的接口测试并不是局限在测试阶段,而很多的问题在需求和设计阶段就可以发现和解决,事实上从需求和设计阶段就发现并解决的问题,比在测试阶段发现之后再解决的成本要小很多。所以本文中叙述的测试点,并非单指测试阶段,QA在参加需求评审和设计评审的时候就需要想到可能出现的问题和处理方法。

本节将从web与server之间交互的环境稳定性、连接建立及关闭、数据发送及接收等方面介绍接口测试的关注点。

2.1 server服务容灾

2.1.1 单点问题

所谓单点,是指这个一旦一台服务器出现问题,将导致整个服务都受到影响。

提供服务的server模块,根据实现方式不同,有的是分布式服务(多台服务器提供不同的数据),有的是互备服务(多台服务器提供相同的数据)。无论哪种情况,都需要在评审、测试时注意服务是不是存在单点问题。

这里说的单点问题包括server和web两个方面:

1、server服务本身是单点的,一台服务器出现问题,整个服务都不可用。

【例1】某web系统的用户信息通过socket接口方式存储在某server模块中,server模块的接口支持用户信息的增删改查。此时一旦 server模块发生问题,那么web的功能就会受到影响。此时需要建议RD考虑避免单点或减少单点影响的方法。

常用方法:(1)server模块有多个,由web端控制,每次的写操作都针对多个server分别执行,保证多个server模块数据一致;(2)为 server准备备机,在主server与备机server之间设定数据同步方式,一旦主server发生问题即切换到备机;(3)主server下挂接从server,从server的数据同步自主server,主server接收写操作,从server接收查询操作,此方法既能够缓解压力,也能够有效缓解单点问题,一旦主server异常,可以把某个从server替换主server。

2、web端连接server服务的方法是单点的,一旦一台服务器出现问题,web端无法自动屏蔽这台服务器,导致web服务受到影响。

【例2】某server模块提供纯查询服务,web系统通过socket接口方式向此server查询数据。Server模块为缓解压力及避免单点问题,同时提供了一模一样的3套服务供web系统使用。但web系统查询3个server时,是按照完全随机的方式查询的。如果3台server中有一个存在问题,那么web系统落在此server上的查询请求全部会失败。此时需要在web系统中考虑容错方法。

常用方法:(1)短连接:发送请求时重试n次无法连接某server,则从server列表中找另外一个server建立连接;(2)长连接:web系统定时发送心跳请求检查与所有server的连接关系;(3)在web与server之间挂接BVS之类的中间转发请求模块,如果server发生问题,只需利用BVS的自动检查连接状态功能或者利用BVS能快速修改配置的特点,在不需web系统调整的情况下,检查服务受影响时间。

【测试检查点:是否单点;避免或缓解单点问题的方法是否可保证数据部丢失且切换快捷。】

2.1.2 域名还是IP

线上部署的web系统,访问server模块一般是从内网访问的。在配置访问地址时,有时配置成内网域名,有的配置成内网IP地址。

配置为内网域名:
【优点】:server服务器的IP调整不会对web发向server的请求造成影响,web不需修改IP地址;
【缺点】:(1)web对server的每次连接建立,都需要经过内网dns的解析,对于实时性和性能要求高的业务功能来说,这样的请求方式效率不如直接配置IP高;(2)一旦内网dns出现故障或者压力过大,会造成域名解析失败,无法建立连接。(实际上,线上出现这种情况的概率还是不小的。)

【例3】某web系统把连接server的地址设置为域名:web-socket.test.com,在实际测试中发现web发出的请求server有时能接收到有时接收不到。原因是此域名在内网dns解析时有时会超时或解析失败。后修改为IP地址此问题未再出现。

【测试检查点:配置的是域名还是IP,域名是否正确,IP是否正确,上线后域名解析是否存在失败较大的失败风险。】

2.1.3 机房因素

网通和电信用户访问系统,会落在不同的机房,我们的web服务和server服务也是分别在不同的机房部署。所以,在程序实现、在线上部署时,为了保证访问速度,最好是配置同机房的web系统访问同机房的server服务。

【例4】某server模块部署在A机房,而访问此server的web系统在A机房和B机房都有部署。上线后发现在业务高峰期,在B机房的web系统偶尔会出现访问server失败或超时,原因是B机房的web系统访问A机房的server跨机房情况下,延迟比同机房要大一些,在web系统配置相同的超时时间情况下,跨机房请求出现超时的概率就大一些。修复方式:(1)修改跨机房的web系统或server模块配置项,把超时时间调大(不推荐);(2)尽量保证同机房内访问server。

【测试检查点:是否同机房web与server相连;如果不是,是否会存在性能问题。】

2.2 连接建立及关闭

Web系统与server服务建立连接时,需要考虑server服务器选择、建立长连接/短连接选择、连接超时时间设定、建立的连接数、是否使用连接池等各种情况,下面就这些情况的测试考虑分别描述。

2.2.1 Server服务器选择

一般情况下,提供服务的server程序都会提供多台服务器(只提供一台服务器的情况也就不存在选择不选择的问题了)。Web系统如何在多台服务器中选择连接哪个服务呢?这要分情况来看。

第一,如果server服务是分布式的,那么web系统选择服务器是根据与server模块的功能接口来确定的。常见的选择方式有:取模、哈希等。

这里需要注意的是,如果分布式的多台server服务器中有部分服务器出现故障,web服务用怎样的逻辑保证web服务不受影响。根据不同的服务类型,有不同的处理办法。有的情况下web系统抛出异常,有的情况下web系统自动识别无法连接的服务器,对可用服务器进行hash,只与可用服务器建立连接。

【测试检查点:取模、哈希结果是否正确,是否能够把请求发送到正确的服务器上;算法结果是否使得请求均匀落在多台server服务器上;如果一台服务器出现错误,容错机制是否满足需求。】

第二,如果server服务是互备式的,那么出于容错和均匀请求考虑,web系统常用如下策略选择server服务器:首先在多台server服务器中随机选择一台建立连接,如果被选中的服务器无法建立连接,则在剩余的服务器中再随机选择一台,如此重复多次。直到在重复次数内选到一台可用server服务器,或者没有选中任何一台可用server服务器。当然,在每次连接过程中都可以控制尝试多次重连。

【测试检查点:上述随机轮询机制是否正确;发送多次请求,是否均匀发送到多台server服务器上。】

2.2.2 长连接/短连接

Web、server之间可以建立“长-长”、“长-短”、“短-长”、“短-短”等四种连接,长短连接各有利弊,在测试中需要关注的是,web与 server的连接是上述四种中的哪种或者哪几种,尤其需要注意的是,这种连接方式是否满足web系统的需要。关于长短连接不同的建立、中断状态,非只言片语可以概括,另撰文叙述,本文中不做讨论。

【例5】凤巢web系统与报表server模块doris之间有一类功能交互:web系统单线程串行向doris请求大数据量数据。在这种情况下,web 与server之间用长连接就比短连接要更高效,单线程顺序发请求,省去了连接重复建立和关闭的过程。
【例5】某Server模块建立的连接始终都是长连接,只要主动发起连接的web系统不断开连接,此server模块就不会断开连接。某web系统与此 server模块的数据交互有两类功能:(1)web系统并访问server模块获取少量数据;(2)web系统单线程不间断串行发请求server模块获取大量数据。对于这两种交互场景,第一种情况下web系统与后台server模块建立短连接,获取数据之后关闭连接,下次请求再重新建立连接;第二种情况下web系统与后台server模块建立长连接,不主动关闭连接,省去了不必要的多次建立连接和关闭连接的时间。

【测试检查点:web与server建立的连接是哪种连接方式;是否符合业务需求、是否符合web系统需求。】

2.2.3 连接超时时间设定

连接超时时间分为:建立连接超时时间、连接空闲超时时间。

建立连接的超时时间是指发起建立连接的请求时,未得到对方响应而中断请求的超时时间。

【测试检查点:建立连接超时时间是否生效,超时时间设置的时长是否合理。】

连接空闲超时时间是指当一个长连接长时间空闲时,连接被关闭回收的时间。很多server服务都限定了长连接的空闲超时时间,包括mysql的长连接也是如此。

【例6】某web系统与mysql数据库之间是长连接,由于web系统访问量小,web系统与mysql之间的连接有时会有很长的空闲时间,该空闲时间超过了mysql配置的空闲超时时间,mysql就主动关闭该连接。当连接关闭之后下一次web系统有访问需要向mysql发请求时,由于长连接已经中断,而web系统容错不足,导致在连接再次建立起来之前的请求都会失败。所以在这种情况下需要注意,或者注意超时时间设置,或者注意发心跳请求以维持连接。

【测试检查点:web端和server端的长连接空闲超时时间是否生效;超时时间设置的时长是否合理;连接超时被关闭后,再有请求到来是是否能够正常建立连接。】

2.2.4 建立的连接数

Web与server建立socket连接时,有的系统用连接池来管理连接、有的系统不用连接池。对于使用连接池的情况,需要设定初始化连接数、最大连接数、最大空闲连接数等参数,在测试中需要关注初始化的连接数是否成功建立,上述三个连接数是否合理。对于不用连接池的情况,也需要注意创建的连接个数是否正确。

另外,还需要考虑上线后多台web服务器连接多台server服务器的情况下,会不会造成server服务支持的连接数超过限制,甚至web服务器和 server服务器机器本身的socket连接不够用。在测试环境中模拟、评估后,如有必要,需要修改线上服务的连接数,或者服务器支持的socket连接数。

【例7】某web系统把用户登录信息存储在server memcache中,web系统与memcache之间是短连接。由于用户在web系统中的所有操作都需要访问memcache以验证登录状态,所以导致当多台web并发访问用户很大时,会导致memcache所在的服务器上由于连接数过多而拒绝了很多web发起的请求。经过分析,发现访问高峰期web系统与memcache上建立的连接,超过了memcache服务器默认1024个最大连接数(即单进程允许打开的最大文件句柄数)。后通过两种方式解决此问题:(1)memcache所在服务器的最大连接数调大,由1024调整为10240;(2)web系统把每次从memcache中得到的结果在本地 web系统中缓存5秒,以减少访问memcache的并发量。

【测试检查点:各个连接数是否与设置相同;特殊情况下设置最大连接数为1时,要特别注意是否会出现已有连接未完全关闭导致出现无法新建连接的情况;server服务支持的连接数是否不足;web服务器和server服务器支持的socket连接数是否过小。】

2.2.5 是否使用连接池

对于使用了连接池的web系统,测试检查点与上小节相同,主要是连接的个数和连接池对各状态的连接的管理。

对于未使用连接池的web系统,测试检查点就要多一些,要关注到连接的建立、状态、个数、关闭,以及连接不足时的新建逻辑等。

2.2.6 关闭连接

建立连接就对应着关闭连接,在实际的项目中,有的是由连接池来管理,有的是程序直接关闭。需要在详设时就明确连接关闭方法,一般情况下说来,用连接池管理效率会更高一些。

【测试检查点】:双方连接是否正常关闭;在大并发情况下,是否会造成连接数过多报错的情况。

附上关闭连接的交互过程,以供参考:


2.3 发送数据

建立了连接之后,下一步就是web端发送请求数据了。发送的请求数据根据不同的功能,有不同的数据格式,以下列出发送请求的主要测试点:

发出的请求格式是否正确。黑盒角度:直接看对端日志和返回结果;白盒角度:截取发出的请求,检查结构体中数据填充是否正确

发出的请求结构体如果不是定长,需要以设计的最大长度作为边界值进行测试。

从功能角度,填充结构体中的不同块的内容(也就是覆盖到不同的业务功能逻辑),检查是否能够正常发出,对方是否能够正常处理。

2.4 接收数据

发送请求之后,web端必然会接收到返回结果。返回的结果数据根据不同的功能,也是有不同的数据格式,一下列出通用的主要测试点:

检查返回结果是否正确。黑盒角度:检查web端是否正常解析,有无报错;白盒角度:截取返回的数据,检查结构体中数据填充是否正确

如果返回的结构体不是定长,需要以设计的最大长度最为边界值进行测试

如果返回的结果体中的循环数据有很多,需要检查与发送出去的数据是否一一对应。

【例9】某web系统向某后台server模块批量发送100个词的合法性验证请求,server模块返回结果中针对每个词都有对应的检查结果标识,在测试中需要检查该server模块返回的是否是100个词,100个词返回结果是否与发出的待检查数据对应等。

从功能角度,设计覆盖到不同业务功能逻辑的数据,发送并接收解析,从web端和server端分别检查处理是否正常。

在并发情况下或者在传输大的数据包情况下,检查是否会出现收包未收完就关闭了连接的情况。这种情况在测试环境不太容易测到,但在java程序中却比较常见,需要做的是防患于未然,在RD设计和开发时,提醒web的RD注意接收数据流的读取方式,一定要循环读取到最后一个字节才关闭连接。

【例10】某web系统向某server发数据查询请求,在测试过程中发现web系统偶尔会出现查询请求报错。Web系统报错提示server返回数据不完整,而server的提示比较奇怪,有时会提示数据传输完成,有时提示连接被意外关闭数据传输失败。经过使用截包工具追查,找到原因是web系统在关闭连接时没有判断server返回的数据是否接收完成,所以当server返回数据量比较大时,web系统会接收到不完整数据导致报错。

3 常用工具

3.1 桩

在测试过程中,有时候为了方便构造数据,或者在server未就绪的时候web就可以进行测试,需要以桩模块的形式设计一个桩模块,用于模拟server 的功能,以特定的结构体返回数据给web。

桩模块在测试接口非常有用,常见应用场景:(1)web系统测试开始时,server模块尚未达到测试条件,web系统与server模块的测试无法进行下去,可以使用桩模块进行测试;(2)web系统与server模块的测试数据难于构造,尤其是边界值、特殊数据等,可以通过桩模块构造数据方便测试;(3)web系统测试需要一套长期稳定的server模块用于测试(此测试非该web系统与server模块的接口测试),但server模块无法提供这样的环境,可以通过桩模块来保证web系统正常功能测试进行。

3.2 截包工具

在测试过程中,有时候为了追查问题,或者需要白盒角度测试结构体内容填充是否正确,需要把web与server之间的交互数据都截取下来进行分析。截包工具截取到的数据,可以用于功能正确性验证、bug分析、自动化结果验证等。

截包工具的原理比较简单,所以在实际测试中,也可以用自己熟悉的变成语言字节编写一个类似的工具,并结合数据解析或者自动化验证的功能,可以加大测试的深度。

4 总结

上文介绍了从web测试角度测试web系统与server模块的接口在测试各阶段需要关注的点,需要说明的是,本文中介绍的测试关注点是根据笔者实际项目测试实践总结的较为通用的检查点,并非web系统与server模块接口测试的全部检查点。在实际测试中,除了通用的检查点之外,更重要的是接口功能检查,因为这才是接口的核心价值所在。

总而言之,Web系统与server的socket交互方式广泛存在于web系统中,为了保障web系统服务稳定,需要从项目设计阶段就开始关注接口的各测试点,以使得问题更早暴露更早解决,同时在测试设计和测试执行阶段需要多方面测试接口,最终交付接口交互稳定高效的web系统。