Google PCD: 测试、质量工程和安全发布管理 — 学习指南

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

属于 Google Professional Cloud Developer — 学习指南. 使用经过验证的答案练习： Google 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

Google Cloud 上的高效率团队将严格的测试与渐进式交付相结合，在加速变更的同时降低风险。一个稳健的策略涵盖了从单元测试到端到端测试的各个层面，包括真实的数据和依赖项模拟、自动化的质量门禁，以及金丝雀 (canary) 和蓝绿 (blue-green) 等受控的发布模式。可观测性、所有权和规范的发布后验证构成了闭环。本节详细介绍如何利用 Google Cloud 服务进行可靠性设计、隔离风险，以及在不同环境间安全地提升构建版本。

测试策略与数据管理

测试金字塔和测试类型

单元测试：快速、隔离地验证函数、类和小型模块。它们应在测试套件中占主导地位。在每次提交和拉取请求时运行。
集成测试：验证组件之间的交互，例如应用程序与其数据存储或队列。在可用时使用 Google Cloud 模拟器。
契约测试：针对微服务的消费者驱动契约可防止破坏性的 API 变更。在集成之前，根据消费者的预期模式和语义验证提供者的行为。使用 Pact 或类似工具；对 API 进行版本控制并发布模式。
端到端测试：使用类似生产环境的配置、身份和网络策略来演练完整的系统路径。限制其数量，进行并行化，并在预生产环境中运行。
冒烟测试：在每次部署后，进行最基本的探测，以确认关键依赖项、路由和健康检查是否正常运行。这是您部署后的第一步验证。

测试数据管理、隔离性、可复现性和环境对等性

数据植入：为单元测试生成小型的、确定性的数据集，为集成/性能测试生成更大型的、有代表性的数据集。从签入源代码控制的固件 (fixtures) 中植入数据。
隔离性：确保测试不共享状态。使用临时数据库、隔离的 GKE 命名空间以及为 Cloud Storage 对象使用唯一前缀。对于 SQL，创建每个测试专用的模式；对于 Pub/Sub，生成临时的 Topic/Subscription。
可复现性：锁定依赖项版本，使构建过程封闭化 (hermetic)，并固定随机种子。将带有摘要 (digest) 的测试容器存储在 Artifact Registry 中。
环境对等性：在开发、QA、预发布和生产环境中标准化容器镜像和基础设施即代码 (IaC)。将配置保留在镜像之外，并使用特定于环境的元数据和密钥。对于 Compute Engine，将每次部署的值存储在实例模板元数据中；对于跨项目的对等性，配置一个环境元数据键，并在启动时读取它以选择特定于环境的配置。

模拟 (Mocking)、模拟器 (emulators)、伪造 (fakes) 和沙盒服务

模拟 (Mocks)/存根 (stubs)：在单元测试级别替换协作者，以隔离逻辑并减少网络调用。避免过度模拟；断言应针对行为，而非实现细节。
模拟器 (Emulators)：对于集成测试，优先使用官方模拟器。例如：Firestore/Datastore、Pub/Sub、Spanner 和 Bigtable 模拟器。它们提供 API 的高保真度，无需云费用，并能加速 CI。
伪造 (Fakes)：当没有模拟器时，运行轻量级的本地伪造服务（例如，一个伪造的对象存储）或具有强隔离和配额的共享沙盒服务。
外部依赖模拟：对于第三方 API，在服务网格或 API 网关后面运行基于契约的伪造服务；配置超时、重试和混沌注入以测试故障处理能力。

常见的失败模式与权衡

过度依赖端到端测试会减慢迭代速度；投入单元测试和契约测试以更早地发现问题。
共享的、长期存在的测试环境会累积偏差和数据污染。优先选择临时环境和幂等的设置/拆除流程。
模拟器可能无法完美反映生产环境。在提升到生产环境之前，使用真实的服务的预发布 E2E 测试。

一个简短的 Cloud Build 示例，用于分离失败的阶段

steps:
- name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args: ['-c', 'make compile && make unit']
- name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args: ['-c', 'docker build -t $IMAGE .']
- name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args: ['-c', 'make integration']  # run against emulators or ephemeral env
images: ['$IMAGE']

分离的步骤可确保构建历史记录能精确定位是编译/单元测试、构建还是集成阶段失败。

非功能性测试与代码质量

性能测试

类型：负载（稳态）、压力（超峰值）、浸泡（长时间）和容量测试。
工具：使用 Cloud Monitoring 进行 SLO 和警报设置，使用 Cloud Trace 进行延迟分析，使用 Cloud Profiler 定位热点路径。对于 GKE，使用 Cluster Autoscaler 和 HPA 进行扩缩；对于 Pub/Sub 工作器，基于外部指标的 HPA 可以处理由流量尖峰驱动的扩缩。
生产环境测试：使用灰度发布 (dark launches) 和请求镜像来安全地用生产流量评估新的后端。External HTTP(S) Load Balancing 支持请求镜像；Anthos Service Mesh 支持流量影子 (traffic shadowing)。

安全测试

SAST/密钥扫描：在 CI 中运行静态分析器，并拒绝硬编码的凭据。将密钥存储在 Secret Manager 中，并遵循最小权限原则进行访问。
依赖项和镜像扫描：在 Artifact Registry 上启用 Container Analysis。使用 Binary Authorization 强制执行策略，要求在部署前必须有证明不存在严重漏洞的证明 (attestations)。
DAST：使用经过身份验证的扫描器扫描预发布环境，并在发现严重问题时阻止发布。

可访问性与回归测试

可访问性：将自动化的 a11y 检查（例如，Lighthouse CI）集成到非阻塞的合并前检查中；在发布前进行修复。
回归测试套件：为关键流程维护经过筛选的、稳定的回归测试套件。在每次部署时运行冒烟测试，在发布候选版本上运行完整的回归测试。

静态分析、质量门禁和代码审查

静态分析：将适合特定语言的 linter 和格式化工具配置为提交前检查。使用 Bazel 或类似工具进行并行化。
质量门禁：当超出阈值（覆盖率、复杂度、linter 错误）时，使构建失败。将结果发布到 Cloud Build 日志中。
代码审查：对于高风险变更要求双人审查，对关键路径使用 CODEOWNERS，并对用于发布的标签进行提交前 CI 检查。
供应链：生成 SBOM，对工件进行签名，并存储来源信息 (provenance)。在 Binary Authorization 中强制执行证明检查。

渐进式交付与安全发布

部署策略

滚动部署 (Rolling)：增量替换 Pod 或实例。对于无状态服务风险较低；与就绪探针 (readiness probes) 和峰值/可用性设置 (surge/availability settings) 结合使用。
蓝绿部署 (Blue-green)：建立一个全新的环境，运行验证，然后切换流量。通过恢复负载均衡器的配置可实现即时回滚。是需要即时回退方案时的理想选择。
金丝雀部署 (Canary)：在观察关键指标的同时，逐步将一小部分流量转移到新版本。如果运行状况良好，则自动升级；如果出现回归，则回滚。
流量拆分 (Traffic splitting)：使用 GKE 加 Anthos Service Mesh 按百分比或属性（标头、Cookie、user-agent）进行路由，或使用 Cloud Run 和 App Engine 中的内置拆分功能。

功能标志与实验

功能标志 (Feature flags)：将部署与发布解耦。使用功能标志进行逐步推出、设置紧急开关 (kill switches) 和实验开关 (experiment toggles)。集中存储（例如，使用托管的功能标志服务或受 IAM 保护的配置存储）。保持功能标志的生命周期简短并移除废弃代码。
灰度发布 (Dark launches)：部署已禁用的功能；通过内部用户或合成流量进行验证。
影子流量 (Shadow traffic)：将生产请求镜像到新服务，而不影响用户；比较响应以检测回归。
受控实验 (Controlled experiments)：使用服务网格规则实现 A/B 或多变量路由。对于基于 user-agent 的实验，按标头匹配进行路由。

门禁、审批、回滚与可观测性

部署门禁 (Deployment gates)：添加部署前集成测试和部署后冒烟/健康检查。对于环境晋升，使用基于标签的触发器将构建与发布分离。
手动审批 (Manual approvals)：在关键里程碑（如从预演环境到生产环境）需要人工审批。Cloud Deploy 支持为每个目标设置手动审批步骤。
自动回滚 (Automatic rollback)：定义 SLO 和提醒策略；当金丝雀部署违反了错误率或延迟阈值时，通过调用部署 API 自动回滚。保持回滚操作的快速和熟练。
发布的可观测性 (Release observability)：在指标和日志中使用版本标签来监测发布。将 Prometheus 指标导出到 Cloud Monitoring，并为错误模式创建基于日志的指标，以经济高效的方式关联遥测数据。

基于标头的金丝雀部署的简短 ASM 路由示例

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
  http:
  - match:
    - headers:
        user-agent:
          regex: ".*Android.*"
    route:
    - destination: { host: svc, subset: v2 }  # canary
  - route:
    - destination: { host: svc, subset: v1 }  # stable

测试可靠性、反馈循环和发布后规范

不稳定测试的管理与可靠性

检测与隔离：长期跟踪测试的不稳定性；隔离已知的不稳定测试，在优先修复的同时，不应让它们阻塞发布。
超时与重试：添加合理的超时设置；对于疑似基础设施导致的不稳定，允许单次重试，但逻辑失败不应重试。
封闭式构建：在单元测试中避免网络调用；固定（pin）工件并使用模拟器以减少不确定性。
并行化：在 Cloud Build 中跨多个步骤或工作器对测试进行分片，以最大限度地减少反馈延迟。

反馈循环

CI 触发器：在每次向主分支提交和发起拉取请求时运行单元测试和集成测试。使用独立的 Cloud Build 步骤，以便构建历史记录能识别失败的阶段。基于 Git 标签（tag）创建发布触发器，而不是每次提交都触发，以控制部署。
渐进式验证：通过订阅 Cloud Deploy 的 Pub/Sub 通知，并在 SUCCEEDED 事件上调用晋升操作，实现从开发环境成功部署后自动晋升到测试环境。
指标驱动的晋升：对于金丝雀发布，基于 Cloud Monitoring 指标和 SLO 来控制流量的增加。

发布文档、所有权和发布后验证

文档：将发布说明、运行手册和回滚步骤与代码放在一起维护。通过链接到提交、镜像和环境版本的工单来跟踪变更。
所有权：定义 on-call 轮值和组件负责人；对敏感区域强制使用 CODEOWNERS。确保生产环境的晋升有明确的审批人。
发布后验证：执行冒烟测试套件，确保错误预算保持健康，并按版本标签验证仪表盘。确认安全和漏洞报告仍在策略范围内。如果出现问题，先回滚，再进行根本原因分析。

实际问题场景

Acme Retail 的平台团队正在为一个基于 GKE 的微服务应用进行测试和发布的标准化，该应用还包括一个部署在 Cloud Run 上的无状态 Web 前端。他们必须确保快速反馈、阻止有风险的构建，并在利用实时流量评估性能的同时安全地推出新功能。

方法

在 Cloud Build 中分离构建和测试阶段

理由：使用不同的步骤来编译、运行单元测试、构建容器和运行集成测试，这样构建历史记录就能精确定位失败的阶段，开发人员也能迅速获得可操作的反馈。
示例：

steps:
- name: gcr.io/cloud-builders/docker
  args: ['build', '-t', '$IMAGE', '.']
- name: gcr.io/cloud-builders/gcloud
  args: ['bash','-lc','make unit']
- name: gcr.io/cloud-builders/gcloud
  args: ['bash','-lc','make integration']  # against emulators
images: ['$IMAGE']

针对模拟器和临时命名空间运行集成测试

理由：对于 Pub/Sub 工作器和使用 Firestore 的服务，使用 Pub/Sub 和 Firestore 模拟器；对于需要集群策略的服务，通过 Workload Identity 为每个构建启动一个临时的 GKE 命名空间，并配备临时的主题和服务账号。这在保持高保真度的同时，提供了隔离性、速度和低成本。

使用 Artifact Registry 和 Binary Authorization 强制执行安全质量门

理由：在镜像推送时启用漏洞扫描，当发现严重 CVE 时使流水线失败，并在部署到 GKE 之前要求在 Binary Authorization 中提供证明（attestation）。这可以防止部署带有已知严重漏洞的镜像。

使用基于 Git 标签的发布触发器

理由：Cloud Build 基于标签（例如 vX.Y.Z）的触发器只允许为明确标记的提交自动执行发布，从而避免了因每次向主分支提交都触发而导致的意外生产部署。

使用 Cloud Deploy 和 Anthos Service Mesh 进行渐进式交付

理由：定义一个包含开发、测试和生产目标的 Cloud Deploy 交付流水线。使用手动批准来控制向生产环境的晋升。对于生产环境，采用金丝雀策略，并借助 ASM 将流量按 5%、25%、50%、100% 的比例进行切换，同时监控 SLO。Cloud Deploy 订阅验证挂钩；一旦失败，会通过 API 自动暂停或回滚金丝雀发布。

可观测性与自动回滚挂钩

理由：将 Prometheus 指标导出到 Cloud Monitoring，并为错误特征创建基于日志的指标。针对带有版本标签的指标配置告警策略。一个订阅了告警的 Cloud Function 调用 Cloud Deploy API 来暂停或回滚部署。这将客观的健康信号与部署控制联系起来。

对 Cloud Run 前端使用影子流量和 A/B 验证

理由：在外部 HTTP(S) 负载均衡器上使用请求镜像，将生产请求输送到新的 Cloud Run 修订版本，而不影响用户。然后使用 Cloud Run 的流量拆分功能，转移小部分百分比的流量，并在完全切换前比较延迟/错误指标。

为关键后端服务提供蓝绿回退方案

理由：对于需要即时回滚的服务，在单个后端服务后面维护蓝色和绿色两个部署。用冒烟测试和契约测试验证绿色部署，然后切换流量。如果出现异常，立即恢复。

发布后验证和文档记录

理由：晋升后，运行自动化的冒烟测试，按发布版本验证仪表盘，并用工件摘要和部署历史更新发布说明。所有权和 on-call 团队接手；如果错误预算消耗过快，先回滚，然后进行无指责分析。

该方法在 CI 中提供了快速、可靠的反馈，强制执行了安全和质量标准，并采用了安全、可观测的部署策略，既支持基于属性的实验，也支持在需要时即时回滚。

← 性能、可扩展性和弹性工程 · 所有领域 · 成本、治理和可持续应用运维 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

通过考试 →

浏览 Google →