«پروژه منبع باز Android» (AOSP) چندین ابزار و مجموعه آزمایشی برای آزمایش بخش‌های مختلف پیاده‌سازی شما ارائه می‌دهد. پیش‌از استفاده از صفحه‌های این بخش، باید با اصطلاحات زیر آشنا باشید:
- دستگاه سازگار با Android
- دستگاهی که بتواند هر برنامه طرف سومی را که توسط توسعه‌دهندگان طرف سوم بااستفاده از کیت توسعه نرم‌افزار Android و NDK نوشته شده است اجرا کند. دستگاه‌های سازگار با Android باید از الزامات سند تعریف سازگاری (CDD) پیروی کنند و مجموعه آزمایش سازگاری (CTS) را باموفقیت بگذرانند. دستگاه‌های سازگار با Android واجدشرایط شرکت در اکوسیستم Android هستند که شامل امکان دریافت پروانه Google Play، امکان دریافت پروانه مجموعه خدمات تلفن همراه Google (GMS) از برنامه و میانای برنامه‌سازی کاربردی، و استفاده از علامت تجاری Android می‌شود. همه می‌توانند از کد منبع Android استفاده کنند، اما برای اینکه دستگاهی بخشی از بوم‌سازگان Android محسوب شود، باید با Android سازگار باشد.
- آرتیفکت
- گزارش مربوط به ساخت که عیب‌یابی محلی را ممکن می‌کند.
- سند تعریف سازگاری (CDD)
- سندی که الزامات نرم‌افزاری و سخت‌افزاری دستگاه سازگار با Android را فهرست می‌کند.
- مجموعه آزمون سازگاری (CTS)
مجموعه آزمایشی رایگان و در سطح تجاری که برای بارگیری به‌صورت دودویی یا منبع در AOSP دردسترس است. CTS مجموعه‌ای از آزمون‌های واحد است که برای ادغام در گردش کار روزانه شما طراحی شده است. هدف CTS آشکار کردن ناسازگاری‌ها و اطمینان از سازگار ماندن نرم‌افزار درطول فرایند توسعه است.
آزمایش‌های CTS و پلاتفرم به‌صورت متقابل انحصاری نیستند. در اینجا چند دستورالعمل کلی آمده است:
- اگر آزمایشی صحت عملکردها یا رفتارهای چارچوب API را تأیید می‌کند، و این آزمایش باید در همه شرکای سازنده تجهیزات اصلی اجرا شود، باید در CTS باشد.
- اگر آزمایشی برای شناسایی پسرفت‌ها درطول توسعه پلاتفرم درنظر گرفته شده است، و ممکن است برای انجام آن به اجازه ویژه نیاز باشد، و ممکن است به جزئیات پیاده‌سازی (همان‌طور که در AOSP منتشر شده است) وابسته باشد، باید آزمایشی پلاتفرمی باشد.
- خدمات تلفن همراه Google (GMS)
مجموعه‌ای از برنامه‌ها و میاناهای برنامه‌سازی کاربردی Google که می‌توانند ازپیش در دستگاه‌ها نصب شوند.
- GoogleTest (GTest)
چارچوب آزمایش و شبیه‌سازی C++. باینری‌های GTest معمولاً به لایه‌های انتزاعی سطح پایین‌تر دسترسی دارند یا IPC خام را دربرابر خدمات مختلف سیستم انجام می‌دهند. رویکرد آزمایشی برای GTest معمولاً با سرویسی که آزمایش می‌شود، ارتباط نزدیکی دارد. CTS حاوی چارچوب GTest است.
- آزمایش ابزارگری
محیط اجرای آزمایش ویژه‌ای که با فرمان
am instrumentراه‌اندازی می‌شود، که در آن فرایند برنامه هدف بازراه‌اندازی می‌شود و با زمینه برنامه پایه مقداردهی اولیه می‌شود، و رشته ابزار دقیق در ماشین مجازی فرایند برنامه شروع می‌شود. CTS حاوی آزمایش‌های ابزار دقیق است.- Logcat
ابزار خط فرمانی که گزارشی از پیام‌های سیستم ایجاد می‌کند، ازجمله ردپای پشته زمانی که دستگاه خطایی را نشان می‌دهد و پیام‌هایی که از برنامه‌تان با کلاس
Logنوشته‌اید.- گزارش
استفاده از گزارش برای پیگیری رویدادهای سیستم رایانه، مانند خطاها. ثبت گزارش در Android به‌دلیل ترکیب استانداردهای استفاده‌شده که در ابزار Logcat ترکیب شده‌اند، پیچیده است.
- postsubmit test
آزمایش Android که وقتی وصله جدیدی در شاخه هسته مشترک انجام می‌شود. با وارد کردن
aosp_kernelبه‌عنوان نام جزئی شاخه، می‌توانید فهرستی از شاخه‌های هسته را با نتایج دردسترس ببینید. برای مثال، نتایجandroid-mainlineرا می‌توانید در https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid پیدا کنید.- آزمایش پیش‌ارسال
آزمایشی که برای جلوگیری از معرفی خرابی‌ها به هسته‌های مشترک استفاده می‌شود.
- فدراسیون تجارت
Tradefed، چارچوب آزمایشی پیوسته‌ای که برای اجرای آزمایش‌ها در دستگاه‌های Android طراحی شده است. برای مثال، از Tradefed برای اجرای آزمایش‌های «مجموعه آزمایش سازگاری» و «مجموعه آزمایش فروشنده» استفاده می‌شود.
- مجموعه آزمایش فروشنده (VTS)
مجموعه‌ای از قابلیت‌های گسترده برای آزمایش Android، ترویج فرایند توسعه آزمون‌محور، و خودکارسازی آزمایش لایه انتزاع سخت‌افزار (HAL) و هسته سیستم‌عامل.
انواع آزمایش پلاتفرم
آزمایش پلاتفرم معمولاً با یک یا چند سرویس سیستم Android یا لایه‌های HAL تعامل دارد، عملکردهای موضوع تحت آزمایش را اجرا می‌کند، و صحت نتیجه آزمایش را تأیید می‌کند. آزمایش پلاتفرم ممکن است:
- (نوع ۱) میاناهای برنامه‌سازی کاربردی چارچوب تمرین بااستفاده از چارچوب Android. میاناهای برنامه‌سازی کاربردی خاصی که
استفاده می‌شوند می‌توانند شامل این موارد باشند:
- میاناهای برنامه‌سازی کاربردی عمومی که برای برنامه‌های شخص ثالث درنظر گرفته شده است
- میاناهای برنامه‌سازی کاربردی پنهان که برای برنامه‌های ممتاز درنظر گرفته شده‌اند، یعنی میاناهای برنامه‌سازی کاربردی سیستم یا
میاناهای برنامه‌سازی کاربردی خصوصی (
@hide، یاprotected،package private)
- (نوع ۲) فراخوانی مستقیم سرویس‌های سیستم Android بااستفاده از binder خام یا پراکسی‌های IPC.
- (نوع ۳) بااستفاده از میاناهای برنامه‌سازی کاربردی سطح پایین یا میاناهای IPC مستقیماً با HAL تعامل برقرار می‌کنند.
آزمایش‌های نوع ۱ و ۲ معمولاً آزمایش‌های ابزاربندی هستند، درحالی‌که آزمایش‌های نوع ۳ معمولاً GTest هستند.
حالا چه می‌شود؟
در اینجا فهرستی از اسنادی که می‌توانید برای کسب اطلاعات دقیق‌تر بخوانید ارائه شده است:
اگر معماری Android را مطالعه نکرده‌اید، نمای کلی معماری را ببینید.
اگر درحال ایجاد دستگاه سازگار با Android هستید، نمای کلی برنامه سازگاری Android را ببینید.
برای ادغام آزمایش‌های ابزارگری، کارکردی، سنجه‌ای، و میزبان JAR در سرویس آزمایش مداوم پلاتفرم، به گردش کار توسعه آزمایش مراجعه کنید.
برای شناسایی و مقاوم‌سازی دستگاه‌هایتان دربرابر آسیب‌پذیری‌ها، آزمایش امنیتی را ببینید.
برای آشنایی با آزمایش پیاده‌سازی‌های HAL و هسته، به مجموعه آزمایش فروشنده (VTS) و زیرساخت مراجعه کنید.
برای آزمایش برنامه، اصول اولیه آزمایش برنامه‌های Android را بخوانید و Android پیشرفته در Kotlin 05.1:اصول اولیه آزمایش را بااستفاده از نمونه‌های ارائه‌شده انجام دهید.
درباره آزمایش پایه پیش‌ارسال که ازطریق قلاب‌های مخزن برای شما دردسترس است بیشتر بدانید. از این قلاب‌ها می‌توان برای اجرای خطایاب‌های نحوی، بررسی قالب‌بندی، و راه‌اندازی آزمون‌های واحد قبل‌از ادامه دادن، مانند بارگذاری کردن یک ثبت، استفاده کرد. این قلاب‌ها به‌طور پیش‌فرض غیرفعال هستند. برای اطلاعات بیشتر، قلاب‌های پیش‌بارگذاری AOSP را ببینید.
برای خواندن بیشتر درباره ثبت گزارش، درک ثبت گزارش را ببینید.
برای درک نحوه اشکال‌زدایی کد Android، به اشکال‌زدایی کد پلاتفرم Android بومی مراجعه کنید.