無論您是剛開始使用、目前正在維護應用程式，或是要為現有整合項目新增功能，測試都是建立成功的 Google Ads API 整合作業的重要步驟。本指南將介紹測試 Google Ads API 整合作業的最佳做法。
測試帳戶
測試帳戶可用於開發目的。雖然並非所有功能都能在測試帳戶中測試，但這仍是一項實用的工具，可驗證應用程式程式碼和設定是否正常運作。
用於開發的正式帳戶
如果測試帳戶的限制導致您無法測試整合作業中的部分功能，可以改用正式版帳戶進行開發。開發人員的正式帳戶與測試帳戶有以下差異：
- 放送使用者能看見的廣告
- 要求提供有效的網址
- 必須遵守廣告政策
由於實際執行帳戶會放送廣告，因此會產生相關指標讓您測試成效報表，以及解鎖 Google Ads API 的所有其他功能。
同時，在開發過程中使用這些功能時，請務必提高警覺。建議您採取下列措施：
- 只將存取權授予需要用於開發的使用者。
- 設定固定的低每日帳戶預算。
- 只有在無法使用測試帳戶時，才使用正式版帳戶進行開發。
測試憑證
為盡量降低在修改開發人員帳戶時，不小心修改實際工作環境帳戶的風險，建議您保留一組與實際工作環境應用程式憑證不同的測試憑證。
我們也建議您為開發目的建立個別的重新整理權杖。
當使用者授權應用程式代為存取 Google Ads API 時，系統會產生更新憑證，因此每個更新憑證都會與授權使用者擁有相同的存取權。如果用於存取開發帳戶的所有重新整理符記都與「沒有」正式版帳戶存取權的使用者相關聯 (包括管理正式版帳戶的管理員帳戶)，就不會發生誤用測試重新整理符記修改正式版帳戶的情況。
由於存取權取決於所使用的更新權杖，因此您不需要建立測試更新權杖以外的測試憑證。只要更新憑證不同，用於存取實際執行帳戶的開發人員權杖、用戶端 ID 和用戶端密碼，就能安全地用於存取測試帳戶。
提出驗證要求
如果您只需要測試要求是否有效 (例如驗證要求是否有正確的結構，且不違反政策)，可以使用 validate_only 欄位，該欄位適用於 GoogleAdsService.SearchStream 和 GoogleAdsService.Search 要求，以及大多數變異要求。請參閱參考說明文件，確認這個欄位是否適用於特定方法。
REST API
針對臨時測試 (例如驗證要求是否會產生預期的輸出內容)，使用 REST API 通常是最簡單的做法。請參閱 REST 範例，瞭解如何在向 REST API 提出要求時使用 cURL。