בדיקת זמן אמת

מתוך ויקיפדיה, האנציקלופדיה החופשית
קפיצה לניווט קפיצה לחיפוש

בדיקת זמן אמת (real time testing) היא סוג של בדיקות תוכנה שנכתבו במיוחד לצורך בדיקת מערכות זמן אמת. מערכות זמן אמת הן מערכות שיש להן אילוצי זמן על תגובות שלהן ומערכות שהן בעלות התנהגות לא דטרמיניסטית,[1] לדוגמה מערכת שליטה של תנועת מטוסים או מערכת מוניטור רפואית. כדי להבטיח פונקציונליות שכזו, מערכות אלו מתזמנות את המשימות שלהן על מנת לעמוד באילוצי הזמן. בדיקות תוכנה הן בדיקות שמבצעים כדי למצוא באגים בתוכנה ולעזור לתקן אותם. בנוסף, בדיקות מבטיחות כי התוכנה נותנת את הפונקציונליות שאותה המשתמש רוצה. ישנן שיטות מקובלות ושיטות סטטיות למציאת באגים, אך הן לא מתאימות לבדיקות של מערכות זמן אמת. כלומר, שיטות סטטיות מקובלות של ניתוח אינן מספיקות כדי להתמודד עם אילוצי הזמן.[2]

אסטרטגיה[עריכת קוד מקור | עריכה]

על מנת לבדוק מערכות זמן אמת, יש לעבור ארבעה שלבים:[3]

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

כלים לבדיקת מערכות זמן אמת[עריכת קוד מקור | עריכה]

בדיקת מערכות זמן אמת הופכת לחשובה, להלן מספר כלים שעוצבו כדי לבדוק מערכות כאלו:

MSC[עריכת קוד מקור | עריכה]

Message Sequence Charts זה תקן בינלאומי מקובל לקבלת דרישות.[4] תקן זה מספק שפה דו ממדית בצורה ציורית המסבירה את הדרישות דרך תרחישי מקרה.

דוגמה ל-MSC

SDL[עריכת קוד מקור | עריכה]

Specification and Description Language זה תקן בתחום של עיצוב וניתוח שעוזר בכתיבת דרישות בשפה חד משמעית שלא ניתנת לפירוש בשני פנים ועוזרת לתיאור מערכות מבוזרות.[5] תקן זה תומך בדרישות של מערכות מורכבות ומיושם בצורה רחבה בכל מיני תחומים מתקשורת ואוטומציה ועד פיתוח מערכות כלליות.

TTCN[עריכת קוד מקור | עריכה]

Testing and Test Control Notation זה תקן בינלאומי רק לשפת בדיקות.[6] מספק יישום רחב יותר בהשוואה לתקנים הקודמים שלו שמתמקדים רק בפרוטוקולים של OSI

משתמשים בשלושת התקנים האלו ביחד כדי לבדוק יישומי זמן אמת. חשוב לבדוק שעומדים שהדרישות עומדות בתקנים אלו, ומקרי הבדיקה שנוצרו צריכים להיות חשופים למידע ולפונקציונליות כדי לבדוק את המערכת. כמו כן, כל שינוי בדרישות של עיצוב וכל מידע חדש על מאפייני מערכת צריכים להיבדק שהם עומדים בדרישות של התקנים.

על מנת לקלוט את מאפייני הזמן של המערכת אותה, אנו בודקים באופן מדויק וכדי להבטיח שעומדים בדרישות ובמודלים שבהם משתמשים ליצירת מידע מתוזמן אשר ניתן לבדיקה, יש צורך שהשפה עצמה (TTCN-3) תהיה מובנת ותכיל עם תחביר עשיר במודלי זמן.

TTCN-3[עריכת קוד מקור | עריכה]

רקע[עריכת קוד מקור | עריכה]

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

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

הסיבה לשימוש בתקן זה לצורך בדיקת מערכות זמן אמת הוא בגלל שעוני העצר (timers) שלו. שעוני העצר האלו מוגדרים בפונקציות של חבילות הבדיקה. לא קיים שימוש בשעוני עצר באופן גלובלי בTTCN3. הפעולות שאפשר לעשות עם שעוני עצר אלו הם להתחיל את השעון, לעצור את השעון ולבדוק אותו.
טכנולוגיית סמנטיקה של תצלום-הבזק (Snapshot Semantics) היא טכנולוגיה בתקן TTCN3 (וגם בTTCN2), שבעזרתה מתמודדים עם העברת מסרים בזמן תקשורת בין מערכות או כאשר בודקים מימוש. כאשר מתקבלת סדרה של תגובות על ידי המערכת, תצלום-הבזק (snapshot) נלקח והתגובות נשמרות לפי הסדר הגעתן. כך, שכל תצלום-הבזק הוא תמונת מצב מרגע התצלום האחרון ועד עליו. אבל טכנולוגיה זו לא יעילה עבור חלק מאירועים היות שהיא עלולה לפספס חלק מהמידע כאשר נלקח התצלום. אירועים מסוימים מתבצעים בזמן תהליך ההקלטה ולא בזמן שעושים את התצלום, אירועים כאלו לא ניתן לעבד. בנוסף, אם ציוד ההקלטה אינו מספיק מהיר, הוא אינו יכול להתקשר עם המערכת אשר נמצאת תחת בדיקה. מקרה שכזה יכול להוביל לשגיאות בזמן הבדיקה.
לדוגמה PragmaDev[7] מספקת כלי לפיתוח העומד בתקן TTCN-3. בנוסף, כלי זה מספק גם Model driven testing וגם Continuous integration

ראו גם[עריכת קוד מקור | עריכה]

הערות שוליים[עריכת קוד מקור | עריכה]

  1. ^ כלומר, שלא ניתן לחזות את התנהגותה מראש, אלא היא דינמית
  2. ^ Tsai, Jeffrey JP, K-Y. Fang, and Yao-Dong Bi. "On real-time software testing and debugging." Computer Software and Applications Conference, 1990. COMPSAC 90. Proceedings., Fourteenth Annual International. IEEE, 1990.
  3. ^ Software Engineering: A Practitioner's Approach by Roger S Pressman
  4. ^ http://www.sdl-forum.org/issre04-witul/papers/EbnerTTCN3.pdf
  5. ^ http://www.sdl-forum.org/SDL/Overview_of_SDL.pdf
  6. ^ http://www.ttcn-3.org
  7. ^ http://www.pragmadev.com/product/testing.html