پروژه متن باز اندروید (AOSP) چندین ابزار و مجموعه آزمایشی برای آزمایش بخش های مختلف پیاده سازی شما ارائه می دهد. قبل از استفاده از صفحات این بخش، باید با اصطلاحات زیر آشنا باشید:
- دستگاه سازگار با اندروید
- دستگاهی که می تواند هر برنامه شخص ثالث نوشته شده توسط توسعه دهندگان شخص ثالث را با استفاده از Android SDK و NDK اجرا کند. دستگاههای سازگار با Android باید از الزامات سند تعریف سازگاری (CDD) پیروی کنند و مجموعه تست سازگاری (CTS) را بگذرانند. دستگاههای سازگار با Android واجد شرایط شرکت در اکوسیستم Android هستند، که شامل مجوز بالقوه Google Play، مجوز بالقوه مجموعه برنامهها و APIهای سرویسهای تلفن همراه Google (GMS) و استفاده از علامت تجاری Android است. هر کسی میتواند از کد منبع اندروید استفاده کند، اما برای اینکه بخشی از اکوسیستم اندروید در نظر گرفته شود، دستگاه باید با اندروید سازگار باشد.
- مصنوع
- گزارش مربوط به ساخت که عیب یابی محلی را امکان پذیر می کند.
- سند تعریف سازگاری (CDD)
- سندی که نرمافزار و سختافزار مورد نیاز دستگاههای سازگار با Android را برمیشمارد.
- مجموعه تست سازگاری (CTS)
یک مجموعه آزمایشی رایگان و تجاری، که برای دانلود به صورت باینری یا منبع در AOSP در دسترس است. CTS مجموعهای از تستهای واحد است که برای ادغام در گردش کار روزانه شما طراحی شده است. هدف CTS آشکارسازی ناسازگاریها و اطمینان از سازگاری نرمافزار در طول فرآیند توسعه است.
تستهای CTS و پلتفرم متقابلاً منحصر به فرد نیستند. در اینجا چند دستورالعمل کلی وجود دارد:
- اگر آزمایشی صحت توابع یا رفتارهای API فریمورک را تأیید میکند و آزمایش باید در شرکای OEM اجرا شود، باید در CTS باشد.
- اگر آزمایشی برای گرفتن رگرسیون ها در طول توسعه پلتفرم در نظر گرفته شده است و ممکن است برای انجام به مجوز ممتاز نیاز داشته باشد و ممکن است به جزئیات پیاده سازی وابسته باشد (همانطور که در AOSP منتشر شده است)، باید یک آزمایش پلت فرم باشد.
- خدمات تلفن همراه گوگل (GMS)
مجموعهای از برنامهها و APIهای Google که میتوانند از قبل روی دستگاهها نصب شوند.
- GoogleTest (GTest)
یک چارچوب تست و تمسخر ++C. باینریهای GTest معمولاً به لایههای انتزاعی سطح پایینتر دسترسی دارند یا IPC خام را در برابر سرویسهای مختلف سیستم انجام میدهند. رویکرد تست برای GTest معمولاً با سرویس در حال آزمایش همراه است. CTS شامل چارچوب GTest است.
- تست ابزار دقیق
یک محیط اجرای آزمایشی ویژه که توسط دستور
am instrument
راه اندازی شده است، که در آن فرآیند برنامه هدفمند مجدداً راه اندازی شده و با زمینه اصلی برنامه شروع می شود و یک رشته ابزار دقیق در داخل ماشین مجازی فرآیند برنامه شروع می شود. CTS شامل تست های ابزار دقیق است.- Logcat
یک ابزار خط فرمان که گزارشی از پیامهای سیستم را ایجاد میکند، از جمله پشتههایی از زمانی که دستگاه خطا میدهد و پیامهایی که از برنامه خود با کلاس
Log
نوشتهاید.- چوب بری
استفاده از گزارش برای پیگیری رویدادهای سیستم کامپیوتری، مانند خطاها. ورود به سیستم اندروید به دلیل ترکیبی از استانداردهای استفاده شده که در ابزار Logcat ترکیب شده اند، پیچیده است.
- پس از ارسال آزمون
یک تست اندروید که زمانی انجام می شود که یک پچ جدید به یک شاخه هسته مشترک متعهد شود. با وارد کردن
aosp_kernel
به عنوان یک نام جزئی شاخه، می توانید لیستی از شاخه های هسته را با نتایج موجود مشاهده کنید. برای مثال، نتایج مربوط بهandroid-mainline
را میتوانید در https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid پیدا کنید.- آزمون را از پیش ارسال کنید
تستی که برای جلوگیری از وارد شدن خرابی ها به هسته های رایج استفاده می شود.
- فدراسیون تجارت
Tradefed نیز نامیده می شود، یک چارچوب آزمایشی پیوسته که برای اجرای تست ها بر روی دستگاه های اندرویدی طراحی شده است. به عنوان مثال، Tradefed برای اجرای تست های Compatibility Test Suite و Vendor Test Suite استفاده می شود.
- مجموعه تست فروشنده (VTS)
مجموعه ای از قابلیت های گسترده برای آزمایش اندروید، ترویج فرآیند توسعه مبتنی بر آزمایش، و خودکارسازی لایه انتزاعی سخت افزار (HAL) و آزمایش هسته سیستم عامل.
یک تست پلت فرم معمولاً با یک یا چند سرویس سیستم Android یا لایههای HAL تعامل دارد، عملکردهای موضوع مورد آزمایش را اعمال میکند و صحت نتیجه آزمایش را تأیید میکند. آزمایش پلت فرم ممکن است:
- (نوع 1) APIهای فریمورک را با استفاده از فریم ورک اندروید تمرین کنید. API های خاص در حال اجرا می تواند شامل موارد زیر باشد:
- API های عمومی در نظر گرفته شده برای برنامه های شخص ثالث
- APIهای مخفی در نظر گرفته شده برای برنامههای دارای امتیاز، یعنی APIهای سیستم یا APIهای خصوصی (
@hide
، یاprotected
،package private
)
- (نوع 2) خدمات سیستم اندروید را با استفاده از بایندر خام یا پروکسی های IPC به طور مستقیم فراخوانی کنید.
- (نوع 3) با استفاده از API های سطح پایین یا رابط های IPC مستقیماً با HAL ها تعامل داشته باشید.
تستهای نوع 1 و 2 معمولاً تستهای ابزار دقیق هستند، در حالی که تستهای نوع 3 معمولاً GTest هستند.
در اینجا لیستی از اسناد وجود دارد که می توانید برای اطلاعات دقیق تر بخوانید:
اگر معماری اندروید را مطالعه نکرده اید، به نمای کلی معماری مراجعه کنید.
اگر در حال ایجاد یک دستگاه سازگار با Android هستید، به نمای کلی برنامه سازگاری Android مراجعه کنید.
برای ادغام تستهای ابزار دقیق، عملکردی، متریک و میزبان JAR در یک سرویس تست پیوسته پلت فرم، گردش کار توسعه تست را ببینید.
برای شناسایی و سختتر کردن دستگاههای خود در برابر آسیبپذیریها، به تست امنیتی مراجعه کنید.
برای آشنایی با آزمایش اجرای HAL و هسته، به مجموعه تست فروشنده (VTS) و زیرساخت مراجعه کنید.
برای آزمایش برنامه، اصول آزمایش برنامه های اندروید را بخوانید و با استفاده از نمونه های ارائه شده ، Android Advanced را در Kotlin 05.1: Testing Basics انجام دهید.
در مورد آزمایش اولیه پیش ارسال که از طریق قلاب های مخزن در دسترس شماست، بیاموزید. این قلابها را میتوان برای اجرای لینترها، بررسی قالببندی و آزمایشهای واحد ماشه قبل از ادامه، مانند آپلود یک commit استفاده کرد. این قلاب ها به طور پیش فرض غیرفعال هستند. برای اطلاعات بیشتر، AOSP Preupload Hooks را ببینید.
برای مطالعه بیشتر در مورد ورود به سیستم، به درک ورود به سیستم مراجعه کنید.
برای درک نحوه اشکالزدایی کد Android، به اشکالزدایی کد پلتفرم اصلی Android مراجعه کنید.