
הטקסט המלא של הדקות הראשונות בהרצאה «בדיקות קופסה לבנה - הסבר מקיף» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
בפרק הזה נעסוק בסעיף 4.3 בחומר ההסמכה של ה-STQB ואנחנו ממשיכים לדבר על טכניקות בדיקה והפעם בקטגוריה של בדיקה ששייכת לקטגוריית קופסה לבנה.
למעט עכשיו עסקנו בטכניקות שקשורות לקופסה שחורה, עכשיו אנחנו מדברים על טכניקות ששייכות לקטגוריה של הקופסה הלבנה. בדיקות מסוג קופסה לבנה מבוססות על מבנה פנימי של מושא הבדיקות.
זאת אומרת, הבנה של איך המערכת עובדת, איך המתודות מבצעות את מה שהן אמורות, איך הקוד כתוב, איך השאילתות כתובות. ניתן להשתמש בטכניקות בדיקה מסוג קופסה לבנה בכל רמות הבדיקה.
זאת אומרת, גם בשלב ה-unitest, בדיקות הקומפוננטות או בדיקות הרכיב, גם בשלב של בדיקות אינטגרציה, בדיקות מערכת, בדיקות סיסטם, בדיקות מסירה, קבלה ועוד.
אולם שתי הטכניקות שיוצגו בפרק זה מבוססות קוד והשימוש בהן נפוץ בעיקר ברמת בדיקות הרכיב Component Testing או Unit Testing. ישנן טכניקות בדיקה מתקדמות יותר שנמצאות בשימוש במערכות קריטיות Safety Critical או Mission Critical או בסביבות שדורשות אמינות גבוהה I-Integrity Environment.
המטרה להשיג כיסוי יסודי את הבדיקות וכיסוי משפטי. בדיקות משפטים מפעילה את משפטי הפקודה בקוד לא כולל למשל הערות בקוד. הכיסוי נמדד על ידי חלוקה של המשפטים שהופעלו על ידי הבדיקה בסך משפטי הפקודה במוסר הבדיקות.
בדרך כלל מבטאים כיסוי זה באחוזים. בדיקות וכיסוי משפטים זה אומר ככה שהגישה הזאת אומרת שלכל שורת קוד או כל איזשהו פעולת קוד תהיה בדיקה כלשהי שתוודא, את הפעולה עצמה, את הקוד שנכתב. זאת אומרת, אנחנו אומרים אם מפתח כותב כמה שורות או כמה מתודות, אז אנחנו מנסים להגיע למצב שכל המתודות וכל שורות הקוד בעצם נבדקות על ידי תהליכים מקבילים
למשפטים האלה. זאת אומרת, שכל מתודה כאמור תיבדק ותתוקף ועל ידי כך נוכל להגיע לקוורג' מקסימלי. זאת אומרת שבכל תהליך תכנותי פיתוחי יהיה תהליך מקביל של בדיקה שייחתם במקביל לכתיבת הקוד.
קוד וכיסוי החלטות. בבדיקת החלטות מריצים מקרי בדיקה שגורמים לכל נקודת החלטה בקוד, לדוגמה משפטי if, לקבל לפחות פעם אחת ערך true ולפחות פעם אחת שקר.
מקרי הבדיקה מונחים על ידי בקרת הזרימה שנובעת מתוצאת ההחלטות. כלומר, משפט איף, מקרה בדיקה אחד עבור תוצאת אמת ומקרה בדיקה אחר עבור תוצאת שקר.
במשפט קייס יידרשו מקרי בדיקה לכל תוצאות אפשריות, כולל תוצאות ברירת מחדל. פה יש פה איזו התייחסות לסינטקס, יש לנו תאיף שהוא צומת החלטה בוליאני, זאת אומרת true או false, ויש לנו את הקייס שהוא בעצם מאפשר כמה אפשרויות בחירה, לא רק true או false, אלא מקרה אחד, שתיים, שלוש, ארבע או חמש,
וזה בעצם הבדיקה הזאת היא פועל יוצא של בדיקות וכיסוי משפטים, זאת אומרת, בדיקות וכיסוי החלטות זה הדרך של המערכת לוודא שהמתכנת כתב את הפעולות בצורה נכונה, זאת אומרת, לוודא על ידי מערכת שמנהלת את הבדיקות מסוג ה-white box, שעשינו בדיקה לכל צומת וצומת של if,
זאת אומרת, שיהיה בדיקה ל-true ול-false בכל אחד ואחד מהמקומות בקוד, וגם שיהיה בדיקה לכל אחד ואחד מצמתי ה-Case, צמתים מרובי אפשרויות. הערך של בדיקות משפטים ובדיקות החלטות 100% כיסוי משפטים מבטיח שכל משפטי ההפעלה בקוד נבדקו לפחות פעם אחת, אבל לא מבטיח שכל לוגיקת ההחלטות נבדקה.
מבין שתי טכניקות הבדיקה מסוג קופסא לבנה שמוצדות כאן, בדיקות משפטים מספקות כיסוי נמוך יותר מבדיקות ההחלטות, שבעצם הן לא מכסות את כל האפשרויות.
100% כיסוי ההחלטות מבטיח שכל תוצאות ההחלטות הופעלו, כולל התוצאות החיוביות והתוצאות השליליות, גם כאשר אין משפטים מפורשים לתוצאה השלילית.
לדוגמה, כאשר בקוד ישנו משפט if, זה לא משפט else, כיסוי, זה אפשרי מבחינת תוכנה, שיהיה רק אם true, שיבצע משהו, ואם else לא יבצע שום דבר.
כיסוי משפטי, עוזר למצוא פגמים בקוד שלא היה מופעל על ידי בדיקות אחרות. כיסוי ההחלטות עוזר למצוא פגמים בקוד במקומות שבהם בדיקות אחרות לא בדקו גם את התוצאות החיוביות וגם את התוצאות השליליות.
100% כיסוי ההחלטות מבטיח 100% כיסוי המשפטים, אך לא להפך. זאת אומרת, כיסוי החלטות מבטיח 100% כיסוי המשפטים. את זה אנחנו צריכים להבין, שבעצם כל הפסקה הזאת שקראנו עד עכשיו מבוססת