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)
GTest یک چارچوب تست و تمسخر ++C است. باینریهای GTest معمولاً به لایههای انتزاعی سطح پایینتر دسترسی دارند یا IPC خام را در برابر سرویسهای مختلف سیستم انجام میدهند. رویکرد تست برای GTest معمولاً با سرویس در حال آزمایش همراه است. CTS شامل چارچوب GTest است.
- تست ابزار دقیق
یک تست ابزار دقیق یک محیط اجرای تست ویژه را همانطور که توسط دستور
am instrument
راه اندازی می شود، فراهم می کند، جایی که فرآیند برنامه هدفمند مجدداً راه اندازی می شود و با زمینه برنامه اصلی شروع می شود، و یک رشته ابزار دقیق در داخل ماشین مجازی فرآیند برنامه شروع می شود. CTS شامل تست های ابزار دقیق است.- Logcat
Logcat یک ابزار خط فرمان است که گزارشی از پیامهای سیستم را ایجاد میکند، از جمله پشتههایی از زمانی که دستگاه خطا میدهد و پیامهایی که از برنامه خود با کلاس
Log
نوشتهاید.- چوب بری
ورود به سیستم به استفاده از گزارش برای پیگیری رویدادهای سیستم کامپیوتری مانند خطاها اشاره دارد. ورود به سیستم اندروید به دلیل ترکیبی از استانداردهای استفاده شده که در ابزار Logcat ترکیب شده اند، پیچیده است.
- پس از ارسال آزمون
تستهای ارسال پست اندروید زمانی انجام میشوند که یک پچ جدید به یک شاخه هسته مشترک متعهد شود. با وارد کردن
aosp_kernel
به عنوان یک نام جزئی شاخه، می توانید لیستی از شاخه های هسته را با نتایج موجود مشاهده کنید. برای مثال، نتایج مربوط بهandroid-mainline
میتوانید در https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid پیدا کنید.- آزمون را از پیش ارسال کنید
تست های Presubmit برای جلوگیری از ورود خرابی ها به هسته های رایج استفاده می شود.
- فدراسیون تجارت
Trade Federation که به آن Tradefed نیز میگویند، یک چارچوب آزمایشی پیوسته است که برای اجرای آزمایشها در دستگاههای اندرویدی طراحی شده است. به عنوان مثال، Tradefed برای اجرای تست های Compatibility Test Suite و Vendor Test Suite استفاده می شود.
- مجموعه تست فروشنده (VTS)
مجموعه تست فروشنده Android (VTS) قابلیتهای گستردهای را برای آزمایش اندروید ارائه میکند، فرآیند توسعه مبتنی بر آزمایش را ترویج میکند و آزمایش هسته HAL و OS را خودکار میکند.
انواع تست پلت فرم
یک تست پلت فرم معمولاً با یک یا چند لایه از سرویسهای سیستم Android یا لایههای لایه انتزاعی سختافزار (HAL) تعامل دارد، عملکردهای موضوع مورد آزمایش را اعمال میکند و صحت نتیجه آزمایش را تأیید میکند. آزمایش پلت فرم ممکن است:
- (نوع 1) APIهای فریمورک را با استفاده از فریم ورک اندروید تمرین کنید. API های خاص در حال اجرا می تواند شامل موارد زیر باشد:
- API های عمومی در نظر گرفته شده برای برنامه های شخص ثالث
- APIهای مخفی در نظر گرفته شده برای برنامههای دارای امتیاز، یعنی APIهای سیستم یا APIهای خصوصی (
@hide
, or
محافظت شده,
بسته خصوصی»)
- (نوع 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، به اشکالزدایی کد پلت فرم بومی مراجعه کنید.