נתחיל מהיסודות. סקירה של שני מצבי הבדיקה הכלליים ושלושה סוגים נפוצים של אוטומציה של בדיקות.
כולנו היינו שם: מהו מם חוזר בנושא תכנות שקורה לעיתים קרובות מדי בחיים האמיתיים?
המם הזה מסכם את זה יפה: כל מגירה פועלת בצורה מושלמת בנפרד, אבל בשילוב עם המגירה השנייה, הן חוסמות זו את זו ולא פועלות. חשוב שהשניים יפעלו היטב זה לצד זה ואפשר יהיה להשתמש בשניהם בו-זמנית.
אפשר להחיל את זה על פיתוח אתרים: כתבתם כמה בדיקות, אולי אפילו הגעתם לכיסוי בדיקה של 100%, אבל האפליקציה עדיין צריכה לפעול אחרי שחלקים אחרים ייכנסו לתמונה. יכול להיות שהיחידות יפעלו טוב בפני עצמן, אבל לא ביחס זו לזו. חשוב לכתוב בדיקות מסוימות, אבל הן רק חלק אחד מההגדרה האידיאלית של בדיקות לפרויקט. בשלב הראשון, צריך לקבוע אילו חלקים באיכות האפליקציה צריך לוודא ואיך אפשר להשיג זאת.
במילים פשוטות, צריך תוכנית לפני שמתחילים לכתוב את קוד הבדיקה בפועל. כדי להבין איך מבצעים בדיקה באופן מעשי, נתחיל מהתחלה ונשאל שתי שאלות בסיסיות:
- איך רוצים לבדוק?
- מה ברצונך לבדוק?
המאמר הזה מתמקד בדברים הכלליים שצריך לדעת כדי לענות על השאלה הראשונה. כדי שנתחיל ממקום משותף, קודם נלמד אילו מצבי בדיקה קיימים, ולאחר מכן נתמקד בסוגי הבדיקות הנפוצים. במאמרים הבאים נענה על השאלה השנייה, נשלב את התשובות ונמצא את אסטרטגיית הבדיקה שהכי מתאימה לפרויקט שלכם. שנתחיל? 🙌
מתחילים ביסודות: מצבי בדיקה כלליים
כשעונים על השאלה איך בודקים, הנקודה הראשונה שצריך להבהיר היא מאוד מופשטת. האם כדאי לבדוק באופן ידני או לתת למחשב לעשות את העבודה? עם זאת, חשוב לא ליפול לחשיבה בינארית.
בדיקה ידנית לעומת בדיקה אוטומטית
אם תבקשו מהנדסים להבטחת איכות להגדיר בדיקה, סביר להניח שהם יחלקו אותה קודם לשני 'מצבים':
- בדיקה ידנית. זוהי שיטת בדיקה אופיינית שמתבצעת על ידי אנשים אמיתיים. מהנדס בקרת איכות לוחץ על האפליקציה, בודק אם היא פועלת ובמקביל מנסה לגרום לה לכשל. הדרך הנפוצה ביותר היא בדיקה exploratorie, שבה המהנדס בודק את האפליקציה על סמך הידע שלו לגביה, בהתאם לנתיב או לרשימת משימות מוגדרים מראש.
- בדיקות אוטומטיות. זהו סוג של בדיקה שמתבצעת על ידי מחשב. מהנדסי בקרת איכות מטמיעים אותו כדי לבצע אוטומציה של בדיקות שחוזרות על עצמן וחדגוניות.
סדרת המדריכים הזו תתמקד בעיקר בבדיקות אוטומטיות. עם זאת, אל תתמקדו רק בדרך אחת לבדיקות. גם אם האוטומציה חוסכת הרבה זמן ומאמץ, תמיד תהיה לאנשים ולבדיקה ידנית תפקיד חיוני. במקום זאת, אוטומציית הבדיקות אמורה לאפשר לאנשים להתמקד בבדיקות חקירה ובפתרון בעיות באופן יצירתי. לדוגמה, כדי להבטיח את איכות חוויית המשתמש או להגן על הלוגיקה העסקית עם רמת הסיכון הגבוהה. במילים אחרות, האוטומציה עוזרת לכם. ❤️
תיבה אטומה לעומת תיבה שקופה
סיימתם להגדיר את המצבים הכלליים לבדיקה. עם זאת, זה עדיין לא מספיק. כדי לתכנן את אסטרטגיית הבדיקה, צריך לענות על שאלה נוספת: האם צריך לדעת איך האפליקציה פועלת בפנים או שעדיף לבדוק אותה בלי הידע הזה? בהתאם לתשובה, יש שתי שיטות לבחירה וליצירה של תרחישי בדיקה:
- בדיקת קופסה אטומה (או בדיקת קופסה שחורה). הוא מבוסס על ניתוח הדרישות (המפרטים) הפונקציונליות או הלא פונקציונליות של רכיב או מערכת, בלי להביא בחשבון את המבנה הפנימי שלהם.
- בדיקת תיבה שקופה (או בדיקת תיבה לבנה) היא תהליך שמביא בחשבון את המבנה הפנימי של התיבה. במילים אחרות, איך האפליקציה פועלת מאחורי הקלעים.
אפשר להשתמש בשני התהליכים האלה גם בבדיקות ידניות וגם בבדיקות אוטומטיות. עם זאת, יש היבטים מסוימים במצבי בדיקה כלליים שמוגדרים יותר לצורך אחד מהם – נרחיב על כך בהמשך. בינתיים, נפרק את האוטומציה של הבדיקות לפי סוגים.
סוגי אוטומציית בדיקות: איך רוצים לבדוק?
ככל שמתקרבים לתשובה לשאלה 'איך', כבר מחליטים לבצע בדיקה ידנית. עם זאת, הבחירה בסוגים של אוטומציית בדיקות והחלה שלהם היא משימה מורכבת יותר. סוגי בדיקות האוטומציה קשורים מאוד למדדים שרוצים ליצור בפרויקטים. נבחן את האפשרויות החשובות ביותר.
כפי שמוצג ב-meme שצוין קודם, כבר נתקלתם בשני סוגים: בדיקת יחידה ובדיקת שילוב. בדיקת 'קצה-לקצה' (end-to-end) היא האפשרות השלישית שחשוב להביא בחשבון. אבל עדיין לא כל התמונות זמינות. בואו נבחן את הנושא לעומק.
בדיקות יחידה
בדיקת יחידה היא סוג של בדיקה שבה חלקים או יחידות קטנות שניתן לבדוק באפליקציה נבדקים בנפרד ובאופן עצמאי כדי לוודא שהן פועלות כראוי. ההיקף של היחידות האלה יכול להשתנות מפונקציות, כיתות או ממשקים, ועד לשירותים או לרכיבים מלאים. המאפיינים העיקריים שלהם הם מהירות ביצוע, בידוד ותחזוקה נוחה. כדי להבין לעומק את נושא בדיקת היחידה, אפשר לעיין במדריך הזה בנושא בדיקת יחידה.
בדיקת אינטגרציה
בדיקת האינטגרציה מתמקדת באינטראקציות בין רכיבים או מערכות. במילים אחרות, על מידת ההתאמה ביניהם. דוגמאות אופייניות לבדיקות שילוב הן בדיקות API או בדיקות רכיבים.
בדיקה מקצה לקצה
הבדיקות האלה נקראות לעיתים קרובות בדיקות ממשק משתמש, והשם הזה מסביר את הפונקציה שלהן בצורה טובה יותר. הבדיקות האלה מבצעות אינטראקציה עם ממשק המשתמש של האפליקציה, כולל סטאק האפליקציות המלא, ובודקות את האפליקציה מקצה לקצה.
אם מתייחסים לתיאוריה של בקרת איכות, הן דומות לבדיקה של מערכת. הבדיקות האלה מדמות משתמש אמיתי ואת האינטראקציות שלו. בדיקות מקצה לקצה נמשכות יותר זמן ריצה כי הן כוללות את המערכת כולה, וזמן ריצה ארוך יותר דורש יותר כוח מחשוב. כתוצאה מכך, המאמץ הנוסף הזה מוביל לעלייה בעלויות התחזוקה.
בדיקת ממשק משתמש חזותי
קטגוריית משנה מעניינת של בדיקות ממשק משתמש היא בדיקות חזותיות. הבדיקות האלה הן בדיקות מקיפות מקצה לקצה שמאפשרות לאמת את הפלט הגלוי של אפליקציה. בבדיקה כזו מתבצע צילום מסך אחרי שינוי ועוד צילום מסך שמכיל את 'הסטטוס קוו' (או הקובץ המושלם), ולאחר מכן התוצאות האלה מועברות לבודק אנושי לבדיקה ולבדיקה חוזרת. במילים אחרות, הוא עוזר למצוא "באגים חזותיים" במראה של דף, מעבר לבדיקות נכונות (assertions) שלא נכתבו במפורש.
ניתוח סטטי
יש עוד נושא אחד שצריך להציג כאן: ניתוח סטטי. זה לא סוג של בדיקה במובן של ספר לימוד. עם זאת, הוא יהיה היבט חיוני באסטרטגיות של בקרת איכות בהמשך. אפשר לדמיין את הפעולה שלו כמו פונקציית בדיקת איות: הוא סורק את הקוד כדי לזהות פגמים משמעותיים יותר ושגיאות תחביר בלי להריץ את התוכנית, וכך מזהה בעיות בסגנון הקוד. הפעולה הפשוטה הזו יכולה למנוע הרבה באגים. זהו זמן טוב ללמוד על ניתוח סטטי, אם אתם רוצים להכיר אותו לעומק.
בדיקה בכל הצורות: איך כל זה פועל ביחד?
כשמחפשים תשובות לכל השאלות האלה, יכול להיות שתמצאו פתרון אפשרי בהשוואות מסוימות. בקהילות האינטרנט והבדיקות בפרט, מפתחים נוטים להשתמש באנלוגיות האלה כדי לתת לכם מושג כמה בדיקות כדאי להשתמש בהן ואיזה סוג בדיקות.
חמשת השיטות הבאות שמוצגות בתמונה הזו הן הנפוצות ביותר:
- פירמידה של בדיקות
- בדיקת יהלום
- Test Ice Cone (נקרא גם Test Pizza)
- בדיקת Honeycomb
- Test Trophy
זהו כמות גדולה מאוד של מידע לעיבוד. על סמך כל המידע הזה, איך בוחרים אסטרטגיית בדיקה מתאימה? אל דאגה, אנחנו כאן כדי לעזור. במאמר הבא נדון בשיטות השונות האלה בהרחבה ונסביר איך לבחור את השיטה שהכי מתאימה לפרויקט שלכם. עדכונים נוספים בקרוב! 🔥