通过首先记录每个移动客户端版本使用的具体字段，建立一个系统的版本矩阵方法，使用 Charles Proxy 或 Burp Suite 来拦截生产流量，创建一个依赖图，将 iOS 和 Android 应用版本与 GraphQL 架构字段相关联。执行合同验证的探索性测试，通过手动构造模拟遗留客户端请求的查询，故意将 null 值注入到已弃用字段中，以验证移动客户端是否通过错误边界处理缺失数据，而不是崩溃。通过通过 Postman 集合并行运行 REST 和 GraphQL 请求来实现影子测试，比较响应负载的语义等价性，同时监测弃用头和 @deprecated 指令触发客户端日志记录而不破坏用户界面。
问题描述
我们的电子商务平台正将产品目录从 REST 端点迁移到统一的 GraphQL 架构，以支持新的推荐引擎，但我们支持的 iOS 版本从 v12.4（2019 年发布）开始，到 Android 版本 API 级别 28（Android 9），创建了一个具有不同 GraphQL 客户端能力的 15 个以上活跃应用版本的矩阵。主要风险是 iOS v14.2 客户端依赖于已弃用的 productVariants 字段，该字段将被 productOptions 替换，如果在弃用窗口期间该字段返回意外的 null 值而不是空数组，Swift 解析逻辑将导致应用程序崩溃。而且，使用 Apollo Client v2.5 的 Android 客户端以不同于 iOS Alamofire 实现的方式处理可空性，这意味着同一架构变更可能导致一个平台的静默数据损坏，而另一个平台崩溃。
解决方案 1：全面的端到端回归测试
我们考虑对每个支持的操作系统版本在物理设备上执行完整的回归测试，手动导航通过产品目录流程，以验证所有平台上的视觉一致性和数据完整性。该方法将提供绝对的信心，确保用户面向的功能正常工作，并捕获与 GraphQL 数据绑定相关的平台特定 UI 故障。然而，这需要访问超过 40 个物理设备和大约三周的测试时间，这超过了我们的两周迁移截止日期，并且无法保证检测到仅在特定网络条件下出现的细微 API 合同违规。
解决方案 2：使用模拟客户端响应的 API 合同测试
第二种方法涉及使用 Postman 和 Mockoon 来模拟由遗留移动客户端发送的确切查询结构，验证 GraphQL 架构返回语法上正确的 JSON 响应，符合历史 REST 负载结构。该方法显著更快，允许我们在三天内测试所有版本组合，并提供对弃用头和字段可空性的精确验证。不幸的是，这种纯合成测试错过了关键的平台特定解析行为，例如 iOS Swift Codable 协议在意外的 null 与缺失键时失败，这只有在实际客户端环境中才能体现。
解决方案 3：基于风险的拦截测试与生产分析
我们最终选择了一种混合策略，分析 Firebase Analytics 数据，以确定每个平台上代表 85% 活跃用户基础的前三个操作系统版本，然后使用 Charles Proxy 拦截实时流量，并将 REST 响应重写为 GraphQL 查询，同时监控客户端稳定性。这使我们能够在聚焦高影响版本组合的手动验证工作，测试真实的查询模式和网络延迟条件，并通过自动化合同测试补充边缘案例。我们选择这种方法，因为它在风险覆盖和时间约束之间取得了平衡，提供了在不影响大多数用户的情况下迁移的信心，同时识别出特定的兼容性问题，如 iOS null 处理错误。
我们实施了解决方案 3，专注于 iOS 14.2、15.0 和 16.0，以及 Android 10、11 和 12，使用 Charles Proxy 模拟 productVariants 字段的弃用，返回 null 值并监测崩溃。在对 iOS v14.2 的测试中，我们发现当已弃用的字段返回 null 时，客户端应用因 EXC_BAD_ACCESS 错误崩溃，而不是显示后备 UI，显示 Swift 错误边界错误地解析了 GraphQL 错误响应。我们将此记录为关键缺陷，实施了服务器端架构更改，以在六个月的过渡期内返回带有弃用警告的空数组，而不是 null 值，并建立了针对按应用版本分段的 GraphQL 错误率的监控警报；迁移在支持的版本上进行，没有任何崩溃。
您如何验证在没有访问服务器端日志或自动化负载测试工具的情况下，GraphQL 查询深度限制和复杂性评分在手动测试期间是否得到适当执行？
许多候选人假设测试 GraphQL 安全性需要自动化脚本，但手动测试人员可以使用 GraphiQL 或 Insomnia 构造嵌套查询，通过故意创建循环引用或深嵌套对象来触发 DoS 保护机制。您应该验证 API 返回特定的错误代码，如 GRAPHQL_VALIDATION_FAILED 或 QUERY_TOO_COMPLEX，而不是通用的 500 错误，并测试复杂性计算是否在使用别名请求同一字段多次时，适当地考虑字段乘数。此手动验证可确保服务器的复杂性分析准确计算请求的字段，并在超出配置阈值之前拒绝查询，以防止它们消耗数据库资源。
此外，候选人经常忘记测试持久查询（允许查询白名单）在生产环境中拒绝任意手动查询，这对防止资源耗尽攻击至关重要。您可以通过尝试通过 Postman 执行偏离持久查询哈希的即兴查询，确保服务器返回 PersistedQueryNotFound 错误或等效响应，而不是执行查询。该安全边界可防止攻击者构造资源密集型查询，从而降低合法用户的系统性能。
当多个微服务为同一实体类型贡献字段时，系统测试 GraphQL 架构拼接或联合的方法是什么，特别是在一个服务降级时的错误传播？
在 Apollo Federation 或架构拼接架构中，初学者通常单独测试每个服务，错过进行部分故障测试，即 User 类型可能组合自 Authentication Service（关键）和 Preferences Service（非关键）字段。您必须使用 Chaos Monkey 技术手动触发下游服务的故障，或通过 Charles Proxy 阻止特定端点，然后验证 Gateway 返回带有 null 字段和 errors 数组中特定错误路径的部分数据，而不是使整个查询失败并导致完全页面失败。这种方法验证了联邦层的弹性，并确保即使在非核心服务发生故障时，关键用户旅程仍然可以正常运作。
关键见解是验证 @defer 指令和 @stream 指令在处理缓慢解析字段时可以避免阻塞整个 UI，并且客户端接收可操作的错误元数据，以显示特定组件的后备内容，同时从健康服务呈现可用数据。测试正确的错误传播确保即使在暂时性功能（如推荐或分析）不可用的情况下，用户仍然可以完成核心交易。
在使用像 Apollo Codegen 或 GraphQL Codegen 这样的代码生成工具的应用程序中，您如何区分预期的 GraphQL 可空性（可以合法为 null 的字段）和实际缺陷？
候选人经常在生成的 TypeScript 或 Swift 类型标记字段为可选（可空）时，商业逻辑实际上需要它们，这导致关于 null 值是否表示错误或有效空状态的困惑。您必须检查架构的感叹号 (!) 与生成的客户端类型，测试边界条件，通过手动操纵 Charles Proxy 中的 JSON 响应，向非可空架构字段注入 null 值，以验证服务器在发送响应到客户端之前是否正确检测数据。这一区别至关重要，因为非可空架构字段中的 null 表示服务器端缺陷，而可空字段中的 null 可能代表合法的数据缺失。
此外，您应该验证客户端应用程序是否正确处理架构驱动的可空性，通过检查访问可空字段时 TypeScript 严格模式编译是否成功，确保生成的类型实际上防止运行时 null 指针异常，而不仅仅是表面上与架构匹配。这要求理解 GraphQL 的不可空字段绝不应从服务器返回 null，而可空字段应始终在客户端代码中通过可选链或 null 检查进行处理，无论商业逻辑对数据的存在总是存在的假设如何。开发人员经常忘记在商业逻辑表明数据总是存在时添加这些防御检查，因此对 null 注入的严格手动测试有助于在实际用户之前捕获潜在崩溃。