اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
نظرة عامة على اتحاد التجارة
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
Trade Federation (المعروفة أيضًا باسم Tradefed أو TF) هي إطار عمل اختبار مستمر مصمّم لإجراء
الاختبارات على أجهزة Android. على سبيل المثال، يتم استخدام Tradefed لإجراء
مجموعة أدوات اختبار التوافق (CTS) و
مجموعة اختبار المورّد (VTS).
Trade Federation هو تطبيق Java يتم تشغيله على جهاز كمبيوتر مضيف، ويتواصل مع جهاز Android واحد أو
أكثر باستخدام ddmlib (المكتبة التي تستند إليها أداة DDMS) عبر adb.
لقد أدرجنا في ما يلي بعض الميزات الرئيسية لخدمة TF، بالإضافة إلى نموذجَين لحالات الاستخدام. ومع ذلك،
إذا كنت تريد البدء فورًا، يمكنك الانتقال مباشرةً إلى صفحة
البدء من هنا.
الميزات
- تصميم معياري ومرن وقابل للتوسع
- تتوفّر ميزة مدمجة لإجراء العديد من أنواع اختبارات Android المختلفة:
الأدوات،
uiautomator،
gtest/native وJUnit المستند إلى المضيف وما إلى ذلك
- توفّر آليات موثوقية واسترداد بالإضافة إلى adb
- تتيح جدولة الاختبارات وتنفيذها على أجهزة متعددة بشكل موازٍ
اطّلِع على الاختبار من خلال TF
للحصول على أحدث المعلومات حول كيفية إجراء اختباراتك الحالية، مثل
الأدوات.
حالات الاستخدام
تسمح لك وحدات Trade Federation بإجراء عمليات دمج سهلة في البيئات التي تتضمّن بنية أساسية حالية لعمليات الإنشاء والاختبار وإعداد التقارير. في ما يلي بعض حالات الاستخدام النموذجية
التي يمكن أن تتيح فيها أداة Tradefed ممارسات اختبار فعّالة وقابلة للتطوير.
أولاً، من المفيد النظر في المشهد العام لحالات الاستخدام المحتملة من حيث السؤال:
"ما هي الأجزاء القابلة للتعديل، وما هي الأجزاء الثابتة؟" على سبيل المثال، يمكن لمصنعي الأجهزة الأصليين تعديل
الإطار الأساسي والنظام والأجهزة، ولكن ليس لديهم تأثير يذكر أو لا تأثير على التطبيقات الحالية.
من ناحية أخرى، يمكن لمطوّر التطبيقات تعديل التطبيق، ولكن لا يملك سيطرة كبيرة على معظم
جوانب النظام أو الإطار.
نتيجةً لذلك، سيكون للكيان في كل حالة استخدام أهداف اختبار مختلفة، وسيكون لديه خيارات مختلفة
في حال حدوث مجموعة من حالات تعذُّر الاختبار. على الرغم من هذه الاختلافات، يمكن أن تساعد Trade Federation في
جعل كل عملية اختبار من عمليات الاختبار هذه فعّالة ومرنة وقابلة للتطوير.
المصنّع الأصلي للجهاز
يُنشئ المصنّع الأصلي للجهاز الأجهزة، وغالبًا ما يعدّل نظام Android وإطارات العمل ليعملا بشكلٍ جيد
على تلك الأجهزة. قد يسعى المصنّع الأصلي للجهاز إلى تحقيق هذه الأهداف مع الحفاظ على ثبات
والأداء على مستوى الأجهزة والنظام، والتأكّد من أنّ تغييرات الإطار الأساسي لا تؤدي إلى تعطيل
التوافق مع التطبيقات الحالية.
يمكن أن ينفِّذ المصنّع الأصلي للجهاز وحدة فلاش للجهاز سيتم تنفيذها أثناء مرحلة إعداد الاستهداف
في رحلة المستخدم. ستتحكّم هذه الوحدت بشكل كامل في الجهاز أثناء فترة تنفيذها، ما سيسمح لها بفرض تشغيل برنامج الإقلاع على الجهاز وفلاشه ثم إعادة تشغيله مجددًا في وضع مساحة المستخدم. بالإضافة إلى وحدة لربطها بنظام الإنشاء المستمر، سيسمح ذلك
لمصنعي المعدّات الأصلية بإجراء اختبارات على أجهزتهم أثناء إجراء تغييرات على البرامج الثابتة على مستوى النظام و
الأُطر على مستوى Java.
بعد تشغيل الجهاز بالكامل، سيتمكّن المصنّع الأصلي للجهاز من الاستفادة من الاختبارات الحالية المستندة إلى JUnit
أو كتابة اختبارات جديدة للتحقّق من الوظيفة المعنيّة. أخيرًا، يمكنهم كتابة وحدة واحدة أو أكثر من
وحدات إعداد تقارير النتائج لربطها بمستودعات نتائج الاختبار الحالية، أو للإبلاغ عن النتائج
مباشرةً (على سبيل المثال،
عبر البريد الإلكتروني).
مطوِّر التطبيقات
ينشئ مطوّر التطبيقات تطبيقًا يجب أن يعمل بشكل جيد على مجموعة متنوعة من إصدارات منصّة
ومجموعة متنوعة من الأجهزة. إذا ظهرت مشكلة في إصدار معيّن من النظام الأساسي و/أو
الجهاز، يكون الحل الوحيد هو إضافة حل بديل والمتابعة. بالنسبة إلى المطوّرين الأكبر حجمًا، قد يتم دمج عملية الاختبار في تسلسل إنشاء مستمر. بالنسبة إلى المطوّرين الأصغر حجمًا، قد يتم بدء عملية المراجعة بشكل دوري أو يدوي.
سيستخدم معظم مطوّري التطبيقات وحدات تثبيت اختبار apk المتوفّرة حاليًا في TF.
يتوفّر إصدار يتم تثبيته من نظام الملفات المحلي، بالإضافة إلى إصدار يمكنه
تثبيت
حِزم apk التي تم تنزيلها من خدمة إنشاء. من المهمّ الإشارة إلى أنّ الإصدار الأخير سيواصل عمله بشكلٍ سليم مع عدد عشوائي من عمليات تشغيل TF على الجهاز المضيف نفسه.
نظرًا لمهارة فريق TF في التعامل مع الأجهزة المتعددة، سيكون من السهل
تصنيف كل نتيجة اختبار حسب نوع الجهاز المستخدَم لإجراء هذا الاختبار. وبالتالي، يمكن أن يؤدي TF
إلى إنشاء مصفوفة توافق ثنائية الأبعاد (أو متعددة الأبعاد) لكل
إصدار من التطبيق.
خدمة اختبار
على سبيل المثال، قد تسمح "خدمة الاختبار" لمطوّري التطبيقات بإرسال التطبيقات وإجراء الاختبارات على الأجهزة التي تم تجهيزها بأدوات قياس الطاقة لتحديد استهلاك الطاقة للتطبيق. ويختلف ذلك عن حالتَي الاستخدام السابقتَين لأنّ "أداة إنشاء الخدمات" لا تتحكّم في الأجهزة أو التطبيقات التي يتم تشغيلها.
بما أنّ Trade Federation يمكنه تشغيل أي فئة Java تنفِّذ واجهة
IRemoteTest البسيطة، من السهل
كتابة برامج تشغيل يمكنها تنسيق بعض الأجهزة الخارجية مع حالة الاختبار
التي يتم تشغيلها على الجهاز. يمكن لبرنامج التشغيل نفسه إنشاء سلاسل محادثات أو إرسال طلبات إلى ملفّات غيرها
الخادم أو تنفيذ أيّ إجراء آخر قد يحتاج إليه. بالإضافة إلى ذلك، تعني بساطة واجهة إعداد تقارير النتائج وتنوعها
ITestInvocationListener أنّه من السهل أيضًا
تمثيل نتائج اختبارات عشوائية (بما في ذلك، على سبيل المثال، مقاييس الطاقة الرقمية) في
مسار إعداد التقارير العادي للنتائج.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# Trade Federation overview\n\nTrade Federation (Tradefed or TF for short) is a continuous test framework designed for running\ntests on Android devices. For example, Tradefed is used to run the\n[Compatibility Test Suite (CTS)](/docs/compatibility/cts) and\n[Vendor Test Suite (VTS)](/docs/core/tests/vts).\n\nTrade Federation is a Java application which runs on a host computer, and communicates to one or\nmore Android devices using ddmlib (the library behind DDMS) over adb.\n\nWe've listed some of TF's main features below, along with a couple sample usecases. That said,\nif you want to jump right in and get started, you can head straight for the\n[Start Here](/docs/core/tests/tradefed/fundamentals) page.\n\nFeatures\n--------\n\n- modular, flexible, scalable design\n- has built in support for running many different types of Android tests: [instrumentation](https://developer.android.com/studio/test#create_instrumented_test_for_a_build_variant), [uiautomator](https://developer.android.com/training/testing/ui-testing), native/gtest, host-based JUnit, etc\n- provides reliability and recovery mechanisms on top of adb\n- supports scheduling and running tests on multiple devices in parallel\n\nSee [Testing Through TF](/docs/core/tests/tradefed/testing/through-tf)\nfor the most up-to-date information about how to run your existing tests, such as\n[Instrumentation](/docs/core/tests/tradefed/testing/through-tf/instrumentation).\n\nUse cases\n---------\n\nTrade Federation's modularity makes it straightforward to slot into environments with existing\nbuild, test, and reporting infrastructures. We list below a few demonstrative\nusecases where tradefed could enable efficient, scalable test practices.\n\nFirst, it is useful to consider the landscape of potential usecases in terms of the question\n\"which parts are modifiable, and what parts are static?\" For instance, a Device OEM can modify the\nframework, the system, and the hardware, but has little or no influence over existing applications.\nAn application developer, on the other hand, can modify the app, but has little control over most\naspects of the system or the framework.\n\nAs a result, an entity in each usecase will have different testing goals, and will have different\noptions in the case of a set of test failures. Despite these differences, Trade Federation can\nhelp make each of their test processes efficient, flexible, and scalable.\n\n### Device OEM\n\nA Device OEM builds hardware, and will often tweak the Android system and frameworks to run well\non that hardware. The OEM might strive to accomplish those goals while retaining stability\nand performance at the hardware and system levels, and making sure the framework changes don't break\ncompatibility with existing applications.\n\nThe OEM could implement a device flashing module that will execute during the Target Setup stage\nof the [lifecycle](/docs/core/tests/tradefed/fundamentals/lifecycle). That\nmodule would have complete control over the device during its execution period, which would allow\nit to potentially force the device into the bootloader, flash, and then force the device to reboot\nback into userspace mode. Combined with a module to tie into a continuous build system, this would\nallow the OEM to run tests on their device as they make changes to the system-level firmware and\nJava-level frameworks.\n\nOnce the device is fully booted, the OEM would be able to leverage existing JUnit-based tests,\nor write new ones, to verify the functionality of interest. Finally, they could write one or more\nresult reporting modules to tie into existing test-result repositories, or to report results\ndirectly (for instance,\n[by email](/reference/com/android/tradefed/result/EmailResultReporter)).\n\n### App developer\n\nAn Application Developer builds an app which needs to run well across a variety of platform\nversions and a variety of devices. If an issue comes up on a particular platform version and/or\ndevice, the only remedy is to add a workaround and move on. For larger developers, the test\nprocess might be incorporated into a continuous build sequence. For smaller developers, it\nmight be kicked off periodically or by hand.\n\nMost app developers would use the apk test installation modules that already exist in TF.\nThere's a version that [installs from the local filesystem](/reference/com/android/tradefed/targetprep/InstallApkSetup), as well as a version that can\n[install\napks downloaded from a build service](/reference/com/android/tradefed/targetprep/InstallBuildEnvApkSetup). It is important to note that the latter version would\ncontinue to work properly with arbitrarily many TF instances running on the same host machine.\n\nBecause of TF's proficiency at dealing with multiple devices, it would be straightforward to\nclassify each test result by the type of device that was used for that test. Thus, TF could\npotentially generate a 2-dimensional (or multi-dimensional) compatibility matrix for every\nbuild of the application.\n\n### Testing service\n\nA Test Service might, for instance, allow app developers to submit apps and run tests on devices\ninstrumented with power-measurement tools to determine power usage for the app. This differs from\nthe prior two usecases in that the service builder does not control the devices or the applications\nthat are being run.\n\nBecause Trade Federation can run any Java class that implements the simple\n[`IRemoteTest`](/reference/com/android/tradefed/testtype/IRemoteTest) interface, it's\ntrivial to write drivers that can coordinate some external piece of hardware with the test case\nthat's being run on the device. The driver itself can spawn Threads, send requests to other\nservers, or do anything else that it might need. Moreover, the simplicity and versatility of the\nresult reporting interface,\n[`ITestInvocationListener`](/reference/com/android/tradefed/result/ITestInvocationListener), means that it is likewise straightforward to\nrepresent arbitrary test results (including, for instance, numerical power metrics) into the\nstandard result reporting pipeline."]]
