בדיקות תוכנה ממוכנות
בדיקות תוכנה ממוכנות (מכונות לרוב "בדיקות אוטומטיות", באנגלית: "Test Automation") הן בדיקות תוכנה המבוצעות בדרך אוטומטית על ידי שימוש בתוכנת מחשב ייעודית (נפרדת מהתוכנה הנבדקת).
ניתן לממש בדיקות אוטומטיות כתחליף לתהליכי בדיקות ידניים, או בנוסף להן – עבור תרחישים שלאדם יהיה קשה מאוד (ולעיתים בלתי אפשרי) לבצע ללא מיכון.
הקדמה
עריכהבדיקות תוכנה הן הניסיון להפעיל את כלל התהליכים האפשריים במערכת הנבדקת ולהעריך את פעולתם, זאת על ידי כתיבת מקרי בדיקה וביצועם.
כאשר מבוצעת באופן ידני, עבודה זו עלולה להיות מייגעת, לדרוש זמן רב ולהתבצע באופן לא יעיל בשל חזרה מרובה על אותן הפעולות (חזרה מרובה היא מאפיין נפוץ בעבודת הבדיקה).
אוטומציה של התהליך יכולה לפתור את הבעיות הללו מהסיבות הבאות:
סוגי בדיקות אוטומטיות
עריכהניתן לחלק בדיקות אוטומטיות לשני סוגים:
- בדיקות מבוססות קוד – הממשקים והמודולים השונים של המערכת נבדקים באמצעות קלטים מסוגים שונים תוך וידוא התוצאה המוחזרת.
- בדיקות ממשק משתמש – סביבת האוטומציה מייצרת אירועים המדמים אינטראקציה של משתמש עם המערכת כגון שימוש במקלדת ובעכבר, בוחנת את השינויים בממשק המשתמש שנגרמו כתוצאה מכך ומשווה אותם להתנהגות הרצויה.
בדיקות מבוססות קוד
עריכהטרנד מתפתח בפיתוח תוכנה הוא שימוש בכלי בדיקות כגון JUnit או NUnit המאפשרים הרצה של בדיקות יחידה כדי לקבוע האם חלק מסוים בקוד מתנהג כצפוי תחת תנאים שונים. מקרי הבדיקה מתארים בדיקות הכרחיות לווידוא הרצה תקינה של התכנה.
אוטומציה של בדיקות מבוססות קוד הוא פיצ'ר מרכזי במתודולוגית פיתוח תוכנה זריז, ומוגדר גם כפיתוח מונחה בדיקות (TDD). בדיקות היחידה נכתבות להגדרת הפונקציונליות לפני כתיבת הקוד. עם זאת, בדיקות אלו מתפתחות ומתרחבות במקביל להתקדמות תהליך הפיתוח שבמהלכו סוגיות חדשות מתגלות והקוד נתון לשינויים. רק במקרה שבו כל הבדיקות עבור הפיצ'רים המפותחים עברו, הקוד נחשב גמור. חסידי הגישה טוענים שהיא מפיקה תוכנה אמינה יותר וזולה יותר מאשר קוד שנבדק בצורת חקירה ידנית. גישה זו נחשבת אמינה יותר מכיוון שכיסוי הקוד נרחב יותר. כמו כן, הבדיקות רצות לעיתים תכופות במהלך תהליך הפיתוח ולא פעם אחת בסופו. המפתח מגלה פגמים מיד עם ביצוע השינוי בקוד, בשלב שבו תיקון הפגם זול יותר ביחס לשלבים אחרים. בסופו של דבר, ארגון הקוד מחדש הוא בטוח יותר; תהליך שינוי הקוד על ידי שיפור המבנה הפנימי תוך שמירה על ההתנהגות החיצונית יניב פחות פגמים בשימוש בגישה זו.
בדיקות ממשק משתמש
עריכהכלי אוטומציה רבים מאפשרים את היכולות להקליט פעולות משתמש ולהציג את תוצאות ההקלטות לצורך השוואת ההתנהגות בפועל להתנהגות הרצויה. היתרון בגישה זו הוא שפיתוח התכנה שנדרש עבורה הוא מועט אם בכלל. ניתן להשתמש בגישה זו בכל אפליקציה שכוללת ממשק משתמש. יחד עם זאת, גישה זו עלולה ליצור בעיות אמינות ותחזוקה רבות. תיוג מחדש של כפתור או הזזתו למיקום אחר במסך דורשת הקלטה מחודשת של הבדיקה. כמו כן, חלק מן ההקלטות כוללות "רעשים" – פעולות לא רלוונטיות או הקלטה שגויה של חלק מן הפעולות.
דוגמה לווריאציה של כלי מסוג זה – כלי לבדיקת אתרי אינטרנט. במקרה זה, ה"ממשק" הוא דף האתר. כלים מסוג זה משתמשים בטכניקה שונה של קריאת דף ה-HTML במקום לבחון אירועים במסך.
וריאציה נוספת היא אוטומציה ללא תסריטים (סקריפטים) שבה במקום להקליט ולהציג את פעולות המשתמש, יוצרת מודל של האפליקציה הנבחנת ומאפשר לבודק לייצר מקרי בדיקה על ידי עריכה פשוטה של הפרמטרים ותנאי הבדיקה. גישה זו לא דורשת מהבודק יכולת כתיבת תסריטים, אך עדיין יש לה את הכוח והגמישות של גישה מבוססת תסריטים. תחזוקת מקרי הבדיקה פשוטה למדי, אין קוד שדורש תחזוקה ועם כל שינוי באפליקציה הנבחנת מעדכנים את המערכת ליצירת מודל חדש. הבעיה היא שמודל האפליקציה מבוסס על תסריטי בדיקות שדורשים תחזוקה כל פעם שיש שינוי באפליקציה הנבחנת.
מה לבדוק
עריכה
פרק זה טעון שכתוב. אנא תרמו לוויקיפדיה ועזרו לשכתב אותו. ייתכן שתמצאו פירוט בדף השיחה. הסיבה היא ניסוח בסגנון סיכום שיעור.כלי בדיקה יכולים לעזור להפוך מטלות לאוטומטיות כגון התקנת מוצר, יצירת נתוני בדיקה, אינטראקציית ממשק משתמש גרפי, זיהוי בעיות וכו', לא בהכרח על ידי הפיכת הבדיקות לאוטומטיות בתצורת רשת קצה-אל-קצה. יש לבדוק התקיימות דרישות פופולריות כאשר חושבים על אוטומציה של בדיקות:
- אי תלות של פלטפורמות ומערכות הפעלה
- היכולת המונעת על ידי נתונים (קלט, פלט, נתוני-על)
- דיווח שניתן לאפיון (DB Access, Crystal reports)
- ניפוי שגיאות ותיעוד יומן בצורה קלה
- שליטה ידידותית בגרסאות – קבצים בינאריים מינימליים
- בר הרחבה ובר התאמה (API חופשיים כדי שיהיה אפשר לשלב עם כלים אחרים)
- דרייבר נפוץ (לדוגמה IDE עבור JAVA). זה מאפשר ביצוע אינטגרציה בין בדיקות לזרימת העבודה של המפתחים.
- תמיכה בהרצת בדיקות לא-מטופלות לצורך אינטגרציה עם תהליכי build ואצווה. שרתים של אינטגרציה מתמשכת דורשים זאת.
- הודעות אימייל (הודעה אוטומטית במקרה של כישלון או השגת רף כלשהו). מריץ הבדיקות מבצע זאת.
- תמיכה בסביבת הרצה מחולקת.
- תמיכה באפליקציה מחולקת.
גישת המסגרת באוטומציה
עריכהמסגרת היא מערכת משולבת, שקובעת חוקים של אוטומציה למוצר ספציפי. המסגרת משלבת את ספריות הפונקציות, מקורות הנתונים של הבדיקות, פרטי האובייקטים ומגוון מודולים לשימוש חוזר. רכיבים אלו פועלים כאבני בניין קטנות אשר צריכות הרכבה כדי לייצג תהליך עסקי. המסגרת מספקת את הבסיס של בדיקות האוטומציה ומפשטת את מאמץ האוטומציה.
הגדרת גבולות בין מסגרת אוטומציה וכלי בדיקה
עריכהכלים מעוצבים באופן ייעודי לסביבת בדיקות מסוימת, כגון סוג מערכת ההפעלה וכלי אוטומציה וביים (אינטרנטיים), וכולי. כלים משמשים כ-driving agent[דרושה הבהרה] עבור תהליך אוטומציה. אולם, מסגרת אוטומציה היא לא כלי לביצוע מטלה ספציפית, אלא תשתית שמספקת פתרון, היכן שכלים שונים יכולים לבצע את עבודתם בצורה אחודה. זה מספק פלטפורמה רווחת למהנדס האוטומציה.[דרושה הבהרה]
יש סוגים שונים של מסגרות. הן מקוטלגות על בסיס רכיב האוטומציה שהן ממנפות:
כלי בדיקות אוטומציה ראויים לציון
עריכה| שם הכלי | פותח ע"י | גרסה אחרונה |
|---|---|---|
| AutoIt | Jonathan Bennett & AutoIt Team | 3.3.16.1 |
| Cucumber | קוד פתוח | 1.0.2 |
| eggPlant | TestPlant | 2012 |
| JSystem | Top-Q | 6.1.11 |
| 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 | קוד פתוח | 4.12.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 |
ראו גם
עריכהלקריאה נוספת
עריכה
- Elfriede Dustin (1999). Automated Software Testing. Addison Wesley. ISBN 0-201-43287-0.
- Elfriede Dustin. Implementing Automated Software Testing. Addison Wesley. ISBN 978-0-321-58051-1.
- 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, ISBN 978-0-615-23372-7
- Hong Zhu (2008). AST '08: Proceedings of the 3rd International Workshop on Automation of Software Test. ACM Press. ISBN 978-1-60558-030-2.
- Mosley, Daniel J.; Posey, Bruce. Just Enough Software Test Automation. ISBN 0130084689.