בדיקות קופסה לבנה הן סוג של בדיקות תוכנה שמתמקדות במבנה הפנימי של רכיב או מערכת. בניגוד לבדיקות קופסה שחורה, שמטרתן לאמת את עמידת הרכיב בדרישותיו, בדיקות קופסה לבנה נועדו לבדוק את תקינות החלקים הפנימיים של הרכיב. בדיקות אלו מתבססות על קוד המקור ונכתבות בעיקר על ידי מתכנתים, ולא על ידי בודקי תוכנה.
בסילבוס של ISTQB נושא של בדיקות קופסא לבנה מקבל מקום בפרק 4 העוסק בטכניקות בדיקה. פרק זה כולל בדיקות קופסא שחורה, בדיקות קופסא לבנה וטכניקות בדיקה נוספות כמו בדיקות מבוססי ניסיון עליהן כתבתי בעבר.
בבדיקות קופסא לבנה נוכל להשתמש בכל רמות הבדיקה, אולם הטכניקות הנפוצות ביותר שאותן אציג כעת נפוצות בעיקר ברמת בדיקות הרכיבים (Integration Testing). טכניקות אלו מתבססות על
2 צורות בדיקה חשובות:
1. בדיקת הצהרות קוד וכיסויין (Statement Testing And Coverage) :
שיטת בדיקות הקובעת את מקרי הבדיקה כך שכל הצהרת קוד נבדקת לפחות פעם אחת. הצהרת קוד מבחינתנו היא שורת קוד אחת כאשר המטרה היא להגיע ל 100% כיסוי הצהרות קוד. במילים אחרות עלינו לבדוק כל שורת קוד ולוודא שהיא פועלת כראוי.
דוגמא לקוד:
בדוגמא זאת עלינו לדאוג שהביטוי בשורה הראשונה יהיה חיובי כך שנוכל להיכנס לכל אחת מ-3 ההצהרות ולוודא שהן עובדות.
2. בדיקת החלטות וכיסויין (Decision Testing And Coverage) :
שיטת בדיקות שבה נריץ את מקרי הבדיקה שגורמים לכל נקודת החלטה בקוד (לדוגמא משפט תנאי IF) לקבל בהרצה אחת ערך חיובי (True) ופעם אחת נוספת ערך שלילי (False).
הערך של בדיקות משפטים ובדיקות ההחלטה:
100% כיסוי משפטים יוכל להבטיח שכל משפטי הקוד נבדקו והורצו לפחות פעם אחת, אבל אין בכך להבטיח שכל לוגיקת ההחלטה נבדקה.
מכאן ניתן למדוד שבדיקות משפטים מספקות כיסוי נמוך יותר מבדיקות החלטות ובמילים אחרות:
100% כיסוי החלטות מבטיח 100% כיסוי משפטים אך לא להיפך!
דוגמה לניתוח קוד:
אם נרצה לממש בדיקת משפטים נבחר בבדיקה אחת שכוללת הצבת הערך אפס עבור המשתנה A (0=A)
כך נוכל לעבור על כל שורות הקוד ולוודא שקיבלנו את התוצאה המבוקשת של: הדפס "1" והדפס "2".
לעומת זאת,
בבדיקת משפטים נצטרך לממש שתי בדיקות שכוללות הצבת הערך אפס, כדי לבדוק את התוצאות של הפונקציה כאשר התנאי מתממש.
אבל כדי לסיים את הבדיקה נצטרך גם להציב כל ערך ששונה מאפס, כדי לבדוק את התנהגות הקוד כאשר התנאי לא מתממש.
בדיקות קופסא לבנה כוללות טכניקות נוספות כמו:
בדיקות לולאות
לולאות בקוד יכולות לגרום לבעיות כמו לולאות אינסופיות אם לא נבדקות כראוי. בדיקות לולאות בודקות את תנאי היציאה מהלולאה ואת התנהגות הלולאה במצבים שונים. חשוב לוודא שהלולאות מתנהגות כנדרש ושלא מתרחשות בעיות בביצועים
בדיקות מסלולים
בדיקות מסלולים עוסקות במעקב אחרי המסלולים השונים שהקוד עובר. כל מסלול בקוד נבחן על פי התנאים וההגבלות שלו, במטרה לזהות בעיות הפועלות רק במסלולים ספציפיים. טכניקה זו מאפשרת לוודא שהמערכת יכולה להתמודד עם כל האפשרויות.
בדיקות מחסומים
בדיקות מחסומים נועדו לבדוק את יכולת הקוד להתמודד עם קלטי קצה,
כלומר קלטים שאינם סטנדרטיים. בדיקות אלו עוזרות לוודא שהמערכת לא קורסת כאשר היא נתקלת בקלטים בלתי צפויים, נושא חשוב במיוחד במערכות קריטיות (mission or safety critical) או בסביבות שמצריכות אמינות גבוהה (high integrity environment).
בדיקות משולבות
בדיקות משולבות בוחנות את הקוד בהקשר של שילובו עם רכיבים אחרים במערכת. טכניקה זו מאפשרת לזהות בעיות הנובעות מאינטראקציה בין רכיבים שונים, מה שיכול לסייע בזיהוי בעיות מורכבות יותר.
בדיקות חיזוי
בדיקות חיזוי מתמקדות בניתוח התוצאות הצפויות על בסיס קוד המקור. המטרה היא לוודא שהפונקציות השונות מייצרות את התוצאות הצפויות במצבים שונים. באמצעות טכניקה זו ניתן לבדוק האם המערכת מתפקדת כראוי בכל התרחישים האפשריים.
בדיקות קופסה לבנה מציעות יתרונות משמעותיים בתהליך פיתוח התוכנה, שכן הן מתמקדות במבנה הפנימי של הקוד ובבדיקת הלוגיקה של המערכת. טכניקות אלו מאפשרות גילוי מוקדם של בעיות, מה שמפחית עלויות וזמן תיקון מאוחר יותר. יתרה מכך, הן מספקות כיסוי קוד מעמיק, מה שמבטיח שהרכיבים הפנימיים פועלים בצורה תקינה ועומדים בדרישות המהותיות של המערכת. בזכות הגישה המעמיקה, ניתן גם לייעל את ביצועי הקוד ולוודא שהמערכת מתפקדת בצורה אופטימלית.
להלן מגוון יתרונות שסקרתי:
יתרונות וחסרונות בבדיקות קופסה לבנה
- גישה למבנה הפנימי:
מאפשרת להבין את הלוגיקה והמבנה הפנימי של הקוד, מה שמוביל לגילוי בעיות שלא תמיד ניתן לראות מבחוץ. מקרי קצה ושגיאות שחבויות בקוד יתגלו באופן מהיר ויעיל. - זיהוי בעיות מוקדם:
בדיקות קופסה לבנה מאפשרות גילוי בעיות בתהליך הפיתוח, דבר שמפחית עלויות וזמן תיקון בהמשך. כאשר בדיקה נכשלת, יותר קל לאתר את שורות הקוד שאחראיות לבעיה. - כיסוי קוד גבוה:
ניתן להשיג כיסוי קוד גבוה יותר, מה שמסייע להבטיח שהרבה מהקוד נבחן ונבדק. - יכולת לנתח ביצועים:
מאפשרת לנתח את ביצועי הקוד בצורה מעמיקה, כולל זיהוי צווארי בקבוק וביצועים לא אופטימליים. (בעיות Performance) - בדיקות מותאמות אישית:
ניתן להתאים את הבדיקות לצרכים הספציפיים של הפיתוח והדרישות הטכניות.
בדיקות קופסה לבנה, אף שהן מציעות יתרונות רבים, נושאות עימן גם חסרונות משמעותיים. אחת הבעיות המרכזיות היא הצורך בידע טכני מעמיק, מה שעשוי להגביל את יכולת הבודקים שאינם מתכנתים לבצע את הבדיקות בצורה אפקטיבית. בנוסף, בדיקות אלו עשויות לדרוש יותר זמן ומאמץ, במיוחד כאשר מדובר במערכות מורכבות. כמו כן, ההתמקדות במבנה הפנימי של הקוד עלולה להוביל להזנחת דרישות המשתמש והציפיות שלו, דבר שיכול לפגוע בחוויית השימוש הכוללת.
להלן מגוון חסרונות שסקרתי:
חסרונות בדיקות קופסה לבנה:
דרישות טכניות:
□ נדרשת הבנה מעמיקה של הקוד והמבנה הפנימי, מה שעלול להקשות על אנשי QA שאינם מתכנתים.
זמן ומאמץ:
□ עלולות לדרוש יותר זמן ומאמץ לפיתוח בדיקות מקיפות, במיוחד עבור מערכות גדולות ומורכבות.
מוגבלות בהבנת דרישות משתמש:
□ מתמקדות בקוד ולא תמיד בודקות את עמידת המערכת בדרישות המשתמש או בציפיותיו.
סיכון של "ראיית הקוד":
□ הבודקים עשויים לפתח "הטיית קוד", שבהם הם מתמקדים באספקטים הטכניים ולא בבעיות חוויית המשתמש.
דוגמאות מהתעשייה:
גוגל: גוגל משתמשת בבדיקות קופסה לבנה במגוון המוצרים שלה, כולל מנוע החיפוש ו-Google Maps. הם מבצעים בדיקות פונקציות כדי לוודא שכל אלגוריתם מקבל את הקלטים הנכונים ומחזיר את התוצאות הצפויות. בנוסף, גוגל משתמשת בבדיקות כיסוי קוד כדי לוודא שכמה שיותר מהקוד נבדק ומעובד, מה שמפחית סיכוני תקלות במוצרי החברה.
טסלה: משתמשת בבדיקות קופסה לבנה במערכות התוכנה של רכבי החשמל שלה. הם מבצעים בדיקות כיסוי קוד על מנת להבטיח שכל רכיב במערכת הבקרה של הנהיגה האוטונומית נבדק ומאומת בתנאי סביבה שונים. (עומס תנועה, תנאי מזג אויר קשים, מסלולי כביש ירודים וכו').
Adobe: מבצעת בדיקות קופסה לבנה בתוכנות כמו Photoshop ו-Illustrator. הם משתמשים בבדיקות תנאים ובדיקות מסלולים בכדי לוודא שכל תכונה במוצר פועלת כראוי, והמשתמשים חווים ביצועים חלקים.
דוגמא למקרה שלא בוצעו בו בדיקות קופסא לבנה:
חברה: Toyota
תקלת הקוד: מערכת בקרת הדלק ברכב
פרטי התקלה:
בשנת 2019, טויוטה הודיעה על תקלה במערכת בקרת הדלק בכמה דגמים שלה. התקלה נגרמה כתוצאה משגיאה בקוד שבדק את מצב החיישנים במערכת. כאשר החיישנים לא פעלו כראוי, המערכת לא הצליחה לזהות את כמות הדלק הנכונה שיש להזריק למנוע.
תוצאה:
במהלך נהיגה, רכבים מסוימים חוו הפסקות פתאומיות של כוח המנוע, דבר שגרם לסכנת תאונה. כתגובה לתקלות, החברה נאלצה לזמן יותר מ-1.3 מיליון רכבים ברחבי העולם כדי לתקן את הבעיה.
השלכות:
1. פגיעה בבטיחות: התקלה יצרה סכנה ממשית לנהגים ולהולכי רגל, דבר שהשפיע על בטיחות הרכבים.
2. נזק תדמיתי: האירוע פגע במוניטין של טויוטה, שנחשבת לחברה שמקפידה על איכות ובטיחות המוצרים שלה.
3. הוצאות תיקון: החברה נדרשה להשקיע כספים רבים בתהליך התיקון, כולל עלויות של זימון רכבים למוסכים.
לקחים:
המקרה הזה מדגיש את החשיבות של בדיקות קוד מקיפות ומדויקות, במיוחד במערכות קריטיות לבטיחות. בדיקות קופסה לבנה שיכולות לזהות בעיות לוגיות בתהליך הפיתוח עשויות היו למנוע את התקלה ולחסוך נזקים משמעותיים.
לסיכום, בדיקות קופסה לבנה הן כלי חיוני בתהליך פיתוח התוכנה, המספקות תובנות מעמיקות על איכות הקוד ותפקוד המערכת. באמצעות הטכניקות השונות, כגון בדיקות פונקציות, מסלולים, תנאים ולולאות, ניתן לזהות בעיות בשלב מוקדם ולשפר את ביצועי התוכנה. השגת כיסוי קוד גבוה ובדיקת אינטראקציות בין רכיבים מאפשרת להבטיח שהמערכת פועלת בצורה תקינה ומספקת חוויית משתמש איכותית. השילוב של טכניקות בדיקה קופסה לבנה בתהליך הפיתוח הוא חיוני להצלחת המערכת, ומסייע להימנע מתקלות בעת השקת המוצר.