מבוא להנדסת תוכנה אימות ותקפות - 1 אימות ובדיקות Verification & Testing מקורות: S. R. Schach: Chapter 6 R. S. Pressman: Chapter ד. גלין ו-ז. בלובבנד, הבטחת איכות תוכנה, “אופוס”, 1995

מבוא להנדסת תוכנה אימות ותקפות - 2 שיטות בהנדסת תוכנה - תוכנית הקורס מבוא מודלים של מחזור חיי תוכנה הגדרת דרישות וניהולן ניתוח קלאסי ניתוח מונחה - עצמים תכן אימות ובדיקות קידוד ובדיקות יחידה מימוש ושילוב אחזקה והנדסה מחדש הבטחת איכות תוכנה

מבוא להנדסת תוכנה אימות ותקפות - 3 מה עומד על הפרק? אימות התהליךאימות התהליך –בדיקת הצעדים והשלבים במהלך הפיתוח מפתחיםנכון –האם אנו מפתחים נכון את המוצר? בדיקותבדיקות –שיטות בדיקה ללא הרצה –תיכנון בדיקת המוצר המוצר הנכון –האם אנו מפתחים את המוצר הנכון ? –עקרונות לבדיקת תוכנה –בדיקתיות (testability) על אופן ביצוע הבדיקות נדבר בפרק הבא...

מבוא להנדסת תוכנה אימות ותקפות - 4 איכות התוכנה Software Quality איכות  “ וורטואוזייות"איכות  “ וורטואוזייות" –חדשנות, אלגנטיות אישית - תכונות לא רלוונטיות איכות = מידת העמידה בדרישותאיכות = מידת העמידה בדרישות –דרישות פונקציונליות –דרישות טכנולוגיות –דרישות תקציב –דרישות זמן הבטחת איכות התוכנה (SQA)הבטחת איכות התוכנה (SQA) –הרבה מעבר לבדיקות –עצמאות ניהולית קבוצת פיתוח קבוצת הא”ת

מבוא להנדסת תוכנה אימות ותקפות - 5 אימות (Verification) בדיקות תוך כדי התהליךבדיקות תוך כדי התהליך –נועדו לוודא ששלב הסתיים כראוי בדיקות ללא הרצה (non-executional tests)בדיקות ללא הרצה (non-executional tests) –סקירה (walkthrough) –ביקורת (inspection) –סקר עמיתים (peer review) אימות אוטומטיאימות אוטומטי –הוכחת נכונות שילוב בדיקות במימוש המערכת (assert)שילוב בדיקות במימוש המערכת (assert)

מבוא להנדסת תוכנה אימות ותקפות - 6 סריקה (structured walkthrough ) עיון מפורט במוצר התוכנה, שורה שורה, עם מצגתעיון מפורט במוצר התוכנה, שורה שורה, עם מצגת –מפרט דרישות –תכן –קוד הרוב: מקבוצת הא"ת (SQA) + מקבוצת הפיתוחהרוב: מקבוצת הא"ת (SQA) + מקבוצת הפיתוח מטרות הסריקהמטרות הסריקה –גילוי שגיאות (כולל הפרת כללי תיכון/תכנות) ורישומן –בחינת חלופות שהוצעו –מתן משוב לצוות הפיתוח, בלי חלוקת ציונים –פורום לדיון ולהצעות כלי פיתוח, טכניקות, נסיון ביישום... הסריקה נועדה לאיתור שגיאות, ולא לתיקונן!

מבוא להנדסת תוכנה אימות ותקפות - 7 ביקורת (inspection) סקר (review) בעל כיסוי רחב יותר מאשר סריקהסקר (review) בעל כיסוי רחב יותר מאשר סריקה חמישה שלביםחמישה שלבים –מבוא (overview) מוצג ע”י אחד מהצוות, ואחריו מופץ המסמך למשתתפים –הכנה (preparation) המשתתפים מנסים להבין את פרטי המסמך נעזרים ברשימת של סוגי בעיות שכיחות מביקורות אחרות –ביקורת (inspection) מעבר יסודי על המסמך, למטרת איתור שגיאות (לא לתיקונן!) דו”ח כתוב של הממצאים מופץ ע”י מנחה הסקר (moderator) ביום שלמחרת –“שיפוץ” (rework) כותב המסמך מתקן את הטעון תיקון, על פי הערות הביקורת –מעקב (follow-up) באחריות מנחה הסקר לוודא שכל הטעון תיקון (או הבהרה) - אכן טופל (Fagan, 1976)

מבוא להנדסת תוכנה אימות ותקפות - 8 תקפות (Validation) בדיקת המוצר, או חלקיובדיקת המוצר, או חלקיו בדיקות בהרצה (execution-based testing)בדיקות בהרצה (execution-based testing) –מה בודקים? –עקרונות בדיקה רגע, רגע.... את הבדיקות עושים בסוף, אז למה לעסוק בזה עכשיו? כי יש להתאים את הניתוח, התכן והמימוש כך שאפשר יהיה בסוף לבדוק את הדרישות !

מבוא להנדסת תוכנה אימות ותקפות - 9 מה בודקים? תועלתתועלת –האם התוכנה עונה על צרכי הלקוח? נוחות השימוש פונקציות שימושיות יחס עלות/תועלת (cost-effectiveness) אמינותאמינות –תדירות התקלות וחומרתן זמן ממוצע בין תקלות –(MTBF = Mean Time Between Failures) זמן ממוצע לתקון –(MTTR = Mean Time To Repair) מהו הזמן (והמחיר!!!) הנדרש לתיקון תוצאות הכשל?

מבוא להנדסת תוכנה אימות ותקפות - 10 מה עוד בודקים? חוסן (robustness)חוסן (robustness) –טווח תנאי הפעולה –אפשרות לתוצאות בלתי-צפויות עם קלט חוקי –השפעת קלט לא חוקי ביצועים (performance)ביצועים (performance) –מידת העמידה באילוצים מקום זמן –תוכנת זמן-אמת

מבוא להנדסת תוכנה אימות ותקפות - 11 עקרונות לבדיקת תוכנה (1) עקיבות לדרישותעקיבות לדרישות –כשל = אי-עמידה בדרישות. אילו דרישות? תכנון מראשתכנון מראש –ניתן להתחיל לתכנן בדיקות כבר משלב הדרישות ריכוז מאמץ הבדיקה בחלקים נבחריםריכוז מאמץ הבדיקה בחלקים נבחרים – 80% מהשגיאות נמצאות ב- %20 מהמודולים כיוון הבדיקות מ”קטן” ל”גדול”כיוון הבדיקות מ”קטן” ל”גדול” –מתחילים בבדיקת מודולים, מסיימים בבדיקת מערכת (Davis, 1995)

מבוא להנדסת תוכנה אימות ותקפות - 12 עקרונות לבדיקת תוכנה (2) אין אפשרות לבדיקה ממצה (exhaustive testing)אין אפשרות לבדיקה ממצה (exhaustive testing) –המספר הכולל של מעברים/מצבים הוא אקספוננציאלי למרות זאת, אפשר לכסות בצורה מדוייקת את לוגיקת התכנית ולוודא קיום כל תנאי התכן הפרוצדורלי. בדיקה ראשונית ע"י המפתח (משולב עם קידוד)בדיקה ראשונית ע"י המפתח (משולב עם קידוד) בדיקה מקיפה ע”י גורם חיצוניבדיקה מקיפה ע”י גורם חיצוני –להגברת היעילות כלומר, הגדלת ההסתברות למציאת שגיאות –אדם אינו יכול לבדוק ביעילות את עצמו

מבוא להנדסת תוכנה אימות ותקפות - 13 בדיקתיות (Testability) המשמעותהמשמעות –עד כמה ניתן לבדוק את התוכנה בקלות –עד כמה אוסף נתון של בדיקות מכסה את המוצר –עד כמה ניתן לבדוק (ולתקן!) מערכת בזמן שימוש מבצעי כיצד מבטיחים את בדיקתיות התוכנה?כיצד מבטיחים את בדיקתיות התוכנה? –שומרים על מספר כללים במהלך הפיתוח –דרושות שקיפות ויכולת פירוק

מבוא להנדסת תוכנה אימות ותקפות - 14 שקיפות (Observability) “What you see is what you test” פלט שונה מיוצר עבור כל קלטפלט שונה מיוצר עבור כל קלט מצבים ומשתני מערכת הינם גלויים או ברי-תשאול (queriable) תוך כדי ריצהמצבים ומשתני מערכת הינם גלויים או ברי-תשאול (queriable) תוך כדי ריצה מצבי-עבר וערכים היסטוריים של משתני מערכת הינם גלויים או ברי-תשאולמצבי-עבר וערכים היסטוריים של משתני מערכת הינם גלויים או ברי-תשאול –כגון transaction logs כל הגורמים המשפיעים על הפלט הינם גלוייםכל הגורמים המשפיעים על הפלט הינם גלויים פלט לא תקין - מזוהה בקלותפלט לא תקין - מזוהה בקלות שגיאות פנימיות מתגלות באופן אוטומטי ע”י מנגנוני בדיקה עצמיותשגיאות פנימיות מתגלות באופן אוטומטי ע”י מנגנוני בדיקה עצמיות קיימת נגישות לקוד המקורקיימת נגישות לקוד המקור

מבוא להנדסת תוכנה אימות ותקפות - 15 בעית השקיפות ב-OO חלק מהמצב אינו גלויחלק מהמצב אינו גלוי פולימורפיזם => אותו קטע קוד וקריאות מביאים להפעלה של מטודות שונותפולימורפיזם => אותו קטע קוד וקריאות מביאים להפעלה של מטודות שונות מוסיפים מטודות לצורך בדיקהמוסיפים מטודות לצורך בדיקה מוסיפים בדיקות בתוך מטודות קיימותמוסיפים בדיקות בתוך מטודות קיימות ניתן להוסיף "חלקי בדיקה" בעזרת דגלים, או לעבוד עם aspects המוכרזים בנפרד (AOP)ניתן להוסיף "חלקי בדיקה" בעזרת דגלים, או לעבוד עם aspects המוכרזים בנפרד (AOP) בעיה: הקוד הנבדק שונה מהקוד "האמיתי"בעיה: הקוד הנבדק שונה מהקוד "האמיתי" –תופעה: שגיאות צצות אחרי חיסור התוספות –עקרון אי-הוודאות של Heisenberg

מבוא להנדסת תוכנה אימות ותקפות - 16 יכולת פירוק (Decomposability) יכולת פירוק (Decomposability) “By controlling the scope of testing, we can more quickly isolate problems and perform smarter retesting” –מערכת התוכנה בנויה ממודולים עצמאיים –ניתן לבדוק את מודולי התוכנה באופן עצמאי בעיה ב-OO : קשה לבודד את הבדיקה של מחלקהבעיה ב-OO : קשה לבודד את הבדיקה של מחלקה נראה דיון בהמשך:נראה דיון בהמשך: – stubs ובדיקה top-down – drivers ובדיקה bottom-up כיצד נדאג לקיום תנאיי קדם להפעלת מטודה?כיצד נדאג לקיום תנאיי קדם להפעלת מטודה? –נבדוק לפני קריאה מחוץ למחלקה ? בעייתי.... –נבדוק אחרי הקריאה, בתחילת המטודה ? כן!!

מבוא להנדסת תוכנה אימות ותקפות - 17 טכניקות לבדיקה קופסה לבנה (white box, glass box)קופסה לבנה (white box, glass box) –בחינת המבנה הפנימי של המודול: נראה בהמשך מסלולי החישוב נכונות החישובים נכונות ההחלטות הלוגיות קופסה שחורה (black box)קופסה שחורה (black box) –בחינת התפקוד יחסית למפרט, בלי "ידע פנימי" נכונות הפלט מהירות התגובה נתוני בחינה (test data)נתוני בחינה (test data) –קבצי נתונים לבדיקת המקרים השונים

מבוא להנדסת תוכנה אימות ותקפות - 18 עקרונות קופסה שחורה בדיקות מהמפרט ו- Use Case או sequence diagramבדיקות מהמפרט ו- Use Case או sequence diagram ניתן לתיכנון אחרי הגדרת המפרט או מה-UMLניתן לתיכנון אחרי הגדרת המפרט או מה-UML יש לקשור בדיקה עם דרישה או תרחיש, ולהיפךיש לקשור בדיקה עם דרישה או תרחיש, ולהיפך חייבים להגדיר "שקילות" בין בדיקות, ולבדוק מקרים מכל מחלקת שקילות, ועל יד הגבולותחייבים להגדיר "שקילות" בין בדיקות, ולבדוק מקרים מכל מחלקת שקילות, ועל יד הגבולות דוגמה: בדרישות x: דוגמה: בדרישות x: –לבדוק עם x = 3-, 0, 1, 947, 15000, היום, בד"כ בדיקה אינה רק הכנת קובץ נתוניםהיום, בד"כ בדיקה אינה רק הכנת קובץ נתונים –דרוש script או נוהל אנושי דרך GUI

מבוא להנדסת תוכנה אימות ותקפות - 19 המאפיינים של בדיקה “טובה” הסתברות גבוהה למציאת שגיאותהסתברות גבוהה למציאת שגיאות –הבודק צריך להבין היטב את התוכנה ולנסות לפתח תמונה מנטלית של אופני הכשל נחיצותנחיצות –אין בדיקות מיותרות –לכל בדיקה יש מטרה שונה –חפיפה נמוכה בין האלמנטים הנבדקים בכל בדיקה משובחות (“best of breed”)משובחות (“best of breed”) –אם יש כמה בדיקות אפשריות (מבחינת מטרה, זמן ומשאבים) - יש לבחור את זו בעלת כושר הכיסוי הגבוה ביותר. לא פשוטה מדי, לא מורכבת מדילא פשוטה מדי, לא מורכבת מדי –אפשר, לעיתים, לאחד כמה בדיקות לבדיקה אחת, אך מבלי ליצור סיבוכיות גבוהה מדי (Kaner, Falk & Nguyen, 1994)

מבוא להנדסת תוכנה אימות ותקפות - 20 סיום הבדיקות מתי מסתיימות הבדיקות?מתי מסתיימות הבדיקות? –כאשר בוצעו כל הבדיקות, על פי התכנית המקורית –כאשר הוכח שהתוכנה עומדת בדרישות למשל, כאשר הזמן בין תקלות עולה מעל לערך נתון –על פי ההשגים בגילוי השגיאות קצב השגיאות יורד מתחת לערך נתון התגלו %X מהשגיאות –על פי אומדן סטטיסטי, בהתאם לקצב הגילוי –על ידי גילוי שגיאות “שתולות” –השוואה בין שני צוותי בדיקה בלתי תלויים –כאשר נגמרו האמצעים (זמן, כסף) יש להגדיר מראש מהם התנאים לסיום הבדיקות!

מבוא להנדסת תוכנה אימות ותקפות - 21 תוכנית בדיקות –Test Plan חלק מתכנון – ולפעמים מהדרישותחלק מתכנון – ולפעמים מהדרישות מי יבצע? המפתח או קבוצת הבטחת איכות?מי יבצע? המפתח או קבוצת הבטחת איכות? משימות בדיקה:משימות בדיקה: –סריקות, ותכן שיאפשר בדיקה –בדיקות קופסה שחורה, ליחידה –בדיקות קופסה לבנה, סוג הכיסוי, כלים ונוהלים –בדיקות שילוב –בדיקות המוצר, בדיקות קבלה (alpha, beta) –תנאיי סיום לבדיקות

מבוא להנדסת תוכנה אימות ותקפות - 22 אז מה היה לנו...? אימות אימות בדיקת התהליך מפתחיםנכון האם אנו מפתחים נכון את המוצר? שיטות בדיקה ללא הרצה בדיקות בדיקות בדיקת המוצר המוצר הנכון האם אנו מפתחים את המוצר הנכון ? עקרונות לבדיקת תוכנה בדיקתיות (testability) תיכנון לבדיקות קופסה שחורה

מבוא להנדסת תוכנה אימות ותקפות - 23 וכעת נעבור ל... קידוד ובדיקות יחידה