相关文章推荐
爱笑的蜡烛  ·  Microsoft Azure: ...·  7 月前    · 
爱笑的蜡烛  ·  什么是SQL Server? - SQL ...·  7 月前    · 
爱笑的蜡烛  ·  Detect, enable, and ...·  7 月前    · 

经常在测试招聘中发现职位要求有做过服务端测试的经验,一看就感觉很高大尚,忒牛逼的样子,服务器端测试到底是测什么、怎么测,今天在看到微信公众号(搜狗测试)上一篇写的还算不错的文章,特此转给大家一起学习。

摘取了文章中精华部分内容,如想看原创文章 请关注搜狗测试公众号。

首先服务端的测试包含哪些东西呢 ?

第一反应是不是 , 服务端嘛 ~! 就是后端 , 就是 java, 就是 php, 就是 c++

实际上 , 服务端的测试简单来说就是除了前端以外的的测试 ,

总的来说可以分为以下两类 :

1. WEB 或者 APP 的提供业务逻辑的服务端接口测试

2. 数据库、缓存系统、中间件、、 jar 包依赖、输入输出敏感信息等测试 .

其中接口测试占据工作工作中的 80%, 接口测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等。下面粗略的列举出测试的几个点。

  • 检查接口请求是否正确,返回数据的正确性与格式
  • 检查接口入参的默认值、参数类型、非空校验、以及边界值检查接口的容错性 .
  • 所有功能都需要考虑兼容老版本,列表页的接口需考虑排序值
  • 检查接口的性能以及安全性
  • 对于接口内部依赖接口的不可靠性预防 ( : 依赖的第三方接口超时 )

那么有人要问了 , 那么对于接口测试如何才能做到完善完备的测试呢 ?

下面干货来了 , 在写测试用例时候可以根据该图的思路分支进行用例设计。

对于第二部分的 后端的数据库、缓存系统、中间件、文件系统、 jar 包依赖、输入输出敏感信息等测试这方面其实是要根据各个公司的流程和实际的开发环境来决定的 , 以下是小编在实际项目中一些总结 , 请对号入座各取所需

  1. 1. 性能

  2. a) 项目涉及老系统的 QPS 是多少?新系统预估的 QPS 是多少?如何预估的?

  3. b) 项目对外提供接口或者页面的平均响应时间是多少?

  4. c) 修改对系统的请求量是否会有影响?预估变化是多少?要给出计算和评估方式,不能拍脑袋!

  5. d) 修改对系统的处理能力是否会有影响?对 CPU 和内存开销影响有多大?响应时间是否会变慢?

  6. e) 修改对公共系统是否有影响,如数据库,消息中间件。

  7. 2. 内容

  8. a) 页面

i. 资源

  1. 所有页面资源要转到公司统一 CDN 的下,所有资源要写相对路径

  2. 所有的地址在上线前都要检查为外网地址

ii. 文字描述

  1. 公司名称等名词正确,语句通顺,无错别字。

  2. 3. 数据

  3. a) 对老数据的影响

i. 此次上线的接口模块产生的一系列活动和效果对老数据的影响

i. 验证精度匹配

  1. 接口参数类型

i. 参数是否都是用到了对应类型如 :bigdecimal

i. 是否涉及数据备份?

i. 是否需要对老数据进行清理和处理?

  1. 初始化脚本

i. 核对初始化脚本数据正确、是否齐全

  1. 4. 安全

  2. a) 敏感信息测试

i. 请求方式

  1. 请求中包含敏感信息的要使用 post 请求(使用 live http header 工具查看)

ii. 多余敏感信息

  1. 当接口返回中有当前页面不需要的敏感信息时要对接口拆分

iii. 敏感信息隐藏

  1. 页面中有屏蔽敏感信息的要查看其原代码是否会明文显示

  2. 生成的订单等打码 , 手机号前三后四作为显示

  3. b) 越权访问

i. 无权限

  1. 无权限访问有权限页面或接口(如:未登录访问已登录页面)

ii. 低权限

  1. 低权限访问高权限页面或接口

  2. 5. 冲突测试

  3. a) 接口并发测试

i. 多线程

  1. 是否涉及数据库操作的多线程并发?

  2. 多线程是否需要加锁进行处理?

  3. b) 管理后台

i. 管理后台同时操作测试

  1. 6. 第三方依赖测试

  2. a) 如果是 java: 是否引用了第三方的 jar 包?本次升级是否依赖第三方 jar 更改?

  3. 7. 系统结构

  4. a) 新应用

i. POM 文件

i. 数据库访问权限

  1. 要有所使用库的访问权限

ii. 配置文件

  1. 配置文件名称规则、配置文件内容

  2. c) 系统结构

i. 系统结构

  1. 外部系统异常,数据持久层异常( redis memcache db 异常) , 是否捕捉,是否影响主流程?

  2. 外部系统异常,调用第三方接口返回失败,异常,超时,是否捕捉,是否影响主流程?

  3. 对外部系统异常必须 try catch

  1. 8. 对外部系统影响,服务提供者与服务消费者

  2. a) 对上游系统

i. 是否修改原有接口的数据结构与返回数据的格式?

ii. 都有哪些外部系统(上游系统)调用了被修改的接口?

  1. 对下游系统

i. 是否新增调用第三方接口(包含下游系统,数据库,消息中间件)?

ii. 对新增调用第三方接口(包含下游系统,数据库,消息中间件)的压力有多少大,多少 QPS

iii. 接口调用方是否有缓存?自己是否需要做缓存?

  1. 9. 监控

  2. a) 项目上线后是否响应监控?监控是否加告警?

  3. b) 项目发布后应该查看哪些监控?

  4. 10. 日志

  5. a) 生产环境配置文件

i. 日志级别

  1. 应为 INFO 级别

  2. 关键业务流程和异常流程是否有日志记录?

  3. 11. 发布流程

  4. a) 数据脚本

i. 最后一个版本由 DBA 审核通过 ( 业务不同要求不同 )

ii. 内容正确,特别是涉及到展现给用户的文字(包括业务端用户和运营人员)

  1. 业务端确认

i. 核查收到需求文档中所列各业务端总监确认邮件。

ii. 确认内容为知晓此事并做相应改动或无影响。

iii. 系统的业务峰值时间段是什么?是随时发布,还是业务低谷发布?

i. 协调 PM 、开发做好发布前准备

ii. 工作时间发布管理后台,需要 PM 提前通知运营人员

i. 复杂项目必须提前定义发布流程,要求拉着 QA leader ,开发 leader 一起确认。

总结以上 , 可以形成一个进行接口测试的模板 ,( 我的心在滴血 ): 经常在测试招聘中发现职位要求有做过服务端测试的经验,一看就感觉很高大尚,忒牛逼的样子,服务器端测试到底是测什么、怎么测,今天在看到微信公众号(搜狗测试)上一篇写的还算不错的文章,特此转给大家一起学习。摘取了文章中精华部分内容,如想看原创文章 请关注搜狗测试公众号。首先服务端的测试包含哪些东西呢?第一反应是不是,服务端嘛~!就是后端,就是java,就是php,就是c+
接触过性能 测试 的小伙伴一定都听过响应时间(Response Time)、TPS、CPU资源利用率等术语,它们都属于性能 测试 的指标。本文对性能 测试 中涉及到的指标做了较为详细的整理。 性能 测试 指标一般可以分为系统性能指标、资源指标、应用指标:系统性能指标:如并发用户数、TPS(系统每秒处理事务数)、成功率、响应时间。 资源指标:如CPU资源利用率、内存利用率、I/O、内核参数(信号量、打开文件数)等。 应用指标:如空闲线程数、数据库连接数、GC/FULL GC次数、函数耗时等。
DAU:Daily Active User,日活跃用户数量,DAU通常统计一日(统计日)之内,登录或使用了某个产品的用户数(去除重复登录的用户)。 MAU: 月活跃用户量,通常DAU会结合MAU(月活跃用户数量)一起使用,这两个指标一般用来衡量服务的用户粘性以及服务的衰退周期。 pv:page view,即页面浏览量,或点击量;通常是衡量一个网络新闻频道或网站甚至一条网络新闻的... 随着5G时代的到来,以及万物互联时代的到来,云应用和云服务会越来越多,数据量会指数级增长。尤其是2020年全球疫情的时代意义,会导致各行各业开始上云。从而会催生出极具个性化的各类产品的诞生。 所有行业的生态会像鲸落效应一样,围绕若干个巨无霸公司衍生出满足人们各种需求的中小型产品。大部分产品的形态可能会变成重 服务端 、轻客户端。 所以, 服务端 性能 测试 的需求也有可能会出现井喷式增长。但是 服务端 性能 测试 需求对于中小型公司,尤其是大部分不关注用户体验的公司来说.
文章转自微信公众号(搜狗 测试 ) 上一次和大家分享了《服务器接口 测试 浅析》,讲了一些接口 测试 的基本概念和理论知识。在上次的分享中,简单提到了接口 测试 用例设计包含的几个方面。本期我将在上次分享的基础上,和各位小伙伴一起具体看看这几个方面都是什么,在实际的项目中应该如何使用。 一、功能性用例设计 之前讲过, 服务端 的接口是和客户端的功能相对应的,对功能的验证,可以参照接口说明文档来进行。
你好!如果你正在寻找一个用于 测试 WebSocket 服务端 的工具,我推荐使用以下几个工具: 1. WebSocket-Sharp:这是一个用 C# 编写的开源库,可以用于创建 WebSocket 服务端 和客户端。你可以使用它来 测试 你的 WebSocket 服务端 的功能和性能。 2. Autobahn|Python:这是一个用 Python 编写的 WebSocket 测试 套件,可以用于 测试 WebSocket 服务端 的遵从性和性能。它提供了一系列的 测试 用例和工具,可以帮助你验证你的 WebSocket 服务端 是否符合标准规范。 3. wscat:这是一个基于 Node.js 的命令行工具,用于 测试 WebSocket 服务端 。它可以向 WebSocket 服务端 发送消息并接收响应,方便你进行简单的功能 测试 和调试。 以上是一些常用的 WebSocket 服务端 测试 工具,你可以根据自己的需求选择合适的工具来进行 测试 。希望能对你有所帮助!如果有其他问题,请随时提问。