با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
تست بخشی جدایی ناپذیر از فرآیند توسعه اپلیکیشن است. معمولاً برنامهها را روی یک شبیهساز یا دستگاه اجرا میکنید تا به صورت دستی تأیید کنید که کد شما مطابق انتظار کار میکند. با این حال، آزمایش دستی برای برنامههایی که روی صفحهنمایشها و دستگاههایی با اندازههای مختلف اجرا میشوند، زمانبر، مستعد خطا و اغلب غیرقابل مدیریت است. مشکلات تست دستی اغلب نتیجه استفاده از یک دستگاه برای توسعه است. در نتیجه، خطاها می توانند در دستگاه های دیگر با فاکتورهای شکلی متفاوت مورد توجه قرار نگیرند.
برای شناسایی رگرسیونها در اندازههای مختلف پنجره و صفحه، آزمایشهای خودکار را برای تأیید اینکه رفتار و ظاهر برنامهتان در فاکتورهای شکلی مختلف سازگار است، اجرا کنید. تستهای خودکار مشکلات را زود شناسایی میکنند و خطر مشکلاتی را که تجربه کاربر را تحت تأثیر قرار میدهند، کاهش میدهند.
چه چیزی را تست کنیم
هنگام توسعه UIهای ساخته شده برای اندازه های مختلف صفحه و پنجره، به دو جنبه توجه ویژه داشته باشید:
چگونه ویژگیهای بصری اجزا و طرحبندیها در پنجرههای با اندازههای مختلف متفاوت است
چه UI ها را برای اندازه های مختلف پنجره سفارشی کنید یا نه، باید بررسی کنید که UI ها به درستی نمایش داده شوند. عرض و ارتفاعی را که فشرده، متوسط و گسترده هستند در نظر بگیرید. برای نقاط شکست توصیه شده ، کلاس های اندازه پنجره را ببینید.
شکل 1. صفحه "برای شما" در Now In Android در اندازه های مختلف پنجره
همچنین، برنامه شما ممکن است برخی از مؤلفهها را در سیستم طراحی شما آنطور که انتظار میرود ارائه نکند، زمانی که محدودیتهای اندازه آنها افزایش یافته است.
اگر برنامه شما دارای طرحبندیهای تطبیقی برای اندازههای مختلف پنجره است، باید آزمایشهای خودکار برای جلوگیری از رگرسیون داشته باشید. به عنوان مثال، رفع حاشیه در تلفن می تواند منجر به تناقضات چیدمان در تبلت شود. برای تأیید رفتار طرحبندیها و مؤلفههای خود، آزمایشهای رابط کاربری ایجاد کنید یا برای تأیید بصری طرحبندیها، آزمایشهای اسکرینشات بسازید.
مرمت دولتی
برنامههایی که در دستگاههایی مانند تبلتها اجرا میشوند بسیار بیشتر از برنامههای موجود در تلفنها چرخانده میشوند و اندازه آنها تغییر میکند. همچنین، تاشوها قابلیتهای نمایشگر جدیدی مانند تا کردن و باز کردن را ارائه میکنند که میتواند باعث تغییرات پیکربندی شود. وقتی این تغییرات پیکربندی رخ می دهد، برنامه شما باید بتواند وضعیت را بازیابی کند. سپس باید آزمایش هایی بنویسید که وضعیت بازیابی برنامه شما را به درستی تأیید کند.
شکل 2. دستگاه تاشو تا شده، مسطح باز، تخت باز چرخیده به منظره، و نیمه باز (رومیزی).
ابتدا، آزمایش کنید که برنامه شما در هنگام ایجاد تغییرات پیکربندی از کار نرود. اطمینان حاصل کنید که هر رابط کاربری در برنامه شما می تواند هر ترکیبی از چرخش، تغییر اندازه یا تا کردن را انجام دهد. از آنجایی که تغییرات پیکربندی به طور پیش فرض فعالیت را دوباره ایجاد می کند، برخی از خرابی ها به دلیل فرضیات تداوم فعالیت رخ می دهد.
چندین روش برای آزمایش تغییرات پیکربندی وجود دارد، اما در بیشتر موارد، دو راه برای آزمایش وجود دارد:
در Compose، از StateRestorationTester برای شبیه سازی یک تغییر پیکربندی به روشی کارآمد بدون شروع مجدد فعالیت استفاده کنید. برای اطلاعات بیشتر به بخش های زیر مراجعه کنید.
در هر تست UI مانند Espresso یا Compose، با فراخوانی Activity.recreate() یک تغییر پیکربندی را شبیه سازی کنید.
معمولاً لازم نیست از دستگاه های مختلف برای آزمایش بازیابی حالت در پاسخ به تغییرات پیکربندی استفاده کنید. این به این دلیل است که همه تغییرات پیکربندی که فعالیت را دوباره ایجاد میکنند، پیامدهای مشابهی دارند. با این حال، برخی از تغییرات پیکربندی ممکن است مکانیسمهای بازسازی حالت مختلف را در دستگاههای خاص ایجاد کند.
به عنوان مثال، زمانی که کاربر در حال مشاهده یک رابط کاربری با جزئیات فهرست بر روی یک صفحه تاشو باز است و دستگاه را تا میکند تا به صفحه نمایش جلویی جابجا شود، رابط کاربری معمولاً به صفحه جزئیات تغییر میکند. یک آزمایش خودکار باید این بازیابی حالت رابط کاربر، از جمله وضعیت ناوبری را پوشش دهد.
برای آزمایش تغییرات پیکربندی که در دستگاههایی که از یک نمایشگر به نمایشگر دیگر میروند یا وارد حالت چند پنجرهای میشوند، چندین گزینه دارید:
با استفاده از هر دستگاهی، اندازه صفحه را در طول آزمایش تغییر دهید. در بیشتر موارد، این همه مکانیسمهای بازیابی حالت را که باید تأیید کنید، فعال میکند. با این حال، این تست برای منطقی که وضعیتهای خاصی را در تاشوها تشخیص میدهد، کار نمیکند، زیرا تغییرات وضعیت باعث تغییر پیکربندی نمیشود.
با استفاده از دستگاه یا شبیهسازی که از ویژگیهایی که میخواهید آزمایش کنید پشتیبانی میکند، تغییرات پیکربندی مرتبط را فعال کنید. به عنوان مثال، یک تبلت یا تاشو را می توان با استفاده از دستگاه اسپرسو کنترل کرد تا در حالت افقی از حالت تا شده به صفحه باز حرکت کند. برای نمونهها، بخش دستگاه اسپرسوکتابخانه و ابزار را ببینید تا اندازههای مختلف صفحه نمایش را آزمایش کنید .
شکل 3. تا شدن و باز شدن دستگاه.
انواع تست برای اندازه های مختلف صفحه نمایش و پنجره
از نوع مناسب تست برای هر مورد استفاده استفاده کنید تا بررسی کنید که تست در فاکتورهای فرم مختلف به درستی کار می کند:
آزمایشهای رفتار رابط کاربری، بخشی از رابط کاربری برنامه را راهاندازی میکنند، مانند نمایش یک فعالیت. آزمونها تأیید میکنند که عناصر خاصی وجود دارند یا ویژگیهای خاصی دارند. آزمایش ها ممکن است به صورت اختیاری اقدامات کاربر شبیه سازی شده را انجام دهند. برای مشاهده، از اسپرسو استفاده کنید. Jetpack Compose APIهای آزمایشی خود را دارد. تست های رفتار رابط کاربری می توانند ابزاری یا محلی باشند. تستهای ابزاری روی دستگاهها یا شبیهسازها اجرا میشوند، در حالی که تستهای UI محلی روی Robolectric در JVM اجرا میشوند.
از تستهای رفتار رابط کاربری برای تأیید صحت اجرای ناوبری برنامه استفاده کنید. تست ها اقداماتی مانند کلیک و کشیدن انگشت را انجام می دهند. تست های رفتار رابط کاربری نیز وجود عناصر یا ویژگی های خاص را بررسی می کنند. برای اطلاعات بیشتر، به تستهای خودکار رابط کاربری مراجعه کنید.
تست های اسکرین شات از یک رابط کاربری یا مؤلفه عکس می گیرند و تصویر را با اسکرین شات تایید شده قبلی مقایسه می کنند. این یک راه بسیار موثر برای محافظت در برابر رگرسیون است، زیرا یک اسکرین شات می تواند تعداد زیادی از عناصر و ویژگی های بصری آن را پوشش دهد. می توانید تست های اسکرین شات را روی JVM یا دستگاه ها اجرا کنید. چندین چارچوب تست اسکرین شات موجود است. برای اطلاعات بیشتر، به تست های اسکرین شات مراجعه کنید.
در نهایت، ممکن است برای آزمایش عملکرد واحدهای منطقی که بسته به نوع دستگاه یا اندازه پنجره رفتار متفاوتی دارند، به تستهای واحد نیاز داشته باشید، اما تستهای واحد در این زمینه کمتر رایج هستند.
مراحل بعدی
برای اطلاعات بیشتر در مورد نحوه اجرای چک های موجود در این سند، به کتابخانه ها و ابزارها مراجعه کنید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-08-27 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","easyToUnderstand","thumb-up"],["مشکلم را برطرف کرد","solvedMyProblem","thumb-up"],["غیره","otherUp","thumb-up"]],[["اطلاعاتی که نیاز دارم وجود ندارد","missingTheInformationINeed","thumb-down"],["بیشازحد پیچیده/ مراحل بسیار زیاد","tooComplicatedTooManySteps","thumb-down"],["قدیمی","outOfDate","thumb-down"],["مشکل ترجمه","translationIssue","thumb-down"],["مشکل کد / نمونهها","samplesCodeIssue","thumb-down"],["غیره","otherDown","thumb-down"]],["تاریخ آخرین بهروزرسانی 2025-08-27 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# Test different screen and window sizes\n\nTesting is an integral part of the app development process. You usually run apps\non an emulator or device to manually verify that your code works as expected.\nHowever, manual testing is time consuming, susceptible to errors, and often\nunmanageable for apps that run on screens and devices of various sizes. The\nproblems of manual testing are most often the result of using a single device\nfor development. As a result, errors can go unnoticed on other devices with\ndifferent form factors.\n\nTo identify regressions on different window and screen sizes, implement\nautomated tests to verify that the behavior and look of your app is consistent\nacross different form factors. Automated tests identify issues early on,\nmitigating the risk of problems impacting the user experience.\n\nWhat to test\n------------\n\nWhen developing UIs made for different screen and window sizes, pay special\nattention to two aspects:\n\n1. How the visual attributes of the components and layouts are different on windows of different sizes\n2. How state is preserved across [configuration changes](/guide/topics/resources/runtime-changes)\n\n### Visual attributes\n\nWhether you customize UIs for different window sizes or not, you should verify\nthat the UIs are displayed correctly. Take into account widths and heights that\nare compact, medium, and extended. See [Window size classes](/develop/ui/compose/layouts/adaptive/window-size-classes) for the\nrecommended breakpoints.\n**Figure 1.** The \"For you\" screen in Now In Android in different window sizes\n\nAlso, your app might not render some components in your design system as\nexpected when their size constraints are stretched.\n\nIf your app has adaptive layouts for different window sizes, you should have\nautomated tests to prevent regressions. For example, fixing a margin on a phone\ncan lead to layout inconsistencies on a tablet. Create [UI tests](/training/testing/ui-tests) to verify\nthe behavior of your layouts and components, or construct screenshot tests to\nverify the layouts visually.\n\n### State restoration\n\nApps running on devices such as tablets are rotated and resized much more\nfrequently than apps on phones. Also, foldables introduce new display\ncapabilities, such as folding and unfolding, that can trigger [configuration\nchanges](/guide/topics/resources/runtime-changes). Your app needs to be able to restore state when these configuration\nchanges occur. You also then need to write tests that confirm your app restores\nstate correctly.\n**Figure 2.** Foldable device folded, open flat, open flat rotated to landscape, and half opened (tabletop).\n\nFirst, test that your app doesn't crash when configuration changes occur. Make\nsure that every UI in your app can handle any combination of rotating, resizing,\nor folding. Because configuration changes recreate the activity by default, some\ncrashes happen due to assumptions of activity persistence.\n\nThere are multiple ways to test configuration changes, but for most cases, there\nare two ways to test:\n\n- In Compose, use [`StateRestorationTester`](/training/testing/different-screens/tools#staterestorationtester) to simulate a configuration change in an efficient way without restarting the activity. See the following sections for more information.\n- In any UI test such as Espresso or Compose, simulate a configuration change by calling `Activity.recreate()`.\n\nYou generally don't have to use different devices to test state restoration in\nresponse to configuration changes. This is because all configuration changes\nthat recreate the activity have similar repercussions. However, some\nconfiguration changes might trigger different state restoration mechanisms on\nspecific devices.\n\nFor example, when a user is viewing a [list-detail UI](https://m3.material.io/foundations/layout/canonical-layouts/list-detail) on an open foldable\nand they fold the device to switch to the front display, the UI typically\nswitches to the detail page. An automated test should cover this restoration of\nthe UI state, including the navigation state.\n\nTo test configuration changes that happen on devices going from one display to\nanother or entering multi-window mode, you have multiple options:\n\n- Using any device, resize the screen during a test. In most cases, this triggers all the state restoration mechanisms that you need to verify. However, this test won't work for logic that detects specific postures in foldables, as posture changes don't trigger a configuration change.\n- Using a device or emulator that supports the features you want to test, trigger the related configuration changes. For example, a foldable or a tablet can be controlled using Espresso Device to move from folded to open flat in landscape. See the [Espresso Device](/training/testing/different-screens/tools#espresso-device) section of [Libraries and\n tools to test different screen sizes](/training/testing/different-screens/tools) for examples.\n\nYour browser doesn't support the video tag. **Figure 3.** Device folding and unfolding.\n\nTypes of tests for different screen and window sizes\n----------------------------------------------------\n\nUse the appropriate type of test for each use case to verify the test is working\ncorrectly across different form factors:\n\n- **UI behavior tests** launch some portion of the app UI, such as the display\n of an activity. The tests verify that certain elements exist or have\n specific attributes . The tests might optionally perform simulated user\n actions. For views, use [Espresso](/training/testing/espresso). Jetpack Compose has its own [testing\n APIs](/jetpack/compose/testing). UI behavior tests can be [instrumented](/training/testing/instrumented-tests) or [local](/training/testing/local-tests).\n Instrumented tests run on devices or emulators, while local UI tests run on\n [Robolectric](https://robolectric.org/) on the JVM.\n\n Use UI behavior tests to verify that an app's implementation of navigation\n is correct. The tests perform actions such as clicks and swipes. UI behavior\n tests also check the existence of certain elements or properties. For more\n information, see [Automate UI tests](/training/testing/ui-tests).\n- **Screenshot tests** take a screenshot of a UI or component and compare the\n image to a previously approved screenshot. This is a very effective way to\n protect against regressions, as a single screenshot can cover a large number\n of elements and its visual properties. You can run screenshot tests on the\n JVM or on devices. There are multiple screenshot test frameworks available.\n For more information, see [screenshot tests](/training/testing/screenshot).\n\nFinally, you might need unit tests to test the functionality of units of logic\nthat behave differently depending on the type of device or window size, but unit\ntests are less common in this area.\n\nNext steps\n----------\n\nFor more information about how to implement the checks contained in this\ndocument, see [Libraries and tools](/training/testing/different-screens/tools)."]]