# 1. REST API 测试的核心验证点，状态码、响应体结构、Header、错误处理的系统化测试策略？ A 只需验证 HTTP 状态码即可，不必关注错误响应体 B 错误响应体应统一格式并包含错误码、消息与 trace id，便于诊断，且不应泄露内部堆栈 ✓ 正确答案 C 所有 4xx 错误都应返回 500 以简化处理 D 错误信息应尽量详细，包括完整堆栈跟踪
# 2. GraphQL 测试的特殊挑战，查询复杂度、N+1 问题、类型系统的测试方法？ A 只需验证响应时间即可，无需关心内部查询 B 应通过查询日志或 DataLoader 统计数据库查询次数，确认嵌套数据不会导致查询数线性增长 ✓ 正确答案 C N+1 问题只影响写操作，与读取无关 D 使用 introspection 就能完全避免 N+1
# 3. gRPC 接口测试的四种调用方式(unary/server streaming/client streaming/bidi)各自的测试策略？ A Bidi streaming 同时支持双向并发，测试需重点验证消息顺序、背压与错误中断后的恢复 ✓ 正确答案 B 四种模式测试策略完全相同，无需区分 C Client streaming 中服务端需要持续返回多个响应 D Server streaming 中客户端需要等待服务端逐个请求
# 4. REST API 的鉴权测试矩阵，JWT/API Key/OAuth2 的过期、刷新、越权与并发用例设计 A 401 与 403 语义相同，可互换 B 只需测试 token 有效与无效两种状态 C 未认证返回 401，已认证但无权限返回 403，且越权用例是鉴权矩阵的关键 ✓ 正确答案 D 并发刷新无需测试，因为 token 刷新是原子的
# 5. gRPC 接口测试的工具和方法，grpcurl/gRPC UI/编程式测试的适用场景？ A grpcurl 适合复杂断言与流水线编排 B 三种工具功能完全相同，可任意替换 C 编程式测试只适合冒烟测试 D gRPC UI 适合交互式调试与结构探索，但难以自动化 ✓ 正确答案
# 6. API 测试自动化框架选型，Postman/Newman、REST Assured、Karate 的对比？ A Postman 适合复杂编程断言与大型套件 B Karate 只能做 API 测试，不能做性能测试 C REST Assured 适合 Java 团队的 BDD 风格自动化测试，与 JUnit/Spring 集成紧密 ✓ 正确答案 D 所有框架功能完全等价，选型无意义
# 7. GraphQL 测试中如何针对"查询深度"与"N+1 查询"设计专项用例？ A 深度测试只需验证能正常查询最深数据即可 B 深度限制配置无需测试，因为默认安全 C N+1 用例应通过查询日志或 DataLoader 统计数据库查询次数，判断是否随嵌套数据量线性增长 ✓ 正确答案 D N+1 问题与数据库查询次数无关
# 8. WebSocket/SSE 实时接口的自动化测试如何做时间维度断言（顺序、延迟、重连）？ A 应使用等待/轮询机制（如 Awaitility）并设置时间阈值，模拟断线验证重连与消息恢复 ✓ 正确答案 B 直接使用固定 sleep 即可保证时序断言稳定 C 消息顺序无需断言，因为实时接口一定有序 D 重连测试只需验证客户端能重连即可，无需验证消息恢复
# 9. GraphQL 的安全测试，权限绕过、批量查询、introspection 泄露与深度限制的验证方法 A 只需验证 introspection 即可，其他安全项无需关注 B 深度限制与权限无关，可忽略 C 应验证字段级授权、alias 批量查询滥用、生产环境 introspection 禁用与深度/复杂度限制 ✓ 正确答案 D 批量查询只影响性能，不影响安全
# 10. gRPC 健康检查协议（grpc.health.v1）与反射服务在测试框架中的应用 A 测试框架可用健康检查做就绪门控，用反射服务动态发现方法，无需硬编码 proto ✓ 正确答案 B 健康检查协议只用于生产监控，测试中无用 C 反射服务只用于性能测试 D 健康检查协议与反射服务功能完全相同
# 11. REST API 幂等性测试如何设计，为何 GET/PUT/DELETE 幂等而 POST 不幂等，如何用 Idempotency-Key 头（Stripe 模式）验证重复提交、超时重试与并发请求只生效一次，服务端对同 key 应返回缓存结果而非重复执行？ A GET/PUT/DELETE 幂等源于 HTTP 语义，POST 需用 Idempotency-Key 等机制保证，且同 key 重试应返回缓存结果而非重复执行 ✓ 正确答案 B POST 天然幂等，无需额外处理 C 幂等只影响性能，不影响正确性 D 并发请求无法测试幂等性
# 12. Webhook 异步回调的测试要点，如何验证签名（HMAC-SHA256 与时间戳容差）、失败重试与指数退避、乱序/重复投递的幂等去重，并用 webhook.site/ngrok 隧道本地接收真实回调做端到端验证？ A 只需验证接收方能收到回调即可 B 签名验证只影响安全性，不影响正确性 C 重试机制与幂等去重无关，可分别独立测试 D 应验证 HMAC 签名与时间戳容差防重放、指数退避重试、event id 幂等去重，并可用 ngrok 接真实回调做端到端验证 ✓ 正确答案
# 13. OpenAPI/Swagger 文档驱动的接口测试，如何从规范自动生成用例并验证实现与文档的一致性？ A 文档只用于人类阅读，与测试无关 B 只需验证状态码，无需校验响应 schema C 从规范自动生成用例并对响应做 schema 校验，能验证实现与文档的一致性，防止漂移 ✓ 正确答案 D 文档驱动测试与契约测试完全不同，无任何关联
# 14. 接口测试中的编码与字符集问题，Content-Type、URL 编码、JSON 转义与 Unicode 边界如何覆盖？ A 只要设置 UTF-8 就无需测试其他字符集 B URL 编码不会影响参数解析 C 应覆盖 Content-Type/charset、URL 编码、JSON 转义与 Unicode 边界（emoji、代理对、规范化），并验证全链路回显一致 ✓ 正确答案 D Unicode 边界与接口测试无关
# 15. API 版本兼容性测试，如何验证新旧版本客户端与服务端的兼容性？ A 只需测试最新版本客户端与服务端 B 版本策略（路径/Header/查询参数）不影响兼容性测试 C 向后兼容与向前兼容含义相同 D 应构建新旧客户端×服务端的组合矩阵，验证向后兼容（旧客户端调新服务端）与向前兼容 ✓ 正确答案
# 16. 契约测试中 Provider 侧如何用"待验证契约列表"管理多消费方版本兼容？ A 应聚合所有活跃消费者的最新契约（按版本与 tag 过滤）逐一验证，作为 Provider 发布的安全门禁 ✓ 正确答案 B 只需验证默认分支的契约即可 C 待验证列表只用于记录，不影响发布 D Provider 变更无需关心消费者兼容
# 17. GraphQL 测试，查询、变量与 Schema？ A 查询定义字段结构，变量实现复用与类型校验，Schema 提供类型契约并以 introspection 验证一致性 ✓ 正确答案 B 变量与查询必须写在同一个字符串里，无法分离 C Schema 与查询无关，无需测试 D 变量类型错误不会导致执行前校验失败
# 18. REST API 的错误码体系测试，业务错误码、HTTP 状态码与错误响应体的对应关系如何验证？ A 业务错误码与 HTTP 状态码可以相互矛盾 B 应验证业务错误码、HTTP 状态码与统一错误响应体的一致映射，且错误码枚举与文档一致 ✓ 正确答案 C 错误响应体格式无需统一 D 错误码唯一性不重要
# 19. API 的分页、排序与过滤参数测试，cursor/offset 分页、排序稳定性与过滤组合如何设计用例？ A cursor 分页与 offset 分页在数据变化时行为完全相同 B 过滤与分页彼此独立，无需组合测试 C 排序稳定性无需关注，任何排序键都行 D 应验证 cursor/offset 分页边界、多字段排序稳定性（含稳定键）与过滤组合逻辑（AND/OR）及三者的协同 ✓ 正确答案
# 20. API 测试中的时间与并发边界，时间戳校验、限流触发与并发写冲突如何构造验证？ A 时间戳校验可随机测试，无需控制时钟 B 应通过可控时钟验证时间戳边界、构造高并发触发限流（429/Retry-After）并验证并发写冲突（乐观锁/条件更新） ✓ 正确答案 C 限流触发后无需验证恢复 D 并发写冲突无法验证，只能依赖应用自身保证
