الاختبار
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
يُعدّ الاختبار خطوة مهمة في إنشاء عملية دمج ناجحة مع Google Ads API، سواء كنت في بداية عملية الدمج أو كنت بصدد صيانة تطبيق أو إضافة ميزات جديدة إلى عملية دمج حالية. يقدّم هذا الدليل بعض أفضل الممارسات لاختبار عملية الدمج مع Google Ads API.
الحسابات التجريبية وحسابات الإنتاج
تتوفّر حسابات تجريبية لأغراض التطوير. باستخدام الحسابات الاختبارية، يمكنك التأكّد من أنّ رمز التطبيق وإعداداته تعمل على النحو المنشود.
ومع ذلك، لا يمكن اختبار
جميع الميزات في
حساب اختباري.
عندما تمنعك قيود الحساب التجريبي من اختبار بعض الميزات في عملية الدمج، يمكنك بدلاً من ذلك استخدام حساب إنتاج لأغراض التطوير.
تختلف حسابات الإنتاج المخصّصة للتطوير عن حسابات الاختبار بالطرق التالية:
بما أنّ حسابات الإنتاج تعرض الإعلانات، فإنّها تنشئ مقاييس تتيح لك اختبار تقارير الأداء، بالإضافة إلى إتاحة جميع الميزات الأخرى في Google Ads API. ومع ذلك، يتطلّب استخدامها في التطوير توخّي الحذر الشديد. ننصحك باتّخاذ الإجراءات التالية:
- لا تمنح إذن الوصول إلا للمستخدمين الذين يحتاجون إليه لأغراض التطوير.
- حدِّد ميزانية يومية ثابتة ومنخفضة للحساب.
- استخدِم حسابات الإنتاج لأغراض التطوير فقط عندما يتعذّر استخدام الحسابات التجريبية.
وبالتالي، لإجراء اختبار كامل لعملية الدمج، من المحتمل أن تحتاج إلى بيانات اعتماد اختبارية وبيانات اعتماد إنتاجية.
بيانات اعتماد الاختبار
للحدّ من خطر تعديل حسابات الإنتاج عن طريق الخطأ عند محاولة تعديل حسابات التطوير، ننصحك بالاحتفاظ بمجموعة من بيانات الاعتماد التجريبية منفصلة عن بيانات اعتماد تطبيقك المخصّص للإنتاج.
لإنشاء مجموعة من بيانات اعتماد الاختبار، اتّبِع الخطوات التالية:
- أنشئ حساب بريد إلكتروني (مثل api.test@example.com) أو حساب خدمة
سيتم استخدامه لأغراض الاختبار فقط.
- أضِف هذا المستخدم أو حساب الخدمة كمستخدم صالح في حسابات "إعلانات Google" التي تجري اختبارات عليها. تأكَّد من منح مستويات الوصول المناسبة لهذا المستخدم أو حساب الخدمة. لا تمنح هذا المستخدم أو حساب الخدمة إذن الوصول إلى أي حسابات إنتاج.
- إذا كنت تستخدم مسار مصادقة المستخدمين في الإصدار 2.0 من OAuth بدلاً من
مسار حساب الخدمة، عليك إنشاء رمز مميز لإعادة التحميل لحساب المستخدم التجريبي.
- استخدِم بيانات الاعتماد الجديدة هذه عند اختبار تطبيقك. يمكن إعادة استخدام رمز المطوّر ومعرّف العميل وسر العميل لأغراض الاختبار، لأنّها لا تؤثّر في تحديد حسابات "إعلانات Google" التي يمكن الوصول إليها.
طلب التحقق
إذا كنت بحاجة فقط إلى اختبار ما إذا كان الطلب صالحًا، مثلاً للتأكّد من أنّ الطلب منظَّم بشكل صحيح ولا ينتهك السياسات، يمكنك استخدام الحقل validate_only، وهو متاح لطلبات GoogleAdsService.SearchStream وGoogleAdsService.Search، بالإضافة إلى معظم طلبات التعديل.
راجِع المستندات المرجعية للتأكّد مما إذا كان هذا الحقل متاحًا لطريقة معيّنة.
واجهة برمجة تطبيقات REST
بالنسبة إلى الاختبارات المخصّصة، مثلاً للتحقّق من أنّ الطلب يؤدي إلى الناتج المتوقّع، يكون استخدام REST API غالبًا هو الخيار الأسهل. راجِع أمثلة REST للتعرّف على كيفية استخدام curl في تقديم الطلبات إلى واجهة REST API. يمكنك أيضًا تجربة الاختبار في REST explorer.
إنّ محتوى هذه الصفحة مرخّص بموجب ترخيص Creative Commons Attribution 4.0 ما لم يُنصّ على خلاف ذلك، ونماذج الرموز مرخّصة بموجب ترخيص Apache 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)."]]
