نمای کلی «فدراسیون تجارت»

«فدراسیون تجارت» (Tradefed یا به‌اختصار TF) چارچوب آزمایشی پیوسته‌ای است که برای اجرای آزمایش‌ها در دستگاه‌های Android طراحی شده است. برای مثال، از Tradefed برای اجرای مجموعه آزمایش سازگاری (CTS) و مجموعه آزمایش فروشنده (VTS) استفاده می‌شود.

‫Trade Federation یک برنامه Java است که روی رایانه میزبان اجرا می‌شود و بااستفاده از ddmlib (کتابخانه پشت DDMS) ازطریق adb با یک یا چند دستگاه Android ارتباط برقرار می‌کند.

برخی‌از ویژگی‌های اصلی TF را در زیر به‌همراه چند نمونه مورد استفاده فهرست کرده‌ایم. بااین‌حال، اگر می‌خواهید مستقیماً وارد شوید و شروع کنید، می‌توانید مستقیماً به صفحه از اینجا شروع کنید بروید.

ویژگی‌ها

  • طراحی مدولار، انعطاف‌پذیر، مقیاس‌پذیر
  • از اجرای انواع مختلف آزمایش‌های Android پشتیبانی داخلی دارد: ابزار دقیق، uiautomator، بومی/gtest،‏ JUnit میزبان‌محور، و غیره
  • سازوکارهای قابلیت اطمینان و بازیابی را در بالای adb ارائه می‌دهد
  • از زمان‌بندی و اجرای موازی آزمایش‌ها در چندین دستگاه پشتیبانی می‌کند

برای دریافت جدیدترین اطلاعات درباره نحوه اجرای آزمایش‌های موجود، مانند ابزار دقیق، به آزمایش ازطریق TF مراجعه کنید.

موارد استفاده

واحدی بودن Trade Federation باعث می‌شود که به‌راحتی در محیط‌هایی با زیرساخت‌های ساخت، آزمایش، و گزارش‌دهی موجود قرار گیرد. در زیر چند مورد استفاده نمایشی را فهرست می‌کنیم که در آن‌ها tradefed می‌تواند روال‌های آزمایش کارآمد و مقیاس‌پذیر را فعال کند.

ابتدا، مفید است که چشم‌انداز موارد استفاده بالقوه را ازنظر این سؤال درنظر بگیریم: «کدام بخش‌ها قابل‌تغییر هستند و کدام بخش‌ها ثابت هستند؟» برای مثال، سازنده اصلی محصول دستگاه می‌تواند چارچوب، سیستم، و سخت‌افزار را اصلاح کند، اما تأثیر کمی بر برنامه‌های موجود دارد یا اصلاً تأثیری ندارد. از طرف دیگر، توسعه‌دهنده برنامه می‌تواند برنامه را تغییر دهد، اما کنترل کمی بر اکثر جنبه‌های سیستم یا چارچوب دارد.

در نتیجه، یک نهاد در هر مورد استفاده اهداف آزمایشی متفاوتی خواهد داشت و درصورت مجموعه شکست‌های آزمایشی، گزینه‌های متفاوتی خواهد داشت. باوجود این تفاوت‌ها، Trade Federation می‌تواند به کارآمد، انعطاف‌پذیر، و مقیاس‌پذیر کردن هریک از فرایندهای آزمایشی آن‌ها کمک کند.

سازنده اصلی محصول دستگاه

«سازنده اصلی محصول» سخت‌افزار می‌سازد و اغلب سیستم و چارچوب‌های Android را تغییر می‌دهد تا در آن سخت‌افزار به‌خوبی اجرا شود. «سازنده اصلی محصول» ممکن است تلاش کند این اهداف را درحالی‌که پایداری و عملکرد را در سطوح سخت‌افزار و سیستم حفظ می‌کند، و مطمئن می‌شود که تغییرات چارچوب با برنامه‌های موجود سازگاری را ازبین نمی‌برد، محقق کند.

سازنده اصلی محصول می‌تواند واحدی برای فلش کردن دستگاه پیاده‌سازی کند که در مرحله «راه‌اندازی هدف» چرخه عمر اجرا خواهد شد. آن واحد درطول دوره اجرای خود کنترل کامل دستگاه را دراختیار خواهد داشت، که به آن امکان می‌دهد دستگاه را به‌طور بالقوه به bootloader،‏ flash، و سپس دستگاه را مجبور به راه‌اندازی مجدد در حالت فضای کاربر کند. این ویژگی در ترکیب با واحدی که به سیستم ساخت مداوم متصل می‌شود، به «سازنده اصلی محصول» اجازه می‌دهد هم‌زمان با ایجاد تغییر در سفت‌افزار سطح سیستم و چارچوب‌های سطح Java، آزمایش‌هایی را روی دستگاهش اجرا کند.

وقتی دستگاه به‌طور کامل راه‌اندازی شد، سازنده اصلی محصول می‌تواند از آزمون‌های موجود مبتنی بر JUnit استفاده کند یا آزمون‌های جدیدی بنویسد تا عملکرد موردنظر را درستی‌سنجی کند. درنهایت، می‌توانند یک یا چند واحد گزارش‌دهی نتایج بنویسند تا با مخزن‌های موجود نتایج آزمایش مرتبط شوند یا نتایج را مستقیماً گزارش کنند (برای مثال، ازطریق ایمیل).

توسعه‌دهنده برنامه

«توسعه‌دهنده برنامه» برنامه‌ای می‌سازد که باید در نسخه‌های مختلف پلاتفرم و دستگاه‌های مختلف به‌خوبی اجرا شود. اگر مشکلی در نسخه پلاتفرم و/یا دستگاه خاصی پیش بیاید، تنها راه حل اضافه کردن راهکار موقت و ادامه دادن است. برای توسعه‌دهندگان بزرگ‌تر، فرایند آزمایش ممکن است در توالی ساخت پیوسته گنجانده شود. برای توسعه‌دهندگان کوچک‌تر، ممکن است به‌صورت دوره‌ای یا دستی شروع شود.

اکثر توسعه‌دهندگان برنامه از واحدهای نصب آزمایشی apk که ازقبل در TF وجود دارد استفاده می‌کنند. نسخه‌ای وجود دارد که از سیستم فایل محلی نصب می‌شود، و همچنین نسخه‌ای که می‌تواند نصب فایل‌های APK بارگیری‌شده از سرویس ساخت را انجام دهد. توجه به این نکته مهم است که نسخه دوم با تعداد دلخواه نمونه‌های TF که روی همان ماشین میزبان اجرا می‌شوند، همچنان به‌درستی کار خواهد کرد.

به‌دلیل مهارت TF در کار با چندین دستگاه، طبقه‌بندی هر نتیجه آزمایش براساس نوع دستگاهی که برای آن آزمایش استفاده شده است، ساده خواهد بود. بنابراین، TF می‌تواند به‌طور بالقوه یک ماتریس سازگاری ۲ بعدی (یا چند بعدی) برای هر ساختمان برنامه تولید کند.

سرویس آزمایش

برای مثال، «سرویس آزمایشی» ممکن است به توسعه‌دهندگان برنامه اجازه دهد برنامه‌ها را ارسال کنند و آزمایش‌ها را روی دستگاه‌های مجهز به ابزارهای اندازه‌گیری توان اجرا کنند تا میزان مصرف توان برنامه را تعیین کنند. این مورد با دو مورد استفاده قبلی متفاوت است زیرا سازنده سرویس دستگاه‌ها یا برنامه‌هایی را که اجرا می‌شوند کنترل نمی‌کند.

ازآنجایی‌که Trade Federation می‌تواند هر کلاس Java را که رابط ساده IRemoteTest را پیاده‌سازی می‌کند اجرا کند، نوشتن درایورهایی که بتوانند قطعه سخت‌افزاری خارجی را با مورد آزمایشی که در دستگاه اجرا می‌شود هماهنگ کنند بسیار ساده است. خود درایور می‌تواند «رشته‌ها» را ایجاد کند، به سرورهای دیگر درخواست ارسال کند، یا هر کار دیگری را که ممکن است نیاز داشته باشد انجام دهد. علاوه‌براین، سادگی و تطبیق‌پذیری میانای گزارش نتایج، ITestInvocationListener، به این معنی است که نمایش نتایج آزمایش دلخواه (ازجمله، برای نمونه، سنجه‌های توان عددی) در خط لوله استاندارد گزارش نتایج نیز به همین سادگی انجام می‌شود.