בדיקה ותחזוקה
הוצג| English | משמעות |
|---|---|
| run-time error/rʌn taɪm ˈerə/ | שגיאת ריצה |
| syntax error/ˈsɪntæks ˈerə/ | שגיאת סינטקס |
| logic error/ˈlɒdʒɪk ˈerə/ | שגיאת לוגיקה |
| dry run/draɪ rʌn/ | ריצת יבשה |
| walkthrough/ˈwɔːkθruː/ | סקירה |
| white-box testing/waɪt bɒks ˈtestɪŋ/ | בדיקה תיבת לבנה |
| black-box testing/blæk bɒks ˈtestɪŋ/ | בדיקה תיבת שחורה |
| integration testing/ˌɪntɪˈɡreɪʃn ˈtestɪŋ/ | בדיקה משולבת |
| stub/stʌb/ | תומך (stub) |
| alpha testing/ˈælfə ˈtestɪŋ/ | בדיקה אלפא |
| beta testing/ˈbiːtə ˈtestɪŋ/ | בדיקה בטא |
| acceptance testing/əkˈseptəns ˈtestɪŋ/ | בדיקת קבלה |
| test strategy/test ˈstrætədʒi/ | אסטרטגיית בדיקה |
| test plan/test plæn/ | תוכנית בדיקה |
| normal data/ˈnɔːml ˈdeɪtə/ | נתונים תקינים |
| abnormal data/əbˈnɔːml ˈdeɪtə/ | נתונים חריגים |
| extreme data/ekˈstriːm ˈdeɪtə/ | נתוני קצה |
| boundary data/ˈbaʊndəri ˈdeɪtə/ | נתוני גבול |
| corrective maintenance/kəˈrektɪv ˈmeɪntənəns/ | תחזוקה תיקונית |
| adaptive maintenance/əˈdæptɪv ˈmeɪntənəns/ | תחזוקה אדפטיבית |
| perfective maintenance/pəˈfektɪv ˈmeɪntənəns/ | תחזוקה משופרת |
| regression testing/rɪˈɡreʃn ˈtestɪŋ/ | בדיקה מחזורית |
שלושים ושבע שניות
- ב-4 ביוני 1996 שוקקה הטיל אריאן הראשון 5 מהגויאנה הצרפתית. לאחר 37 שניות הוא סטה ממסלולו והתפוצץ. המטען הכולל ארבעה לוויינים בשווי $370 מיליון.
- הגורם היה שורת קוד אחת, שנעשה שימוש בה באריאן 4, שהמירה מס 64-ביט לשלם 16-ביט. אריאן 5 טסה מהר יותר, המספר היה גדול יותר, וההמרה גרמה לשפיכת ערך (overflow): שגיאת ריצה בפרוצדורה שלא הייתה אפילו נחוצה לאחר ההשקה.
- הקוד לעולם לא נבדק עם נתוני הטיסה של אריאן 5. אף אחד לא בחר נתוני בדיקה בקצוות הטווח של הרקטה החדשה.
- לקח זה עוסק בשלושת סוגי השגיאות, בשיטות הבדיקה, כיצד לבחור נתוני בדיקה, וכיצד לתמרן תוכנית לאחר השקה.
שלושה סוגי שגיאות
- שגיאת סינטקס שוברת את הדקדוק של השפה: סוגריה חסר, מילה מופרעת. היא נמצאת בתרגום, ולכן התוכנית לא תפעל עד שתוקן.
- שגיאת ריצה מתרחשת בזמן הפעלת התוכנית: חלוקה באפס, קובץ שאינו קיים, אינדקס מטריצה מחוץ לטווח. התוכנית קורסת או מזהירה על יוצא דופן; התיקון הוא בדיקה לפני הפעולה המסוכנת.
- שגיאת לוגיקה מאפשרת לתוכנית לפעול ולהפיק תוצאות שגויות:
+עבור-, לולאה עם טעות של אחד, תנאים בסדר הלא נכון. אין שום דבר שמזהיר עליה; רק בדיקה ומעקב חושפים אותה.
נמצאת בתרגום, נמצאת בזמן ריצה, נמצאת רק בתוצאה
התאם כל סוג שגיאה לכיצ היא מופיעה.
Difficulty 2/5 · 140 coins + a small bonus on first completion today
שגיאת סינטקסis נאחזת בזמן התרגום; לוגיקה = תוצאה שגויה; בזמן ריצה = קריסה בעת הביצוע.
דוגמא מפורטת: מציאת שגיאות ותיקונן
Total ← 0
FOR i ← 1 TO Count
Total ← Total + Marks[i]
NEXT i
Average ← Total / Count
IF Average > 50 THEN
OUTPUT "Pass"
- סינטקס: ה
IFחסר לוENDIF. המתרגם דוחה אותו. רציה: אםCountהוא 0 החלוקה נכשל; יש לסגן זאת עםIF Count > 0 THEN. לוגיקה: אם ציון מעבר הוא 50 או יותר, ה> 50מפיל סטודנט עם בדיוק 50; אמור להיות>= 50. - קרא את הסוג, הסבר מדוע זהו הסוג, ותן את התיקון. שלושה חלקים, שלוש נקודות.
תוכנית מחלקת סכום כולל במספר הרשומות ונקרסת כאשר קובץ הקלט הוא ריק. זהו:
Difficulty 1/5 · 100 coins + a small bonus on first completion today
חלוקה באפס מתרחשת בזמן ביצוע התוכנית ומעצרת אותה. שמירה כמו IF Count > 0 פותרת את הבעיה.
שיטות בדיקה: קריאת הקוד
- בדיקה יבשה (Dry run) עוקבת אחר הקוד על נייר, וכותבת את ערך כל משתנה בטבלת מעקב לאחר כל שורה.
- סיור דרך הקוד (Walkthrough) הוא ביקורת צוות: המתכנן מסביר את הקוד שורה אחר שורה בעוד שהעמיתים מחפשים תקלות.
- בדיקת תיבה לבנה (White-box testing) מתכננת בדיקות על בסיס המבנה הפנימי של הקוד, כך שכל הודעה, ענף ולולאה יוצאים לפועל. בדיקת תיבה שחורה (Black-box testing) מתכננת בדיקות על בסיס הספק בלבד: מזינים קלטות, משווה תוצאות למה שצפוי, מבלי להסתכל בקוד.
מבחוץ פנימה, או מפנימה ומסתכלת על כל מסלול
עיצוב מקרי בדיקה על בסיס המפרט בלבד (קלט ותוצאות צפויות), תוך התעלמות מהקוד הפנימי, נקרא בדיקת קופסה ______.
Difficulty 1/5 · 100 coins + a small bonus on first completion today
בדיקות קופסה שחורה מבוססות על המפרט; קופסה לבנה משתמשת במבנה הפנימי של הקוד כדי לכסות פקודות וענפים.
שיטות בדיקה: הרכבה ושחרור
- בדיקת אינטגרציה משלבת מודולים שנבדקו בנפרד ובודקת את הממשקים ביניהם. מודול חלופי (Stub) משמש כמקום לחלופה למודול שעדיין לא נכתב, ומחזיר ערכים קבועים כדי שאר החלקים יוכלו להיבדק מלמעלה למטה.
- בדיקת אלפא (α) נערכת בתוך הארגון על ידי המתכננים לפני השחרור. בדיקת בטא (β) נותנת קבוצה מוגבלת של משתמשים אמיתיים את התוכנה בסביבה שלהם.
- בדיקת קבלה נערכת על ידי הלקוח, בהתאם לדרישות, כדי לקבוע האם המוצר מתאים למטרתו.
מעבדת תהליך תוכנה
סווגו דוגמאות פיתוח לפי השלב או הכלי שבהם הן שייכות.
דוגמה מפורטת: איזה שיטה למצב איזה
- מודול הדיווח מוגמר אך מודול הבנקים שהוא קורא עוד לא קיים: לבדוק אותו עם מודול חלופי שמחזיר נתונים קבועים.
- שני מודולים עוברים את הבדיקות שלהם אך כושלים כאשר התוצאה של אחד מאכנת את השני: בדיקת אינטגרציה של הממשק.
- התוכנה מוגמרת; החברה רוצה שתגלו תקלות בתנאי אמיתיים לפני השחרור הכללי: בדיקת בטא על ידי קבוצה מוגבלת של משתמשים.
- הלקוח מחליט אם לשלם: בדיקת קבלה בהתאם לדרישות הנסכמות. קראו את השיטה וגם מה היא נועדה לעשות.
התאם כל מצב לשיטת הבדיקה המתאימה לו.
Difficulty 2/5 · 140 coins + a small bonus on first completion today
Stub עבור חלק חסר, beta למשתמשים אמיתיים, קבלה עבור הלקוח, אינטגרציה עבור החיבורים.
אסטרטגיית בדיקה ותוכנית בדיקה
- אסטרטגיית בדיקה היא הגישה ברמת הגובה: איזה סוגי בדיקות ייעשו, על ידי מי, מתי, ומה חייב לעבור לפני השלב הבא.
- תוכנית בדיקה היא הרשימה המפורטת של הבדיקות. עבור כל אחת: המטרה, נתוני הקלט, התוצאה המצופה, ועמודה לתוצאה האמיתית כאשר הבדיקה מופעלת.
- בדיקה ללא תוצאה מצופה אינה בדיקה. היא מראה רק מה התוכנה עשתה, ולא האם היה זה נכון.
תוכנית בדיקה מפרטת, עבור כל בדיקה, את נתוני הקלט והתוצאה הצפויה.
Difficulty 1/5 · 100 coins + a small bonus on first completion today
מטרה, קלט, תוצאה צפויה ועמודה לתוצאה בפועל. האסטרטגיה היא הגישה ברמת-על; התוכנית היא הרשימה המפורטת.
בחירת נתוני בדיקה
- נתונים תקינים: ערכים סטנדרטיים וקבילים בתוך הטווח, אשר צריכים להתקבל ולעבור עיבוד נכון.
- נתונים לא תקינים: ערכים שיש לדחות, מחוץ לטווח או מהסוג הלא נכון.
- נתונים קיצוניים: הערכים הגדולים והקטנים ביותר שעדיין מתקבלים, בקצוות הטווח. נתוני גבול: הזוגות החוצים את כל קצה, הערך הקיצוני המקובל והערך הדחוי מיד מחוצה לו, שם טעויות אי-התאמה (off-by-one) נסתרות.
בתוך, מחוץ, ובדיוק על הקו
לשדה המקבל ציונים 0–100, אילו ערכי בדיקת גבול הם הנדרשים?
Difficulty 1/5 · 100 coins + a small bonus on first completion today
נתוני גבול נמצאים בקצוות הטווח תקף (וגם מעט מחוצה לו) — שם טעויות ספירה נסתרות.
דוגמא פתורה: נתוני בדיקה לציון מ-0 עד 100
| סוג | נתונים | תוצאה מצופה |
|---|---|---|
| תקינים | 50, 75 |
מתקבלים ועוברי עיבוד |
| לא תקינים | -10, 200, "abc" |
נדחים: מחוץ לטווח או סוג שגוי |
| קיצוניים | 0, 100 |
מתקבלים: הערכים הקטנים והגדולים הקבילים ביותר |
| גבול | -1 ו0, 100 ו101 |
-1 נדחה, 0 מתקבל; 100 מתקבל, 101 נדחה |
- לכל שורה יש תוצאה מצופה; טבלה של כניסות בלבד מקבלת חצי נקודות. הקיצוניים מתקבלים:
-1הוא נתון גבול, לא קיצוני.
שדה מקבל ציונים מ-0 עד 100. אילו ערכים הם מבחני קצה? בחרו את כולם החלופות המתאימות.
Difficulty 2/5 · 140 coins + a small bonus on first completion today
ערכי קצה הם הקטן והגדול שעדיין מתקבלים. -1 נדחה, ולכן הוא גבולי או חריג; 50 הוא נורמלי.
תחזוקה
- רוב עלות המחזור החיים של תוכנה מושקעת לאחר השקתה. תחזוקה תיקונית מתקנת באגים שנמצאו במהלך השימוש.
- תחזוקה אדפטיבית שומרת על פעילות התוכנה בסביבה משתנה: מערכת הפעלה חדשה, API חדש, שינוי בחוק.
- תחזוקה מושלמת משפרת תוכנה שכבר פועלת: ביצועים מהירים יותר, תכונה חדשה שהמשתמשים ביקשו. ייתכן שתוכנה תזדקק לשלושת הסוגים הללו לאורך כל מחזור חייה.
תיקון, שמירה על פעילות, שיפור
תחזוקה תיקונית פותרת תקלות, תחזוקה משכרלת משפרת מאפיינים, ותחזוקה מותאמת שמרה על התוכנה פועלת בסביבה משתנה.
Difficulty 1/5 · 100 coins + a small bonus on first completion today
שלושה סוגי תחזוקה: תיקונית (תיקון באגים), משכרלת (שיפור), מותאמת (מערכת הפעלה חדשה/חומרה/חוקים).
תוכנית שכר שונתה מכיוון שהחוק למיסוי השתנה. איזה סוג של תחזוקה זה?
Difficulty 1/5 · 100 coins + a small bonus on first completion today
התוכנה לא הייתה פגומה ואינה משודרגת; הסביבה שלה השתנתה. זו תחזוקה מותאמת.
שינוי תוכנה קיימת
- קראו את הקוד הקיים עד שתבינו את האלגוריתם ואת זרימת הנתונים. מצאו היכן השינוי צריך להיכנס: לאילו תת-תוכנית, לאילו שורות.
- ביצע את השינוי כקטן ככל האפשר; אל תכתוב מחדר קוד שפועל. עדכן כל חלק רלוונטי: כל קורא של רשימת פרמטרים משתנה, כל פונקציה שמשתמעת במבנת נתונים משתנה.
- בדיק את ההתנהגות החדשה וגם הישנה: בדיקות נסיגה (regression testing) ודאות שאין דבר שהיה עובד הפך לשבור. לאחר מכן מסמן את השינוי.
לאחר שינוי בתוכנה, בדיקת רגרסיה בוודא:
Difficulty 1/5 · 100 coins + a small bonus on first completion today
בדיקת רגרסיה מבצעת מחדש בדיקות ישנות כדי לאמת שההתנהגות הקיימת עדיין עובדת לאחר שינוי.
סדרו את שלבי שינוי בתוכנה קיימת.
Difficulty 3/5 · 200 coins + a small bonus on first completion today
הבן, מיקם, שנה קטן, הפץ, בדוק הכל, תעד. דילוג על בדיקת השבת הוא מה שגורם לתיקון להפריע למשהו אחר.
סימונים נופלים מהיד
- קיצוני מתקבל; חריג נדחה.
0ו-100הם קיצוניים;-1ו-101הם ערכי גבול בצד הנדחק. - טעות לוגית אינה גורמת לתכנית להתמוטט. אם התמוטטה, זו הייתה טעות בזמן הרצה.
- אלפא היא פנימית; בטה היא משתמשים אמיתיים מחוץ. סטאב (stub) מחליף מודול חסר; הוא אינו שיטת בדיקה לקוד מוגמר.
- שורת תוכנית בדיקה ללא תוצאה צפויה אינה זוכה לנקודות. בדיקות נסיגה עוקבות אחר כל שינוי.
הבנתך מושלמת
- שגיאות סינטקס עצרות תרגום · שגיאות זמן הרצה גורמות לתכנית בתנועה להתמוטט · שגיאות לוגיות רצות ומחזירות תוצאה שגויה, נמצאות רק על ידי בדיקה
- שיטות: ריצון יבש, סיור (walkthrough), תיבה לבנה (מהקוד), תיבה שחורה (מהמפרט), אינטגרציה (ממשקים, עם סטאבים למודולים חסרים), אלפא (פנימית), בטה (משתמשים אמיתיים), קבלה (הלקוח)
- נתוני בדיקה: נורמלי מתקבל, חריג נדחה, קיצוני הקצוות המתקבלים, גבול בשני צדי כל קצה; לכל בדיקה יש תוצאה מצופה
- תחזוקה: תיקון מתקנים, הסתגלות שומרת על מערכת העבודה, שיפור משפר; לערוך קטן, עדכן קוראים, בדיק נסיגה