משתמש:Shiransi5/בדיקות פרויקט תוכנה גדול

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

תוכן הערך שנמחק:

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

הקדמה

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

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

החידוש שבבדיקות תוכנה בפרויקטים גדולים

בהשוואה בין תוכנה רגילה לתוכנה גדולה נגדיר:

• תוכנה רגילה: עד כ-8,000 שורות קוד

הבדלים מהותיים בין תוכנה רגילה לגדולה

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

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

שיטות נפוצות

בין השיטות שהתפתחו בצורה מיוחדת ומורחבת בעקבות הצורך במתן מענה הולם לבדיקות פרויקטי תוכנה גדולים:

בדיקות אוטומטיות (Automated Testing)

הדגש בבדיקות אוטומטיות הוא על השילוב בין כלים אוטומטיים. פרויקטים גדולים רבים נבדקו בהצלחה תוך שימוש משולב בכלים רבים ושונים (דוגמת Java Pathfinder שפותח לראשונה בנאס"א). לעיתים יפותחו כלים יעודיים לפרוייקט מסויים (על ידי הארגון עצמו או חברה חיצונית), ואלו יתאימו לצרכים המיוחדים של בדיקות הפרויקט הספציפי. חלק מהכלים הם כלים הנפוצים בשוק ואינם יעודיים לפרויקט ספציפי, את אלו ניתן לרכוש או להשיג כקוד פתוח ואף לערוך לו התאמות לפרויקט. ארגונים רבים ניגשים למשימת פיתוח כלים אוטומטיים לבדיקות תוכנה, החל מבתי תוכנה וכלה באוניבריטאות (דוגמת הכלים "MOSP" ו-"BLAST" שפותחו על ידי אוניברסיטת קליפורניה).

בדיקות נסיגה (Regression Testing)

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

בדיקות תוכנה זריזות (Agile Testing)

יותר ויותר חברות עוברות לעבודה בשיטת פיתוח תוכנה זריז וכך גם בנושא בדיקות תוכנה זריזות. יש הטוענים שקיים קושי ביישום השיטה כאשר מדובר במערכות בקנה מידה גדול, אמנם באחד מביצועי השיטה עם התמקדות על Extreme Programming, אחת משיטות הפיתוח המהירות, בעיקר עם פיתוח מונחה בדיקות, נרשמה הורדה משמעותית בכמות הבאגים בתוכנה והפרויקט כולו רץ בצורה חלקה.

ראו גם

• מדעי המחשב
• הנדסת תוכנה
• הבטחת איכות

לקריאה נוספת

• George Lawton ,Faster Testing for Complex Software Systems
• Alessandro Orso, Nanjuan Shi, and Mary Jean Harrold ,Scaling Regression Testing to Large Software Systems
• David Talby and Arie Keren, Orit Hazzan and Yael Dubinsky, Agile Software Testing in a Large-Scale Project