דף זה תורגם על ידי Cloud Translation API.

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

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

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

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

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

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

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

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

**איור 1.** בדרך כלל, התפלגות מספר הבדיקות לפי היקף מוצגת בתרשים פירמידה.

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

צמצום העלות של באג

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

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

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

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

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

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

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

אסטרטגיית בדיקה שניתן להתאים לעומס

הפירמידה שנבדקה פוצלה בדרך כלל ל-3 קטגוריות:

בדיקות יחידה (unit testing)
בדיקות אינטגרציה
בדיקות מקצה לקצה.

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

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

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

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

	היקף	גישה לרשת	ביצוע	סוג build	מחזור חיים
היחידה	שיטה או כיתה יחידה עם קשרי תלות מינימליים.	לא	מקומי	אפשר לנפות באגים בקוד	לפני המיזוג
רכיב	ברמת המודול או הרכיב כמה כיתות יחד	לא	מקומי Robolectric Emulator	אפשר לנפות באגים בקוד	לפני המיזוג
תכונה	ברמת התכונה שילוב עם רכיבים שבבעלות צוותים אחרים	Mocked	מקומי Robolectric מכשירי הדמיה	אפשר לנפות באגים בקוד	לפני המיזוג
בקשה	ברמת האפליקציה שילוב עם תכונות או שירותים שבבעלות צוותים אחרים	מודל משוער שרת ייצור שרת ייצור	אמולטור מכשירים	אפשר לנפות באגים בקוד	לפני המיזוג אחרי המיזוג
מועמד לפרסום	ברמת האפליקציה שילוב עם תכונות או שירותים שבבעלות צוותים אחרים	שרת Pro	אמולטור מכשירים	גרסת build מינימלית של גרסה זמינה	אחרי המיזוג טרום-השקה

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

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

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

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

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

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

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

תשתית לבדיקה

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

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

קטגוריה	סביבה (כאשר)	טריגר (מתי)
היחידה	[Local][4]	כל התחייבות
רכיב	מקומי	כל שמירה (commit)
תכונה	מקומיים ואמולטורים	מיזוג מראש, לפני מיזוג או שליחה של שינוי
אפליקציה	מקומי, אמולטורים, טלפון אחד, מכשיר מתקפל אחד	לאחר המיזוג, אחרי שמיזגו או שלחו שינוי
גרסת Release Candidate	8 טלפונים שונים, טלפון מתקפל אחד וטאבלט אחד	גרסת טרום-השקה

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

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