קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
בדיקת האינטראקציות של המשתמשים עוזרת לוודא שהמשתמשים לא נתקלים בתוצאות לא צפויות או בחוויה גרועה במהלך האינטראקציה עם האפליקציה. כדאי לכם לפתח את ההרגל ליצור בדיקות של ממשק המשתמש (UI) אם אתם צריכים לוודא שממשק המשתמש של האפליקציה פועל בצורה תקינה.
אחת מהגישות לבדיקת ממשק המשתמש היא לבקש מבוחן אנושי לבצע קבוצה של פעולות משתמש באפליקציית היעד ולאמת שהיא פועלת בצורה תקינה. עם זאת, הגישה הידנית הזו עשויה לגזול זמן רב ולהוביל לשגיאות. גישה יעילה יותר היא לכתוב את בדיקות ממשק המשתמש כך שפעולות המשתמשים יבוצעו באופן אוטומטי. הגישה האוטומטית מאפשרת להריץ את הבדיקות במהירות ובאופן מהימן, באופן שניתן לחזור עליו.
בבדיקות ממשק המשתמש מופעלת אפליקציה (או חלק ממנה), מתבצעת הדמיה של אינטראקציות של משתמשים ובסוף בודקים שהאפליקציה הגיבה כראוי. אלה בדיקות שילוב שיכולות לנוע בין אימות ההתנהגות של רכיב קטן לבין בדיקת ניווט גדולה שעוברת על כל תהליך השימוש. הן שימושיות לזיהוי רגרסיות ולאימות התאימות לרמות API שונות ולמכשירים פיזיים שונים.
הרצת בדיקות ממשק משתמש
כדי להריץ בדיקות UI מוטמעות באמצעות Android Studio, מטמיעים את קוד הבדיקה בתיקיית בדיקה נפרדת של Android – src/androidTest/java. Android Gradle Plugin יוצר אפליקציית בדיקה על סמך קוד הבדיקה שלכם, ואז טוען את אפליקציית הבדיקה באותו מכשיר שבו נמצאת אפליקציית היעד. בקוד הבדיקה, אתם יכולים להשתמש במסגרות לבדיקת ממשק המשתמש כדי לדמות אינטראקציות של משתמשים באפליקציית היעד, כדי לבצע משימות בדיקה שמכסות תרחישים ספציפיים של שימוש.
אפשר גם להשתמש ב-Robolectric כדי להריץ בדיקות ממשק משתמש ב-JVM.
ארכיטקטורה והגדרת בדיקה
הארכיטקטורה של האפליקציה צריכה לאפשר לבדיקות להחליף חלקים ממנה לצורך בדיקת עותקים כפולים, וצריך להשתמש בספריות שמספקות כלי עזר לבדיקה. לדוגמה, אפשר להחליף מודול של מאגר נתונים בגרסה שלו שמאוחסנת בזיכרון, שמספקת לבדיקה נתונים מזויפים ודטרמיניסטיים.
איור 3: בדיקת ממשק משתמש על ידי החלפת יחסי התלות שלו במודלים מזויפים.
הגישה המומלצת להחלפת יחסי התלות היא החדרת תלות (dependency injection). אפשר ליצור מערכת משלכם באופן ידני, אבל מומלץ להשתמש למטרה הזו במסגרת DI כמו Hilt.
למה כדאי לבדוק ממשקי משתמש באופן אוטומטי?
אפליקציה ל-Android יכולה לטרגט אלפי מכשירים שונים ברמות API ובפורמטים שונים. רמת ההתאמה האישית הגבוהה שמערכת ההפעלה מספקת למשתמש עלולה לגרום לכך שהאפליקציה תעבור עיבוד שגוי או אפילו תאבד את יציבותה במכשירים מסוימים.
בדיקת ממשק המשתמש מאפשרת לבצע בדיקת תאימות, כדי לוודא את ההתנהגות של האפליקציה בהקשרים שונים. מומלץ להריץ את בדיקות ממשק המשתמש במכשירים שונים במובנים הבאים:
רמת ה-API: 21, 25 ו-30.
לוקאל: אנגלית, ערבית וסינית.
כיוון: לאורך, לרוחב.
בנוסף, אפליקציות צריכות לבדוק את ההתנהגות מעבר לטלפונים. מומלץ לבדוק את הנושא בטאבלטים, במכשירים מתקפלים ובמכשירים אחרים. מידע נוסף על בדיקה של מסכים בגדלים שונים
סוגי בדיקות ממשק המשתמש
בקטע הזה נסביר על שני סוגים של בדיקות ממשק משתמש:
בדיקות התנהגות מנתחות את היררכיית ממשק המשתמש כדי לבצע טענות נכוֹנוּת לגבי המאפיינים של רכיבי ממשק המשתמש.
בדיקות של צילומי מסך מצלמות צילומי מסך של ממשק משתמש ומשוותפות אותם לתמונות שאושרו בעבר.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-07-27 (שעון UTC).
[[["התוכן קל להבנה","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-07-27 (שעון UTC)."],[],[],null,["# Automate UI tests\n\nTesting user interactions helps ensure users don't encounter unexpected results\nor have a poor experience when interacting with your app. You should get into\nthe habit of creating user interface (UI) tests if you need to verify that the\nUI of your app is functioning correctly.\n\nOne approach to UI testing is to have a human tester perform a set of user\noperations on the target app and verify that it is behaving correctly. However,\nthis manual approach can be time-consuming and error-prone. A more efficient\napproach is to write your UI tests such that user actions are performed in an\nautomated way. The automated approach lets you run your tests quickly and\nreliably in a repeatable manner.\n\nUI tests launch an app (or part of it), then simulate user interactions, and\nfinally check that the app reacted appropriately. They are integration tests\nthat can range from verifying the behavior of a small component to a large\nnavigation test that traverses a whole user flow. They are useful to check for\nregressions and to verify compatibility with different API levels and physical\ndevices.\n\nRun UI tests\n------------\n\n- To run [instrumented](/training/testing/instrumented-tests) UI tests using Android Studio, you implement your test code in a separate Android test folder - `src/androidTest/java`. The [Android Gradle Plugin](/studio/releases/gradle-plugin) builds a test app based on your test code, then loads the test app on the same device as the target app. In your test code, you can use UI testing frameworks to simulate user interactions on the target app, in order to perform testing tasks that cover specific usage scenarios.\n- You can also use [Robolectric](/training/testing/local-tests/robolectric#ui-testing) to run UI tests on the JVM.\n\nArchitecture and test setup\n---------------------------\n\nThe architecture of your app should let tests replace parts of it for [testing\ndoubles](/training/testing/fundamentals/test-doubles) and you should use libraries that provide utilities to help with\ntesting. For example, you can replace a data repository module with an in-memory\nversion of it that provides fake, deterministic data to the test.\n\n\u003cbr /\u003e\n\n**Figure 3**: Testing a UI by replacing its dependencies with fakes.\n\n\u003cbr /\u003e\n\nThe recommended approach to replace dependencies is dependency injection. You\ncan create your own system [manually](/training/dependency-injection/manual) but we recommend using a DI framework\nlike [Hilt](/training/dependency-injection/hilt-android) for this.\n\nWhy test UIs automatically?\n---------------------------\n\nAn Android app can target thousands of different devices across many API levels\nand form factors, and the high level of customization that the OS brings to the\nuser means your app could be rendered incorrectly or even crash on some devices.\n\nUI testing lets you do *compatibility testing*, verifying the behavior of an app\nin different contexts. You might want to run your UI tests on devices that vary\nin the following ways:\n\n- **API level**: 21, 25, and 30.\n- **Locale**: English, Arabic, and Chinese.\n- **Orientation**: Portrait, landscape.\n\nMoreover, apps should check the behavior beyond phones. You should test on\ntablets, foldables, and other devices. Read more about [testing different screen\nsizes](/training/testing/different-screens).\n\nTypes of UI Tests\n-----------------\n\nThis section covers two types of UI tests:\n\n- [Behavior tests](/training/testing/ui-tests/behavior) analyze the UI hierarchy to make assertions on the properties of the UI elements.\n- [Screenshot tests](/training/testing/ui-tests/screenshot) take screenshots of a UI and compares them with a previously-approved images."]]
