از 27 مارس 2025، توصیه می کنیم از android-latest-release
به جای aosp-main
برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
بررسی اجمالی فدراسیون تجارت
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
Trade Federation (به اختصار Tradefed یا TF) یک چارچوب آزمایشی مداوم است که برای اجرای آزمایشها در دستگاههای اندرویدی طراحی شده است. به عنوان مثال، Tradefed برای اجرای مجموعه تست سازگاری (CTS) و مجموعه تست فروشنده (VTS) استفاده می شود.
Trade Federation یک برنامه جاوا است که روی یک کامپیوتر میزبان اجرا می شود و با استفاده از ddmlib (کتابخانه پشت DDMS) از طریق adb با یک یا چند دستگاه اندرویدی ارتباط برقرار می کند.
ما برخی از ویژگی های اصلی TF را به همراه چند نمونه از موارد استفاده در زیر فهرست کرده ایم. گفته شد، اگر میخواهید مستقیماً وارد شوید و شروع کنید، میتوانید مستقیماً به صفحه شروع اینجا بروید.
امکانات
- طراحی مدولار، انعطاف پذیر، مقیاس پذیر
- برای اجرای انواع مختلف تستهای اندروید پشتیبانی میکند: ابزار دقیق ، uiautomator ، native/gtest، JUnit مبتنی بر میزبان و غیره
- قابلیت اطمینان و مکانیسم های بازیابی را در بالای adb فراهم می کند
- از برنامه ریزی و اجرای آزمایش ها بر روی چندین دستگاه به صورت موازی پشتیبانی می کند
برای بهروزترین اطلاعات در مورد نحوه اجرای آزمایشهای موجود، مانند ابزار دقیق، به Test Through TF مراجعه کنید.
موارد استفاده کنید
ماژولار بودن فدراسیون تجارت، ورود به محیطهایی با زیرساختهای ساخت، آزمایش و گزارش موجود را آسان میکند. ما در زیر چند مورد استفاده نمایشی را فهرست می کنیم که در آن Tradefed می تواند روش های آزمایشی کارآمد و مقیاس پذیر را فعال کند.
ابتدا، مفید است که چشم انداز موارد استفاده بالقوه را از نظر این سوال در نظر بگیریم که "کدام بخش ها قابل تغییر هستند و چه بخش هایی ثابت هستند؟" به عنوان مثال، یک دستگاه OEM میتواند چارچوب، سیستم و سختافزار را تغییر دهد، اما تأثیر کمی بر برنامههای موجود دارد یا هیچ تأثیری ندارد. از طرف دیگر، یک توسعهدهنده برنامه میتواند برنامه را تغییر دهد، اما کنترل کمی بر بیشتر جنبههای سیستم یا چارچوب دارد.
در نتیجه، یک موجودیت در هر Usecase اهداف آزمایش متفاوتی خواهد داشت و در صورت مجموعه ای از شکست های تست، گزینه های متفاوتی خواهد داشت. علیرغم این تفاوتها، فدراسیون تجارت میتواند به کارآمد، انعطافپذیر و مقیاسپذیر هر یک از فرآیندهای آزمایشی آنها کمک کند.
دستگاه OEM
یک دستگاه OEM سخت افزار می سازد و اغلب سیستم و چارچوب های اندروید را بهینه سازی می کند تا به خوبی روی آن سخت افزار اجرا شود. OEM ممکن است برای دستیابی به این اهداف در عین حفظ ثبات و عملکرد در سطوح سخت افزاری و سیستم تلاش کند و مطمئن شود که تغییرات چارچوب سازگاری با برنامه های موجود را مختل نمی کند.
OEM می تواند یک ماژول چشمک زن را پیاده سازی کند که در مرحله Target Setup چرخه حیات اجرا می شود. آن ماژول کنترل کاملی بر روی دستگاه در طول دوره اجرای آن خواهد داشت، که به آن اجازه میدهد به طور بالقوه دستگاه را به بوت لودر، فلش، و سپس مجبور به راهاندازی مجدد به حالت فضای کاربر کند. همراه با یک ماژول برای اتصال به یک سیستم ساخت مداوم، این به OEM اجازه میدهد تا تستهایی را روی دستگاه خود اجرا کند، زیرا آنها تغییراتی در سیستمافزار سطح سیستم و چارچوبهای سطح جاوا ایجاد میکنند.
هنگامی که دستگاه به طور کامل بوت شد، OEM میتواند از آزمایشهای مبتنی بر JUnit استفاده کند یا آزمایشهای جدید بنویسد تا عملکرد مورد علاقه را تأیید کند. در نهایت، آنها می توانند یک یا چند ماژول گزارش نتیجه را بنویسند تا به مخازن نتایج آزمایش موجود متصل شوند، یا نتایج را مستقیماً گزارش کنند (مثلاً از طریق ایمیل ).
توسعه دهنده برنامه
یک برنامهنویس برنامهای را میسازد که باید در انواع نسخههای پلتفرم و دستگاههای مختلف به خوبی اجرا شود. اگر مشکلی در یک نسخه پلتفرم و/یا دستگاه خاص پیش آمد، تنها راه حل اضافه کردن یک راه حل و ادامه دادن است. برای توسعه دهندگان بزرگتر، فرآیند آزمایش ممکن است در یک توالی ساخت پیوسته گنجانده شود. برای توسعه دهندگان کوچکتر، ممکن است به صورت دوره ای یا دستی راه اندازی شود.
اکثر توسعه دهندگان برنامه از ماژول های نصب تست apk که از قبل در TF وجود دارد استفاده می کنند. نسخه ای وجود دارد که از سیستم فایل محلی نصب می شود ، و همچنین نسخه ای که می تواند apk های دانلود شده از یک سرویس ساخت را نصب کند . مهم است که توجه داشته باشید که نسخه دوم به درستی با بسیاری از نمونههای TF که بر روی یک ماشین میزبان اجرا میشوند به درستی کار میکند.
به دلیل مهارت TF در برخورد با چندین دستگاه، طبقه بندی هر نتیجه آزمایش بر اساس نوع دستگاهی که برای آن تست استفاده شده است ساده است. بنابراین، TF به طور بالقوه می تواند یک ماتریس سازگاری دو بعدی (یا چند بعدی) برای هر ساخت برنامه ایجاد کند.
سرویس تست
به عنوان مثال، یک سرویس تست ممکن است به توسعه دهندگان برنامه اجازه دهد تا برنامه ها را ارسال کنند و آزمایش هایی را روی دستگاه های مجهز به ابزارهای اندازه گیری قدرت برای تعیین میزان مصرف انرژی برای برنامه اجرا کنند. این با دو مورد قبلی تفاوت دارد زیرا سازنده سرویس دستگاه ها یا برنامه های در حال اجرا را کنترل نمی کند.
از آنجایی که Trade Federation میتواند هر کلاس جاوا را اجرا کند که رابط ساده IRemoteTest
پیادهسازی میکند، نوشتن درایورهایی که میتوانند برخی از قطعات خارجی سختافزار را با کیس آزمایشی که روی دستگاه اجرا میشود هماهنگ کنند، امری بیاهمیت است. خود راننده می تواند Thread ها را ایجاد کند، درخواست ها را به سرورهای دیگر ارسال کند، یا هر کار دیگری که ممکن است نیاز داشته باشد انجام دهد. علاوه بر این، سادگی و تطبیقپذیری رابط گزارشدهی نتیجه، ITestInvocationListener
، به این معنی است که نمایش نتایج آزمایش دلخواه (از جمله معیارهای توان عددی) در خط لوله گزارش نتایج استاندارد نیز ساده است.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],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."]]