בדיקות נסיגה
 |
הערך נמצא בשלבי עבודה במסגרת מיזם הכתיבה של ויקיפדיה והוא פתוח לעריכה. השלמות, תוספות והערות יתקבלו בברכה. | ||
| ערך זה נכתב בשיתוף פעולה עם אוניברסיטת בן גוריון בנגב במסגרת הקורס "הנדסת איכות בתוכנה". הקורס יסתיים בתאריך 15 ביוני 2012. | |||
בדיקות נסיגה (באנגלית: Regression testing) הן כל סוג של בדיקות תוכנה שמטרתם למצוא באגים חדשים בתוכנה (באנגלית: software bugs), או רגרסיה פונקציונאליות קיימת או לא קיימת של תוכנה אחרי שינוי, כמו שיפור הוספה או שינוי בקונפיגורציה. בדיקות המבוצעות על מנת להשוות יכולות וביצועים בין גרסאות של אותה תוכנה.
מטרת בדיקות הנסיגה היא לוודא כי כל תפקודי התוכנה ויכולותיה מגרסאות העבר לא נפגעו כתוצאה משינויים בגרסה הנוכחית כדי להימנע מרגרסיה. במסגרת בדיקות הנסיגה מתבצעת בדיקה המוכיחה שהשינויים שהוכנסו לתוכנה עונים על הדרישה שבינה הוכנסו ואחריה מתבצעת סדרת בדיקות המבקשת להוכיח שאוסף דרישות קודמות עדיין מקבלות מענה בתוכנה. אחת המטרות הבולטות לביצוע בדיקות רגרסיה (תוכנה) היא לקבוע האם השינוי האחרון שנעשה בתוכנה משפיע על חלקים אחרים בתוכנה.
שיטות נפוצות בבדיקות רגרסיה, היא הרצה חוזרת של טסטים ובדיקה האם ישנם שינויים בהתנהגות התוכנה והאם שינויים ישנים של תקלות התגלו מחדש. בדיקות רגרסיה יכולות לשמש לבדיקות יכולת של התוכנה, פשוט ע"י בחירה של טסטים מינימאלים נכונים באופן שיטתי, שבמידה מספקת יכסה אזור מסויים שבו השינוי.
היקף הבדיקות המתבצעות במסגרת בדיקות נסיגה יכול לנוע מבדיקות תוכנה הנערכות על ידי אנשי הבטחת איכות ומכסות דרישות של מערכת שלמה, עד לבדיקות יחידה, בהן מוודא מתכנת כי שינוי בקוד יחידה בודדת אינו פוגע בדרישות קודמות שלה.
תאורטית, יש להריץ את כל תסריטי הבדיקה הקיימים עבור כל גרסת תוכנה, על מנת לוודא כי לא חלה נסיגה בהתנהגות התוכנה או בביצועיה. למעשה, ניתן לצמצם את כמות הבדיקות על ידי ניהול תהליך בדיקות מונחה סיכונים ועל ידי ניתוח השינויים הכלולים בגרסה האחרונה והשפעתם על רכיבים ותהליכים שונים בתוכנה הנבדקת. עם זאת, צמצום כזה כרוך בסיכון מסוים להחמצת נסיגה קיימת בתפקוד התוכנה (בשל השפעות בלתי צפויות של השינויים).
תוכן עניינים |
[עריכה] רקע
הניסיון מלמד אותנו שכאשר מתקנים תוכנה, מופיע באג חדש או מתגלה מחדש באג ישן. לפעמים הופעה מחדש של באג קורת בגלל שתיקון הולך לאיבוד בשל ניסיון דל בניהול גרסאות (או בשל טעות אנוש פשוטה לניהול גרסאות). בהרבה מקרים תיקון של בעיה יהיה "שביר", מכיוון שהוא יפתור את הבעיה נקודתית, איפה שהבעיה נצפתה לראשונה, אך הוא לא יטפל במקרה הכללי שעלול להסתבך במהלך השנים של התוכנה.
לעיתים קרובות, תיקון של בעיה באזור אחת, בהיסח דעת גורם לבאג בתוכנה במקום אחר. לפעמים כשפונקציונאליות אחת משתנה , חלק מאותם התקלות שנצפו בהטמעה של הפונקציונאליות המקורית חוזרות על עצמם גם בשינוי. לכן ברוב המקרים של פיתוח תוכנה כאשר באג מתקלה ומתוקן, הטסט שחשף את הבאג מוקלט ונבדק באופן קבוע אחרי שינוי משמעותי בתוכנה. למרות שזה בדרך כלל נעשה באופן ידני, לעיתים קרובות זה גם נעשה ע"י כלים של בדיקות אוטומטיות. כמו רצף של בדיקות ב(אנגלית:test suite ) שמכילים כלי תוכנה המאפשרים סביבת בדיקה המאפשרת להריץ את כל בדיקות הנסיגה (רגרסיה) אוטומטית. חלק מהפרוייקטים בונים מערכות אוטומטיות שבאופן אוטומטי יריץ מחדש את כל בדיקות הרגרסיה בחלקים מוגדרים מראש ותוציא דוח תקלות, אסטרטגיות נפוצות היא הרצה של מערכות אלו בכל קימפול, כל לילה או אחת לשבוע.
בדיקות נסיגה הם חלק חשוב בשיטות פיתוח תוכנה, בשיטה זו מסמכי הדרישה מוחלפים בבדיקות חוזרות ואוטומטיות, של כל חבילות התוכנה במהלך כל שלב מעגל פיתוח תוכנה.
[עריכה] דוגמה לבדיקות רגרסיה
•יכולה להיות כאשר המערכת עבדה היטב על דפדפן אקספלורר וכעת ברצוננו לבדוק האם המערכת עובדת ונתמכת על ידי דפדפן Firefox.
•כמו כן בדיקות נסיגה יכולות להיות לאחר שהפיתוח העלה גרסה חדשה אשר כוללת בתוכה מודול חדש ולאחר ניהול הסיכונים והבנת השינויים עולה הנקודה כי מודולים מסוימים יכולים להיפגע כתוצאה מהוספת המודול החדש (מכיוון ויש ממשק חדש בין המודולים), ולכן המודולים הקיימים במערכת הישנה יבדקו פעם נוספת.
[עריכה] איך נריץ בדיקות רגרסיה
בעצם אם נריץ בדיקות שונות , אחרי כל שינוי לא יהיה לנו דרך לדעת בוודאות שבאג חדש נוצר.לכן בדיקות רגרסיה צריכות לרוץ באופן עקבי עם אותן בדיקות בכל פעם. בדיקות חדשות מתווספות על פונקציונאליות חדשה, אך הבדיקות הישנות מתווספות גם הן. כמו כל בדיקה גם בדיקות רגרסיה צריכות תכנון תואם. בשביל בדיקות אפקטיביות של רגרסיה המרכיבים הבאים הכרחיים:
1. צור תוכנית בדיקה לרגרסיה
• אזורים שתתמקד בהם בדיקות כניסה ויציאה
• אפשר גם להתמקד בהדגשה של דרישות הקדם לTC , הגדרת אחריות וכו'
2. יצירת ה- TC
• TC צריך לכסות אזור שלם, צריך להיות מוגדר בו מה בודקים איך בודקים ומה מצופה בסיומו.
• ציין את הפונקציונאליות שנבדקת, ואת הפונקציונאליות שעלולה להיפגע משינוי
3. מעקב אחרי דפקטים
• כמו בכל סוגי הבדיקה מאוד חשוב שיהיה מעקב סדרתי על באגים אחרת יורד ערכם של הטסטים.
[עריכה] איך נקבע את היקף הרגרסיה
מטרת בדיקות הרגרסיה היא להרוויח ביטחון בתוכנה, בעצם בדיקה שהשינויים האחרונים לא פגעו בפונקציונאליות הקיימת. את זה ניתן להשיג ע"י הרצה של סט הרגרסיה כאשר התוכנית החדשה והישנה מניבות תוצאות שונות. לכן בהינתן תוכנה P סט טסטים T התוכנית ששונתה P’ נצטרך למצוא T’ המוכל ב- T.
[עריכה] בחירה ותעדוף
האם נצטרך להריץ מחדש סט שלם של בדיקות רגרסיה? אם כן באיזה סדר?
יכול להיות בעצם לא אכפת לנו, אם אתה יכול להריץ את סט בדיקות הנסיגה אוטומטית בזמן ארוחת הצהרים למה לא?
מתי הבחירה חשובה? בעצם כאשר סט בדיקות הנסיגה יקר לביצוע, מכיוון שהוא דורש ציוד מיוחד, זמן הרצה ארוך, או שאי אפשר להריץ אותם במלואם
מתי הסדר חשוב? כאשר לא ניתן להריץ סט של בדיקות עצום בכל יום.
[עריכה] בחירה מינימאלית של סט בדיקות
- נבחר מספר מינימאלי של בדיקות שיכסו את כל האלמנטים שנוגעים אליהם
- נבצע בחירה רנדומאלית עד שכל האלמנטים שנוגעים בדבר מכוסים לפחות ב- TC אחד.
