測試

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

無論您是剛開始使用、目前正在維護應用程式，或是要為現有整合項目新增功能，測試都是建立成功 Google Ads API 整合項目的重要步驟。本指南將介紹測試 Google Ads API 整合作業的最佳做法。

測試帳戶

測試帳戶可用於開發目的。雖然並非所有功能都能在測試帳戶中測試，但這仍是一項實用的工具，可驗證應用程式程式碼和設定是否正常運作。

用於開發的正式帳戶

如果測試帳戶的限制導致您無法測試整合作業中的部分功能，可以改用正式版帳戶進行開發。開發人員的正式帳戶與測試帳戶有以下差異：

• 放送使用者可看見的廣告
• 要求提供有效的網址
• 必須遵守廣告政策

由於正式版帳戶會放送廣告，因此會產生指標，讓您測試成效報表，並解鎖 Google Ads API 的所有其他功能。

但在開發時，請務必格外謹慎。建議您採取下列措施：

• 只將存取權授予需要用於開發的使用者。
• 設定固定的低每日帳戶預算。
• 只有在無法使用測試帳戶時，才使用正式版帳戶進行開發。

測試憑證

為盡量降低在修改開發人員帳戶時，誤修改實際工作環境帳戶的風險，建議您保留一組與實際工作環境應用程式憑證不同的測試憑證。

我們也建議您為開發目的建立個別的重新整理權杖。

當使用者授權應用程式代為存取 Google Ads API 時，系統會產生更新憑證，因此每個更新憑證都會與授權使用者擁有相同的存取權。如果用於存取開發帳戶的所有重新整理符記都與不具備正式版帳戶存取權的使用者相關聯，包括管理正式版帳戶的管理員帳戶，那麼誤用測試重新整理符記修改正式版帳戶的風險就會降低。

由於存取權取決於所使用的更新權杖，因此您不需要建立測試更新權杖以外的測試憑證。只要更新憑證不同，用於存取實際執行帳戶的開發人員權杖、用戶端 ID 和用戶端密碼，就能安全地用於存取測試帳戶。

提出驗證要求

如果您只需要測試要求是否有效 (例如驗證要求是否有正確的結構，且不違反政策)，可以使用 validate_only 欄位，該欄位適用於 GoogleAdsService.SearchStream 和 GoogleAdsService.Search 要求，以及大多數變異要求。請參閱參考說明文件，確認這個欄位是否適用於特定方法。

REST API

針對臨時測試 (例如驗證要求是否會產生預期的輸出內容)，使用 REST API 通常是最簡單的做法。請參閱REST 範例，瞭解如何使用 cURL 向 REST API 提出要求。