אסטרטגיות בדיקה

בדיקות אוטומטיות עוזרות לשפר את איכות האפליקציה בכמה דרכים. לדוגמה, הוא עוזר לכם לבצע אימות, לזהות רגרסיות ולאמת תאימות. אסטרטגיית בדיקות טובה מאפשרת לכם לנצל את הבדיקות האוטומטיות כדי להתמקד ביתרון חשוב: הפריון של המפתחים.

צוותים משיגים רמות גבוהות יותר של פרודוקטיביות כשהם משתמשים בגישה שיטתית לבדיקות בשילוב עם שיפורים בתשתית. כך מקבלים משוב בזמן על אופן הפעולה של הקוד. אסטרטגיית בדיקה טובה כוללת את הפעולות הבאות:

• מזהה בעיות מוקדם ככל האפשר.
• הביצוע מהיר.
• האפליקציה מספקת אינדיקציות ברורות כשצריך לתקן משהו.

בדף הזה מוסבר אילו סוגי בדיקות כדאי להטמיע, איפה להריץ אותן ובאיזו תדירות.

android skills add testing-setup

פירמידת הבדיקות

אפשר לסווג בדיקות באפליקציות מודרניות לפי גודל. בבדיקות קטנות מתמקדים רק בחלק קטן של הקוד, ולכן הן מהירות ואמינות. לבדיקות גדולות יש היקף רחב והן דורשות הגדרות מורכבות יותר שקשה לתחזק. עם זאת, בדיקות גדולות הן מדויקות יותר*, ויכולות לגלות הרבה יותר בעיות בבת אחת.

*מהימנות מתייחסת לדמיון בין סביבת זמן הריצה של הבדיקה לבין סביבת הייצור.

ברוב האפליקציות כדאי להריץ הרבה בדיקות קטנות ומעט בדיקות גדולות יחסית. החלוקה של הבדיקות בכל קטגוריה צריכה להיות בצורת פירמידה, כאשר הבסיס מורכב מהבדיקות הקטנות הרבות והקצה מורכב מהבדיקות הגדולות המעטות.

מזעור העלות של באג

אסטרטגיית בדיקה טובה מאפשרת למפתחים להפיק את המרב מהעבודה שלהם, תוך צמצום העלות של איתור באגים.

דוגמה לאסטרטגיה לא יעילה: כאן, מספר הבדיקות לפי גודל לא מסודר בצורת פירמידה. יש יותר מדי בדיקות גדולות מקצה לקצה ומעט מדי בדיקות של רכיבי ממשק משתמש:

כלומר, לא מריצים מספיק בדיקות לפני המיזוג. אם יש באג, יכול להיות שהבדיקות לא יזהו אותו עד להרצת הבדיקות מקצה לקצה בלילה או מדי שבוע.

חשוב להבין את ההשלכות של זה על העלות של זיהוי באגים ותיקונם, ולמה חשוב להטות את מאמצי הבדיקה לכיוון של בדיקות קטנות ותכופות יותר:

• אם הבאג מתגלה על ידי בדיקת יחידה, בדרך כלל אפשר לתקן אותו תוך דקות, ולכן העלות נמוכה.
• בדיקת קצה לקצה עשויה להימשך ימים עד שהבאג יתגלה. כתוצאה מכך, יכול להיות שיהיו כמה חברי צוות שיעבדו על אותה בעיה, מה שיפגע בפרודוקטיביות הכוללת ויגרום לעיכוב בשחרור. העלות של הבאג הזה גבוהה יותר.

עם זאת, אסטרטגיית בדיקה לא יעילה עדיפה על היעדר אסטרטגיה בכלל. כשבאג מגיע לשלב הייצור, לוקח הרבה זמן עד שהתיקון מגיע למכשירים של המשתמשים, לפעמים שבועות, ולכן לולאת המשוב היא הארוכה והיקרה ביותר.

אסטרטגיית בדיקות שניתנת להרחבה

פירמידת הבדיקות מחולקת באופן מסורתי ל-3 קטגוריות:

• בדיקות יחידה
• בדיקות שילוב
• בדיקות מקצה לקצה.

עם זאת, אין הגדרות מדויקות למושגים האלה, ולכן יכול להיות שצוותים ירצו להגדיר את הקטגוריות שלהם בצורה שונה, למשל באמצעות 5 שכבות:

• בדיקת יחידה מופעלת במחשב המארח ומאמתת יחידה פונקציונלית אחת של לוגיקה ללא תלות במסגרת Android.
  • דוגמה: אימות שגיאות של הבדל של אחד בפונקציה מתמטית.
• בדיקת רכיב מאמתת את הפונקציונליות או את המראה של מודול או רכיב באופן עצמאי מרכיבים אחרים במערכת. בניגוד לבדיקות יחידה, תחום הפעולה של בדיקת רכיב מתרחב להפשטות גבוהות יותר מעל שיטות ומחלקות פרטניות.
  • דוגמה: בדיקת צילום מסך ללחצן בהתאמה אישית
• בדיקת תכונה מאמתת את האינטראקציה של שני רכיבים או מודולים בלתי תלויים או יותר. בדיקות תכונות הן גדולות ומורכבות יותר, ובדרך כלל הן פועלות ברמת התכונה.
  • דוגמה: בדיקות של התנהגות ממשק המשתמש שמאמתות את ניהול המצב במסך
• בדיקת אפליקציה מאמתת את הפונקציונליות של האפליקציה כולה בצורה של קובץ בינארי שניתן לפריסה. אלה בדיקות שילוב גדולות שמשתמשות בקובץ בינארי שאפשר לנפות בו באגים, כמו גרסת פיתוח שיכולה להכיל נקודות עצירה לבדיקה, כמערכת שנבדקת.
  • דוגמה: בדיקת התנהגות של ממשק משתמש כדי לאמת שינויים בהגדרות במכשיר מתקפל, בדיקות לוקליזציה ובדיקות נגישות
• בדיקה של גרסה מועמדת להפצה מאמתת את הפונקציונליות של גרסת build להפצה. הם דומים לבדיקות של אפליקציות, אבל קובץ הבינארי של האפליקציה עבר מיניפיקציה ואופטימיזציה. אלה בדיקות אינטגרציה מקיפות שמופעלות בסביבה שדומה ככל האפשר לסביבת הייצור, בלי לחשוף את האפליקציה לחשבונות משתמשים ציבוריים או למערכות עורפיות ציבוריות.
  • דוגמה: חוויות משתמשים הכרחיות, בדיקות ביצועים

הסיווג הזה מתבסס על נאמנות, זמן, היקף ורמת הבידוד. אפשר להריץ סוגים שונים של בדיקות בכמה שכבות. לדוגמה, שכבת הבדיקה של האפליקציה יכולה לכלול בדיקות התנהגות, צילומי מסך ובדיקות ביצועים.

החלטה על קטגוריית הבדיקה

ככלל, כדאי להתייחס לשכבה הנמוכה ביותר בפירמידה שיכולה לספק לצוות את רמת המשוב הנכונה.

לדוגמה, נניח שרוצים לבדוק את ההטמעה של התכונה הזו: ממשק המשתמש של תהליך הכניסה. בהתאם למה שרוצים לבדוק, בוחרים קטגוריות שונות:

במקרים מסוימים, ההחלטה אם תוכן מסוים שייך לקטגוריה מסוימת או לקטגוריה אחרת היא סובייקטיבית. יכולות להיות סיבות נוספות להעלאה או להורדה של בדיקה, כמו עלות התשתית, חוסר יציבות וזמני בדיקה ארוכים.

שימו לב שקטגוריית הבדיקה לא קובעת את סוג הבדיקה, ולא צריך לבדוק את כל התכונות בכל קטגוריה.

בנוסף, בדיקות ידניות יכולות להיות חלק מאסטרטגיית הבדיקה שלכם. בדרך כלל, צוותי בקרת איכות מבצעים בדיקות של גרסאות מועמדות להפצה, אבל הם יכולים להיות מעורבים גם בשלבים אחרים. לדוגמה, בדיקה גישושית לאיתור באגים בתכונה מסוימת ללא סקריפט.

תשתית לבדיקות

אסטרטגיית בדיקה צריכה להסתמך על תשתית וכלים שיעזרו למפתחים להריץ את הבדיקות שלהם באופן רציף ולאכוף כללים שיבטיחו שכל הבדיקות יעברו בהצלחה.

אפשר לסווג את הבדיקות לפי היקף כדי להגדיר מתי ואיפה להריץ כל בדיקה. לדוגמה, בהתאם למודל של 5 שכבות:

• בדיקות יחידה ורכיבים מופעלות במערכת השילוב הרציף לכל קומיט חדש, אבל רק למודולים המושפעים.
• כל הבדיקות של יחידות, רכיבים ותכונות מופעלות לפני מיזוג או שליחה של שינוי.
• בדיקות האפליקציה מופעלות אחרי המיזוג.
• בדיקות Release Candidate מופעלות מדי לילה בטלפון, במכשיר מתקפל ובטאבלט.
• לפני השקה, מתבצעות בדיקות של גרסת קנדידט במספר גדול של מכשירים.

הכללים האלה יכולים להשתנות עם הזמן, כשהמספר של הבדיקות משפיע על הפרודוקטיביות. לדוגמה, אם תעבירו את הבדיקות לקצב של פעם בלילה, יכול להיות שתקצרו את הזמן של בניית CI והבדיקות, אבל יכול להיות גם שתאריכו את משוב.