تست بخشی جدایی ناپذیر از فرآیند توسعه اپلیکیشن است. معمولاً برنامهها را روی یک شبیهساز یا دستگاه اجرا میکنید تا به صورت دستی تأیید کنید که کد شما مطابق انتظار کار میکند. با این حال، آزمایش دستی برای برنامههایی که روی صفحهنمایشها و دستگاههایی با اندازههای مختلف اجرا میشوند، زمانبر، مستعد خطا و اغلب غیرقابل مدیریت است. مشکلات تست دستی اغلب نتیجه استفاده از یک دستگاه برای توسعه است. در نتیجه، خطاها می توانند در دستگاه های دیگر با فاکتورهای شکلی متفاوت مورد توجه قرار نگیرند.
برای شناسایی رگرسیونها در اندازههای مختلف پنجره و صفحه، آزمایشهای خودکار را برای تأیید اینکه رفتار و ظاهر برنامهتان در فاکتورهای شکلی مختلف سازگار است، اجرا کنید. تستهای خودکار مشکلات را زود شناسایی میکنند و خطر مشکلاتی را که تجربه کاربر را تحت تأثیر قرار میدهند، کاهش میدهند.
چه چیزی را تست کنیم
هنگام توسعه UIهای ساخته شده برای اندازه های مختلف صفحه و پنجره، به دو جنبه توجه ویژه داشته باشید:
- چگونه ویژگیهای بصری اجزا و طرحبندیها در پنجرههای با اندازههای مختلف متفاوت است
- نحوه حفظ حالت در سراسر تغییرات پیکربندی
ویژگی های بصری
چه UI ها را برای اندازه های مختلف پنجره سفارشی کنید یا نه، باید بررسی کنید که UI ها به درستی نمایش داده شوند. عرض و ارتفاعی را که فشرده، متوسط و گسترده هستند در نظر بگیرید. برای نقاط شکست توصیه شده ، کلاس های اندازه پنجره را ببینید.
![](https://developer.android.com/static/images/training/testing/different-screens/nia_sizes.png?authuser=4&hl=fa)
همچنین، برنامه شما ممکن است برخی از مؤلفهها را در سیستم طراحی شما آنطور که انتظار میرود ارائه نکند، زمانی که محدودیتهای اندازه آنها افزایش یافته است.
اگر برنامه شما دارای طرحبندیهای تطبیقی برای اندازههای مختلف پنجره است، باید آزمایشهای خودکار برای جلوگیری از رگرسیون داشته باشید. به عنوان مثال، رفع حاشیه در تلفن می تواند منجر به تناقضات چیدمان در تبلت شود. برای تأیید رفتار طرحبندیها و مؤلفههای خود، آزمایشهای رابط کاربری ایجاد کنید یا برای تأیید بصری طرحبندیها، آزمایشهای اسکرینشات بسازید.
مرمت دولتی
برنامههایی که در دستگاههایی مانند تبلتها اجرا میشوند بسیار بیشتر از برنامههای موجود در تلفنها چرخانده میشوند و اندازه آنها تغییر میکند. همچنین، تاشوها قابلیتهای نمایشگر جدیدی مانند تا کردن و باز کردن را ارائه میکنند که میتواند باعث تغییرات پیکربندی شود. وقتی این تغییرات پیکربندی رخ می دهد، برنامه شما باید بتواند وضعیت را بازیابی کند. سپس باید آزمایش هایی بنویسید که وضعیت بازیابی برنامه شما را به درستی تأیید کند.
![](https://developer.android.com/static/images/training/testing/different-screens/foldable_multiple_postures.png?authuser=4&hl=fa)
ابتدا، آزمایش کنید که برنامه شما در هنگام ایجاد تغییرات پیکربندی از کار نرود. اطمینان حاصل کنید که هر رابط کاربری در برنامه شما می تواند هر ترکیبی از چرخش، تغییر اندازه یا تا کردن را انجام دهد. از آنجایی که تغییرات پیکربندی به طور پیش فرض فعالیت را دوباره ایجاد می کند، برخی از خرابی ها به دلیل فرضیات تداوم فعالیت رخ می دهد.
چندین روش برای آزمایش تغییرات پیکربندی وجود دارد، اما در بیشتر موارد، دو راه برای آزمایش وجود دارد:
- در Compose، از
StateRestorationTester
برای شبیه سازی یک تغییر پیکربندی به روشی کارآمد بدون شروع مجدد فعالیت استفاده کنید. برای اطلاعات بیشتر به بخش های زیر مراجعه کنید. - در هر تست UI مانند Espresso یا Compose، با فراخوانی
Activity.recreate()
یک تغییر پیکربندی را شبیه سازی کنید.
معمولاً لازم نیست از دستگاه های مختلف برای آزمایش بازیابی حالت در پاسخ به تغییرات پیکربندی استفاده کنید. این به این دلیل است که همه تغییرات پیکربندی که فعالیت را دوباره ایجاد میکنند، پیامدهای مشابهی دارند. با این حال، برخی از تغییرات پیکربندی ممکن است مکانیسمهای بازسازی حالت مختلف را در دستگاههای خاص ایجاد کند.
به عنوان مثال، زمانی که کاربر در حال مشاهده یک رابط کاربری با جزئیات فهرست بر روی یک صفحه تاشو باز است و دستگاه را تا میکند تا به صفحه نمایش جلویی جابجا شود، رابط کاربری معمولاً به صفحه جزئیات تغییر میکند. یک آزمایش خودکار باید این بازیابی حالت رابط کاربر، از جمله وضعیت ناوبری را پوشش دهد.
برای آزمایش تغییرات پیکربندی که در دستگاههایی که از یک نمایشگر به نمایشگر دیگر میروند یا وارد حالت چند پنجرهای میشوند، چندین گزینه دارید:
- با استفاده از هر دستگاهی، اندازه صفحه را در طول آزمایش تغییر دهید. در بیشتر موارد، این همه مکانیسمهای بازیابی حالت را که باید تأیید کنید، فعال میکند. با این حال، این تست برای منطقی که وضعیتهای خاصی را در تاشوها تشخیص میدهد، کار نمیکند، زیرا تغییرات وضعیت باعث تغییر پیکربندی نمیشود.
- با استفاده از دستگاه یا شبیهسازی که از ویژگیهایی که میخواهید آزمایش کنید پشتیبانی میکند، تغییرات پیکربندی مرتبط را فعال کنید. به عنوان مثال، یک تبلت یا تاشو را می توان با استفاده از دستگاه اسپرسو کنترل کرد تا در حالت افقی از حالت تا شده به صفحه باز حرکت کند. برای نمونهها، بخش دستگاه اسپرسو کتابخانه و ابزار را ببینید تا اندازههای مختلف صفحه نمایش را آزمایش کنید .
انواع تست برای اندازه های مختلف صفحه نمایش و پنجره
از نوع مناسب تست برای هر مورد استفاده استفاده کنید تا بررسی کنید که تست در فاکتورهای فرم مختلف به درستی کار می کند:
آزمایشهای رفتار رابط کاربری، بخشی از رابط کاربری برنامه را راهاندازی میکنند، مانند نمایش یک فعالیت. آزمونها تأیید میکنند که عناصر خاصی وجود دارند یا ویژگیهای خاصی دارند. آزمایش ها ممکن است به صورت اختیاری اقدامات کاربر شبیه سازی شده را انجام دهند. برای مشاهده، از اسپرسو استفاده کنید. Jetpack Compose APIهای آزمایشی خود را دارد. تست های رفتار رابط کاربری می توانند ابزاری یا محلی باشند. تستهای ابزاری روی دستگاهها یا شبیهسازها اجرا میشوند، در حالی که تستهای UI محلی روی Robolectric در JVM اجرا میشوند.
از تستهای رفتار رابط کاربری برای تأیید صحت اجرای ناوبری برنامه استفاده کنید. تست ها اقداماتی مانند کلیک و کشیدن انگشت را انجام می دهند. تست های رفتار رابط کاربری نیز وجود عناصر یا ویژگی های خاص را بررسی می کنند. برای اطلاعات بیشتر، به تستهای خودکار رابط کاربری مراجعه کنید.
تست های اسکرین شات از یک رابط کاربری یا مؤلفه عکس می گیرند و تصویر را با اسکرین شات تایید شده قبلی مقایسه می کنند. این یک راه بسیار موثر برای محافظت در برابر رگرسیون است، زیرا یک اسکرین شات می تواند تعداد زیادی از عناصر و ویژگی های بصری آن را پوشش دهد. می توانید تست های اسکرین شات را روی JVM یا دستگاه ها اجرا کنید. چندین چارچوب تست اسکرین شات موجود است.
در نهایت، ممکن است برای آزمایش عملکرد واحدهای منطقی که بسته به نوع دستگاه یا اندازه پنجره رفتار متفاوتی دارند، به تستهای واحد نیاز داشته باشید، اما تستهای واحد در این زمینه کمتر رایج هستند.
مراحل بعدی
برای اطلاعات بیشتر در مورد نحوه اجرای چک های موجود در این سند، به کتابخانه ها و ابزارها مراجعه کنید.