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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תשתית בדיקה

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

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

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

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

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