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