接口加密(AES / RSA)场景下,测试怎么构造和校验数据?
👔 Raina面试官: 接口走 AES 或 RSA 加密,测试怎么造数据和校验?
🙋 候选人:
- 测试要有加解密工具链,和开发共用同一套密钥管理与算法参数,不能只测密文不为空。
- AES:对称密钥轮换、IV 随机性、填充模式(PKCS7)、错误密钥/篡改密文应解密失败。RSA:公钥加密私钥解密、签名验签分离、密钥长度边界、分段加密长报文。
- 构造数据时明文已知 → 加密请求 → 解密响应对比;测性能时关注大包加解密耗时。测试环境用独立密钥,禁止把生产私钥放进用例仓库。
👔 Raina面试官: 响应也是加密的,你怎么断言业务字段?
🙋 候选人:
- 脚本层先解密再JSON 断言,或 Mock 网关返回固定明文桩。
- 密钥过期场景要测轮换窗口内新旧密钥都能通。
GraphQL 接口和 REST 接口测试有什么不同?
👔 Raina面试官: GraphQL 和 REST 测起来有什么不同?
🙋 候选人:
- GraphQL 测的是单端点 + 查询组合,REST 测的是资源路径与动词矩阵,风险点不一样。
- GraphQL 专项:嵌套过深、字段爆炸(N+1)、introspection 泄露、mutation 幂等、变量类型校验、batch query 限流。REST 专项:HTTP 语义、状态码、资源 CRUD、缓存头。
- 工具上 GraphQL 用 schema 驱动生成查询;我会加复杂度/深度限制用例,防恶意 query 打垮服务。回归时 GraphQL 要覆盖高频 query 组合,不能只测一个 hello 字段。
👔 Raina面试官: 同一个业务,GraphQL 漏测常见在哪?
🙋 候选人:
- 常见漏部分字段失败:errors 数组有值但 data 半成功,客户端有没有正确处理。
- 还有 alias 重复、fragment 循环引用,要在 schema 校验层挡掉。
WebSocket 心跳、断线重连、消息乱序怎么测?
👔 Raina面试官: WebSocket 心跳、断线重连、消息乱序你怎么测?
🙋 候选人:
- 分连接保活、断连恢复、消息有序性三层,弱网和代理环境必测。
- 心跳:ping/pong 间隔、超时未响应是否主动断连重连;Idle 过久服务端踢线策略。重连:指数退避、最大重试、重连后 session 恢复、未 ack 消息补发。乱序:并发多发、服务端推送 + 客户端上行交叉,验 seq/id 排序与去重。
- 用Charles/代理限速 + 脚本模拟断网;Kill 进程、切换 WiFi/4G、中间盒 idle timeout。断言 reconnect 后不能重复消费同一条业务消息。
👔 Raina面试官: 重连成功后旧连接还在发消息会怎样?
🙋 候选人:
- 应测单连接单会话:新连接建立后旧连接被踢或消息拒绝。
- 服务端要有 connection id,客户端重连带 lastMsgId 做增量同步。
第三方回调(支付回调、短信回调)超时或重复通知怎么测?
👔 Raina面试官: 支付回调、短信回调超时或重复通知,你怎么测?
🙋 候选人:
- 回调测试核心是幂等 + 超时重试 + 签名校验,不能只看第一次成功。
- 重复:同一 notify_id 连发 2~5 次,业务状态只变更一次,返回给第三方固定 success 防无限重试。超时:Mock 慢响应,看第三方是否按策略重试;我方处理超时时不能 double charge。
- 还要测乱序到达(成功回调先于用户跳转)、错误签名、错误金额、部分字段缺失。用 Mock 平台录真实报文回放,联调环境开回调日志对账。
👔 Raina面试官: 第一次处理失败,第二次重试成功了,怎么验?
🙋 候选人:
- 查订单状态 + 流水表 + 第三方对账单三处一致,且只有一条有效入账。
- 失败原因要可观测,方便运维手动补单而不重复记账。
批量接口(一次处理上千条)边界和失败回滚怎么测?
👔 Raina面试官: 批量接口一次上千条,边界和失败回滚你怎么测?
🙋 候选人:
- 先确认语义是全成功或全失败还是部分成功,再设计边界和失败注入。
- 边界:0 条、1 条、上限条、上限+1、单条超大 payload、总包体超限。失败:第 N 条故意非法,验事务回滚或 error 明细;并发两批含重复主键。
- 性能:超时、分页批量、异步任务进度查询;上千条响应体大小与前端渲染。我会用脚本生成可控数据集,断言失败条号、错误码、已成功条是否回滚干净。
👔 Raina面试官: 部分成功部分失败,前端怎么展示你怎么验?
🙋 候选人:
- 接口应返回逐条结果数组,成功失败分开计数,不能只有笼统失败。
- 验用户重提交失败条时不会重复处理已成功条目。
接口版本号(v1 / v2)并存时,回归策略怎么定?
👔 Raina面试官: v1 和 v2 并存,回归策略你怎么定?
🙋 候选人:
- 按流量占比 + 废弃时间表分层回归:v2 全量测,v1 测存量核心路径直到下线。
- 维护版本矩阵:哪些客户端仍调 v1、哪些字段仅 v2 有;共享底层服务时改一处要双版本冒烟。自动化按 tag 分套件,CI nightly 跑 v1 最小集 + v2 全量。
- 发布门禁:v2 不破坏 v1 契约,Deprecation 公告后 v1 用例逐步缩但不 silent 删。文档、Mock、监控按版本分 dimension,避免 v2 错误被 v1 流量掩盖。
👔 Raina面试官: v1 没人用了还要测吗?
🙋 候选人:
- 看监控:30 天无流量可降级为 weekly,下线前做最后一次全量并留 rollback 方案。
- 有合同 SLA 的开放平台,v1 往往比预期活得更久,不能主观砍回归。
