服务端测试｜单接口如何测试_微服务 单个服务接口测试，2024年最新你们觉得作为一名程序员最大的悲哀是什么

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注软件测试）

正文

不管是测试单个服务还是某个服务提供了API需要测试，它的思想本质是不会改变的，那么这个本质是什么呢？其实就是客户端与服务端之间的交互，不管是单体架构模式还是微服务架构模式而言，服务提供的API本质上都是客户端与服务端之间的交互，只不过在通信模式有区别而已。大多数我们见到的都是同步通信的模式，也就是客户端向服务端发送请求后，服务端需要响应回复客户端的请求，具体交互过程如下所示。

如上的交互模式一般都叫请求/响应模式，当然也可以说同步通信模式。

有了同步通信必然会有异步通信的模式，那么为什么会有异步通信的模式呢？这主要是因为同步通信虽然能够满足大部分的场景，但是在某些场景下使用异步通信模式更加具备优势，同时同步通信模式还存在请求请求超时的问题，具体来说就是客户端发送请求后当服务端存在异常导致客户端的请求一致超时，第二是同步通信由于存在超时问题可能导致任务堵塞。毕竟在工作中实际测试的产品服务与服务之间的交互虽然没有不是高并发的情况但是客户端的请求不可能是只发送一个请求，而是在产品业务链交互过程中客户端与服务端会不断的发生交互。因此由于同步通信模式存在缺陷，也就有了异步通信的模式，它的优势是客户端与服务端交互的过程中并不需要关注对方的存在，更多关注的是消息。对客户端而言，它不需要关注服务端是否存在，它关注的是消息发送后把消息经过处理后的结果返回给客户端就可以了，异步通信模式具体如下。

单接口测试维度

服务最终提供的都是API进行测试，因此首先需要的是针对单个接口的测试策略与思路，总结下来具体如下几点：

• 验证请求参数中必填参数是否做了为空校验
• 验证请求参数的数据类型是否做了判断
• 验证请求参数的字段长度是否做了长度限制的判断
• 验证请求参数是否做了填写特定值的判断

下面结合具体的案例来说下这部分，首先来看被测服务的源代码，具体如下：

#! /usr/bin/env python

-- coding:utf-8 --

author:无涯

from flask import Flask,jsonify
from flask_restful import Api,Resource,reqparse

app=Flask(name)
api=Api(app)

class LoginView(Resource):
def get(self):
return {‘status’:0,‘msg’:‘ok’,‘data’:‘this is a login page’}

def post(self):
parser=reqparse.RequestParser()
parser.add_argument(‘username’, type=str, required=True, help=‘用户名不能为空’)
parser.add_argument(‘password’,type=str,required=True,help=‘账户密码不能为空’)
parser.add_argument(‘age’,type=int,help=‘年龄必须为正整数’)
parser.add_argument(‘sex’,type=str,help=‘性别只能是男或者女’,choices=[‘女’,‘男’])
args=parser.parse_args()
return jsonify(args)

api.add_resource(LoginView,‘/login’,endpoint=‘login’)

if name == ‘main’:
app.run(debug=True,host=‘0.0.0.0’)

在如上代码中可以看到服务端针对为空以及请求参数数据类型都做了处理，比如年龄只能是正整数而不能是字符串，性能只能是指定的特定值也就是男或者是女而不能是其他。来一个简单的案例实战，如年龄传的是字符串，看服务端服务的错误信息，具体如下：

如上所示服务端针对年龄不规范的请求参数在后端做了处理。另外一点需要考虑的是请求参数中字段的长度限制，如POST请求是往数据库中添加一条数据，如请求参数里面包含了书籍名称等字段，数据库设计书籍名称字段是10，但是请求参数中长度超过了10，如果后端针对这部分没做处理的时候导致在数据库这层出错，进而导致服务端这层也就出了问题。所以如上总结的针对单接口的测试维度每个点的背后都是存在它的逻辑合理性与测试范围完整性的考虑。

业务驱动

针对服务提供的接口仅仅考虑单接口的测试维度是不够的，也要结合产品的业务来验证服务提供的API合理性和业务完整性。服务提供API的最终目的是服务业务，因此满足业务特性是第一要素。如服务请求参数是username与password，返回的TOKEN作为其他服务访问系统的认证凭证，但是返回的TOKEN又是加密的。在这样的一个业务形态中，仅仅验证接口是否返回TOKEN是不够的，也要验证返回的TOKEN它的有效性、和它的时效性，总结下来就是：

• 返回了TOKEN不代表TOKEN可用，因此把它作为其他服务请求参数验证它的可用性
• 返回的TOKEN可用也要考虑它的时效性，如返回的TOKEN5分钟过期，那么很明显这是不合理的。具体它的时效性是多少合适了，还是需要结合具体的业务和整体的产品和系统架构来规定这个时间

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
0)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！