יום ראשון, 28 בספטמבר 2008

בדיקות קומפוננטה

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

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

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

יום ראשון, 21 בספטמבר 2008

ביקורת קוד, Code Review

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

הגדרה:
* בדיקה מתודית והבנת הפעילות של הקוד.

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

מתי?
ה- Code Review הוא חלק מבדיקות ה-Unit Test, ויכול לבוא לפני הבדיקות הכוללות את הרצת הקוד, אחרי ואחרי תיקונים משמעותיים. בכל אופן זה בא אחרי קימפול מוצלח.

מומלץ להשתמש לפני ה- Code Review בכלי ביקורת קוד אוטומאטי, למשל QACPP.

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

צ'ק ליסט לדוגמא:
* האם יש שימוש בכל הארגומנטים?
* האם יש ארגומנט של אאוטפוט שאינו נוצר?
* האם יש משתנים שאינם מוגדרים היטב ביחס למטרתם?
* האם יש שימוש במשתנה לפני האתחול שלו?
* האם הקוד עקבי עם הדרישות?
* האם הקוד הוא לפי הסטנדרטים?
* האם יש הודעות שגיאה בלתי ברורות למשתמש?

חלק משאלות אלה ימצאו פתרון ע"י שימוש בכלי אוטומאטי.

רשומות פופולריות