בדיקה מצטברת בבדיקות תוכנה היא מתודולוגיה המאפשרת לצוותים לפרק מודולים בודדים, לבדוק אותם בבודדים ולשלב אותם בשלבים. זה עוזר למצוא פגמים מוקדם, מפחית את המורכבות ומגדיל את כיסוי הבדיקות.
מאמר זה ייקח צלילה עמוקה לתוך בדיקות מצטברות, יסביר מה זה, ויחקור את הסוגים, התהליכים, הגישות, הכלים ועוד הקשורים למתודולוגיה שימושית זו.
מהי בדיקה מצטברת?
בדיקה היא אחד השלבים החשובים ביותר במחזור החיים של פיתוח תוכנה (SDLC). בדיוק כמו עם ה-SDLC, הבדיקה מחולקת לשלבים לוגיים שונים. בדיקה מצטברת היא אחד מהשלבים הללו, והיא מתרחשת בדרך כלל במהלך בדיקות אינטגרציה ומיד לאחר בדיקת יחידה .
בדיקות מצטברות היא גישת בדיקת תוכנה פרגמטית המפרקת תוכניות גדולות או מורכבות לנתחים ניתנים לניהול, בגודל ביס. במקום לשלב ולבדוק מערכת תוכנה שלמה בבת אחת, בדיקות מצטברות מסתכלות על מודולים ומיישמות תהליך אימות מדורג.
מודולי תוכנה הם בדרך כלל יחידות קוד עצמאיות המבצעות משימות או פונקציות ספציפיות. עד כמה המודולים הללו מפורטים תלוי בגורמים שונים, כגון שיטות קידוד, מתודולוגיות פיתוח, או אפילו שפת התכנות שבה אתה משתמש.
מודולים נבדקים באופן עצמאי במהלך בדיקת יחידה. לאחר מכן, במהלך בדיקות האינטגרציה, כל מודול משולב חלק אחר חלק – או במרווחים. תהליך זה מבטיח שכל מודול עובד היטב ביחד. עם זאת, כדי לאמת כל מודול באופן מלא, הבודקים צריכים לדמות רכיבים שטרם יושמו או מערכות חיצוניות. כדי לעשות זאת, הם זקוקים לעזרה של בולים ונהגים.
מה הם בדלי ודרייברים בבדיקות מצטברות?
סטאבים ומנהלי התקנים הם כלי קריטי לבדיקת תוכנה. פיסות קוד זמניות אלו משמשות במהלך בדיקות אינטגרציה מכיוון שהן מציעות לצוותים את היכולת לחקות את ההתנהגויות והממשקים של מודולים או רכיבים שונים.
1. בדלי:
בלמים מחקים מודולים שטרם פותחו והם, ככאלה, אינם זמינים לבדיקה. הם מאפשרים למודול הנבדק (MUT) להתקשר למודולים לא שלמים. התוצאה כאן היא שניתן לבדוק את ה-MUT בבידוד, גם כאשר מודולים קשורים אינם זמינים.
2. דרייברים:
מנהלי התקנים, לעומת זאת, מדמים את ההתנהגות של מודולים הקוראים ל-MUT. בתוך סביבת הבדיקה, מנהלי התקנים אלה יכולים לשלוח את נתוני בדיקת MUT. שוב, זה מקל על בדיקת מודולים בבידוד ללא צורך בתלות חיצונית.
שימוש בסטאב או מנהלי התקנים מקטין את זמן הפיתוח, משפר את איכות הקוד ומגביר את הפרודוקטיביות של הצוות. עם זאת, ההחלטה באיזו מהם להשתמש תלויה באיזו מתודולוגיית בדיקה היא המתאימה ביותר. נרחיב על כך בסעיף להלן העוסק בסוגים השונים של בדיקות שילוב מצטברות.
סוגים שונים של אינקרמנטליים
בדיקות אינטגרציה
ניתן לפצל באופן כללי סוגי בדיקות מצטברות לשלוש קטגוריות. בואו נחקור כל אחד.
1. אינטגרציה מצטברת מלמעלה למטה
אינטגרציה מצטברת מלמעלה למטה מתחילה בבדיקת המודולים מהסדר הגבוה ביותר בתוך מערכת. משם, הוא משתלב בהדרגה ובודק מודולים מסדר נמוך יותר.ישנם שני תרחישים עיקריים שבהם נעשה שימוש באינטגרציה מצטברת מלמעלה למטה. הם:
- כאשר מערכת גדולה מאוד או מורכבת מאוד
- כאשר צוות המפתחים עובד על מודולים רבים בו-זמנית.
שלבים לאינטגרציות מצטברות מלמעלה למטה
- זיהוי מודולים קריטיים
- צור בולים כדי לחקות מודולים מסדר נמוך
- פתח מנהלי התקנים לאינטראקציה עם המודולים בסדר גבוה יותר כדי לשלוח להם נתונים ולפרש את הפלטים של המודול
- מודולים קריטיים לבדיקת יחידה עם מנהלי התקנים וסתימות
- שלב מודולים מסדר נמוך והחלף בהדרגה את השבבים בהטמעות אמיתיות
- מנהלי התקנים מחזירים כדי להתאים את המודולים החדשים
- חזור על הפעולה עד שכל המודולים מסדר נמוך ישתלבו ונבדקו.
2. אינטגרציה מצטברת מלמטה למעלה
שילובים מצטברים מלמטה למעלה הולכים בכיוון ההפוך. עם גישה זו, מודולים מסדר נמוך (או לפחות קריטי) של המערכת נבדקים, כאשר מודולים מסדר גבוה יותר מתווספים בהדרגה. גישה זו מתאימה לתרחישים שונים, כגון:
- כאשר אתה עוסק במערכות קטנות יותר
- כאשר מערכת מודולרית
- כאשר יש לך כמה דאגות לגבי הדיוק או השלמות של בדלי.
שלבים לאינטגרציות מצטברות מלמטה למעלה
- זהה מודולים מסדר נמוך יותר
- בדיקת יחידה מודולים מסדר נמוך כדי לאמת את הפונקציונליות האישית שלהם
- פתח דרייברים שישמשו כמתווכים עם מודולים מסדר נמוך יותר
- צור בולים כדי לדמות את ההתנהגות של מודולים מסדר גבוה יותר
- שלב את המודולים הבאים, מסדר נמוך לגבוה יותר, והחלף בהדרגה את הסטאבים בהטמעות אמיתיות
- מנהלי התקנים מחזירים כדי להתאים את המודולים החדשים
- חזור על הפעולה עד שכל המודולים מסדר גבוה יותר משולבים ונבדקים.
3. אינטגרציה מצטברת פונקציונלית
בדיקות אינקרמנטליות של פונקציות הן הסוג הנפוץ הבא של בדיקות מצטברות בבדיקות תוכנה. בעוד ששני הסוגים הקודמים התמקדו במודולים מסדר גבוה ונמוך יותר, בדיקות מצטברות פונקציונליות מבוססות על הפונקציונליות של מודול מסוים.
נעשה שימוש באינטגרציה מצטברת פונקציונלית במתודולוגיות Agile/DevOps , וזו בחירה מצוינת עבור יישומים עם תלות מורכבת בין מודולים או רכיבים.
שלבים לאינטגרציה מצטברת פונקציונלית
- זהה מודולים ורכיבים בודדים עם ממשקים מוגדרים היטב
- ודא את הפונקציונליות של כל מודול באמצעות בדיקת יחידה
- שלב את מודולי הליבה המינימליים ביותר של המערכת והבטח שהיא תפעל
- הוסף בהדרגה מודולים בודדים, תוך בדיקת פונקציונליות בכל שלב
- שחזר את הקוד כאשר כל מודול נוסף
- כאשר כל המודולים מתווספים, בדוק את הפונקציונליות והביצועים
יתרונות וחסרונות של גישת בדיקות מצטברות
עד עכשיו, אתה אמור לקבל מושג מדוע בדיקה מצטברת היא גישה פופולרית. עם זאת, כמו כל מתודולוגיות בדיקת תוכנה, יש לה יתרונות וחסרונות. בואו נחקור כמה מהיתרונות והחסרונות הללו.
היתרונות של גישת בדיקות מצטברות
1. גמישות
כפי שכל מפתחי התוכנה והבודקים יודעים טוב מדי, דרישות יכולות להשתנות ולהתפתח במהלך ה-SDLC, לפעמים באופן דרמטי למדי. בדיקות מצטברות דינמיות מספיק כדי לאפשר לצוותים להסתגל במהלך תהליך הבדיקה ולשלב תוכניות וכיוונים חדשים.
2. איתור באגים מוקדם
הזמן הטוב ביותר לזהות באג או פגם הוא מוקדם ככל האפשר. כאשר מפתחים מאמתים מודולים בגודל ביס בנפרד, זיהוי ותיקון בעיות הוא הרבה יותר קל. יתרה מכך, זה עוזר להפחית את הסבירות שבעיות גדולות יתרחשו מאוחר בפיתוח.
3. פשטות
בדיקת תוכנה יכולה להיות תהליך מורכב ביותר. אחד ההיבטים המשכנעים ביותר של בדיקות מצטברות נמצא באופן שבו היא מפרקת את העיר הבודקת לחלקים מעשיים. במקום להתמודד עם מורכבות מכריעה, בודקים יכולים להתמקד ואפילו לתעדף מודולים מסוימים. הטבה זו היא מתנה משמים עבור יישומים גדולים ומורכבים.
4. סיכון רגרסיה נמוך יותר
רגרסיה היא נושא שלוקח זמן ומורכב בפיתוח תוכנה. בדיקות מצטברות יכולות להפחית את התדירות והסיכונים הנגרמים עקב רגרסיה מכיוון שהיא מאפשרת לצוותים לבדוק מודולים בנפרד ולטפל בבעיות כשהן מתרחשות. בשימוש עם מוצק בדיקות רגרסיה , צוותים יכולים לחסוך הרבה זמן ועוגמת נפש.
5. הזדמנויות משוב
היתרון הנשכח לעתים קרובות של בדיקות מצטברות הוא שהוא מאפשר לצוותים את מרחב הרוחב להרכיב אבות טיפוס ו-MVPs. משם, בעלי עניין ומשקיעים יכולים להעריך את הפונקציונליות הבסיסית של התהליך ולספק משוב שלא יסולא בפז. מצב זה יכול לחסוך הרבה זמן וכסף ולהוביל למוצרים חזקים יותר.
חסרונות של גישת בדיקות מצטברות
1. בעיות אינטגרציה
בדיקת מודולים בנפרד היא רצויה מכיוון שהיא מפרקת יישום מורכב לנתחים שניתנים לניהול. עם זאת, שילוב מודולים אלה עלול לגרום לשגיאות חדשות ובלתי צפויות. ככזה, גישת בדיקה מצטברת חייבת להיות מתוכננת בקפידה ובמכוון.
2. מורכבות חבילת הבדיקה
עם מקרי בדיקה מרובים עבור כל מודול והאינטראקציה שלהם זה עם זה, חבילות בדיקה יכולות להיות מורכבות למעקב ולניהול. עבור אפליקציות גדולות ומסובכות, זה הופך תיעוד יסודי או כלי ניהול בדיקות להכרח.
3. עוד עבודה
בדיקה מונוליתית, אמנם מורכבת יותר, אך דורשת פחות בדיקות. על ידי בדיקת המון מודולים בנפרד, בדיקות מצטברות דורשות יותר עבודה. עם זאת, היתרונות של בדיקות מצטברות, כגון גילוי מוקדם של באגים, אומר שמאמץ נוסף הוא השקעה חוסכת זמן. כמובן, אוטומציה של בדיקות תוכנה יכולה לעזור להפחית מאמצים אלה.
4. הגברת דרישות ההנהלה
בדיקות מצטברות דורשות צוותים מרובים לעבוד יחד. לדוגמה, צוותי פיתוח, בדיקות ו-DevOps יצטרכו לעבוד ביחד. מצב זה יוצר ביקוש נוסף של ההנהלה ודורש תקשורת טובה בין הצוותים הללו כדי להבטיח שהם ממוקדים ומושכים לאותן יעדים.
דוגמה לבדיקה מצטברת
אולי הדרך הקלה ביותר להבין גישת בדיקה מצטברת היא לחשוב על דוגמה. הנה מצב פשוט שיעזור לדמיין את התהליך.
1. דוגמה לבדיקה מצטברת לאפליקציית בנקאות סלולרית
תַרחִישׁ: צוות בונה אפליקציית בנקאות ניידת. האפליקציה מורכבת ממספר מודולים שונים המאפשרים:
- 2FA ואימות משתמש ביומטרי
- עיבוד עסקה
- לוח מחוונים לניהול נתונים פיננסיים
מַטָרָה: הצוות רוצה לבדוק את האינטגרציה של כל מודול ולקבוע אם הם עובדים טוב ביחד. כתוצאה מכך, הם בונים שלושה מקרי מבחן.
מקרה מבחן 1
במקרה המבחן הראשון, הצוות רוצה להבטיח כי על ידי הזנת נתונים ביומטריים או סיסמא, המשתמש יקבל גישה הן לעיבוד העסקאות והן ללוח המחוונים של ניהול הנתונים הפיננסיים.
האפליקציה תעבור את המבחן אם המשתמש יוכל להזין את פרטיו ולקבל את היכולת לגשת לעסקאות.
מקרה מבחן 2
מקרה המבחן הבא נועד לראות כיצד האפליקציה מטפלת בעסקאות לא מורשות.
האפליקציה עוברת את הבדיקה אם נחסם ניסיון לבצע עסקה לא מורשית והאפליקציה מפיקה הודעת שגיאה.
מקרה מבחן 3
מבחן האינטגרציה הסופי כולל אימות אם האפליקציה יכולה לבצע עסקאות במקביל.
האפליקציה תעבור את המבחן אם המשתמש יכול להתחיל עסקה ולגשת למידע הפיננסי שלו בו-זמנית ללא חוסר עקביות או בעיות בנתונים.
האם גישת בדיקת אינקרמנטליות היא
זהה לבדיקות מצטברות?
לא. בדיקת אינקרמנטליות מתייחסת לשיטת שיווק סטטיסטית המוכרת אולי כדוגמת ייחוס. בקיצור, זה עוזר לצוותי שיווק להבין את ההשפעה של מסעות פרסום, ערוצי שיווק או אסטרטגיות מסוימות.
בעוד שהעניין במודלים מסוג זה גדל בשנים האחרונות הודות ל”מוות” של קובצי Cookie ונתוני צד שלישי, הקשר היחיד שיש לו לבדיקות מצטברות הוא מילה משותפת.
3 הכלים המובילים לבדיקות מצטברות
#1. ZAPTEST
כמו גם מתן RPA מהשורה הראשונה היכולות, ZAPTEST מציעה מגוון של כלי אוטומציה לבדיקות תוכנה המושלמים לבדיקות מצטברות. חלק מהתכונות כוללות:
- ניהול נתוני בדיקה : צמצם את כמות הזמן והמאמץ הכרוכים בבדיקות מצטברות על ידי מתן אפשרות לצוותים לעשות שימוש חוזר בנתוני בדיקה
- הקלטת סקריפטים והשמעה : כלי ללא קוד זה מאפשר לצוותים להקליט ולבצע סקריפטים ולחסוך זמן רב במהלך בדיקות מצטברות
- מודולי בדיקה ניתנים לשימוש חוזר : ZAPTEST הוא מודולרי ביותר ומאפשר לצוותים ליצור ולעשות שימוש חוזר במודולי בדיקה ולגלח כמויות משמעותיות של זמן הפסקה בתהליך הבדיקה.
בסך הכל, ZAPTEST מציעה חבילת אוטומציית בדיקות עוצמתית ומגוונת המתאימה לכל סוג של בדיקות, כולל בדיקות מצטברות.
#2. סֵלֶנִיוּם
Selenium היא פלטפורמת אוטומציה של בדיקות בקוד פתוח שנבנתה כדי להקל על בדיקות יישומים ניידים. הכלים תומכים במספר פלטפורמות ניידות (אנדרואיד, iOS, Windows) ומשתמשים בסטאב ובמנהלי התקנים כדי לדמות מודולים.
#3. Testsigma
Testsigma היא פלטפורמת אוטומציית בדיקות מבוססת ענן. ניתן להשתמש בו לבדיקת אפליקציות אינטרנט ומובייל והוא מתאים לבדיקות מצטברות הודות ליצירת בדיקות ללא קוד ואינטגרציה עם צינורות CI/CD.
מחשבות אחרונות
בדיקות מצטברות בבדיקות תוכנה הן חלק חשוב בבדיקות אינטגרציה. זה מאפשר לצוותים לפרק מודולים לחלקים הניתנים לבדיקה בקלות לפני שילוב איטי שלהם. היתרונות כאן הם שניתן לאמת כל מודול עבור באגים ולאחר מכן כיצד הוא משתלב עם החלקים המחוברים שלו.
לצד ה-RPA הטוב ביותר מסוגו כלים, ZAPTEST מציעה אוטומציה של בדיקות תוכנה ללא קוד שהיא גם בין פלטפורמות וגם בין יישומים. יתר על כן, חבילת הבדיקות שלנו מגיעה עמוסה בתכונות כמו שילוב CI/CD, דיווח וניתוח חזקים ותמיכה ושירות לקוחות מהשורה הראשונה.
