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