© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 1 קידוד ובדיקות יחידה Coding and Unit Testing (CUT) מקורות: S. R. Schach: Chapter 13 (14, in 5 th edition) R. S. Pressman: Chapter 17,22 ד. גלין ו-ז. בלובבנד, הבטחת איכות תוכנה, “אופוס”, 1995

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

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 3 מה עומד על הפרק? בחירת שפת התיכנותבחירת שפת התיכנות –משמעות הבחירה של שפת התכנות –משמעות השימוש במחוללי יישומים עקרונות לקידוד נכוןעקרונות לקידוד נכון בדיקות יחידהבדיקות יחידה –טכניקות לבדיקת מודולים –בדיקות מונחות-עצמים

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 4 שפות התכנות דורות של שפותדורות של שפות –דור ראשון: שפת מכונה –דור שני: אסמבלר –דור שלישי (3GL): שפות עליות - ++COBOL, FORTRAN, C –דור רביעי (4GL): מחוללי יישומים משפט בשפה עלית = 5-10 משפטי אסמבלי משפט במחולל יישומים = משפטי אסמבלי תבניות (paradigms)תבניות (paradigms) –תכנות פרוצדורלי: C, Pascal –תכנות מונחה עצמים: C++, Java –תכנות בסיסי-נתונים: SQL –תכנות לוגי: Prolog –תכנות פונקציונלי: LISP, ML

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 5 מחוללי יישומים הציפיות ממחולל-יישומיםהציפיות ממחולל-יישומים –בנייה מואצת של יישומים –עריכת קלה ומהירה של שינויים הקטנת הוצאות האחזקה –debugging פשוט –שפה ידידותית מובילה לתכנות-עצמי ע”י המשתמש הציפיות היו מתממשות, אילו מחוללי היישומים היוהציפיות היו מתממשות, אילו מחוללי היישומים היו – שפות גבוהות-מאד –ידידותיות למשתמש –לא-פרוצדורליות for every surveyor if rating is excellent add 6500 to salary

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 6 דוגמאות יצירה ושימוש במסד נתוניםיצירה ושימוש במסד נתונים –DB2 או Oracle –כולל שפה להגדרת שאילתות –משולב עם מערכת "רגילה" מייצר דו"חות Excelמייצר דו"חות Excel יצירת קוד אוטומטי מתיאור ב- UMLיצירת קוד אוטומטי מתיאור ב- UML –מבוסס על class diagrams –יוצר שלד: הכרזות וכותרות למטודות, בלי גוף המטודות

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 7 משמעות השימוש במחולל-יישומים בעיותבעיות –מחסור בשיטות תכן –מחסור בשיטות ניהול תמיכהתמיכה –אין אף מחולל-יישומים השולט בשוק –מספר גדול של מחוללי-יישומים (מאות) –חלקם הגדול נתמך בעיקר ע”י קבוצות משתמשים הסיבההסיבה –לאף מחולל-יישומים אין את כל התכונות הנדרשות נדרשת תשומת-לב רבה בבחירת מחולל-יישומים מתאים

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 8 עקרונות לקידוד נכון תוכנית מחשב נועדה לקריאה ע”י בני-אנושתוכנית מחשב נועדה לקריאה ע”י בני-אנוש –שמות שמות משמעותיים עקביות במתן שמות –מבנה עריכה חזותית של הקוד –כתיבה מדורגת (indented) –שורות ריקות מבנים ברורים וברי-עקיבה –מבני בקרה –מבני נתונים –הערות (comments) הבהרות של כל מה שלא מובן מאליו

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 9 שימוש נכון בשמות שמות משמעותייםשמות משמעותיים –קשר בין השם לבין מה שהוא מייצג שמות מלאים, אך ללא סירבול מיותרשמות מלאים, אך ללא סירבול מיותר The_DataBase_Capacity_Counter = The_DataBase_Capacity_Counter + 1; חד משמעיותחד משמעיות –מה מייצג המשתנה fstpt? first point? (first_point, frstpnt, point1) file start pointer? (file_start_ptr) fast prototype? (fastPT) שמירה על עקביותשמירה על עקביות –דוגמה גרועה: ייצוג המונח תדירות (frequency) באופנים שונים freqAverage, frequencyMaximum, minFr, frqncyTotl

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 10 משפטי תנאי ברורים if (latitude > 30 && longitude > 120) { if (latitude <= 60 && longitude <= 150) mapSquareNo = 1; else if (latitude <= 90 && longitude <= 150) mapSquareNo = 2; else System.out.println(“Not on the map”); } else System.out.println(“Not on the map”); if (longitude > 120) && longitude <= 150 && latitude > 30 && latitude <= 60) mapSquareNo = 1; else if (longitude > 120 & longitude <= 150 && latitude > 60 && latitude <= 90) mapSquareNo = 2; else System.out.println(“Not on the map”);

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 11 משפטי תנאי ברורים - עקרונות משפטי תנאי מקוננים - קשים לקריאהמשפטי תנאי מקוננים - קשים לקריאה –if-if –if-else-if בדרך כלל יש שקילות בין שני המבנים:בדרך כלל יש שקילות בין שני המבנים: if if && כלל אצבע:כלל אצבע: –יש להמנע ממשפטי תנאי מקוננים בעומק של יותר מ-3 רמות.

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 12 נוהלי תכנות יכולים להיות ברכה, או קללהיכולים להיות ברכה, או קללה דוגמה:דוגמה: –“כל מודול יכיל 35 עד 50 משפטי ביצוע” עלול לגרום לפיצול מלאכותי ולכפילויות ניסוח עדיף:ניסוח עדיף: –“התכנת יוועץ במוביל התוכנה לפני יצירת מודול בן פחות מ-35 או יותר מ-50 משפטי ביצוע” אין נהלים יישימים באופן גורף!

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 13 הערות נוספות לגבי נהלי תכנות יכולים לעזור בניתוח אוטומטי של הקוד: זיהוי insertיכולים לעזור בניתוח אוטומטי של הקוד: זיהוי insert הנהלים צריכים להיות ניתנים לבדיקה באופן אוטומטיהנהלים צריכים להיות ניתנים לבדיקה באופן אוטומטי דוגמאות לנהלים “טובים”דוגמאות לנהלים “טובים” –משפטי if לא יקוננו לעומק של יותר מ-3, אלא באישור מוביל התוכנה –מודולים יכילו משפטי ביצוע, פרט לאישור מוקדם של מוביל התוכנה. –יש להמנע משימוש ב-goto. למרות זאת ניתן להשתמש, באישור מוביל התוכנה, ב-goto קדימה, לצורך טיפול בשגיאות. מטרת הנהלים - להקל על אחזקת התוכנה ולהגביר אחידותמטרת הנהלים - להקל על אחזקת התוכנה ולהגביר אחידות –אם הם מקשים על הפיתוח - יש לשנותם, ויש לאפשר חריגות לפעמים –האחידות משפרת את הטיפול בשינויים אסור שנוכל לזהות "זה הקוד של יוסי..." מסגנון הכתיבהאסור שנוכל לזהות "זה הקוד של יוסי..." מסגנון הכתיבה

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 14 הערות בגוף הקוד (comments) כותרת המודול תכיל, לפחות, את המידע הבא:כותרת המודול תכיל, לפחות, את המידע הבא: –שם המודול –תאור קצר - מה המודול עושה –שם התכנת –תאריך יצירה –תאריך ושם המאשר –תאור הפרמטרים –משתנים ותפקידיהם - בסדר א”ב –קבצים בשימוש המודול (קריאה, עדכון) –קלט / פלט –טיפול בשגיאות –שם קובץ נתוני בדיקות (עבור regression testing) –רשימת שינויים: מהות, כותב, תאריך –באגים ידועים

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 15 עוד על הערות בגוף הקוד... מתי להוסיף הערהמתי להוסיף הערה –כאשר הקוד לא קריא מאליו אין קוד כזה –דקויות ההבנה הקיימות בזמן הכתיבה, לא יהיו מובנות מאליהן בשלבים מאוחרים יותר, או ע”י אנשים אחרים! –כאשר הקוד “מתוחכם” או לא שגרתי הערות לא נועדו לשם...הערות לא נועדו לשם... –קידוד-מחדש בשפה אחרת X = X+1; /* add 1 to X */ –חיפוי על קידוד גרוע XBZ132 = G5_A3*BBZZZ; /* compute rectangle area */

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 16 על שילוב תנאים מהמפרט Checker = מטודה\נוהל לבדיקת תנאי לוגי של מצב המערכתChecker = מטודה\נוהל לבדיקת תנאי לוגי של מצב המערכת התגובה לאי-קיום התנאי: בהתאם לשפת התיכנות ולהחלטת תיכנוןהתגובה לאי-קיום התנאי: בהתאם לשפת התיכנות ולהחלטת תיכנון –לרשום ב-log –לזרוק exception –לחזור עם דגל מיוחד –לעצור את הביצוע, עם הודעה מיוחדת לפעמים מופעל רק בשלב debuggingלפעמים מופעל רק בשלב debugging לפעמים נשאר במוצר המוגמר: %10 מהקודלפעמים נשאר במוצר המוגמר: %10 מהקוד

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 17 סוגי התנאים Preconditions : קריאה ל-checker בתחילת המטודה (ולא "מבחוץ" לפני הקריאה)Preconditions : קריאה ל-checker בתחילת המטודה (ולא "מבחוץ" לפני הקריאה) Postconditions : קריאה ל-checker בסוף המטודה (ולרוב מוצא מהקוד הנמסר ללקוח)Postconditions : קריאה ל-checker בסוף המטודה (ולרוב מוצא מהקוד הנמסר ללקוח) שמורה למחלקה: ה-checker מופעל לפני ואחרי כל מטודה במחלקהשמורה למחלקה: ה-checker מופעל לפני ואחרי כל מטודה במחלקה נטייה חדשה: להשאיר הרבה checkers לצורך אבחנה מרחוק ותיחזוקנטייה חדשה: להשאיר הרבה checkers לצורך אבחנה מרחוק ותיחזוק לפעמים יש פקודות assert משולבות במטודותלפעמים יש פקודות assert משולבות במטודות

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

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 19 האם ניתן לבדוק את כל המקרים? “התפוצצות קומבינטורית”“התפוצצות קומבינטורית” –בתרשים זרימה זה יש מסלולים שונים! loop <= 18 times

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 20 סוגי כיסוי: מה רוצים לבדוק? כל הפקודות (all instructions)כל הפקודות (all instructions) –בעיה: אם יש מספר דרכים לסיים if או do, לא כל המסלולים יבדקו כל ההתפצלויות (all branches) בכל כיווןכל ההתפצלויות (all branches) בכל כיוון –שונה מ"כל הפקודות" כשיש if בלי else כל קטע קוד בלי התפצלויות (basic block)כל קטע קוד בלי התפצלויות (basic block) כל מסלול מהגדרת ערך לשימוש בערך (definition-use paths)כל מסלול מהגדרת ערך לשימוש בערך (definition-use paths) מסלולי בסיס (נראה בהמשך)מסלולי בסיס (נראה בהמשך) לקבוע: איזה סוג כיסוי, איך נבנה את הבדיקותלקבוע: איזה סוג כיסוי, איך נבנה את הבדיקות

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 21 בדיקת מסלולי-בסיס (Base Path testing) שיטה קלאסית לבדיקת “קופסה לבנה”שיטה קלאסית לבדיקת “קופסה לבנה” בניית גרף זרימה (flow graph) של המודולבניית גרף זרימה (flow graph) של המודול –צומת - יחידת חישוב ללא הסתעפות –קשת - הסתעפות בחישוב מסלול בלתי-תלוימסלול בלתי-תלוי –מסלול מהתחלה לסיום, הכולל לפחות צומת אחד חדש, לעומת מסלולים אחרים מדד לסיבוכיות הבדיקה (Cyclomatic Complexity)מדד לסיבוכיות הבדיקה (Cyclomatic Complexity) –המספר המקסימלי של מסלולים בלתי תלויים V(G) = E - N + 2 (E = קשתות, N = צמתים) (McCabe, 1976)

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 22 בדיקת מסלולי-בסיס - דוגמה 1: do while records remain read record; 2: if record field 1 = 0 3: then process record; store in buffer; increment counter; 4: elseif record field 2 = 0 5: then reset counter; 6: else process record; store in file; 7a: endif endif 7b: enddo 8: end a7a 7b7b 8 a procedure in PDL flow graph path 1: path 2: b path 3: a - 7b path 4: a - 7b base paths

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

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 24 דוגמה לביצוע סימבולי Read (x, y, z) ; (X, Y, Z)Read (x, y, z) ; (X, Y, Z) x = x + 2 y ; (X + 2 Y, Y, Z)x = x + 2 y ; (X + 2 Y, Y, Z) z = x + y ; ?z = x + y ; ? y = 2 x – z; ?y = 2 x – z; ? if ( 2 z > 10) { y = 1};if ( 2 z > 10) { y = 1}; if ( x = y) { x = y + z};if ( x = y) { x = y + z}; Write(x, y, z);Write(x, y, z); ניתן לחשב תוצאות החישוב, לסדרות בלי לולאות או קריאות חיצוניותניתן לחשב תוצאות החישוב, לסדרות בלי לולאות או קריאות חיצוניות

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 25 כלים ליצירת הבדיקות בניית גרף מהקודבניית גרף מהקוד ניתוח הגרף ע"י אלגוריתמים מתורת הגרפיםניתוח הגרף ע"י אלגוריתמים מתורת הגרפים חישוב תנאי לערכי משתני המצב בתחילת מסלול שיבטיח ביצוע שיעבור דרך המסלולחישוב תנאי לערכי משתני המצב בתחילת מסלול שיבטיח ביצוע שיעבור דרך המסלול פותר לאוסף של אי-שוויונותפותר לאוסף של אי-שוויונות שימוש ב-dataflow לזהות מסלולי def-useשימוש ב-dataflow לזהות מסלולי def-use קיימים כלים COTS להגדרת מקרי בדיקה ובדיקת כיסויקיימים כלים COTS להגדרת מקרי בדיקה ובדיקת כיסוי

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 26 בדיקות למערכת מונחית-עצמים על פיעל פי The Unified Software Development Process אמצעי הגדרת הבדיקותאמצעי הגדרת הבדיקות –מקרה בדיקה (test cases) –שגרות בדיקה (test procedures) –רכיבי בדיקה (test components)

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 27 Test Case הגדרת דרך אחת לבדיקת המערכתהגדרת דרך אחת לבדיקת המערכת –מה בודקים עם כל קלט / פלט? קבוצת דרישות אשר יישומן מצדיק בדיקה –הבדיקה אפשרית –בהשקעה סבירה –באילו תנאים בודקים? –נוצר לבדוק דרישה או תרחיש מ-use-case –נוצר לבדוק מעבר במסלול חישוב כמימוש תרחיש

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 28 שגרות בדיקה test procedures הוראות מפורטות לביצוע בדיקותהוראות מפורטות לביצוע בדיקות –test case אחד –כמה test cases –חלקים של test cases אפשרות “מיחזור”אפשרות “מיחזור” –ניתן להשתמש באותו test procedures עבור test cases שונים הוראות מפורטות למפעילהוראות מפורטות למפעיל –הפעלה ידנית –הפעלה / שילוב של אמצעי בדיקה אוטומטיים

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 29 רכיבי בדיקה test components רכיב תוכנה לביצוע אוטומטי של שגרת בדיקהרכיב תוכנה לביצוע אוטומטי של שגרת בדיקה –תכנית בשפת תכנות –script –בדיקה “מוקלטת” באמצעי בדיקה אוטומטי משולב בביצועמשולב בביצוע –מייצר קלט –בקרה ומעקב אחר הביצוע של הרכיב הנבדק –דיווח / בחינה של התוצאות לשימוש חוזר אחרי שינויים: regression testלשימוש חוזר אחרי שינויים: regression test

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 30 כלי לארגון בדיקות: JUnit לבדיקות יחידה ב-Javaלבדיקות יחידה ב-Java במקור, בשימוש ל-XP, היום לשימוש כלליבמקור, בשימוש ל-XP, היום לשימוש כללי חבילה עם מחלקות Java שהמשתמש מרחיב לסביבת בדיקה אוטומטיתחבילה עם מחלקות Java שהמשתמש מרחיב לסביבת בדיקה אוטומטית כל בדיקה: אוביקטכל בדיקה: אוביקט "מריץ בדיקות" מפעיל את הבדיקות, ומסכם תוצאות"מריץ בדיקות" מפעיל את הבדיקות, ומסכם תוצאות מעודד בדיקות חוזרות לאחר שינויים (regression testing)מעודד בדיקות חוזרות לאחר שינויים (regression testing)

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 31 גישות חדשות לבדיקת תוכנה בדיקות מונחות מודלים (model-based testing)בדיקות מונחות מודלים (model-based testing) –בודק אם המימוש מתאים לדיאגרמת מצבים –מכיל בדיקות שליליות, למעברים שאינם במודל בדיקת מודלים לתוכנה (software model checking)בדיקת מודלים לתוכנה (software model checking) –ניתוח הקוד כדי להוכיח שלכל ריצה אפשרית, מתקיימות התכונות הנחוצות מהדרישות –בשימוש לפרוטוקולים ולתוכנה חיונית (safety critical)

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 32 אז מה היה לנו...? 4בחירת שפת התיכנות 4משמעות הבחירה של שפת התכנות 4משמעות השימוש במחוללי יישומים 4עקרונות לקידוד נכון 4בדיקות יחידה 4טכניקות לבדיקת מודולים 4בדיקות מונחות-עצמים

© , ד"ר עמיר תומר מבוא להנדסת תוכנה קידוד ובדיקות יחידה - 33 וכעת נעבור ל... אספקטים