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 服務來設計系統的可靠性、隔離風險，並安全地將建構成品部署到各個環境中。

測試策略與資料管理

測試金字塔與測試類型

單元測試 (Unit tests)：快速、隔離地驗證函式、類別和小型模組。這應該是測試套件中的主要部分。在每次提交 (commit) 和拉取請求 (pull request) 時執行。
整合測試 (Integration tests)：驗證應用程式與其資料儲存庫或佇列等元件之間的互動。在可行的情況下，使用 Google Cloud 模擬器。
契約測試 (Contract tests)：針對微服務的消費者驅動契約 (consumer-driven contracts) 可防止破壞性的 API 變更。在整合前，根據消費者預期的結構描述 (schema) 和語意來驗證提供者的行為。使用 Pact 或類似工具；為您的 API 進行版本控制並發布結構描述。
端到端測試 (End-to-end tests)：使用類似生產環境的配置、身分識別和網路策略來演練整個系統路徑。限制其數量、進行平行化，並在預備生產環境 (pre-prod) 中執行。
煙霧測試 (Smoke tests)：在每次部署後，進行最基本的探測，以確認關鍵依賴項、路由和健康檢查是否正常運作。這是您部署後的第一道驗證。

測試資料管理、隔離性、可重現性與環境對等性

資料植入 (Data seeding)：為單元測試產生小型的、確定性的資料集，並為整合/效能測試產生較大的、具代表性的資料集。從簽入到原始碼控制的固定資料 (fixtures) 中植入資料。
隔離性 (Isolation)：確保測試之間不共享狀態。使用臨時性的資料庫、隔離的 GKE 命名空間，以及為 Cloud Storage 物件使用獨特的前綴。對於 SQL，為每個測試建立結構描述；對於 Pub/Sub，產生臨時的主題/訂閱。
可重現性 (Reproducibility)：固定依賴項的版本，使建構過程封閉化 (hermetic)，並固定隨機種子。將帶有摘要 (digests) 的測試容器儲存在 Artifact Registry 中。
環境對等性 (Environment parity)：在開發、QA、預備 (staging) 和生產環境中，標準化容器映像檔和基礎設施即程式碼 (infrastructure-as-code)。將配置保留在映像檔之外，並使用特定於環境的中繼資料和密鑰。對於 Compute Engine，將每次部署的值儲存在執行個體範本的中繼資料中；對於跨專案的對等性，配置一個環境中繼資料鍵，並在啟動時讀取它以選擇特定於環境的配置。

模擬 (Mocking)、模擬器 (emulators)、偽造服務 (fakes) 與沙箱服務

模擬/樁件 (Mocks/stubs)：在單元層級替換協作者，以隔離邏輯並減少網路呼叫。避免過度模擬；斷言應針對行為，而非實作細節。
模擬器 (Emulators)：在整合測試中，優先使用官方模擬器。例如：Firestore/Datastore、Pub/Sub、Spanner 和 Bigtable 模擬器。它們提供 API 的擬真度，無需雲端費用，並能加速 CI。
偽造服務 (Fakes)：當沒有模擬器可用時，執行輕量級的本地偽造服務（例如，一個偽造的物件儲存庫）或具有強隔離性和配額的共享沙箱服務。
外部依賴模擬 (External dependency simulation)：對於第三方 API，在服務網格或 API 閘道器後方執行基於契約的偽造服務；配置超時、重試和混沌注入 (chaos injection) 來測試故障處理。

常見的失敗模式與權衡

過度依賴端到端測試會減慢迭代速度；應投資於單元測試和契約測試，以更早地發現問題。
共享的、長期運行的測試環境會累積差異 (drift) 和資料污染。應優先選擇臨時性環境和冪等的設定/拆除流程。
模擬器可能無法完美地反映生產環境。在升級到生產環境前，應使用真實服務進行階段性的端到端測試。

一個簡短的 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']

獨立的步驟可確保建構歷史記錄能精確指出是編譯/單元測試、建構，還是整合測試失敗。

非功能性測試與程式碼品質

效能測試

類型：負載 (steady-state)、壓力 (beyond peak)、浸泡 (long duration) 和容量測試。
工具：使用 Cloud Monitoring 進行 SLO 和警報設定，使用 Cloud Trace 進行延遲分析，並使用 Cloud Profiler 來找出效能熱點路徑。對於 GKE，使用 Cluster Autoscaler 和 HPA 進行擴展；對於 Pub/Sub worker，基於外部指標的 HPA 可處理由流量尖峰驅動的擴展。
生產環境測試：使用闇黑啟動 (dark launches) 和請求鏡像 (request mirroring) 來安全地評估帶有生產流量的新後端。External HTTP(S) Load Balancing 支援請求鏡像；Anthos Service Mesh 支援流量鏡像 (traffic shadowing)。

安全性測試

SAST/密鑰掃描：在 CI 中執行靜態分析器，並拒絕寫死在程式碼中的憑證。將密鑰儲存在 Secret Manager 中，並採用最小權限存取原則。
依賴項目與映像檔掃描：在 Artifact Registry 上啟用 Container Analysis。使用 Binary Authorization 強制執行政策，要求在部署前必須有證明 (attestations) 確認不存在嚴重漏洞。
DAST：使用經過身份驗證的掃描器掃描預備環境，並在發現嚴重問題時阻止發布。

無障礙性與回歸測試

無障礙性 (Accessibility)：將自動化的 a11y 檢查（例如，Lighthouse CI）整合到非阻斷性的合併前檢查中；在發布前修復問題。
回歸測試套件 (Regression suites)：維護一套為關鍵流程精心挑選的、穩定的回歸測試套件。在每次部署時執行煙霧測試，並在發布候選版本上執行完整的回歸測試。

靜態分析、品質閘門與程式碼審查

靜態分析 (Static analysis)：將適用於特定語言的 linter 和格式化工具配置為提交前檢查。使用 Bazel 或類似工具進行平行化處理。
品質閘門 (Quality gates)：當超過閾值（例如，覆蓋率、複雜度、linter 錯誤）時，使建構失敗。將結果發布到 Cloud Build 日誌中。
程式碼審查 (Code review)：對於高風險的變更，要求兩人審查；對於關鍵路徑，使用 CODEOWNERS；並在用於發布的標籤 (tags) 上執行提交前 CI。
供應鏈 (Supply chain)：產生 SBOMs (軟體物料清單)、簽署產物，並儲存來源證明 (provenance)。在 Binary Authorization 中強制執行證明檢查。

漸進式交付與安全發布

部署策略

滾動式 (Rolling)：漸進地替換 Pod 或執行個體。對於無狀態服務風險較低；可結合 readiness probe 和突增/可用性設定使用。
藍綠部署 (Blue-green)：建立一個完整的新環境，執行驗證，然後切換流量。透過還原負載平衡器即可實現立即還原。當您需要立即備援時，這是理想的選擇。
金絲雀部署 (Canary)：逐步將一小部分的流量轉移到新版本，同時觀察關鍵指標。如果健康狀況良好，就自動升版；若出現迴歸問題則還原。
流量分割 (Traffic splitting)：使用 GKE 加上 Anthos Service Mesh，依百分比或屬性 (標頭、cookie、user-agent) 進行路由，或使用 Cloud Run 和 App Engine 的內建分割功能。

功能旗標與實驗

功能旗標 (Feature flags)：將部署與發布解耦。使用旗標進行漸進式推出、緊急關閉開關和實驗切換開關。集中儲存 (例如，託管的旗標服務或受 IAM 保護的組態儲存庫)。保持旗標的生命週期簡短並移除廢棄的旗標。
暗啟動 (Dark launches)：部署已停用的功能；透過內部使用者或綜合流量進行驗證。
影子流量 (Shadow traffic)：將生產環境的請求鏡像到新服務而不影響使用者；比較回應以偵測迴歸問題。
受控實驗 (Controlled experiments)：使用服務網格規則實作 A/B 或多變量路由。對於基於 user-agent 的實驗，可依標頭匹配進行路由。

關卡、核准、還原與可觀測性

部署關卡 (Deployment gates)：新增部署前的整合測試和部署後的煙霧/健康檢查。對於環境升級，使用基於標籤的觸發器來將建置與發布分開。
手動核准 (Manual approvals)：在里程碑 (例如從 staging 到 production) 要求人工核准。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

測試可靠性、回饋循環與發布後紀律

不穩定測試 (Flaky-test) 的管理與可靠性

偵測與隔離：長期追蹤測試的不穩定性；隔離已知的 flaky tests，並且在優先修復它們的同時，不要讓它們阻擋發布。
逾時與重試：加入合理的逾時設定；允許對可疑的基礎設施不穩定進行單次重試，但邏輯錯誤則不重試。
封閉式建置 (Hermetic builds)：在單元測試中避免網路呼叫；鎖定 artifact 版本並使用模擬器以減少不確定性。
平行化：在 Cloud Build 中將測試分片到多個步驟或 worker 上，以最小化回饋延遲。

回饋循環

CI 觸發器：在每次對 main 分支的 commit 和 pull request 上執行單元測試與整合測試。使用獨立的 Cloud Build 步驟，以便建置歷史記錄能識別失敗的階段。在 Git 標籤上建立發布觸發器，而非每次 commit 都觸發，以控制部署。
漸進式驗證：透過訂閱 Cloud Deploy 的 Pub/Sub 通知，並在部署成功 (SUCCEEDED 事件) 時呼叫升級，來自動將應用程式從開發 (dev) 環境推廣到測試 (test) 環境。
指標驅動的升級：對於金絲雀部署，根據 Cloud Monitoring 的指標和 SLO 來控制流量的增加。

發布文件、所有權與發布後驗證

文件：將版本說明、runbook 和回滾程序與程式碼放在一起維護。追蹤變更工單，並附上指向 commit、映像檔和環境版本的連結。
所有權：定義 on-call 輪值和元件負責人；對敏感區域強制執行 CODEOWNERS。確保生產環境的升級有明確的核准人。
發布後驗證：執行煙霧測試套件 (smoke suites)，確保錯誤預算 (error budgets) 保持在健康範圍內，並透過版本標籤驗證儀表板。確認安全性與弱點報告仍在政策範圍內。如果出現問題，先回滾，再進行根本原因分析。

實務問題情境

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']

針對模擬器和臨時性 namespace 執行整合測試

理由：對於 Pub/Sub worker 和使用 Firestore 的服務，使用 Pub/Sub 和 Firestore 模擬器；對於需要叢集政策的服務，則透過 Workload Identity 為每個建置啟動一個臨時的 GKE namespace，並搭配臨時的 topic 和服務帳戶。這樣可以在維持擬真度的同時，提供隔離性、速度和低成本。

使用 Artifact Registry 和 Binary Authorization 強制執行安全性品質閘門

理由：在映像檔推送時啟用弱點掃描，在發現嚴重 CVE 時讓 pipeline 失敗，並在部署到 GKE 之前要求 Binary Authorization 中的證明 (attestations)。這可以防止部署帶有已知嚴重弱點的映像檔。

使用基於 Git 標籤的發布觸發器

理由：Cloud Build 在標籤 (例如 vX.Y.Z) 上觸發，只允許對明確標記的 commit 進行自動化發布，從而避免因每次對 main 分支的 commit 都觸發而導致意外的生產環境部署。

使用 Cloud Deploy 和 Anthos Service Mesh 進行漸進式交付

理由：定義一個包含 dev、test 和 prod 目標的 Cloud Deploy pipeline。使用手動核准來控制到 prod 環境的升級。對於 prod 環境，使用金絲雀策略搭配 ASM，在監控 SLO 的同時，將流量依序切換為 5%、25%、50%、100%。Cloud Deploy 會訂閱驗證掛鉤 (verification hooks)；一旦失敗，就會透過 API 自動暫停或回滾金絲雀部署。

可觀測性與自動化回滾掛鉤

理由：將 Prometheus 指標匯出到 Cloud Monitoring，並為錯誤特徵建立基於日誌的指標。在帶有版本標籤的指標上設定警示政策。一個訂閱了警示的 Cloud Function 會呼叫 Cloud Deploy API 來暫停或回滾部署。這將客觀的健康訊號與部署控制連結起來。

針對 Cloud Run 前端的影子流量 (Shadow traffic) 與 A/B 驗證

理由：在外部 HTTP(S) 負載平衡器上使用請求鏡像 (request mirroring)，將生產環境的請求導入新的 Cloud Run 修訂版本，而不會影響使用者。然後使用 Cloud Run 的流量分割功能，轉移小部分百分比的流量，並在完全切換前比較延遲/錯誤指標。

針對關鍵後端服務的藍綠 (Blue-green) 部署備援

理由：對於需要即時回滾的服務，在單一後端服務後面維護藍色和綠色兩個部署。用煙霧測試和合約測試驗證綠色部署，然後切換流量。如果出現異常，立即還原。

發布後驗證與文件記錄

理由：升級後，執行自動化的煙霧測試，按發布版本驗證儀表板，並用 artifact 摘要和部署歷史記錄更新版本說明。所有權和 on-call 人員接收交接；如果錯誤預算 (error budgets) 耗盡，先回滾，然後進行無指責的分析 (blameless analysis)。

這種方法在 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 →