Transcript כלי בדיקת איכות תוכנה - יסמין פאנוס

‫סמינר בהנדסת תוכנה‬
‫כלים אוטומטים לבדיקות תוכנה‬
‫‪WinRunner‬‬
‫סמינר בהנדסת תוכנה‬
‫ד"ר אביב יצחק‬
‫יסמין פאנוס‬
‫‪300398310‬‬
‫סדר המצגת‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫מבוא‬
‫בדיקות תוכנה‬
‫תפקיד בודקי תוכנה‬
‫רמות בדיקה‬
‫בדיקות אוטומטיות‬
‫כלי בדיקות קיימים‬
‫איך מתחילים?‬
‫‪GUI Map‬‬
‫תכנות באמצעות ‪TSL‬‬
‫הגדרת פונקציות ‪TSL‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫הרצת התסריט ודיווח תוצאות‬
‫ביצוע הבדיקות‬
‫דיווח ומעקב תקלות‬
‫איך נדווח על תוצאות ההרצה‬
‫כיצד יודעים מתי לסיים את‬
‫הבדיקות?‬
‫דוגמאות‬
‫סיכום‬
‫מבוא‬
‫בעבר היו בדיקות התוכנה תחום חובבני שבוצע על ידי התוכניתנים עצמם או על ידי‬
‫סטודנטים חסרי הכשרה‪ .‬היום הנדסת בדיקות תוכנה היא מקצוע נלמד‪ ,‬ובדיקות התוכנה‬
‫כוללות כתיבת תסריטי בדיקות תוכנה ושימושים מתקדמים בכלי בדיקה אוטומטים‪.‬‬
‫‪ WinRunner‬הוא כלי לבדיקת פונקציונליות בצורה אוטומטית של תוכנה‪.‬‬
‫נראה כי ה ‪ WinRunner‬יכול לקצר באפן משמעותי את זמן הבדיקות באמצעות תהליך‬
‫אוטומציה הכולל את השלבים הבאים‪:‬‬
‫‪ ‬למידת האובייקטים של היישום הנבדק‪.‬‬
‫‪ ‬הקלטת התסריט הידני ‪ Record and Playback‬והוספת פונקציות ופעולות נוספות‬
‫באמצעות שפת ה ‪.TSL‬‬
‫‪.Debugging ‬‬
‫‪ ‬הרצה וניתוח התוצאות‪.‬‬
‫‪ ‬דיווח על תקלות‪.‬‬
‫בדיקות תוכנה‬
‫בדיקות תוכנה זהו תהליך הנועד לאפשר לבעלי העניין במוצר לקבל מדד לאיכותו ועמידתו‬
‫בדרישות שהוצבו לו‪.‬‬
‫בדיקות תוכנה הם אוסף התהליכים המבוצעים במטרה לנקות את התוכנה מבאגים קריטיים‬
‫ועל מנת להבטיח‪ ,‬במידת האפשר‪ ,‬את פעולתה התקינה של התוכנה בהתאם לכוונת‬
‫המפתחים‪.‬‬
‫בדיקות תוכנה מהוות חלק אינטגרלי מתהליכי הנדסת תוכנה‪.‬‬
‫תפקיד בודקי תוכנה‬
‫תפקידו של איש הבדיקות הוא לעבור על כלל חלקיה של התוכנה‪ ,‬דרך הממשק או בתוך‬
‫שורות הקוד‪,‬לבדוק באילו חלקים ישנן תקלות ולהצביע עליהן בפני המתכנתים‪.‬‬
‫על בודק התוכנה מוטלות פעולות חשיבה וסוגי אחריות מרובים מלבד בדיקה יבשה‪ .‬כגון‬
‫חשיבה על עיצוב‪ ,‬יעילות נוחות‪ ,‬ממשק וכד'‪.‬‬
‫את הממצאים מחזיר הבודק לאנשים הקשורים בדבר כגון מנהל המוצר והמעצבים‪.‬‬
‫בודק תוכנה נקרא ‪ QA-Quality Assurance‬או ‪QC-Quality Control‬‬
‫המושג בקרת איכות מגיע מעולם הייצור‪ ,‬אולם בתחום המחשבים מדובר בהפקה של‬
‫תוכנות‪.‬‬
‫עולם בודקי התוכנה מתחלק ל ‪ 4‬רמות‪:‬‬
‫‪‬‬
‫‪‬‬
‫רמה גבוהה ‪ -‬בודקי תוכנה שעובדים ישירות מול הקוד‪.‬‬
‫סוג זה של עבודה נקרא קופסא לבנה (‪ )White Box‬ודורש עבודה מול שורות קוד‪ ,‬כולל‬
‫קריאה מלאה של הקוד ולעיתים תיקונים בקוד‪ .‬כדי לבצע בדיקת תוכנה ברמה כזו יש צורך‬
‫לדעת תכנות ברמה סבירה‪.‬‬
‫סוג נוסף של בודקי תוכנה‪ ,‬היא כתיבת תוכנות שבודקות תוכנית אחרת‪ .‬זהו למעשה תכנות‬
‫לכל דבר‪ .‬המתכנת בונה סביבה שתבדוק את הרכיב הספציפי אותו הוא מתכוון לבחון‪.‬‬
‫רמה בינונית ‪ -‬בדיקת תוכנה ללא התעסקות בקוד‪.‬‬
‫סוג זה של עבודה נקרא קופסא שחורה (‪ )Black Box‬משום שהתוכנה הנה כמו קופסה‬
‫שחורה ואטומה בפני הבודק שלא נכנס לקרביה‪ .‬לצורך סוג זה של עבודה נדרש ידע‬
‫טכנולוגי ברמה טובה‪ ,‬אולם לא נדרש ידע בתכנות‪.‬‬
‫בודק התוכנה סורק את כל התוכנה ע"י שימוש במקשים והזנה בשדות השונים‪ ,‬עליו לחפש‬
‫היכן התוכנית מתרסקת ומהם הבעיות הקיימות‪.‬‬
‫‪‬‬
‫‪‬‬
‫רמה נמוכה ‪ -‬בדיקה אוטומטית‬
‫ישנה עבודה בבדיקת תוכנה בעזרת תוכנות בדיקה אוטומטיות המיוצרות לצורך העניין‬
‫ודורשות ידע מסוים בתפעול תוכנת הבדיקה ובתכנון הבדיקה‪.‬‬
‫תוכנות בדיקה מהסוג הן‪ .Win Runner, Record View, Load Runner :‬ניסיון בעבודה‬
‫עם תוכנות מהסוג הוא יתרון אולם בד"כ אינו חובה לעבודה בתחום‪.‬‬
‫בכירים ‪ -‬ישנם בעולם בודקי התוכנה תפקידים בכירים כמהנדס או ראש צוות‪.‬‬
‫מהנדס בדיקות תוכנה אינו אדם שהוא בהכרח מהנדס‪ ,‬אלא אדם מנוסה יחסית בתחום‪ ,‬עם‬
‫ידע בכלי בדיקה שונים ובתכנות‪.‬‬
‫‪‬‬
‫בדיקות הליכים‬
‫‪‬‬
‫בדיקות מודולים‬
‫‪‬‬
‫בדיקות שילוב תוכנה‬
‫‪‬‬
‫בדיקות לתיקוף תוכנה‬
‫‪‬‬
‫בדיקות לשילוב‬
‫מערכת‬
‫‪‬‬
‫בדיקות לתיקוף‬
‫מערכת‬
‫‪‬‬
‫בדיקות קבלה‬
‫אלפא‬
‫בדיקות ביטא‬
‫בדיקת יחידות‬
‫)‪(Unit Testing‬‬
‫בדיקות שילוב (אינטגראציה)‬
‫בדיקות לתיקוף דרישות‬
‫בדיקות אוטומטיות‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫בודקי תוכנה אוטומטיות נמצאות בשימוש בעיקר בפרויקטים גדולים וזאת מפני שהזמן‬
‫שנדרש על מנת ללמוד ולהטמיע את כלי הבדיקות האוטומטיות גבוה‪ ,‬ומשתלם בעיקר‬
‫בפרויקטים בהם נדרשות כמות בדיקות מרובה‪.‬‬
‫בדיקות אוטומטיות נפוצות הן לדוגמה‪:‬‬
‫מנתחי קוד ‪ -‬בודקים את שלמות הקוד ואת התחביר (‪)Syntax‬‬
‫מנתחי זיכרון ‪ -‬בודקים את ניצול הזיכרון בתוכנה‪ ,‬ובודקים שאין זליגת זיכרון‪..‬‬
‫בודקי עומסים ‪ -‬בודקים את עמידות התוכנה‪/‬חומרה בפני עומסים שונים‪.‬‬
‫בדיקות ‪ - Web‬בודקות שהלינקים נכונים‪ ,‬שקוד ‪ HTML‬נכון‪ ,‬שתוכנות השרת עובדות‬
‫ושהגלישה בטוחה‪.‬‬
‫כלי בדיקות קיימים‬
‫בשוק קיום ישנם מספר רב של כלי עזר לתהליך הבדיקות‪ ,‬כמו‪:‬‬
‫•כלי לניהול ומעקב אחר תקלות‪.‬‬
‫•כלי לניהול הבדיקות‪.‬‬
‫•כלי לבקרת קוד‪.‬‬
‫•כלי למעקב כיסוי שורות קוד‪.‬‬
‫•כלי לביצוע בדיקות אוטומטיות‪.‬‬
‫•כלי לסימולציה של עומסים‪.‬‬
‫להלן שמות של מספר כלי בדיקות אוטומטיות כמו‪:‬‬
‫שם הכלי‬
‫‪ TestDirection‬מרקורי‬
‫‪ WinRunner / QTP‬מרקורי‬
‫‪ LoadRunner‬מרקורי‬
‫חברה‬
‫תיאור‬
‫כלי לניהול הדביקות‬
‫ודיווח ומעקב תקלות‪.‬‬
‫כלי לביצוע בדיקות‬
‫פונקציונליות אוטומטיות‪.‬‬
‫כלי ליצירת סימולציה של‬
‫משתמשים‪.‬‬
‫שם התוכנה‪WinRunner 2000 :‬‬
‫היצרן‪Mercury Interactive Corp. :‬‬
‫סביבת היעד‪ :‬מחשב‪MF AS/400 :‬‬
‫סביבת העבודה‪ :‬מחשב‪PC :‬‬
‫נציג בארץ‪ :‬מרקורי אינטראקטיב (ישראל) בע"מ‬
‫ארץ המקור‪ :‬קליפורניה‪ ,‬ארה"ב‬
‫מערכת הפעלה‪ :‬כל מערכת הפעלה‬
‫מערכת הפעלה‪Windows 3.1,95,NT :‬‬
‫הפעלת התוכנה אינה מותנית בביצוע שלבים קודמים על ידי תוכנה אחרת‪.‬‬
‫קטגוריות‬
‫אוטומציה בהרצת מבדקי‬
‫רגרסיה‬
‫פונקציות עיקריות‬
‫סביבת בדיקות ידידותית שפת בדיקות מניפולציה‬
‫בתאריכים אימות )‪ (verification‬אוטומטי‬
‫וגמיש דוחות‬
29. GUI Spy
28. Left Ctrl+F3
30. Copy
& Paste
14. GUI Map Editor
31.
Learn
32. Double click
15. Move
33.
1. Application
Under Test
2. capture
3. WinRunner
Recording
21. object
recognition
22. GUI Map
Configuration
26. defaults
17.
6. object
references
16.
7. Temp.
GUI Map
4. Script
code
generated
19.
12. Perm.
GUI Map
20.
25. Paste
script lines
18. Merge
5. Scripts
10. control
8. References
11. References
9. Run
13. load
‫איך מתחילים?‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫מפעילים את תוכנית התקנת ‪WinRunner‬‬
‫עם פתיחת התוכנה נקבל שתי אפשרויות לבחירה‪:‬‬
‫אם ברצוננו לפתוח תסריט חדש נבחר ב ‪New Test‬‬
‫אם ברצוננו לפתוח תסריט קיים נבחר ב ‪Open Test‬‬
‫כדי להתחיל בדיקות‪ ,‬עליך להזין תבנית סקריפט‪:‬‬
‫באמצעות מסך זה ניתן לראות את התסריט שהקלטנו‪ ,‬וניתן לבצע שינויים ותיקונים לתסריט‬
‫קיים‪ .‬בנוסף‪ ,‬מסך זה ישמש אותנו על מנת לבצע הרצה של התסריט ומעקב אחר התקדמות‬
‫התסריט‪.‬‬
‫הצבעים השונים בתוך התסריט‪ ,‬ישמשו אותנו על מנת להבדיל בין סוגים שונים של טקסט‪:‬‬
‫טקסט בצבע כחול‪ :‬מציין פונקציות של שפת ה ‪.TSL‬‬
‫טקסט בצבע ירוק‪ :‬מציין בד"כ שמות של אובייקטים‪.‬‬
‫טקסט בצבע שחור‪ :‬מציין בד"כ ערכים של אובייקטים ושמות משתנים‪.‬‬
‫טקסט בצבע אדום‪ :‬מציין הערות (התו הראשון בשורה הוא ‪.)#‬‬
‫סרגלי הכלים מכילים סוגים שונים של ‪ icons‬המשמשים להקלטה‪ ,‬הרצה ו ‪.Debugging‬‬
‫לדוגמא‪:‬‬
‫‪ .1‬כפתור ההקלטה ‪.Record‬‬
‫‪ .2‬כפתור הרצה (מתחילת התסריט)‪.‬‬
‫‪ .3‬כפתור הרצה ‪.Step By Step‬‬
‫ה ‪GUI Map‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫ה ‪ ,WinRunner‬בדיוק כמו כלים מקובלים אחרים לבדיקות רגרסיה‪ ,‬הוא בראש ובראשונה‬
‫כלי לבדיקות אוטומטיות באמצעות ה ‪.GUI- Graphic User Interface‬‬
‫כשאנו אומרים ‪ ,GUI‬הכוונה היא לממשק הגרפי בו אנו משתמשים על מנת לתפעל את‬
‫היישום אותו ברצוננו לבדוק או להריץ‪ ,‬או במילים פשוטות‪ -‬השדות‪ ,‬הכפתורים ושאר‬
‫האובייקטים הקיימים על המסך (תחת מערכת ההפעלה ‪ Microsoft Windows‬לצורך‬
‫העניין)‪.‬‬
‫ההנחה (הנכונה בד"כ) היא שרוב בדיקות המשתמש הן למעשה בדיקות ‪ -GUI‬אנחנו‬
‫לוחצים על כפתור <המשך> ומצפים לעבור למסך הבא‪ ,‬אנחנו בוחרים לסמן אפשרות‬
‫מסוימת ב ‪ Checkbox‬מסוים ומצפים לתגובה בעקבות בחירה זו‪ ,‬וכך הלאה‪ .‬מניסיון ידוע‬
‫לנו‪ ,‬כי בדיקות משתמש ברמת ה ‪GUI‬הן פשוטות מצד אחד (אין צורך להבין ממה ואיך‬
‫היישום מורכב) אך מצד שני הסיכוי למצוא תקלות (או יותר נכון את כל התקלות) הוא גדול‬
‫מאוד‪.‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫מסיבות אלה‪ ,‬ה ‪ WinRunner‬עוזר לנו לבצע בדיקות בכך שבשלב ראשון הוא יודע לזהות‬
‫את האובייקטים הגרפיים המוצגים על המסך (כפתורים‪,Checkboxes ,‬‬
‫‪ Radio buttons‬ועוד)‪.‬‬
‫באמצעות זיהוי האובייקטים ניתן להקליט תסריט‪ ,‬המדמה את פעולות המשתמש (למשל‪:‬‬
‫לחיצה על כפתור<‪ )>OK‬ולהריץ אותו שוב ושוב‪.‬‬
‫ה ‪ WinRunner‬מבצע את הזיהוי של כל אובייקט ואובייקט באמצעות זיהוי של התכונות‬
‫‪ Properties‬שלו‪ ,‬כפי שהן מתבטאות בתקשורת בין היישום לבין מערכת ההפעלה‬
‫‪ . Windows‬זיהוי התכונות הוא זיהוי חד חד ערכי ומינימאלי‪ -‬כלומר‪ ,‬נלמדות התכונות‬
‫המייחדות אובייקט אחד מסוים מכל האחרים‪ ,‬ורק התכונות האלה‪.‬‬
‫הלמידה של האובייקטים מתבצעת באמצעות ה ‪ GUI Spy‬ושמירתם של האובייקטים‬
‫מתבצעת בקבצים הנקראים ‪ . GUI Maps‬תכונה זו היא ייחודית ל‪( WinRunner‬לעומת‬
‫כלי בדיקה אחרים) ומאפשרת למשתמש ב ‪" WinRunner‬ללמד" אותו גם אובייקטים‬
‫מיוחדים ועוד אפשרויות למידה מתקדמות אחרות‪ ,‬כפי שהן מתבטאות בפעולת‬
‫ה ‪.GUI Map Configuration‬‬
‫הקלטת תסריטים ‪Recording Scripts‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫באמצעות הקלטה‪ ,‬אנו יכולים בקלות ובמהירות יחסית‪ ,‬ליצור תסריט שישמש אותנו‬
‫בהמשך להרצה חוזרת שלו‪ .‬בד"כ‪ ,‬נבצע הקלטה של תסריט פשוט‪ ,‬שיכלול פונקציות ‪TSL‬‬
‫המתאימות לתסריט שהקלטנו‪ ,‬ולאחר מכן נוסיף לו פונקציות בעזרת שפת ה ‪.TSL‬‬
‫שוב‪ ,‬לא נשכח‪ ,‬כי הקלטה אוטומטית תבוצע רק לאחר שהכנו מראש את התסריט הידני‬
‫המתאים לה‪ .‬ללא הכנה מראש‪ ,‬קשה מאוד לבצע אוטומציה של תהליך הבדיקות‪.‬‬
‫ה ‪ WinRunner‬מאפשר לנו להקליט בשני אופנים‪:‬‬
‫‪ Context Sensitive Mode .1‬ההקלטה וזיהוי האובייקטים מתבצעת ע"י זיהוי התכונות‬
‫של אותו אובייקט‪ .‬המשמעות היא‪ ,‬שהזזת אובייקט (למשל‪ ,‬כפתור פעולה) ושינוי מיקומו‬
‫לא משפיעה על זיהויו‪ ,‬כלומר‪ -‬התסריט המקורי "ירוץ" ללא כל בעיה‪ ,‬גם אם הזזנו‬
‫אובייקטים על פני אותו חלון‪.‬‬
‫‪ Analog Mode .2‬ההקלטה מסתמכת על המיקום המדויק (קואורדינאטות על המסך) של‬
‫הפעולה‪ ,‬כפי שהיא מתבטאת בהזזת העכבר על המסך‪ .‬משום כך‪ ,‬הקלטה כזו היא הרבה‬
‫פחות שכיחה‪ ,‬ומשתמשת בד"כ רק להקלטות של תרשימים‪ ,‬חתימות וכד'‪.‬‬
‫תכנות באמצעות‬
‫‪TSL-Test Script Language‬‬
‫‪‬‬
‫‪‬‬
‫ה ‪ WinRunner‬משתמש בשפת ה ‪ TSL‬על מנת ליצור את תסריטי הבדיקות שאני‬
‫מקליטים‪ .‬זוהי שפה ייחודית‪ ,‬אך "מאחוריה" למעשה עומד תסריט בשפת ‪ .C‬התסריטים‬
‫עצמם נכתבים ומוצגים ב ‪ TSL‬לשם הפשטות והנוחות‪ ,‬ועל מנת שלא נצטרך לטפל בבעיות‬
‫מורכבות כגון הקצאת משתנים‪ ,‬הקצאת מקום בזיכרון וכד'‪.‬‬
‫יחד עם זאת‪ ,‬לעיתים אנו נזקקים להוסיף לתסריט שהקלטנו גם לוגיקה פנימית‪ ,‬פונקציות‬
‫בקרה‪ ,‬לולאות וכד'‪.‬‬
if..else ‫ להלן דוגמא לבקרה על זרימת התסריט באמצעות‬
if )win_exists )“Flight Reservation Message”,1)==E_OK)
{
set_window )“Flight Reservation System”(;
button_press )“OK”(;
set_window )“Open Order”(;
button_press )“Cancel”(;
tl_step )flight_data, FAIL, couldn’t_open_by_date(;
}
# verifying that order table came up.
Else if )win_exists )“Search Results”,5)==E_OK){. . . .
:for ‫ באמצעות פונקציה‬loop "‫להלן דוגמא ליצירת "לולאה‬
Loc=1;
For (loc=0;loc<=1;loc++){ . . .
TSL ‫הגדרת פונקציות‬
function function_name([parameter1,[parameter2,[parameter3…]]]](
{
<function body>
}
:‫ פונקציות שימושיות‬3 ‫תיאור קצר ל‬
.‫ ביצוע התוכנית‬system() .1
.‫ מחרוזת להצגה בדוח הבדיקה‬Report_msg() .2
. C ‫ בשפת‬sprintf ‫ דומה ל‬Sprintf() .3
‫הגדרת פונקציות ‪TSL‬‬
‫‪‬‬
‫זיהוי האובייקט מתבצע במסגרת החלון לו הוא שייך(במקרה זה‪ ,‬החלון הוא ‪ .)login‬משום‬
‫כך לפני כל שימוש באובייקט כלשהו בתסריט‪ ,‬אנחנו צריכים להגדיר מהו החלון אליו אנחנו‬
‫מתכוונים‪ .‬הגדרה זו מתבצעת באמצעות הפונקציה )‪. set_window ("login",1‬‬
‫הרצת התסריט ודיווח תוצאות ההרצה‬
‫‪‬‬
‫לאחר שסיימנו את תהליך הפיתוח וה ‪ Debugging‬של התסריט‪ ,‬אנו יכולים לבצע הרצה‬
‫ולבחון את התוצאות‪.‬‬
‫מכיוון שהתסריט נכתב על מנת לעשות בו שימוש חוזר (בדיקה רגרסיה)‪ ,‬אנחנו צריכים‬
‫אפשרות להריץ ולקבל תוצאות לגרסאות שונות של היישום הנבדק‪ .‬נעשה זאת באמצעות‬
‫מתן שם לכל הרצה ‪.Test Run‬‬
‫יש לשים לב שה ‪ WinRunner‬מאפשר לנו הרצה ב ‪ 3‬מצבים‪:‬‬
‫‪Debug , Verify , Update‬‬
‫‪‬‬
‫במצב של ‪ Debug‬נשתמש כאשר התסריט עדיין בשלב ה ‪ .Debugging‬מכיוון שה‬
‫‪ WinRunner‬יוצר ספריות שונות עבור כל הרצה והרצה‪ ,‬בבחירת ‪ Debug‬אנחנו‬
‫"דורסים" בכל פעם את תוצאות ההרצה הקודמת‪ ,‬אך חוסכים בפתיחת ספריות מיותרות‪.‬‬
‫לאחר שהתסריט מוכן‪ ,‬נשתמש ב ‪ Verify Mode‬על מנת להריץ ולשמור את תוצאות‬
‫ההרצה לכל גרסה בנפרד‪ ,‬ע"י בחירה בשם משמעותי לכל ‪( Test Run‬תאריך או מספר‬
‫גרסה‪ ,‬בד"כ)‪.‬‬
‫במצב של ‪ Update‬אנו מאפשרים הרצה ועדכון כך שהתוצאות הצפויות יהיו שוות לתוצאות‬
‫בפועל‪.‬‬
‫ביצוע הבדיקות‬
‫בשלב זה מוקמת סביבת הבדיקות ומבוצעות ("מורצות") הבדיקות באופן מיידי ובהתאם‬
‫לעדיפויות עפ"י תיקי הבדיקות המפורטים‪.‬‬
‫תוצאות הבדיקות נרשמות ע"ג טפסי תקלה ומועברים לגורמים המתאימים לתיקון הליקויים‪.‬‬
‫תהליך ביצוע הבדיקות הנו תהליך איטרטיבי והוא מבוצע מספר פעמים עד לתיקון מלא של‬
‫כל הליקויים שאותרו‪.‬‬
‫דיווח ומעקב תקלות‬
‫בתהליך דיווח ומעקב התקלות מוודאים שכל התקלות שאותרו דווחו באופן ברור לגורם‬
‫המתאים לטיפול‪ ,‬וטופלו על ידיו‪ .‬לאחר מכן נבדקו שוב ונמצאו תקינות‪ .‬שלב זה מבוצע‬
‫לאורך כל מהלך הבדיקות‪ .‬כלים לדיווח ומעקב תקלות מאפשרים למנהל הבדיקות ולצוות‬
‫הבדיקות לאתר בכל נקודת זמן את מצבה של כל תקלה‪ ,‬קצב התקדמות תיקון התקלות‬
‫וקבלת דיווחים סטטיסטיים שונים על מוקדי "ריבוי תקלות"‪ ,‬תקלות בעייתיות שלא נפתרות‬
‫לאורך זמן‪ ,‬הספקי תיקון תקלות ע"י המתכננים ועוד‪.‬‬
‫‪28‬‬
‫איך נדווח על תוצאות ההרצה?‬
‫הפונקציה הנוחה והשימושית ביותר לשם דיווח על התוצאות (הצלחה וכישלון) היא‬
‫ה ‪.tl_step‬‬
‫לדוגמא‪:‬‬
‫;)‪rc = button_check_info)“OK”,”enabled”,1‬‬
‫)‪If (rc‬‬
‫{‬
‫(”‪tl_step )“button OK”,1,”is disables‬‬
‫}‬
‫‪ - button OK‬הוא שם הפעולה‬
‫‪ 1‬מצביע על כך שאנו מעוניינים להציג את ההודעה ככישלון (הודעה אדומה)‪.‬‬
‫‪ 0‬מצביע על כך שאנו מעוניינים להציג את ההודעה כהצלחה (הודעה ירוקה)‪.‬‬
‫‪ is disables‬היא ההודעה עצמה‪.‬‬
‫את התוצאות של הרצת התסריט נוכל לראות במסך התוצאות‪ ,‬באמצעות לחיצה‬
‫על ‪ icon‬המתאים (בצד הימני של המסך הראשי)‪.‬‬
‫כיצד יודעים מתי לסיים את הבדיקות?‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫קשה לייצר תוכנה גדולה ללא באגים‪ ,‬וכיוון שרבות מהתוכנות כיום מסובכות ומופעלות‬
‫בסביבות שונות‪ ,‬בלתי אפשרי פעמים רבות לבצע בדיקה מושלמת‪.‬‬
‫הבדיקה מסתיימת‪ ,‬אם כן‪ ,‬בהתאם לאחת מכמה אפשרויות‪:‬‬
‫תאריכי יעד להפצת המוצר או להפסקת הבדיקות‪.‬‬
‫רמת התקלות ירדה מרמה מסוימת‪.‬‬
‫מספר וסוג הבדיקות הגיעו לרמה מסוימת שנקבעה קודם לכן‪.‬‬
‫נגמר תקציב הבדיקה‪.‬‬
‫‪‬‬
‫חלון תוצאות הבדיקה מופיע מיד לאחר סיום הרצת התסריט‬
‫דוגמאות‬
‫סיכום‬
‫תוכנת ה ‪WinRunner‬‬
‫עם הזמן פתחו תוכנות חדשות ויעילות יותר מה ‪ WinRunner‬כמו תוכנת ‪QTP‬‬
‫בדיקות אוטומטיות מהוות חלק חשוב בתחום ‪ -‬בדיקה מקיפה ‪,‬מקצועית ‪,‬וחוסכת הרבה‬
‫עבודה ידנית‪.‬‬