侧边栏壁纸
  • 累计撰写 31 篇文章
  • 累计创建 14 个标签
  • 累计收到 0 条评论

目 录CONTENT

文章目录

服务端测试有什么价值?

AllyTester
2024-07-25 / 0 评论 / 0 点赞 / 11 阅读 / 0 字

服务端测试是指绕过客户端,直接对后端服务进行测试的测试手段,服务端的测试相比客户端的测试方式,能够更加体现出测试的效率和服务底层的质量保障,减少后期维护和修复成本。

服务端测试内容

1.对外接口:

  • 对外接口通常是基于 http 协议实现的,主要是面向客户端提供对应的业务功能。

  • 价值:对外接口测试基本可以实现业务保障、服务高可用和安全性。

  • 测试内容:可以将用例分为主流程、Input、handle、output层进行设计,用例维度更加清晰。各种正向、逆向场景:入参协议校验(必填/非必填、数据类型、边界值、特殊值)、约束条件(条件覆盖、数值限制、状态限制)、数据源校验(重复操作、状态限制、不同数量处理)。

2.三方或内部服务交互(服务故障演练)

  • 底层服务逻辑有的场景也需要依赖于三方服务/内部服务获取数据,例如登录接口的验证码服务。

  • 测试内容:对于被测服务我们应该关注的是服务交互异常的情况,通常需要考虑的是三方服务返回超时、连接失败、返回异常状态码、查询数据时三方服务返回空结果、被测服务在请求三方服务时协议是否正确、依赖服务异常下线等。

  • 服务故障模拟手段:

    • 依赖服务返回异常状态码 - 通过抓包工具篡改结果返回

    • 依赖服务返回超时 - 通过抓包工具拦截依赖服务的回调

    • 依赖服务异常下线 - kill -9 对应进程

3.数据读写

  • 数据的读写存储通常都需要依赖于服务中间件、数据库等。

  • 常见服务中间件:redis、kafka、rabbitmq。

  • 测试内容:正向数据读写功能、服务器资源利用率、数据一致性、处理效率。

    • a. 正向数据读写功能:验证读写和我们期望的结果是否一致,通常需要依赖于对外接口来实现。此外,我们可以通过数据库查看,或者通过其他查询接口验证结果。

    • b. 服务资源利用率:数据频繁的IO读写会占用内存使用率、cpu 使用率,如果使用率过高会导致服务的内存溢出甚至是宕机。一般需要通过性能测试的手段衡量服务器资源是否满足于产品需求场景。

    • c. 数据一致性:该场景通常是在数据读写分离时出现,如果写入的数据没及时同步到查的数据表中,那查询的数据结果和你所存储的数据就会有不一致的现象,测试手段除了校验数据更新、数据写入、数据查询等接口功能,有时也需要依赖于性能测试等手段去校验。

    • d. 处理效率:合适的内存读写和缓存读写方式可以提高业务逻辑处理效率。必要时我们需要通过性能测试等手段提供可参考的性能指标。

4.性能测试

高并发情况下:观察 cpu 使用率、内存使用率是否有递增,事务失败率是否异常,tps 是否有波动。

5. 服务端安全性

服务最容易被攻击的对象还是接口,只要解析接口参数就能进行数据篡改,或者通过接口请求进行 DDoS 攻击,在接口层通常需要增加几层防御措施。

  • 第一层:提高接口路径、IP、port的获取难度,比如使用网关进行路径映射,或者通过 http 接口认证后才能获取到 socket 对象。

    • 测试内容:校验映射关系是否正确。如果有认证接口,需校验不同的操作对象、身份正确性、时效性。

  • 第二层:增加网关防护,可以进行 IP 白名单管理,或者增加限流策略。

    • 测试内容:设计文档需描述详细的配置信息,校验防护机制的功能是否与预期一致。

  • 第三层:消息传递时进行数据加密,通常有对称加密 AES 和非对称加密。

    • 测试内容:请求协议在不加密的情况下是否能够请求成功;返回协议是否有加密处理;服务端是否能正常解析加密数据;加密方式是否严谨,容不容易被破解。

6.服务升级测试

验证版本升级的正确性、可靠性,文档正确性、历史数据是否能够向下兼容、回滚策略校验、新版本业务数据是否能够向上兼容。

7.服务端启动配置项

服务的启动配置项通常包括启动时的端口配置、服务数据库的连接信息、业务属性相关的开关、网关策略。

涉及业务层的开关、网关策略,如果想要保障服务代码高覆盖、高可用,需要针对性而定进行测试,测试前需确定配置是否支持“热更新”,如支持“热更新”则在服务运行时修改配置,校验服务对外表现是否是修改配置后的效果,否则静态更新配置后需重启服务才能校验对应功能的正确性。

服务端测试的价值

践行测试左移,更早的发现问题:

除了需求了解阶段之外,服务端测试允许测试人员在设计阶段就可以介入,了解底层服务交互逻辑、接口设计文档等,并站在质量保障的角度提出可优化的建议,还能前置编写测试计划、测试用例、搭建自动化测试框架以及用例脚本的转化,大大缩短了周期。

服务端测试远比功能测试更理解底层服务的实现,遇到问题能够更快速更精准的发现问题,减少后期修复成本。

测试策略的颗粒度更细,场景覆盖相对于功能测试更齐全,有更高的代码覆盖率:

测试层次

服务端测试覆盖场景

功能测试覆盖场景

单元测试

函数逻辑、异常分支

接口测试

各种正向、逆向场景:入参协议校验(必填/非必填、数据类型、边界值、特殊值)、约束条件(条件覆盖、数值限制、状态限制)、数据源校验(重复操作、状态限制、不同数量处理)

仅验证接口返回结果是否符合预期

集成测试

分布式锁、缓存一致性、消息队列消费异常

模块间简单交互

性能测试

单接口压测、混合场景负载、资源泄漏检测

页面响应时间

服务端测试 VS. 功能测试的区别

维度

服务端测试

功能测试

测试目标

验证服务端逻辑、性能、安全、数据一致性

验证用户可见功能是否符合需求

测试范围

接口、数据库、中间件、网络通信等底层模块

用户界面、端到端业务流程

测试手段

接口测试、性能压测、安全扫描、Mock测试

手动测试、UI自动化测试、冒烟测试

测试颗粒度

细粒度(单接口、单服务、依赖隔离)

粗粒度(完整业务流程、多模块组合)

环境依赖

可独立运行(如通过Mock隔离外部依赖)

依赖完整前后端环境

问题发现阶段

早期发现底层逻辑缺陷(如并发问题)

中后期发现交互逻辑或兼容性问题

服务端测试可以更细粒度的保障产品质量,提早发现问题,提高服务的可用性、稳定性、安全性,提高测试效率,降低后期维护修复成本。

0

评论区