Web 系统与后台 Server 的 socket 接口测试

【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 系统。

微信+17031115530，拉测试微信群交流