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

את הארכיטקטורה מאחורי הקלעים בודקים פחות מכירים כי:

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

ב. זה לא משהו שאתה מתעסק איתו ביום יום, המערכת קיימת וזהו

 

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

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

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

 

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

 

Automation-Framework

[הקישו על התמונה להצגה בגודל מלא]
 התמונה נלקחה מהאתר: http://www.zenqconnect.com/services/TestAutomation.aspx

 

Application Under Test (או – System Under Test) – זהו המוצר שעליו אנחנו מריצים את הבדיקות

 

Object Repository – בסיס נתונים השומר בתוכו מידע על אובייקטים לבדיקות המבוססות GUI. כל שינוי באובייקטים הללו מצד המוצר יגרור שינוי מרכזי כאן , ללא נגיעה בקוד. למשל האובייקט שנקרא כפתור ישמר ב-OR ואיתו ביחד כל המאפיינים שלו כמו גודל, צבע, רקע , ID , שם Class, וכו'.

 

Config & Global Variables – בסיס נתונים המיוצג בדרך כלל כקובץ אשר מכיל בתוכו משתנים גלובאליים שהם בד"כ אינם משתנים לאורך הריצה (לדוגמא: מיקום ספרייה מסויימת שם יושבים קבצי הלוג) הם ישמשו אותנו בכל איזור בקוד בו אנו נמצאים וכן פרמטרים משתנים (כמו למשל שם המכונה, שם המשתמש, שם גרסה וכו')

 

Common Business Automation Scripts – אני לא כל כך מסכים עם שם הקומפוננטה הזו, הייתי קורא לה Function Library והיא באה לאגד את פונקציות הבסיס (Building Blocks) השימושיות ביותר במוצר, כמו למשל – לחיצה על כפתור. כאן יושב הלב הפועם של הבדיקות האוטומטיות.

 

Input Data – כאן יושב ה-Data של מקרי הבדיקה, בשיטת ה-Data Driven Testing, היינו מחליפים בקומפוננטה הזו את הקישור לבסיס מידע אחר, בסיסי נתונים יכולים להיות מיוצגים כקבצי XML , Excel, Access, NotePad , קובץ Dump ועוד.

 

Execution – החץ המופנה אל עבר ה-AUT למעשה בא להגיד לנו שפה יושב כלי ההרצה איתו אנו עובדים, כלי כמו AutoIT או Selenium, הקוד נכתב ב-IDE של הכלי ואילו הריצה מתבצעת במנוע ההרצה שלו (Parser + Test Runner)

 

Automation Test Scripts – קומפוננטה זו תכיל אוסף של טסטים ביזנסיים הכתובים כסקריפטים, היא תכיל את הלוגיקה בקוד שמבצעת את מקרי הבדיקה, היא יושבת מעל ה-Function Library ואליה היא קוראת מספר רב פעמים, למשל: לחיצה על כפתור עם סט של פרמטרים נלווים כמו מזהה ייחודי, כמה פעמים ללחוץ, אורך זמן הלחיצה וכו'. אם ה-Function Library הוגדר כ-לב הפועם, הרי שקומפוננטה זו תוגדר כ-מוח של כל המערכת.

 

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

 

Reporting – קומפוננטה שאמורה לקחת את תוצאות הריצה כולל הצלחות, כשלונות ו-exceptions למיניהם ולהציג אותן למשתמש, הכלל החשוב כאן הוא שהנתונים צריכים להיות הכי ברורים שאפשר, במיוחד אם בודקים כאן מוצר גדול ומורכב.

הדוחות אמורים לכלול, בנוסף לתוצאות הריצה הכלליות, גם מידע על תוצאות verification points וכן של זמנים. כדאי מאוד שיילקח Screen Shot ויצורף לכל אחד מן הסטפים של ההרצה. מומלץ גם שלקומפוננטה תהיה היכולת להפיץ את ה-reports בצורה נוחה (כמו למשל שליחת מייל תפוצתי).

 

Common Library – בנוסף ליכולת הסקריפטים האוטומטיים לקרוא מתוך ה-Function Library, יש גם את האפשרות לקרוא מתוך ספריות חיצוניות שלא קשורות בהכרח לפרוייקט האוטומציה שלנו, כמו למשל פונקציות מתמטיות, עבודה עם קבצים וכו'.

 

Driver Script – יכיל בתוכו את ה-Clean Up Scripts שתפקידם יהיה לנקות את סביבת ההרצה (קבצים, DB) לפני כל הרצה או כמה הרצות וכן את ה-Scheduler שאיתו נוכל לתזמן הרצות בצורה אוטומטית, ניתן יהיה לקבוע יום ושעה , לקבוע מתי אסור לרוץ (למשל כשרץ במערכת פרוסס End of Day) וכן לקבוע תלויות בין הרצות, כמו למשל שטסט 2 לא ירוץ עד אשר טסט 1 לא סיים את הרצתו בהצלחה.

 

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

 

 

תוספות ושינויים:

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

ה-Keyword Driven testing (KDT) תיתן לנו את היכולת לבנות טסטים אוטומטיים גם מבלי לדעת קוד.

 

מעל שכבת ה-Function Library ניצור קומפוננטה חדשה שתיקרא: KDT Engine, השכבה הזו תדע לקשר בין הפונקציות הקיימות במערכת לבין שכבה עליונה יותר שתהווה את ה-GUI למשתמש.

KDT GUI – יציג לאותו בודק ידני \ מיישם אוטומציה חלון ובו הוא יוכל לבנות (בין אם זה לגרור, לבחור או לכתוב) אובייקטים שונים עליהם ניתן לבצע אוסף פעולות, זה בנוסף ללוגיקה ביזנסית ייצרו מקרה בדיקה, ה-GUI יכול להיות מיוצג כאפליקציה דסקטופית, מסמך אקסל או אפילו web page. קומפוננטה זו תהיה מקבילה ל-Automation test Scripts.

 

Logs:

הלוגים אמורים להיבנות כקומפוננטה נפרדת כך שהיא מתממשקת ל-Automation Tast Scripts ול-Reporting. באיזה אופן ?
לפני כל תחילת טסט (כחלק מפונקציה שמכינה את הטסט להרצה) נשלחת בקשה להתחיל לכתוב ל-Reporting ובמקביל מידע נשלח ללוג (בין היתר – timestamp ושם הטסט)
במהלך הטסט, כל לוג שיוצא מן המערכת הנבדקת נשפך ללוג של האוטומציה, ניתן כמובן לפלטר את הלוג ל-LogLevel שייתן רק ERROS בכדיי לא להעמיס יותר מידיי במידע לא רלווני.
בסיום כל טסט שוב תישלח בקשה ל-Reporting לסיום הטסט עם הסטטוס שלו ובמקביל ללוג עם timestamp וסגירת session
כך נוכל לרשום בלוג מידע עם קישור בין שמות טסטים לזמני הרצה.
ניתן לכתוב עוד סקריפט פשוט שירוץ על הלוגים ויחפש מילים מוגדרות מראש כמו – Failure , Exception, Out of time וכו' ויצעק במידה ומצא משהו.
למעשה, אם ארחיב פה קצת יותר, מעל ה-Reporting יושב עוד מנוע אחד שניזון ממידע המגיע מתוצאות הריצה והוא מחולל report ממבט על (אנחנו קוראים לו manger report),  מה הכוונה ? לרכז במסמך אחד את סטטוס ההרצה של כל הרגרסיה כשמסתכלים על אסופת טסטים: Test Sets או פיצ'רים או מודולים (בכל מקום קוראים לזה אחרת)
למי זה טוב ? למנהל שאין לא עניין או זמן לראות תוצאות ברמה של טסט בודד מה עבר ומה נכשל (יש פרוייקטים שמכילים אלפי טסטים). ה-report הזה נשלח אוטומטית במייל לרשימת תפוצה מוגדרת מראש.

השאר הערה\הודעה