בדיקת ממשק משתמש חשובה מאי פעם הודות לעלייה עולמית באתרים ובאפליקציות, ומגמת ההיפר-אוטומציה (שטבעה גרטנר כדי לקבוע שכל מה שניתן לבצע אוטומטית יהיה אוטומטי). אם אתה משיק תוכנה חדשה או דף אינטרנט חדש, חיוני שתשיג את ממשק המשתמש (UI) נכון כדי לאזן בין פונקציונליות ואסתטיקה.
יש הרבה דברים שקשורים ליצירת ממשק משתמש משכנע, כאשר בדיקות ממשק משתמש משמשות כמבחן לקמוס כדי לקבוע אם הממשק פוגע בכל הסימנים או לא.
במאמר זה, נעבור על כל תחומי המפתח הקשורים לבדיקת ממשק משתמש, החל מהגדרה מהו ממשק משתמש ועד הדרכים הטובות ביותר לבדוק את ממשק המשתמש שלך.
ממשק משתמש לעומת ממשק משתמש: מנקה את הבלבול
כדי להתחיל, בואו ננסה לנקות כל בלבול סביב המונחים UI ו-GUI. להלן פירוט של משמעות שני המונחים הללו והיכן הם שונים:
1. מהי בדיקת ממשק משתמש?
ממשק המשתמש, או ממשק המשתמש, הוא הפלטפורמה שבה אתה משתמש כדי ליצור אינטראקציה עם תוכנה מסוימת. ממשק המשתמש הוא המקום שבו אתה יכול להזין הוראות, להזין נתונים או להציג מידע ממסך או צג.
ישנם סוגים רבים ושונים של ממשק משתמש, כולל ממשקי משתמש גרפיים (GUI) וממשקי שורת פקודה שמציגים רק קוד וטקסט.
2. מהו ממשק משתמש גרפי (GUI)?
ממשק המשתמש הגרפי (GUI) הוא סוג של ממשק משתמש שרוב האנשים מכירים. זהו סוג של ממשק המשתמש בוויזואליות כדי לעזור לנו לקיים אינטראקציה עם תכונות במערכת.
לדוגמה, תוכל להשתמש בתפריטים או בסרגלי כלים הכוללים סמלים כדי לעזור לך לנווט במערכת. אפילו טקסט עובד היטב בממשקי GUI כדרך להדריך את המשתמש דרך פונקציה, כגון לחיצה על ‘קובץ’ כאשר אתה רוצה לפתוח או לשמור מסמך.
3. ממשק משתמש לעומת ממשק משתמש
כדי לעזור לך להבין טוב יותר את שתי הצורות הללו של אינטראקציה עם מחשב, עיין בהשוואה הישירה בין ממשק משתמש לעומת GUI להלן:
ממשק משתמש:
• קיצור של ממשק משתמש
• זהו סוג של פלטפורמה המאפשרת למשתמשים ליצור אינטראקציה עם מכשירים
• זוהי צורה של אינטראקציה בין אדם למכונה
• הוא משמש את כולם ולעיתים קרובות עובד ברקע, כך שאתה לא יודע שאתה משתמש בו
• דוגמאות נפוצות כוללות MS-DOS או Unix
ממשק משתמש:
• קיצור של ממשק משתמש גרפי
• זהו סוג של פלטפורמה המשתמשת בגרפיקה כדי לעזור למשתמשים לנווט בפונקציות של מכשיר
• זוהי תת-מחלקה של ממשק משתמש
• הוא משמש בדרך כלל על ידי משתמשים ממוצעים יומיומיים כגון צרכנים
• דוגמאות נפוצות כוללות Windows 10, iOS ו-Android
מהי בדיקת ממשק משתמש (UI)?
בדיקת ממשק משתמש (UI), המכונה לעיתים בדיקת GUI בהתאם להקשר, היא סדרה של פעולות המשמשות למדידת הביצועים והפונקציונליות הכוללת של האלמנטים החזותיים של האפליקציה. הוא מחפש לאמת ולאמת פונקציות שונות של ממשק המשתמש ומבטיח שלא יהיו תוצאות בלתי צפויות, פגמים או באגים.
בדיקת ממשק משתמש באמצעות כלים כמו ZAPTEST משמשת בעיקר כדי לבדוק דברים כמו שימושיות, פונקציונליות וביצועים של ממשק המשתמש כדי לוודא שהוא מתאים למטרה.
במקרים מסוימים, הוא גם בודק דברים כמו התאמה או אחדות ויזואלית עם תפיסות העיצוב הכוללות של המערכת.
מתי ולמה אתה צריך מבחני ממשק משתמש?
בדיקת ממשק משתמש היא בדרך כלל היעילה ביותר לפני שחרור האפליקציה לייצור. זאת כדי להבטיח שלמשתמש הקצה תהיה החוויה הטובה ביותר, עם כמה שפחות באגים ופגמים.
משתמשי קצה אינם מייצרים את בודקי התוכנה הטובים ביותר, ולכן חשוב לברר את כל הבעיות לפני שהיא מגיעה אליהם.
בדיקת ממשק משתמש היא דרך שימושית להעריך כיצד האפליקציה מתמודדת עם פעולות מסוימות, כמו שימוש במקלדת ועכבר לאינטראקציה עם תפריטים. זה עוזר לבדוק את האלמנטים החזותיים של האפליקציה כדי לוודא שהם מוצגים כהלכה.
בדיקת ממשק משתמש היא גם דרך מצוינת לאמוד ביצועים ולוודא שאין באגים או בעיות עם הפונקציונליות של האפליקציה.
סוגי מבחני UI
יש מגוון של מבחני ממשק משתמש שונים שיש לקחת בחשבון בהתאם לאפליקציה הנבדקת.
למבחני ממשק משתמש יש פוטנציאל לאמת פונקציות רבות באפליקציות, כך שבחירה בסוג הבדיקה הנכון יכולה לסייע בזיהוי בעיות ספציפיות.
במילים אחרות, ישנן שיטות שונות של בדיקת ממשק משתמש לשקול, וכלים כמו תוכנת RPA של ZAPTEST וכלי בדיקת ממשק משתמש אוטומטיים, תלוי מה אתה מתכוון לבדוק.
כמה מהמתודולוגיות הנפוצות ביותר לבדיקות פונקציונליות ולא פונקציונליות, כוללות את הדברים הבאים:
1. בדיקת רגרסיה
בדיקת רגרסיה היא סוג של בדיקת ממשק משתמש שבוחנת כל שינוי בקידוד האפליקציה או האתר.
זה מבטיח שכל הפונקציונליות של האפליקציה היא כפי שנועדה לאחר ביצוע שינויים בחלקים מהקוד.
זה לא צריך לעשות שום בדיקות מפוארות, זה רק מריץ את הקוד כדי לוודא שכל התלות והפונקציות פועלות באותה צורה שבה עשו לפני ביצוע השינויים.
2. בדיקה פונקציונלית
בדיקה פונקציונלית מנסה לאמת את האפליקציה כדי לוודא שהיא עומדת בכל הדרישות הפונקציונליות.
הוא בודק את כל הפונקציות הבודדות של האפליקציה ואז מאמת את התוצאה כדי לוודא שהיא פועלת כצפוי.
סוג זה של בדיקות ממשק משתמש מתמקד בדרך כלל בבדיקת קופסה שחורה, שאינה מסתכלת על אף אחד מקוד המקור. בדיקות פונקציונליות נוטות לבדוק דברים כמו ממשק המשתמש, כל ממשק API משויך, תקשורת או אבטחה של לקוח ושרת.
3. בדיקת קבלה
בדיקת קבלה, המכונה לפעמים בדיקת קבלת משתמש (UAT) היא סוג של בדיקת ממשק משתמש המבוצעת על ידי משתמש הקצה של האפליקציה כדי לאמת את המערכת לפני המעבר לייצור.
סוג זה של בדיקות ממשק משתמש נמצא לרוב בשלבים האחרונים של הבדיקה לאחר אימות התחומים האחרים.
בדיקות קבלה משמשות לאימות הזרימה הכוללת של האפליקציה מתחילתה ועד סופה. זה לא בוחן בעיות ברמת השטח כמו שגיאות כתיב או בעיות אסתטיות. הוא משתמש בסביבת בדיקה נפרדת כדי לחקות את סביבת הייצור, ומבטיח שהיא מוכנה לעבור לשלב הבא.
4. בדיקת יחידות
בדיקת יחידה מחפשת לבדוק רכיבים בודדים של אפליקציה כדי לאמת שהיא פועלת כמתוכנן.
זה מבוצע בדרך כלל בשלב הקידוד, כך שבדרך כלל זה נופל על מפתחים וכלי בדיקת ממשק המשתמש שלהם לבצע סוג זה של בדיקת ממשק משתמש.
בדיקת יחידות פועלת על ידי הפרדת קטע קוד כדי לוודא שהוא פועל כמצופה. פיסת קוד בודדת זו עשויה להיות מודול ספציפי, פונקציה, אובייקט או כל חלק אחר של האפליקציה.
5. בדיקת ביצועים
בדיקות ביצועים ומבחני עומס נועדו להעריך את האופטימיזציה של האפליקציה, תוך בחינת דברים כמו מהירות, יציבות, תגובתיות ומדרגיות של האפליקציה בעת השימוש.
סוג זה של בדיקות ממשק משתמש נועד למצוא אזורים של דאגה באפליקציה או צווארי בקבוק בזרימת הנתונים. שלושת התחומים העיקריים שבהם מסתכלים כלי בדיקת ביצועים הם מהירות, מדרגיות ויציבות של האפליקציה.
6. בדיקת GUI
כלי בדיקת GUI מחפשים לבדוק את ממשק המשתמש הגרפי של אפליקציה כדי לוודא שכל הפונקציונליות פועלת כמצופה.
זה כולל הסתכלות על הנכסים הגרפיים והפקדים של האפליקציה, כגון לחצנים, סרגלי כלים ואייקונים. ה-GUI הוא מה שמשתמש הקצה מקיים איתו אינטראקציה ורואה בעת שימוש באפליקציה.
מהם היתרונות של בדיקת ממשק משתמש?
ישנם מספר יתרונות הקשורים לבדיקות ממשק משתמש ושימוש בכלים כמו חבילת בדיקות ממשק המשתמש של ZAPTEST, הן עבור המפתח והן עבור משתמש הקצה.
להלן כמה מהיתרונות המרכזיים הקשורים לבדיקות ממשק משתמש:
1. זה משפר את הפונקציונליות
חשוב לבדוק אפליקציות כדי לוודא שהן פועלות כמצופה, כך שאם יש תקלות, באגים או בעיות אחרות ניתן לטפל בהן לפני השחרור.
אם אפליקציה עושה את דרכה אל משתמשי הקצה והיא בעייתית, מלאה בשגיאות או מקולקלת אז היא לא תעשה את העבודה שמצופה ממנה. זה, בתורו, יוצר יותר מדי בעיות עבור משתמשי קצה וסביר להניח שהם יפסיקו להשתמש בו.
2. זה מקל על השימוש
כלי אוטומציה לבדיקת ממשק משתמש הם גם דרך מועילה לייעל ולייעל את האפליקציה.
גם אם כל הקידוד עובד כמו שצריך, ממשק מעוצב בצורה גרועה יכול לבלבל את משתמשי הקצה ולכבות אותם במהירות, ולהוריד את שיעורי האימוץ של האפליקציה. בדיקת ממשק משתמש היא דרך מצוינת לגהץ כל אחד מהאלמנטים או בחירות העיצוב כך שיהיה קל יותר לשימוש.
3. זה מחזק את המוניטין של האפליקציה
הקדשת הזמן לביצוע נכון של בדיקות ממשק משתמש והבאת כלים כמו תוכנת אוטומציית הבדיקות של ZAPTEST הן דרכים מצוינות ללטש את האפליקציה ולהפוך אותה לידידותית ככל האפשר.
כאשר נעשה בצורה נכונה, זה הופך את האפליקציה לשגרירת מותג נהדרת, מה שמגביר את המוניטין הכולל שלה. אם האפליקציה פועלת ללא באגים ועושה את כל מה שהיא אמורה לעשות, המשתמשים יעריכו זאת וישתמשו באפליקציה.
מהם האתגרים העיקריים של בדיקת ממשק משתמש?
למרות שבדיקת ממשק משתמש היא חלק חשוב בפיתוח יישומים, זה לא בהכרח חלק קל בתהליך.
ישנם מספר בעיות ואתגרים הקשורים לתוכנת אוטומציה חינמית לבדיקות ממשק המשתמש שהופכות זאת למשימה קשה.
להלן כמה מהאתגרים העיקריים הקשורים לבדיקת ממשק משתמש בעת שימוש בכלי בדיקת ממשק משתמש לא נאותים:
1. עדכוני ממשק משתמש
פיתוח אפליקציות הוא בדרך כלל תהליך איטרטיבי שמביא תכונות ופונקציות חדשות לאורך מחזור הפיתוח ומעבר לו.
כל השינויים הספורדיים הללו יכולים להקשות על ביצוע בדיקות ממשק משתמש ביעילות, שכן תלות ואינטראקציות קוד אחרות משנות את מה שנבדק.
2. בדיקה שגדלה במורכבות
אפליקציות ואתרי אינטרנט הרבה יותר מתוחכמים כיום מאשר אפילו לפני כמה שנים. עם כל הפונקציונליות הנוספת הזו, כלי בדיקת ממשק משתמש ותוכנת אוטומציה של ממשק משתמש צריכים לבדוק אלמנטים ותהליכים נוספים.
כתוצאה מכך, יש להתאים רבים מהכלים בבדיקת ממשק משתמש כדי להכיל את כל התוספות המורכבות הללו.
3. אילוצי זמן
ככל שיישומים גדלים במורכבות, כך גם הכלים המשמשים לבדיקה הולכים וגדלים. סקריפטים לבדיקת ממשק משתמש הופכים לגוזלים הרבה יותר זמן בגלל נפח הקוד הרב שיש לבדוק. בעיה זו מתחזקת כאשר כלי בדיקת ממשק המשתמש הנכונים אינם זמינים.
4. שמירה על סקריפטים של ממשק משתמש מעודכנים
ככל שממשק המשתמש משתנה ופונקציונליות חדשה מוכנסת, יש להתאים סקריפטים לבדיקה כדי לבדוק את התהליכים החדשים. זה הופך למאתגר יותר עם כל תוספת חדשה, מכיוון שסקריפטים לבדיקה מתעדכנים ומתעדכנים כל הזמן כדי להתאים לפונקציונליות החדשה.
האם כדאי להפוך בדיקות ממשק משתמש לאוטומטיות?
כשזה מגיע להחלטה על הגישה הטובה ביותר לבדיקת אפליקציות לנייד או לממשק משתמש באינטרנט , יש שני מסלולים שונים שיש לשקול – בדיקה ידנית או בדיקות ממשק משתמש אוטומטיות באמצעות כלים אוטומטיים . גם לבדיקות ידניות וגם לאוטומציה של ממשק המשתמש יש יתרונות וחסרונות משלהם, לכן כדאי לשקול את שניהם כדי לראות איזה מהם מתאים ביותר לאפליקציה.
מהי בדיקת ממשק משתמש ידנית?
בדיקה ידנית, בניגוד לאוטומציה של ממשק משתמש, כוללת שימוש בבוחן כדי ליצור אינטראקציה ידנית עם כל התכונות שנמצאות באפליקציה או באתר ולבדוק אותן באופן ידני.
המטרה העיקרית שלהם היא לחפש בעיות, אי סדרים או בעיות ביישום הכולל. זוהי אפשרות שימושית במיוחד עבור יישומים קטנים יותר עם רכיבים מוגבלים, כמו אלה שנמצאו בגרסאות מוקדמות של יישומים.
1. היתרונות של בדיקה ידנית של ממשק משתמש
ישנם יתרונות רבים של בחירה בבדיקה ידנית של ממשק משתמש, בהתאם לאפליקציה ולעיצוב שלה.
להלן כמה מהיתרונות הקשורים לבדיקות ידניות של ממשק המשתמש:
• בדיקת ממשק משתמש ידנית משלבת אינטליגנציה אנושית בבדיקות כדי לחפש שגיאות או בעיות. יש דברים שבדיקת ממשק משתמש אוטומטית פשוט לא יכולה להשיג וצריך אינטראקציה אנושית, חשיבה ביקורתית והאלמנט האנושי כדי למצוא את כל הליקויים ביישומים.
• בדיקות אוטומטיות יכולות להיות די גוזלות זמן, מכיוון שהן משחזרות תרחישים מרובים עבור מאפיינים שונים שיש לאמת על ידי בודק אנושי. בדיקת ממשק משתמש ידנית מאפשרת לבודקים אנושיים להתמקד באיתור תקלות במקום בהגדרת אמולציות.
• בודקים אנושיים נוטים להיות בעלי ידע אינטימי של האפליקציה, ולרוב מבלים אינספור שעות להתרגל לממשק. זה בגלל זה שהם מבינים ממה צריך לשים לב מבחינת שגיאות תוך שהם עוזרים להם להישאר מעודכנים לגבי המצב הנוכחי של האפליקציה.
• ישנן בעיות שאולי לא יסומנו על ידי בדיקת ממשק משתמש אוטומטית מכיוון שהיא אינה משפיעה על הקוד. דברים כמו זמני תגובה של שרת עשויים להיות בפיגור, אך ניתן להתעלם מהם בקלות על ידי בדיקה אוטומטית. בדיקת ממשק משתמש ידנית מסירה בעיה זו מכיוון שהמשתמש האנושי מבחין בבעיות אלו באופן מיידי.
• בדיקת ממשק משתמש ידנית היא האמולציה המדויקת ביותר של חווית המשתמש, מכיוון שאתה מגדיר מצב המשקף את אופן האינטראקציה של משתמש הקצה עם האפליקציה. זה יוצר הקשר בעולם האמיתי למציאת בעיות שנמצאות בדרך כלל על ידי משתמשי קצה, אבל אולי מחמיצים על ידי בדיקות ממשק משתמש אוטומטיות.
2. מגבלות של בדיקת ממשק משתמש ידנית
ישנן גם מגבלות לבדיקת ממשק משתמש ידנית שיש לקחת בחשבון לפני קבלת החלטה על גישת הבדיקה הטובה ביותר עבור היישום שלך.
חלק מהמגבלות של מבחני ממשק משתמש ידניים כוללות את הדברים הבאים:
• ביצוע בדיקות ידניות לוקח הרבה יותר זמן מאשר בדיקות ממשק משתמש אוטומטיות, במיוחד בעת שימוש בכלים מודרניים כמו היפר-אוטומציה . סקריפטים לבדיקות אוטומטיות יכולים לרוץ הרבה יותר מהר מכל סוג של קלט אנושי, כך שבחירה בבדיקת ממשק משתמש ידנית באינטרנט מוסיפה שעות נוספות ללוח הזמנים.
• מכיוון שזהו בסופו של דבר תהליך אנושי, בדיקת ממשק משתמש ידנית באינטרנט מועדת לטעות אנוש. באגים שפספסו בגלל חוסר מיקוד או הסחת דעת יכולים לקרות עם בדיקות ממשק משתמש ידניות, מה שעלול להוביל לבעיות. באופן השוואתי, בדיקת ממשק משתמש אוטומטית מסירה את האלמנט האנושי מהתהליך, מה שהופך אותו להרבה פחות מועד לבעיות מסוג זה. זה נכון במיוחד עבור הסוגים האחרונים של בדיקות אוטומטיות של ממשק משתמש, כגון אוטומציה רובוטית של תהליכים .
• התהליך בפועל של רישום שגיאות שנמצאו לוקח הרבה יותר זמן, מה שעלול להקשות על מעקב אחר שינויים כלשהם תוך כדי ביצועם. בדיקת ממשק משתמש אוטומטית היא גישה טובה יותר כאן מכיוון שהיא דורשת עדכון רק אם תכונה חדשה מיושמת.
• בדיקת ממשק משתמש ידנית דורשת ידע אינטימי של האפליקציה כדי לבדוק בעיות בצורה מוכשרת. כתוצאה מכך, יש רמה מסוימת של ידע הנדרשת על ידי בודקים אנושיים לפני שהם יכולים לבדוק ביעילות. בדיקות אוטומטיות ו- RPA לא דורשות רמת ידע זו.
3. בדיקות הקלטה והפעלה חוזרת
בדיקת הקלטה והפעלה חוזרת היא סוג של בדיקת ממשק משתמש ללא קוד המאפשרת לך להריץ בדיקות ללא כל ידע תכנות מעמיק. הוא משתמש בפונקציונליות ולעתים קרובות בטכנולוגיית ראייה ממוחשבת כדי להקליט פעולות ידניות שבוצעו באפליקציה לפני שמירתו כתבנית בדיקה.
זה מאפשר להריץ את מבחן ה-UI שוב ושוב ללא מעורבות אנושית.
4. ידני לעומת הקלטה והפעלה חוזרת לעומת בדיקות אוטומציה
כאשר מחליטים בין שלושת הסוגים הללו של בדיקות ממשק משתמש, חשוב לקחת בחשבון את ההיקף וההיקף של האפליקציה ואת המשאבים הזמינים.
בדיקת ממשק משתמש ידנית היא הקלה ביותר להגדרה ולשימוש, אבל יש לה הרבה דרישות כמו ידע טוב של הבוחנים באפליקציה. קשה גם להמשיך בבדיקת ממשק משתמש ידנית אם אתה כל הזמן מעדכן אפליקציה.
כלי אוטומציה של בדיקות ממשק משתמש כמו אלה שמציעים ZAPTEST הם אפשרות מצוינת אם אתה מתכוון לבצע עדכונים קבועים באפליקציה, ועם הזמן זה משתלם שכן הם מאמצים עקרונות זריזות .
הקלטה והפעלה חוזרת נכנסים לפעולה כדי לגשר על הפער בין שני סוגי בדיקות ממשק המשתמש. הוא מציע רמה בסיסית של אוטומציה של ממשק המשתמש אך עדיין דורש קלט אנושי כדי להפעיל אותו.
מה אתה בודק בעת ביצוע בדיקות ממשק משתמש?
מה אתה בודק בעת ביצוע בדיקות UI באמצעות כלים כגון תוכנת בדיקת UI של ZAPTEST עומד להשתנות בהתאם למה שהאפליקציה מכילה.
עם זאת, הוא נוטה לעקוב אחר הפונקציונליות של האפליקציה. לדוגמה, אם לאפליקציה יש דף תשלום, בדיקת ממשק משתמש תכלול דברים כמו בדיקת כפתור ‘קנה עכשיו’.
למרות שהתהליכים בפועל לבדיקה משתנים מיישום ליישום, יש מספר דברים כלליים של ממשק המשתמש שצריך לבדוק, כגון:
1. שגיאות בסוגי נתונים
מבחן ממשק משתמש זה מבטיח שסוג הנתונים הנכון פועל בשדות המתאימים. לדוגמה, טקסט לשמות ללא אפשרות להשתמש במספרים. אם בודק ממשק המשתמש יכול להזין ערכים מספריים תחת שדה השם, אז משהו לא בסדר.
2. בעיות רוחב שדה
זה משמש כדי להגביל את ספירת התווים עבור שדות מסוימים, כגון מיקוד. אם האפליקציה לא מגבילה את ספירת התווים של שדות אלה, הדבר עלול לגרום לקלט לא חוקי ממשתמש הקצה.
3. כפתורים
בדיקות UI אלו מוודאות שכפתורים פועלים כהלכה, כך למשל כפתור Next page מפנה את משתמש הקצה לעמוד הבא. ישנם המון סוגי כפתורים שונים עם מטרות שונות, לכן חשוב שהם יעשו את העבודה שהם אמורים לעשות כדי ליצור אפליקציה פונקציונלית.
4. גלילה בטבלה
אם ישנן טבלאות כלשהן עם נתונים באפליקציה, גלילה בטבלה מבטיחה שתוכלו לגלול בין הנתונים תוך שמירה על הכותרות גלויות.
אם זה לא עובד, זה מבלבל את הנתונים עבור משתמש הקצה.
5. יומני שגיאות
במקרה של קריסת אפליקציה או שגיאה, חשוב לבדוק את יומני השגיאות כדי לוודא שהם מספקים פלט מדויק עבור דוחות באגים.
ללא דיווח באגים מדויק ויומני שגיאות, אין דרך טובה לקבוע מה גורם לבעיה או כיצד לתקן אותה.
איך מבצעים בדיקת ממשק משתמש (GUI)?
כדי לתת לך מושג טוב כיצד לבצע בדיקת ממשק משתמש – או GUI – ניצור לך דוגמה להסתכל עליה.
נניח שאנחנו הולכים לבדוק דף טופס באפליקציה לרישום חשבון. ישנם מספר רכיבי ממשק משתמש לבדיקה בדף זה, המסומנים TC-X (כאשר TC מייצג מקרה מבחן וה-X מציין את מספר הרכיב).
להלן רשימה של ה-TC’s הזמינים לבדיקה עבורם:
TC-1: לוגו המותג בחלק העליון של המסך
• יש לבדוק את זה כדי לבדוק שהוא מציג את המיקום הנכון, את סוג הגופן ואת תווית העמוד.
TC-2: רשום את חשבונך
• זה אמור לבדוק שכותרת העמוד מדויקת.
• עליו לבדוק גם שהגופן הנכון מוצג.
TC-3: שדה שם פרטי
• זה אמור לבדוק את היישור והמיקום הנכון של תיבת הטקסט.
• עליו לבדוק גם את תוויות השדה ולבדוק שהוא מקבל ערכים תקפים ומסרבים ערכים לא חוקיים.
TC-4: שדה שם משפחה
• זה אמור לבדוק את היישור והמיקום הנכון של תיבת הטקסט.
• עליו לבדוק גם את תוויות השדה ולבדוק שהוא מקבל ערכים תקפים ומסרבים ערכים לא חוקיים.
TC-5: שדה שם משתמש
• זה אמור לבדוק איזו הודעת שגיאה מוצגת בעת הזנת תווים מוגבלים.
• עליו לבדוק גם שהודעת השגיאה תקפה ומדויקת.
TC-6: שדה סיסמה
• זה אמור לבדוק את תוויות השדות כדי לוודא שהוא מקבל תווים חוקיים ודוחה תווים לא חוקיים.
• עליו לבדוק גם את היישור והמיקום של תיבת הטקסט.
TC-7: לחצן העמוד הבא
• זה אמור לבדוק שהגשת הטופס פועלת כמתוכנן.
• עליו גם לבדוק את מיקום הכפתור ולוודא שהוא קריא למשתמש.
תוכנית בדיקת ממשק משתמש – מה זה?
תוכנית בדיקת ממשק משתמש היא מסמך המהווה חלק מתהליך הבדיקה של יישומים.
תוכנית הבדיקה של ממשק המשתמש מפרקת מידע מרכזי על האפליקציה וכל פעילות בדיקה הקשורה אליה.
יצירת תוכנית בדיקה היא בדרך כלל אחד הצעדים הראשונים שאתה נוקט בעת בדיקת יישומים, שכן היא מניחה את הבסיס למתודולוגיות הבדיקה ולתוצאות המיועדות.
זהו מסמך שימושי שנותן לאלו מחוץ לצוות הבדיקות מושג טוב יותר על מה שקורה בתהליך. לכל TCOE רציני ( מרכז בדיקות למצוינות ) יהיה אחד כזה.
כיצד לכתוב תוכנית בדיקת ממשק משתמש
תוכניות בדיקת ממשק משתמש מציעות הדרכה והדרכה מצוינות עבור בודקי ממשק משתמש, כך שביצוע נכון באמת עוזר בבדיקה ובדיקת יישומים.
עיין בשלבים הבאים כדי ללמוד כיצד לכתוב תוכנית בדיקה של ממשק משתמש:
1. כלול מידע מפתח לגבי בדיקת ממשק המשתמש
תוכנית בדיקת ממשק משתמש כוללת את כל המידע המרכזי הנדרש לביצוע בדיקות עבור אפליקציה. חלק מהמידע הזה כולל את הדברים הבאים:
• אנשי המקצוע הנדרשים לבדיקה, תפקידיהם וכישוריהם.
• משך הזמן הכולל הנדרש לבדיקת האפליקציה.
• טכניקות הבדיקה המיושמות בבדיקה, ותהליכי ניהול נתונים לבדיקה .
• כל המשאבים הנדרשים לבדיקה, כגון חומרה, תיעוד או כלים ספציפיים.
• פירוט של סביבות בדיקת היעד, כגון מכשירים ניידים, מערכת הפעלה ספציפית או דפדפנים.
• המטרות הכוללות של תהליך הבדיקה.
2. בדיקת עשן
לאחר מכן, תוכל להשתמש בבדיקות עשן כדי לעזור ביצירת תוכנית בדיקת ממשק משתמש. בדיקת עשן היא דרך שימושית לזהות בעיות ובאגים בסיסיים באפליקציה, אך היא לא מחפשת בעיות לעומק.
זוהי טכניקה המתאימה ביותר לבדיקת ממשק משתמש בשכבה העליונה של האפליקציה, כך שהיא יכולה לתפוס בעיות קשות למדי.
3. בדיקת שפיות
כדי לחפור עמוק יותר לתוך האפליקציה כדי למצוא באגים ותקלות פחות ברורים, בדיקת שפיות היא טכניקה מצוינת לביצוע בדיקות ממשק משתמש.
בדיקת שפיות מנסה לבדוק כל קידוד חדש או שונה כדי לוודא שהוא תואם את דרישות היישום.
זה נבדל מבדיקת עשן בכך שהוא הרבה יותר מקיף עם בדיקת ממשק משתמש, המאפשרת מבט מעמיק יותר על הפונקציונליות של האפליקציה.
לאחר שהאפליקציה עוברת בדיקת עשן, בדיקת השפיות מוסיפה רמת בדיקה נוספת.
תרחישי בדיקת ממשק משתמש
כדי להבטיח שהאפליקציה פועלת כמתוכנן על פני מספר אזורים ואינטראקציות, חשוב לבצע תרחישים שונים של בדיקת ממשק משתמש.
להלן פירוט של תרחישי בדיקת ממשק המשתמש, עם דוגמה.
1. מהם תרחישי בדיקת ממשק המשתמש?
תרחיש בדיקת ממשק משתמש הוא דרך ליצור תיעוד עבור מקרי שימוש מרובים באפליקציה.
תרחיש בדיקת ממשק משתמש משמש לתיאור הפעולות הספציפיות שמשתמש עשוי לבצע בזמן השימוש באפליקציה.
במקרים מסוימים, הוא גם מתאר תרחיש שמשתמש עלול להיתקל בו בזמן השימוש באפליקציה.
תרחישי בדיקת ממשק משתמש שימושיים מכיוון שהם מאמתים שהפונקציונליות בתוך אפליקציה פועלת כמצופה. נדרשת הבנה אינטימית של האפליקציה, ותשומות מלקוחות ומפתחים, כדי ליצור תרחישים שימושיים.
2. דוגמה לתרחישי בדיקת ממשק משתמש
כדוגמה, שקול תרחיש בדיקה עבור דף הכניסה של אפליקציה. תרחיש בדיקת ממשק משתמש עבור זה יבקש לענות על השאלות הבאות:
• האם משתמשים יכולים להיכנס לפלטפורמה באמצעות האישורים הנכונים?
• מהי התוצאה של שימוש באישורים שגויים לכניסה?
• מה קורה כאשר אתה משתמש בשם משתמש חוקי, אך בסיסמה לא חוקית?
• מה קורה כאשר משאירים את השדות ריקים ומנסים להיכנס?
• אם יש כפתור ‘שכחתי סיסמה’, מה קורה כשאתה לוחץ עליו?
• האם כל הקישורים בדף פועלים כמתוכנן?
מענה על שאלות אלו עוזר לבודקי ממשק המשתמש לזהות אזורים באפליקציה שאינם פועלים כפי שהם צריכים.
הוא גם בודק שכל הפעולות הזמינות מספקות תוצאה צפויה, כגון כניסה באמצעות האישורים הנכונים.
מקרי בדיקה של ממשק משתמש
כדי להסתכל על היבטים בודדים של תרחיש בדיקת ממשק משתמש, מקרי בדיקה משמשים לפירוק תכונות בודדות של חלקי פונקציונליות באפליקציה.
להלן סיכום של מקרי בדיקות ממשק משתמש עם דוגמאות.
1. מהם מקרי בדיקת ממשק משתמש?
מקרה בדיקה של ממשק משתמש הוא סדרה של פעולות המבוצעות כדי לאמת תכונה ספציפית או חלק של פונקציונליות בתוך אפליקציה.
מקרי בדיקה של ממשק המשתמש מפרקים שלבי בדיקה, נתונים, תנאי מוקדם ותנאי פוסט עבור תרחישים ספציפיים והם בודקים גם דרישות.
מקרה מבחן UI נוטה לכלול משתנים מאוד ספציפיים כדי לאפשר בדיקה מעמיקה ברמה יחידנית. בודקי ממשק המשתמש משווים את התוצאות בפועל עם התוצאה הצפויה כדי להבטיח שהאפליקציה פועלת בהתאם לדרישות.
2. דוגמאות למקרי בדיקה של ממשק משתמש ו-GUI
כדי לעזור לך להבין טוב יותר מקרי בדיקה של ממשק משתמש ו-GUI, עיין בדוגמאות שלהלן שהן מקרי בדיקה עבור תרחיש הבדיקה שבוחן את הפונקציונליות של מסך התחברות:
• בדוק את התנהגות המערכת בעת הזנת אישורים חוקיים.
• בדוק את התנהגות המערכת כאשר נעשה שימוש באימייל לא חוקי אך סיסמה חוקית.
• בדוק את התנהגות המערכת כאשר נעשה שימוש באימייל חוקי אך סיסמה לא חוקית.
• בדוק את התנהגות המערכת כאשר נעשה שימוש באימייל וסיסמה לא חוקיים.
• בדוק את התנהגות המערכת כאשר השדות נותרים ריקים.
• בדוק את הקישור ‘שכחתי סיסמה’ כדי לראות אם הוא מתנהג כמצופה.
• בדוק את התנהגות המערכת כאשר כפתור ‘שמור אותי מחובר’ מסומן.
• בדוק את התנהגות המערכת כאשר הוזן מספר טלפון לא חוקי.
אז כל הדוגמאות הללו הן מקרי בדיקה בודדים של ממשק משתמש.
בניגוד לתרחיש הבדיקה, המכסה את כל התהליך, מקרי בדיקה מסתכלים על הפונקציות הבודדות. במילים אחרות, כל דוגמה לעיל היא מקרה בדיקה של ממשק משתמש, כאשר כל הרשימה מסווגת כתרחיש בדיקה.
סקריפטים לבדיקת ממשק משתמש
כדי לקבל פירוט מפורט עוד יותר של בדיקות יישומים, נוצרים סקריפטים למבחן ממשק משתמש כדי לתת מידע נוסף לבודקים על מקרי בדיקה ותרחישים.
להלן תקציר של סקריפטים למבחן ממשק משתמש וכיצד לכתוב אותם.
1. מהם סקריפטים לבדיקת ממשק משתמש?
סקריפטים לבדיקת ממשק משתמש הם תיאורים מפורטים ביותר של בדיקות המתבצעות באפליקציה, בדרך כלל בשורה אחר שורה.
הם מאוד ספציפיים באופיים עם הרבה פרטים מבחינת מקרי הבדיקה שבהם נעשה שימוש, הנתונים והפונקציונליות הצפויה של האפליקציה.
כל תוצאות ממקרי בדיקה נכללות גם בתסריטי בדיקה כדי להוסיף לעושר המידע.
2. כיצד לכתוב סקריפטים למבחן UI
תסריטי בדיקה של ממשק המשתמש הם פשוטים מכיוון שהם פשוט מפרטים את מקרי הבדיקה.
כל עוד אתה כולל את המידע הבא בהם, אתה אמור להיות מסוגל להפיק ערך רב מתסריטי הבדיקה שלך בממשק המשתמש:
• מזהה סקריפט בדיקה: זהו המזהה הייחודי של סקריפט הבדיקה.
• כותרת: הכותרת של תסריט הבדיקה.
• מזהה מקרה מבחן: זהו המזהה של מקרה המבחן שעבורו אתה יוצר סקריפט.
• דרישות: אלו הם המפרטים של יישום החומרה הדרוש להפעלת מקרי הבדיקה.
• נוהל: אלו הם הצעדים שננקטו כדי להתקדם עם הבדיקה.
• תוצאה: זוהי הפלט והתוצאה הסופית של הבדיקה.
• סטטוס: זהו אינדיקציה להצלחת תסריט המבחן – האם הוא עבר או נכשל?
• קוד שגיאה: אם התרחשה בעיה, קוד השגיאה מפרט מה הייתה הבעיה.
רשימת בדיקה למבחני ממשק המשתמש שלך
כעת, כשאתה מוכן להתחיל עם בדיקות ממשק משתמש, השתמש ברשימת התיוג שלהלן כדי ליצור בדיקות משלך:
1. בדוק את הפונקציונליות הבסיסית
בדיקה פונקציונלית היא דרך מצוינת למצוא דברים כמו באגים חזותיים או תקלות בפלטפורמה.
הקפד לכלול דברים כמו ביומטריה, הודעות כלשהן ומידע על זיכרון יישומים בשלב זה.
2. בדוק תאימות בין פלטפורמות
כדי למנוע בעיות כמו פיצול מכשירים שחוסם משתמשים מסוימים מהאפליקציה, כדאי לבצע בדיקות תאימות בין פלטפורמות.
זה כולל בדיקת האפליקציה ברזולוציות מסך שונות.
מומלץ לבדוק תאימות של יישומים מקוריים וגם היברידיים במכשירים ניידים כגון אנדרואיד ו-iOS.
3. בדוק תאימות בין גדלי מסך שונים
ישנם גדלי מסך רבים ושונים שמשתמשי קצה עשויים לנסות להשתמש בהם עם האפליקציה, לכן חשוב לבדוק את ממשק המשתמש עבור אלה.
בדיקת תגובתיות ממשק משתמש מיושמת בצורה הטובה ביותר במכשירים העדכניים ביותר כדי לטפל בבעיות פוטנציאליות. כמו כן, זכור לבדוק גם במצב לרוחב וגם במצב דיוקן.
4. בדוק ביצועים ומדרגיות
כאשר לאפליקציה יש מדרגיות, היא מסוגלת לספק ביצועים מצוינים על פני פלטפורמות שונות.
בדוק רמות עומס שונות, תעבורה ותרחישים אחרים של משתמשי קצה כדי להעריך את הביצועים והמדרגיות של האפליקציה.
ניתן לעשות זאת באמצעות בדיקות מקבילות, המשתמשות בבדיקות ממשק משתמש אוטומטיות כמו אוטומציה רובוטית של תהליכים על פני מספר סביבות.
5. בדוק את נגישות האפליקציה
בדיקות נגישות מבטיחות שתכונות ספציפיות שנועדו לעזור למשתמשי הקצה לעבוד כמצופה. בדוק כאן דברים כמו גודל גופן, מצב קורא מסך ואפשרויות התקרבות.
6. בדוק צבעים וטקסט
יישומים צריכים להציג צבעים בצורה ספציפית, לכן חשוב לוודא זאת על ידי בדיקת ערכות צבעים.
זה כולל דברים כמו צבע של היפר-קישור או סוגי גופנים אחרים. זה גם שימושי לבדוק את הטקסט עבור בעיות באיות, גודל גופן ויישור.
7. הערכת מהירות הניווט
הקפד לבדוק שממשק המשתמש של האפליקציה פועל בצורה חלקה, ללא תקלות. דברים כמו מסך הטעינה לכותרות הם מקום טוב לחפש פיגור.
