每次版本迭代测试团队最头疼的往往不是发现新 Bug而是那些重复了无数遍的回归测试。尤其是接口测试面对几十个甚至上百个 API手工在 Postman 里一个个点、复制参数、比对返回结果不仅耗时耗力还容易因为疲劳导致漏测或看错数据。当开发频率加快到一天几个构建时这种“人肉运维”的模式显然已经成了瓶颈。其实对于大多数中小项目或快速迭代的场景我们并不需要立刻引入庞大复杂的自动化框架。利用 Python 强大的生态只需几十行代码就能写出一个轻量级的自动化脚本把我们从机械的重复劳动中解放出来。告别手工点击用 requests 封装核心请求我们可以封装一个简单的函数统一处理 GET 和 POST 请求。这样无论后续有多少个用例调用逻辑都是一致的。以下是一个基础的封装示例importrequestsdefrun_api_request(method,url,paramsNone,dataNone): 封装通用的请求执行函数 :param method: GET 或 POST :param url: 接口地址 :param params: URL 查询参数 (字典) :param data: 请求体数据 (字典或 JSON) :return: 响应状态码和响应内容 try:ifmethod.upper()GET:responserequests.get(url,paramsparams,timeout10)elifmethod.upper()POST:# 自动将字典转换为 JSON 发送responserequests.post(url,jsondata,timeout10)else:returnNone,不支持的请求方法# 返回状态码和响应文本returnresponse.status_code,response.textexceptExceptionase:returnNone,str(e)这段代码虽然简单却解决了手工测试中的几个痛点统一的超时控制、异常捕获防止网络波动导致脚本直接崩溃以及自动处理 JSON 数据序列化。现在你不再需要关心底层的连接细节只需要关注输入和输出。数据驱动从硬编码到读取测试用例有了执行函数接下来要解决的是“测什么”的问题。手工测试时用例通常散落在 Excel 表格或文档里。为了让脚本能批量跑我们需要把这些用例数字化。对于初学者JSON格式是最友好的选择。它既是标准的配置文件格式又与 Python 的字典结构天然契合。我们可以创建一个test_cases.json文件把待测接口整理成列表[{case_id:001,name:获取用户信息,method:GET,url:http://api.example.com/user/123,params:{},expected_code:200},{case_id:002,name:创建新订单,method:POST,url:http://api.example.com/order,data:{product_id:88,count:1},expected_code:201}]如果你的团队习惯用 Excel也可以利用pandas或openpyxl库读取原理相同将每一行转换成一个包含method、url、data等字段的字典对象。关键在于测试数据与执行逻辑分离。以后新增用例只需修改 JSON 文件无需动代码一行。一键批量执行循环与结果反馈最后一步是将数据与执行函数串联起来。通过一个简单的循环脚本可以依次读取用例、发起请求、并即时打印结果。importjsondefmain():# 加载测试用例withopen(test_cases.json,r,encodingutf-8)asf:casesjson.load(f)print(f开始执行回归测试共{len(cases)}个用例...\n)pass_count0forcaseincases:methodcase[method]urlcase[url]paramscase.get(params)datacase.get(data)expectedcase[expected_code]# 执行请求status_code,resultrun_api_request(method,url,params,data)# 简单的断言逻辑ifstatus_codeexpected:verdict✅ 通过pass_count1else:verdict❌ 失败# 打印单条结果print(f[{case[case_id]}]{case[name]}-{verdict}f(期望:{expected}, 实际:{status_code}))print(f\n测试结束。总计{len(cases)}, 通过{pass_count}, 失败{len(cases)-pass_count})if__name____main__:main()运行这个脚本你会看到控制台像流水线一样输出每条用例的执行情况。原本需要半小时手工点点点的回归任务现在几秒钟就能完成。如果某个接口返回了非预期的状态码脚本会立即标记为“失败”让你能迅速定位问题。从手动到自动的思维转变这个脚本虽然没有华丽的报告界面也没有复杂的并发机制但它完成了一次质的飞跃将不确定的手工操作变成了可重复、可验证的代码流程。对于刚接触自动化的同学来说不必一开始就追求完美的框架设计。先试着把最痛的那个重复环节用几行代码替代哪怕只是每天节省 10 分钟长期积累下来的效率提升也是惊人的。当你跑通了这个最小可行性脚本再去考虑如何生成 HTML 报告、如何接入 CI/CD 流水线一切都会变得顺理成章。下次版本发布前试着关掉 Postman运行一下你的 Python 脚本吧。让机器去处理重复让人脑去思考更复杂的业务逻辑这才是技术带来的真正自由。