הצגת המקור של הדף "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).

=== חסרונות ===
* דורש מידול ברמה מאד גבוהה של המערכת - לוקח זמן רב ועלות כספית גבוהה.
==ראו גם==
*[[בדיקות תוכנה ממוכנות]]
== קישורים חיצוניים ==
* [http://www.agedis.de/documents/ModelBasedTestGenerationTools_cs.pdf Model Based Test Generation Tools]
* [http://web.archive.org/web/20090329060732/http://acadjournal.com/2005/v15/part6/p4/ A SURVEY ON AUTOMATIC TEST CASE GENERATION]
* [[:en:Model-based testing|Model-based testing]] בוויקיפדיה האנגלית

[[קטגוריה:בדיקות תוכנה]]