面试题：接口测试相关

1. 接口测试用例的编写要点有哪些？

接口测试用例需覆盖“功能完整性、参数合法性、异常场景、安全性”，核心要点：

2. 你是怎么测试接口的？

接口测试流程遵循“设计→准备→执行→分析”闭环，工具与方法论结合：

一、测试环境与工具

• 环境：独立的接口测试环境（与开发联调环境隔离，避免数据污染）；
• 工具：
• 手动测试：Postman（界面操作，适合单接口调试）、curl（命令行，如curl -X POST -d '{"mobile":"13800138000"}' https://api.test.com/register）；
• 自动化测试：Python+Requests（编写脚本批量执行）、JMeter（性能测试）、Swagger（接口文档+调试）。

二、核心测试步骤

1. 接口文档评审：确认URL、参数、响应格式、业务规则（如“注册接口是否需要短信验证码”），输出《接口疑问清单》。
2. 用例设计：按问题1要点编写用例（覆盖参数、逻辑、异常场景）。
3. 执行测试：

• 功能测试：Postman按用例执行，验证响应是否符合预期（如code=200、数据正确）；
• 自动化测试：用Python+Requests编写脚本（示例如下），结合Jenkins定时执行：

importrequests url="https://api.test.com/v1/user/register"data={"mobile":"13800138000","password":"123456"}res=requests.post(url,json=data)assertres.status_code==200assertres.json()["code"]==200# 验证业务code

• 性能测试：JMeter模拟1000并发请求，检查响应时间、错误率（如“秒杀接口是否支持1000 QPS，错误率<0.1%”）。

4. 缺陷管理：提交BUG（附请求/响应报文、复现步骤），例：“注册接口password传空时返回code=200，应为code=1003”。
5. 回归测试：开发修复后，重新执行相关用例（自动化脚本可快速回归）。

三、问题定位技巧

• 接口返回500：查看服务端日志（grep "register" app.log），定位SQL错误或代码异常；
• 数据不一致：对比请求参数→数据库数据→响应数据，如“注册返回userId=123，但数据库无此记录”→服务端事务未提交。

3. GET和POST的区别？

GET和POST是HTTP最常用的两种请求方法，核心区别在于“语义、数据传输方式、安全性”：

测试关注点：

• GET接口不应用于提交敏感数据（如密码）；
• POST接口需验证“防重复提交”（如订单提交添加Token，避免用户重复点击导致多下单）。

4. HTTP和HTTPS的区别？

HTTPS是HTTP的安全版本，核心差异在于“加密传输”，避免数据被窃听/篡改：

测试验证：

• 用Charles抓包HTTPS请求，若无证书信任配置，应显示“加密数据”（无法直接查看明文）；
• 访问HTTPS接口时，浏览器地址栏显示“锁”图标，点击可查看证书信息（有效期、颁发机构）。

5. Cookie和Session的区别？

Cookie和Session均用于“维持用户会话状态”（如登录后保持身份），但存储位置和安全性不同：

测试场景：

• Cookie测试：清除浏览器Cookie后，访问需登录的接口（如/api/user/info），应返回“未登录”错误；
• Session测试：服务端重启后，Session失效，用户需重新登录（若用Redis存储Session则不受影响）。

6. Token是做什么用的？

Token是“用户身份的令牌”，用于替代Cookie+Session实现无状态认证，核心作用：

• 身份验证：用户登录成功后，服务端生成Token（如JWT格式：header.payload.signature），客户端后续请求在Header中携带Authorization: Bearer <token>，服务端验证Token合法性（签名是否有效、是否过期）。
• 权限控制：Token中可嵌入用户角色信息（如{"role":"admin","exp":1696000000}），服务端无需查库即可判断权限（如“管理员Token可访问/api/admin接口，普通用户不可”）。
• 跨域支持：Cookie受同源策略限制，Token可在不同域名间传递（如前后端分离项目，前端部署在a.com，接口部署在b.com）。

测试验证：

• Token过期：修改Token的exp字段为过去时间，请求接口应返回"code":401,"msg":"Token已过期"；
• 伪造Token：篡改Token签名部分，服务端应返回"msg":"Token无效"。

7. 接口测试有没有测试出什么问题？

接口测试是发现“服务端逻辑缺陷、数据一致性问题、安全漏洞”的关键手段，典型问题案例：

• 1. 参数校验缺失：

• 问题：用户注册接口password未校验长度（可传1位密码），导致弱密码风险；

• 修复：添加校验password长度6-20位，返回"msg":"密码长度需6-20位"。

• 2. 业务逻辑漏洞：

• 问题：订单支付接口未校验商品库存（直接扣减余额），导致“超卖”（库存0时仍可下单）；

• 修复：添加库存预扣减逻辑，下单前检查stock>0。

• 3. 数据一致性问题：

• 问题：用户充值接口返回“充值成功”，但数据库balance未更新（事务未提交）；

• 修复：服务端添加事务管理（@Transactional），确保接口返回成功时数据已落库。

• 4. 性能瓶颈：

• 问题：商品列表接口未分页（GET /product返回所有商品），数据量10万+时响应时间5s+；

• 修复：添加分页参数（page=1&size=20），优化SQL索引，响应时间降至200ms。

• 5. 安全漏洞：

• 问题：用户信息接口GET /api/user/{id}未校验权限，传入他人id可查询信息（越权）；

• 修复：接口添加鉴权，仅允许查询当前登录用户信息（token中的userId与路径id一致）。

8. Fiddler的工作原理？

Fiddler是“HTTP/HTTPS代理工具”，通过“中间人”模式捕获和篡改网络请求，原理如下：

1. 设置代理：Fiddler启动后，自动将本地浏览器/手机的网络代理设置为127.0.0.1:8888（默认端口）；
2. 捕获请求：客户端（浏览器/APP）的请求先发送到Fiddler，Fiddler再转发给目标服务器（“请求拦截”）；
3. 处理响应：服务器响应先返回Fiddler，Fiddler再转发给客户端（“响应拦截”）；
4. HTTPS解密：Fiddler生成根证书并安装到客户端，伪装成目标服务器与客户端建立SSL连接，同时与真实服务器建立SSL连接，从而解密HTTPS流量。

核心流程：客户端 → Fiddler代理 → 服务器，Fiddler在中间可修改请求/响应数据。

9. 工作中用Fiddler来做什么？

Fiddler是接口测试/问题定位的“瑞士军刀”，高频场景：

• 1. 接口调试与篡改：

• 修改请求参数：测试“边界值/异常场景”（如将price=100改为price=0，验证是否允许0元下单）；

• 修改响应数据：模拟“服务器返回异常”（如将"code":200改为"code":500，验证前端错误提示）。

• 2. 抓包分析问题：

• APP接口报错：抓包查看请求是否正确（如参数缺失、Token过期）、响应是否异常（如返回null导致前端崩溃）；

• 前后端联调：对比“前端实际发送的请求”与“接口文档要求”，定位“参数名拼写错误”（如前端传user_name，接口要求username）。

• 3. 弱网测试：

• Fiddler“Rules→Performance→Simulate Modem Speeds”模拟弱网（限制带宽、增加延迟），验证APP在2G/3G下的表现。

• 4. 接口自动化：

• 导出请求为代码（如“File→Export Sessions→Selected Sessions→cURL”），快速生成接口测试脚本。

• 5. 数据导出与统计：

• 导出接口请求/响应为Excel，统计“接口调用次数”“平均响应时间”（如“统计1小时内支付接口调用500次，失败10次”）。

10. 为什么要做接口测试？

接口测试是“质量左移”的关键环节，核心价值：

• 更早发现问题：接口是前后端、服务间的“契约”，在UI开发前测试接口，可提前发现服务端逻辑缺陷（如参数校验缺失），降低修复成本（代码未成型时修改更简单）。
• 覆盖更全面：UI测试只能验证“可见功能”，接口测试可覆盖“隐藏接口”（如后台定时任务接口、第三方回调接口），避免“UI正常但接口异常”的盲区。
• 提高测试效率：接口测试可自动化（如Python脚本批量执行1000个用例），比UI自动化更稳定（不受页面元素变化影响），适合回归测试。
• 保障数据安全：接口是数据交互的入口，通过测试可发现“越权访问”“SQL注入”等安全漏洞（如用户可通过接口获取他人信息）。
• 支撑性能/安全测试：性能测试（如JMeter压测接口QPS）、安全测试（如扫描接口漏洞）均以接口为基础。

11. 说一下你知道的HTTP状态码，以及它们代表什么意思?

HTTP状态码分5类（1xx-5xx），测试中需关注“2xx成功、4xx客户端错误、5xx服务端错误”：

12. 一个接口请求不通（或页面无法访问）该如何排查?

接口不通的排查需“从客户端→网络→服务端”逐层定位，步骤如下：

一、客户端排查

• 检查请求参数：URL是否正确（如少写/v1前缀）、方法是否正确（GET/POST混淆）、请求头是否完整（如Content-Type、Token）；
• 验证网络环境：切换WiFi/4G，访问其他网站（如百度）是否正常，排除本地网络故障。

二、网络层排查（抓包+连通性）

• 抓包分析：用Fiddler/Charles抓包，查看：
• 请求是否发出（无请求→客户端代码问题，如按钮未绑定事件）；
• 返回状态码（如404→URL错误，500→服务端错误）；
• 响应内容（如"msg":"数据库连接失败"→服务端配置问题）。
• 连通性测试：
• ping <服务器IP>：验证网络可达（超时→网络不通或服务器禁ping）；
• telnet <服务器IP> <端口>：验证端口开放（如telnet 192.168.1.100 8080，失败→端口未开放或防火墙拦截）。

三、服务端排查

• 检查服务状态：登录服务器，ps -ef | grep <服务名>（如ps -ef | grep java），确认服务是否启动；
• 查看服务日志：tail -f app.log，搜索关键字（如ERROR），定位代码异常（如“数据库连接超时”“NPE空指针”）；
• 检查依赖服务：数据库（mysql -u root -p能否登录）、Redis（redis-cli ping是否返回PONG）是否正常。

四、典型案例

• 案例1：接口返回401→抓包发现请求头无Token→前端未携带登录状态→修复：添加Authorization头；
• 案例2：接口超时无响应→telnet服务器端口失败→开发未启动服务→重启服务后恢复。

13. 接口测试中的加密参数如何处理?

加密参数（如password=MD5(明文)、sign=SHA256(key+timestamp+params)）是接口安全的常见手段，测试处理方法：

一、明确加密规则

• 向开发获取加密算法文档，包含：
• 加密方式（对称加密：AES；非对称加密：RSA；哈希：MD5/SHA256）；
• 密钥（如AES密钥abc123、RSA公钥）；
• 签名规则（如sign=MD5(appid+timestamp+params+secret)，按ASCII排序后拼接）。

二、手动测试处理

• 工具生成加密值：
• 在线加密工具（如MD5在线加密：输入明文生成密文）；
• Postman Pre-request Script：编写JS脚本自动加密，例：

// 计算MD5签名varparams={mobile:"13800138000",timestamp:"1696000000"};varsecret="abc123";varsignStr=Object.keys(params).sort().map(k=>k+"="+params[k]).join("&")+secret;pm.environment.set("sign",CryptoJS.MD5(signStr).toString());// 签名存入环境变量

• 请求参数引用加密值：{"mobile":"13800138000","sign":"{{sign}}"}。

三、自动化测试处理

• Python脚本中集成加密逻辑（如hashlib库处理MD5，pycryptodome处理AES）：

importhashlibdefgen_sign(params,secret):# 按key排序并拼接sorted_params=sorted(params.items(),key=lambdax:x[0])sign_str="&".join([f"{k}={v}"fork,vinsorted_params])+secret# MD5加密returnhashlib.md5(sign_str.encode()).hexdigest()params={"mobile":"13800138000","timestamp":"1696000000"}sign=gen_sign(params,"abc123")requests.post(url,json={**params,"sign":sign})

四、测试验证

• 验证加密是否生效：篡改加密参数（如修改sign值），接口应返回“签名错误”；
• 验证密钥安全性：密钥是否硬编码在前端（F12查看JS代码，若有则存在泄露风险）。

14. 接口自动化的优缺点?

适用场景：核心接口（如支付、登录）、回归测试频繁的接口、性能/安全测试的基础。

15. 接口测试什么时候介入?

接口测试应“尽早介入，贯穿研发全流程”，理想时机：

• 需求阶段：参与接口文档（如Swagger）评审，确认接口定义（参数、响应、异常码），输出《接口测试用例框架》；
• 开发阶段：接口开发完成后（未联调前端前），优先进行接口测试（即“接口联调测试”），此时发现问题修改成本最低；
• 前后端联调阶段：验证前端调用接口的正确性（如参数传递、响应解析）；
• 系统测试阶段：结合业务场景进行接口集成测试（如“注册→登录→下单”全链路接口调用）；
• 上线前阶段：执行接口回归测试+性能测试，确保接口稳定。

敏捷项目：每个迭代中，开发提测接口后立即介入（通常比UI测试早2-3天）。

16. 接口测试流程?

标准接口测试流程分6步，闭环管理：

1. 需求分析与接口文档评审：

• 输出《接口测试范围》（明确测试哪些接口）、《接口疑问清单》（澄清文档歧义）。

2. 测试用例设计：

• 按“参数验证、业务逻辑、异常场景”设计用例（参考问题1），通过评审（开发/产品参与）。

3. 测试环境与数据准备：

• 搭建独立测试环境（数据库、中间件），准备测试数据（如“已注册手机号”“商品库存100”）。

4. 测试执行：

• 手动测试：Postman调试单接口，验证功能正确性；
• 自动化测试：编写脚本（Python+Requests），执行批量用例；
• 专项测试：性能（JMeter压测）、安全（接口漏洞扫描）。

5. 缺陷管理与回归：

• 提交BUG（含请求/响应报文、复现步骤），跟踪修复进度；
• 开发修复后，执行回归测试（自动化脚本快速验证）。

6. 测试报告与总结：

• 输出《接口测试报告》（用例通过率、发现BUG数、风险点），总结经验（如“参数校验缺失是高频问题”）。

17. 常见的HTTP请求头?

请求头携带客户端信息、请求元数据，测试中需关注“Content-Type、Authorization、Cookie”等核心头：

测试验证：

• Content-Type错误：如POST接口传JSON但Content-Type为form-data，后端可能解析失败（返回400）；
• Authorization缺失：访问需登录的接口，返回401错误。