测试
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
无论您是刚刚开始、维护应用,还是向现有集成添加新功能,测试都是构建成功的 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
请求,以及大多数 mutate 请求。请参阅参考文档,验证相应字段是否适用于指定方法。
REST API
对于临时测试(例如验证请求是否会产生预期输出),使用 REST API 通常是最简单的选择。请参阅 REST 示例,了解如何使用 curl 向 REST API 发出请求。您还可以尝试在 REST 探索器中进行测试。
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-08-26。
[null,null,["最后更新时间 (UTC):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)."]]