בדיקות תוכנה ממוכנות

בדיקות תוכנה ממוכנות (מכונות לרוב "בדיקות אוטומטיות", באנגלית: "Test Automation") הן בדיקות תוכנה המבוצעות בדרך אוטומטית על ידי שימוש בתוכנת מחשב ייעודית (נפרדת מהתוכנה הנבדקת).

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

הקדמה

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

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

אוטומציה של התהליך יכולה לפתור את הבעיות הללו מהסיבות הבאות:

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

סוגי בדיקות אוטומטיות

ניתן לחלק בדיקות אוטומטיות לשני סוגים:

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

בדיקות מבוססות קוד

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

אוטומציה של בדיקות מבוססות קוד הוא פיצ'ר מרכזי במתודולוגית פיתוח תוכנה זריז, ומוגדר גם כפיתוח מונחה בדיקות (TDD). בדיקות היחידה נכתבות להגדרת הפונקציונליות לפני כתיבת הקוד. יחד עם זאת, בדיקות אלו מתפתחות ומתרחבות במקביל להתקדמות תהליך הפיתוח שבמהלכו סוגיות חדשות מתגלות והקוד נתון לשינויים. רק במקרה שבו כל הבדיקות עבור הפיצ'רים המפותחים עברו, הקוד נחשב גמור. חסידי הגישה טוענים שהיא מפיקה תוכנה אמינה יותר וזולה יותר מאשר קוד שנבדק בצורת חקירה ידנית. גישה זו נחשבת אמינה יותר מכיוון שכיסוי הקוד נרחב יותר. כמו כן, הבדיקות רצות לעיתים תכופות במהלך תהליך הפיתוח ולא פעם אחת בסופו. המפתח מגלה פגמים מיד עם ביצוע השינוי בקוד, בשלב שבו תיקון הפגם זול יותר ביחס לשלבים אחרים. בסופו של דבר, ארגון הקוד מחדש הוא בטוח יותר; תהליך שינוי הקוד על ידי שיפור המבנה הפנימי תוך שמירה על ההתנהגות החיצונית יניב פחות פגמים בשימוש בגישה זו.

בדיקות ממשק משתמש

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

דוגמה לווריאציה של כלי מסוג זה - כלי לבדיקת אתרי אינטרנט. במקרה זה, ה"ממשק" הוא דף האתר. כלים מסוג זה משתמשים בטכניקה שונה של קריאת דף ה HTML במקום לבחון אירועים במסך.

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

מה לבדוק

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

כלי בדיקה יכולים לעזור להפוך מטלות לאוטומטיות כגון התקנת מוצר, יצירת נתוני בדיקה, אינטראקציית ממשק משתמש גרפי, זיהוי בעיות וכו', לא בהכרח על ידי הפיכת הבדיקות לאוטומטיות בתצורת רשת קצה-אל-קצה. יש לבדוק התקיימות דרישות פופולריות כאשר חושבים על אוטומציה של בדיקות:

• אי תלות של פלטפורמות ומערכות הפעלה
• היכולת המונעת על ידי נתונים (קלט, פלט, נתוני-על)
• דיווח שניתן לאפיון (DB Access, ‏Crystal reports)
• ניפוי שגיאות ותיעוד יומן בצורה קלה
• שליטה ידידותית בגרסאות – קבצים בינאריים מינימליים
• בר הרחבה ובר התאמה (API חופשיים כדי שיהיה אפשר לשלב עם כלים אחרים)
• דרייבר נפוץ (לדוגמה IDE עבור JAVA). זה מאפשר ביצוע אינטגרציה בין בדיקות לזרימת העבודה של המפתחים.
• תמיכה בהרצת בדיקות לא-מטופלות לצורך אינטגרציה עם תהליכי build ואצווה. שרתים של אינטגרציה מתמשכת דורשים זאת.
• הודעות אימייל (הודעה אוטומטית במקרה של כישלון או השגת רף כלשהו). מריץ הבדיקות מבצע זאת.
• תמיכה בסביבת הרצה מחולקת.
• תמיכה באפליקציה מחולקת.

גישת המסגרת באוטומציה

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

הגדרת גבולות בין מסגרת אוטומציה וכלי בדיקה

כלים מעוצבים באופן ייעודי לסביבת בדיקות מסוימת, כגון סוג מערכת ההפעלה וכלי אוטומציה וביים (אינטרנטיים), וכולי. כלים משמשים כ-driving agent^{[דרושה הבהרה]} עבור תהליך אוטומציה. אולם, מסגרת אוטומציה היא לא כלי לביצוע מטלה ספציפית, אלא תשתית שמספקת פתרון, היכן שכלים שונים יכולים לבצע את עבודתם בצורה אחודה. זה מספק פלטפורמה רווחת למהנדס האוטומציה.^{[דרושה הבהרה]}

יש סוגים שונים של מסגרות. הן מקוטלגות על בסיס רכיב האוטומציה שהן ממנפות:

1. בדיקות מונעות-נתונים
2. בדיקות מונעות-מודלוריות
3. בדיקות מונעות-מילות מפתח
4. בדיקות כלאיים
5. בדיקות מבוססות-מודל
6. בדיקות מונעות-קוד

כלי בדיקות אוטומציה ראויים לציון

שם הכלי	פותח ע"י	גרסה אחרונה
AutoIt	Jonathan Bennett & AutoIt Team	3.3.8.1
Cucumber	קוד פתוח	1.0.2
eggPlant	TestPlant	2012
JSystem	Top-Q	6.1.01
EiffelStudio AutoTest	Eiffel Software	7.1, Jun 2012
FitNesse	קוד פתוח	v20111026
HP QuickTest Professional	HP Software Division	11.5
IBM Rational Functional Tester	IBM Rational	8.3.0
LabVIEW	National Instruments	2011
Maveryx	Maveryx	1.3.1
Oracle Application Testing Suite	Oracle Corporation	12.1
QF-Test	Quality First Software GmbH	3.5.0
Ranorex	Ranorex GmbH	4.0.3
Rational robot	IBM Rational	2003
Robot Framework	קוד פתוח	2.7.5
Selenium	קוד פתוח	2.33.0
Sikuli	קוד פתוח	X 1.0
SilkTest	Borland	14.0
TestComplete	SmartBear Software	9.1
Testing Anywhere	Automation Anywhere	8.0
TestPartner	Micro Focus	6.3
Test Studio	Telerik	2012
Time Partition Testing (TPT)	PikeTec GmbH	4.2
TOSCA Testsuite	TRICENTIS Technology & Consulting	7.5.0
Visual Studio Test Professional	מיקרוסופט	2012
Watir	קוד פתוח	3.0

ראו גם

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

לקריאה נוספת

• Elfriede Dustin; et al. (1999). Automated Software Testing. Addison Wesley. ISBN 0-201-43287-0. {{cite book}}: Explicit use of et al. in: |author= (עזרה)
• Elfriede Dustin; et al. Implementing Automated Software Testing. Addison Wesley. ISBN 978-0-321-58051-1. {{cite book}}: Explicit use of et al. in: |author= (עזרה)
• Mark Fewster & Dorothy Graham (1999). Software Test Automation. ACM Press/Addison-Wesley. ISBN 978-0-201-33140-0.
• Roman Savenkov: How to Become a Software Tester. Roman Savenkov Consulting, 2008, מסת"ב 978-0-615-23372-7
• Hong Zhu; et al. (2008). AST '08: Proceedings of the 3rd International Workshop on Automation of Software Test. ACM Press. ISBN 978-1-60558-030-2. {{cite book}}: Explicit use of et al. in: |author= (עזרה)
• Mosley, Daniel J.; Posey, Bruce. Just Enough Software Test Automation. ISBN 0130084689.

קישורים חיצוניים

• Practical Experience in Automated Testing
• Test Automation: Delivering Business Value
• Test Automation Snake Oil by James Bach
• When Should a Test Be Automated? by Brian Marick
• Why Automation Projects Fail by Art Beall
• Guidelines for Test Automation framework
• Advanced Test Automation

הערך באדיבות ויקיפדיה העברית, קרדיט,
רשימת התורמים
רישיון cc-by-sa 3.0

32043613בדיקות תוכנה ממוכנות