測試
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
無論您是剛開始使用、維護應用程式，還是為現有整合項目新增功能，測試都是建構成功 Google Ads API 整合項目的重要步驟。本指南將介紹測試 Google Ads API 整合的最佳做法。
測試帳戶和正式版帳戶
測試帳戶可用於開發用途。您可以使用測試帳戶，驗證應用程式程式碼和設定是否正常運作。
不過，並非所有功能都能在測試帳戶中測試。
如果測試帳戶的限制導致您無法測試整合中的某些功能，可以改用正式版帳戶進行開發。開發用的正式版帳戶與測試帳戶的差異如下：
- 放送使用者可看到的廣告
- 必須提供有效網址
- 必須遵守廣告政策
由於正式版帳戶會放送廣告，因此會產生指標，供您測試成效報表，並解鎖 Google Ads API 的所有其他功能。不過，使用這些功能進行開發時，請務必格外謹慎。建議採取下列措施：
- 只將存取權授予開發用途所需的使用者。
- 設定固定的低每日帳戶預算。
- 只有在無法使用測試帳戶時，才可使用正式版帳戶進行開發。
因此，如要完整測試整合項目，您可能需要測試憑證和正式環境憑證。
測試憑證
為盡量降低在嘗試修改開發帳戶時，不慎修改實際工作環境帳戶的風險，建議您維護一組與實際工作環境應用程式憑證不同的測試憑證。
如要建立一組測試憑證，請按照下列步驟操作：
- 建立電子郵件帳戶 (例如 api.test@example.com) 或服務帳戶，僅供測試使用。
- 在您用來執行測試的 Google Ads 帳戶中，將這個使用者或服務帳戶新增為有效使用者。請務必為這個使用者或服務帳戶授予適當的存取層級。請勿授予這個使用者或服務帳戶任何正式版帳戶的存取權。
- 如果您使用 OAuth 2.0 使用者驗證流程，而非服務帳戶流程，請為測試使用者帳戶產生更新權杖。
- 測試應用程式時，請使用這些新憑證。開發人員權杖、用戶端 ID 和用戶端密碼可重複用於測試，因為這些項目不會影響可存取的 Google Ads 帳戶。
提出驗證要求
如要測試要求是否有效 (例如驗證要求結構是否正確，以及是否違反政策)，可以使用 validate_only 欄位，這個欄位適用於 GoogleAdsService.SearchStream 和 GoogleAdsService.Search 要求，以及大多數的變動要求。請參閱參考說明文件，確認特定方法是否提供這個欄位。
REST API
如果是臨時測試 (例如驗證要求是否產生預期輸出內容)，使用 REST API 通常是最簡單的方法。請參閱 REST 範例，瞭解如何使用 curl 向 REST API 發出要求。此外，請嘗試在 REST 探索工具中進行測試。
除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間：2025-08-26 (世界標準時間)。
[null,null,["上次更新時間：2025-08-26 (世界標準時間)。"],[[["\u003cp\u003eTesting is crucial for successful Google Ads API integration, whether you're starting fresh, maintaining an app, or adding features.\u003c/p\u003e\n"],["\u003cp\u003eUtilize test accounts for development when possible, but be aware of their limitations and consider using production accounts cautiously for features not supported by test accounts.\u003c/p\u003e\n"],["\u003cp\u003eMaintain separate test credentials, especially refresh tokens, to avoid accidental modifications to production accounts.\u003c/p\u003e\n"],["\u003cp\u003eValidate your requests using the \u003ccode\u003evalidate_only\u003c/code\u003e field to ensure they are structured correctly and comply with policies.\u003c/p\u003e\n"],["\u003cp\u003eLeverage the REST API for quick, ad hoc testing and validation of request outputs.\u003c/p\u003e\n"]]],[],null,["# Testing is an important step in building a successful Google Ads API integration,\nwhether you're just getting started, maintaining an app, or adding\nnew features to an existing integration. This guide presents some best\npractices for testing your Google Ads API integration.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nTest accounts and production accounts\n-------------------------------------\n\n[Test accounts](/google-ads/api/docs/best-practices/test-accounts) are available for\ndevelopment purposes. With test accounts, you can validate that your application\ncode and configuration are working as intended.\n\nHowever, [not all\nfeatures](/google-ads/api/docs/best-practices/test-accounts#limitations) can be tested in a\ntest account account.\n\nWhen test account limitations prevent you from testing some features in your\nintegration, you can instead use a production account for development.\nProduction accounts for development differ from test accounts in the following\nways:\n\n- Serve ads that can be seen by users\n- Require valid URLs\n- Must comply with [advertising policies](//support.google.com/adspolicy/answer/6008942)\n\nBecause production accounts serve ads, they generate metrics letting you test\nperformance reports, as well as unlocking all the other features of the\nGoogle Ads API. However, using them for development requires extra caution. We\nrecommend taking the following measures:\n\n- Only grant access to users that need it for development purposes.\n- Set a fixed, low daily account budget.\n- Use production accounts for development only when test accounts can't be used.\n\nThus, to do full testing of your integration, you will likely need both test\ncredentials and production credentials.\n\nTest credentials\n----------------\n\nTo minimize the risk of accidentally modifying production accounts when trying\nto modify development accounts, we recommend maintaining a set of test\ncredentials that are separate from your production application credentials.\n\nTo create a set of test credentials:\n\n1. Create an email account (e.g. api.test@example.com) or a service account that will be used only for testing purposes.\n2. Add this user or service account as a valid user in the Google Ads accounts you are running your tests against. Make sure you give appropriate [access levels](//support.google.com/google-ads/answer/9978556) to this user or service account. Don't give this user or service account access to **any production accounts**.\n3. If you are using the [OAuth 2.0 user authentication flow, rather than the\n service account flow](/google-ads/api/docs/get-started/choose-application-type#choose-app-type), then generate a refresh token for your test user account.\n4. Use these new credentials when testing your application. The developer token, client ID, and client secret can be reused for testing purposes, since they have no effect in determining which Google Ads accounts can be accessed.\n\nRequest validation\n------------------\n\nIf you just need to test whether a request is valid---for example, to\nverify that the request is structured correctly and does not violate\npolicies---you can use the\n[`validate_only`](/google-ads/api/docs/concepts/api-structure#mutate_validation)\nfield, which is available for `GoogleAdsService.SearchStream` and\n`GoogleAdsService.Search` requests, as well as most mutate requests.\nConsult the [reference documentation](/google-ads/api/reference/rpc/v21/overview) to verify\nwhether this field is available for a given method.\n\nREST API\n--------\n\nFor ad hoc testing, for example to validate that a request yields the expected\noutput, using the REST API is often the easiest option. Consult the [REST\nexamples](/google-ads/api/rest/examples) to learn how to use curl in making\nrequests to the REST API. Also, try testing in the\n[REST explorer](/google-ads/api/rest/try-it)."]]
