Test Case Generation
 |
יש לערוך ערך זה. הסיבה היא: ויקיזציה.
| |
| יש לערוך ערך זה. הסיבה היא: ויקיזציה. | |
Test Case Generation מתייחס לשיטות וכלים המשמשים לייצור אוטומטי, מלא או חלקי, של מקרי בדיקה.
הגדרות[עריכת קוד מקור | עריכה]
- מקרה בדיקה (Test Case) - קלט עבור בדיקה של פונקציה או מודול מסוים בתוכנית, בצירוף עם הפלט הרצוי או מאפיינים של הפלט הרצוי, עבור הרצה של הבדיקה כנגד הקלט הנתון.
- Test Oracle - כלי שיודע להחליט בהתאם לפלט האם הבדיקה עברה בהצלחה או נכשלה.
- Test Driver - מריץ את הבדיקות על המערכת שנבדקת.
מוטיבציה[עריכת קוד מקור | עריכה]
- בדיקות התכנה מהוות חלק גדול מתהליך פיתוח התכנה - נדרש תהליך מובנה ויעיל על מנת לבצע את הבדיקות.
- בדיקות ידניות מצריכות כוח אדם רב ולכן העלות שלהם מאוד גבוהה - אוטומציה של הבדיקות תפחית את כוח האדם הדרוש ותפחית עלויות.
- תהליך ידני של בדיקות לוקח הרבה זמן ומאיט את קצב הפיתוח ולפעמים גם מעכב את כל הפרויקט.
- קשה להעריך את איכות הכיסוי של בדיקות ידניות - בחירת הקלט לא נעשית באופן מובנה ואלגוריתמי וקשה להבטיח שכל המקרים אכן נבדקו.
גישות עיקריות לייצור מקרי בדיקה באופן אוטומטי[עריכת קוד מקור | עריכה]
ישנן מספר גישות הנוגעות לייצור אוטומטי של מקרי בדיקה. כל גישה מגדירה באופן שונה מהיכן שואבים את הפרמטרים לבדיקה ואיך מחליטים האם הבדיקה עברה בהצלחה או נכשלה.
Model Based Test case generation[עריכת קוד מקור | עריכה]
ה- test case מיוצרים לפי מודלים של המערכת. המודלים האלה מתארים התנהגות רצויה של המערכת, ומיצגים את הסביבה בה המערכת נבדקת ורצה. המודלים האלה נכתבים בשפות שונות (תלוי בכלי בו משתמשים ליצירת ה-test case) והם מגדירים אילוצים על המערכת ואופן פעולתה. האילוצים האלה יכולים לבוא בצורה של pre-conditions ו- post conditions או תיאור של מעברים אפשריים בין מצבי המערכת (בדומה ל-state machine). חלק מהכלים עושים שימוש בשפות modeling ייחודיות להם וחלקם עושים שימוש בתרשימי UML סטנדרטיים ושפת OCL.
ה-test case שמיוצרים הם ברמה האבסטרקטית של המודל. על מנת שניתן יהיה להריץ אותם כנגד המערכת יש צורך ליצור Executable Test Suite. Executable Test Suite נגזרים מה- Abstract Test Suite על ידי אוסף של הוראות לייצור של מקרי בדיקה שניתנות ל generator, כקלט בצירוף עם המודל של המערכת.
ה-test case שמיוצרים בשיטה זו מבוססים על מודל אבסטרקטי של המערכת ולא על הקוד עצמו לכן יש נטייה להתייחס אליהם כ- black box testing. ניתן לשלב אותם עם בדיקות שמבוססות על הקוד של המערכת על מנת לשפר את איכות הכיסוי.
שימוש במודל של המערכת על מנת ליצור מקרי בדיקה נהוג כבר זמן רב בתעשיות החומרה, תקשורת ואווירונאוטיקה, וכיום מנסים להכניס את השיטה הזו גם לעולם התוכנה ובמקביל מתבצע מחקר בתחום על מנת לשפר ולהתאים את השיטה לעולם התוכנה.
Specification Based Test case generation[עריכת קוד מקור | עריכה]
ה- test cases מיוצרים לפי ספציפיקציה של המערכת - מסמכים המגדירים דרישות פונקצינאליות של המערכת כמו use-cases או תרשימי מכונת מצבים. למעשה רב הכלים שעובדים בשיטה זו משתמשים בתרשימי מכונת מצבים של המערכת או מודול מסוים שלה כדי לייצר test-cases. היתרון העיקרי בשיטה זו הוא האפשרות ליצירה של test oracles בקלות יחסית.
גישות נוספות[עריכת קוד מקור | עריכה]
- random test case generation - ייצור מקרי בדיקה באופן אקראי. בחירת פרמטרים לבדיקה באופן אקראי מתוך domain מסוים.
יתרונות עיקריים: קל לייצר test cases, לא נדרשת הבנה של ה-domain והמערכת. חסרונות: קשה ליצור test oracle שיגדיר האם הבדיקה עברה בהצלחה או לא, קשה להעריך את איכות הכיסוי.
- path oriented test case generation - בחירת פרמטרים לבדיקה על ידי הרצות סימבוליות של המערכת וזיהוי במסלולים בקוד שיש לכסות בבדיקות, ואז בחירת פרמטרים לבדיקה כך שיכסו את המסלולים האלה בקוד.
יתרונות: ניתן להעריך את איכות הכיסוי של הבדיקות.
חסרונות: קשה לבחור פרמטרים שיכסו את מסלול ספציפי בקוד.
- goal oriented - בחירת פרמטרים לבדיקה כך שיכסו ענף מסוים (התפצלות של if) או הצהרה מסוימת.
כלים לייצור אוטומטי של מקרי בדיקה[עריכת קוד מקור | עריכה]
Specification Based Test case generator[עריכת קוד מקור | עריכה]
DAS-BOOT כלי אוטומטי ליצירת test-cases לפי תרשים מצבים.
- מקבל כקלט:
- מחלקה ב-java. - תרשים מצבים למחלקה. - מטריקת כיסוי.
- הבודק יוצר מיפוי בין מצב בתרשים לבין מצב האובייקט: כל מצב בתרשים מזוהה עם ערכים מסוימים של משתני המחלקה.
- הבודק ממפה את מתודות המחלקה לטריגרים שגורמים מעבר ממצב למצב או לפעולות שמבוצעות כתוצאה ממעבר למצב מסוים.
- making test-ready: הבודק מגדיר טווח ערכים עבור משתני המחלקה ו pre conditions עבור פונקציות המחלקה.
- בחירה של מטריקת כיסוי מתוך מטריקות קיימות.
- המטריקות נבחרות לפי ה-W method. - מחייבת כיסוי של כל הרצפים האפשריים של מעברים בתרשים, החל ממצב התחלתי מסוים, מבלי לבקר במצב יותר מפעם אחת. Das-Boot מאפשר ביקור של עד 3 פעמים במצב.
- כל רצף של מעברים שהתקבל ממטריקת הכיסוי שנבחרה מתורגם ל-test cases שמספקים כיסוי לרצף המעברים.
- ה-input ב- test case גורם למעבר הרצוי.
- Test driver שנוצר מריץ את המחלקה כנגד ה- test cases ובמקביל בודק בעזרת ה-test oracle אם התנהגות המימוש היא כפי שהוגדרה בתרשים המצבים.
- הבדיקה עברה בהצלחה אם המערכת נמצאת במצב בו היא אמורה להימצא לפי מכונת המצבים, לאחר כל מעבר.
Model Based Test case generator[עריכת קוד מקור | עריכה]
קיימים כמה כלים שעובדים בשיטה זו: UNITESK כלי שנכתב על ידי האקדמיה הרוסית למדעי המחשב. מקבל מודל של המערכת שנכתב בשפות J@VA או C@++, השפות האלה הן שפות שנועדו למידול של מערכת שנכתבה בשפות c++, java. המודל מגיע בצורה של pre-condition ו- post-condition לפונקציות ולמחלקות שבקוד. ה-Test case מיוצרים על ידי ניתוח של המודל, כך שיגיעו לערכים קיצוניים במסלול ההחלטות (סוג של branch covering). הכלי עובד ברמה של הקוד כלומר מייצר unitTests בצירוף עם test drivers (תוכנית שמריצה את הבדיקות). הכלי היה בשימוש על ידי nortel כדי לבדוק מערכת הפעלה שפיתחו.
REACTIS פותח על ידי Reactive Systems. מקבל כקלט מודלים בשפות SimuLink, StateFlow המודל מהודר ומתקבל סימולטור של המודל (איך המערכת אמורה להתנהג במצבים מסוימים). מתוך הסימולטור הזה נגזרים ה- test case תוך כדי אפשרות לבחירת קריטריון הכיסוי של המודל (branches, states, transitions, conditions).
קריטריון כיסוי[עריכת קוד מקור | עריכה]
מדד לאיכות הכיסוי של סט בדיקות.
ישנם כמה קריטריונים ע"פ ניתן לקבוע את איכות הכיסוי:
- path coverage - כמה אחוזים מהמסלולים האפשריים בקוד כוסו.
- statement coverage - האם כל שורה בקוד רצה לפחות פעם אחת?
- branch coverage - האם כל הסתעפות בקוד (if, while, for) קיבלה לפחות פעם אחת false ולפחות פעם אחת true?
כל כלי לייצור של test case עובד עם קריטריון כיסוי שונה, חלקם (כמו reactis) נותנים אפשרות לבחור. במערכות גדולות לא ניתן להשיג כיסוי מלא ב- path coverage, דורש כמות אקספוננציאלית של test case ואין את הזמן הדרוש לייצר ולהריץ אותם.
יתרונות/חסרונות של Model\specification based test case generation[עריכת קוד מקור | עריכה]
יתרונות[עריכת קוד מקור | עריכה]
- ייצור של test case אבסטרקטיים - לא תלויים במימוש אלא רק במודל ניתן להריץ אותם לאורך כל תהליך הכתיבה של הקוד.
- ניתן להעריך באופן יותר מדויק את איכות הכיסוי - ה- test case נבחרים לפי שיטת כיסוי מסוימת בצורה מובנה ואלגוריתמית.
- ייצור והרצה אוטומטית של הבדיקות.
- בחלק מהמקרים ניתן לספק test oracles (כמו ב-DAS BOOT).
חסרונות[עריכת קוד מקור | עריכה]
- דורש מידול ברמה מאוד גבוהה של המערכת - לוקח זמן רב ועלות כספית גבוהה.