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

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

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

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

עיין בתבנית בדיקות היחידה שלהלן:

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

מהיכן מגיעים מקרי הבדיקה? האם עלי להמציא אותם?

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

מקרי הבדיקה (Test Cases) אמורים לבדוק שכל מה שאמור לעבוד ולהתבצע:

1. אכן מתבצע
2. מתבצע בצורה בה הוא היה אמור להתבצע
3. לא פוגע/מפריע לפעולת חלקים אחרים במודול

אז איך נזהה את מקרי הבדיקה?

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

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

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

בדיקה מסוג זה אכן נקראת על שם הקופסה השחורה - Black Box Testing.

היא מתבצעת ברמות רבות של המערכת - החל מרמת המודול הבודד (עליו נדבר כאן) ועד רמת המערכת כולה.

ברמת בדיקת המודול היא בדיקות הקופסה השחורה מיועדות:

1. לבחון את התפקוד של המודול כיישות עצמאית (מחוץ למערכת)
2. לוודא את •נכונות הפלט עבור מקרים מייצגים של קלטים (שים לב! מקרים מייצגים בלבד)
3. לבדוק את מהירות התגובה של המערכת, אך גם כאן - אין מדובר בבדיקות עומסים עם תרחישי עומס אמיתיים אלא בבדיקות ראשוניות בלבד של מודול לפני אינטגרציה כיחידה אחת סגורה.

אם כן, מה יהיה ה-Black Box Test Case שלנו עבור CEquipMgr?

• תיאור הבדיקה - "הוספת פריט מסוג סנובורד"
• מהלך הבדיקה - "בחר באפשרות 'הוספת פריט'
                         בחר סוג ציוד סנובורד
                         הזן את פרטי הסנובורד (כאן יבואו ערכים אמיתיים לשדות הנדרשים)
• תוצאה צפויה - "הפריט הוסף בהצלחה, ניתן לראות אותו ברשימת פריטי הסנובורד"

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

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

בדיקות קופסה לבנה, או White Box Test Cases, משלימות את בדיקות הקופסה השחורה. אם בדיקות אלה התייחסו אל הקוד כאל קופסה שחורה שאיננו יודעים מה מתרחש בתוכה, בדיקות הקופסה הלבנה מסתמכות על "הצצה" אל תוך הקוד ומכאן שתרחישי הבדיקה שלה נבנים על בסיס הקוד והסתעפותו. סיימנו את תרחישי הבדיקה של הקופסה הלבנה כאשר עברנו על כל המסלולים האפשריים בקוד.

למשל, אם CEquipMgr מבצע מעבר בלולאה על פריטי הציוד החדשים שמתווספים, White Box Test Case יבדוק, למשל, מה קורה לתוכנית אם נקבל מספר שלילי של פריטי ציוד:

• תיאור הבדיקה - "הוספת 5- פריטים מסוג סנובורד"
• מהלך הבדיקה - "בטופס הזנת הסנובורד הזן בשדה 'מספר הפריטים' את הערך 5-"
• תוצאה צפויה - "תתקבל הודעת שגיאה: נא הזן מספר פריטים חיובי"

אם כן, מה מטרת בדיקות הקופסה הלבנה?

1. בחינת המבנה הפנימי של המודול
2. בחינת מסלולי החישוב
3. בחינת נכונות החישובים
4. •בחינת נכונות ההחלטות הלוגיות

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

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

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

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

כאמור, כל רמה של בדיקות יכולה להשתמש בכל אחת מהשיטות.

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