את Jlenium כתבתי מתוך אהבה. אהבה למקצוע, אהבה לתכנות, אהבה לבדיקות.
זהו Framework לבדיקות אוטומטיות שפיתחתי בכמה סופי שבוע פנויים, בעקבות איזשהו חוסר מסויים.
נכון, אני יודע, ישנם לא מעט Automation Frameworks בעולם, מה אני כבר יכול להוסיף לשוק הרווי הזה ? מבין כל המוצרים שסקרתי, לא ראיתי אחד שיודע לשלב בין כמה עולמות של בדיקות, וזה היה מוזר.
מה שהחל סתם כאיזו הבלחה של רעיון קטן וכמה שורות קוד שהשתרבבו לי בראש כבר זמן מה, הלך וצבר תאוצה ל-Design על חתיכת נייר ביום שבת שימשי והתפתח לממש Framework עשיר.
בואו נתחיל בשאלה ראשונה: מהם סוגי הבדיקות האוטומטיות הפופולריים ביותר שאנו מבצעים ?
– בדיקות פונקציונליות
– בדיקות עומסים
– בדיקות API
– בדיקות ויזואליזציה
יפה, שאלה שנייה: אלו כלים עומדים לרשותינו לסוגי הבדיקות הנ"ל (ההתייחסות פה היא לכלי Open Source בלבד) ?
– Selenium WebDriver
– Appium
– JMeter
– Sikuli
* רשימה חלקית אני יודע, אבל אלו הם מבין הפופולריים ביותר.
ניסיתי לחפש איזשהו כלי אחד שיכול להכיל את כולם, לא מצאתי (וחיפשתי הרבה) , אז החלטתי להרים את הכפפה ולכתוב אחד כזה כאשר הקו המנחה שלי היה: "אל תמציא את הגלגל ! יש לך דברים מדהימים שאחרים כבר כתבו – תשתמש בהם." אז השתמשתי:
לקחתי את Selenium WebDriver , חיברתי אותו ל-Appium (זה שטויות, פשוט מחברים את ספריות הקוד לאותו פרוייקט), משם המשכתי לכלי ה-JMeter וממשקתי את 2 העולמות (פונקציונלי ועומסים) בעזרת הפריימוורק היחיד שנתמך בו – JUnit (עקיצה לכל ה-TestNG Fan Boys) , הכנסתי לפרוייקט גם את מנוע השוואת התמונות – Sikuli לבדיקות וויזואליזציה, על הדרך אמרתי "למה לא DB ?" וה-MySQL הוכנס גם הוא , אין כיום Framework ללא Reports , אז השתמשתי פה בשתי מערכות Report מתקדמות (למה שתיים ? סתם בשביל הכיף וההתנסות), החלטתי לתת את היכולת לבנות את מקרי הבדיקה ע"י ממשק ה-KDT (שימוש במילים שמורות) או ע"י ה-BDD (שימוש ב User Stories), אם כבר אז כבר – גם ה-Maven נכנס, גם מערכת ה-Git וכמובן שעל הכל מנצח ה-Jenkins :
וואוו. הרבה באזזוורדס !
אז איך זה בדיוק עובד ? הביטו בתמונה הבאה:
שימו לב כי התמונה מראה את המערכת כולה והיא מתחלקת לשניים:
בחלק הימני יש לנו את מילטון (דמות מהסרט Office Space) – מילטון הוא מפתח מוצר, נגיד Full Stack Developer , הוא אחראי על הצד שלו – Server ו-Cleint , אני בטוח שמה שהוא עושה מעניין מאוד, אבל אנחנו לא נתייחס אליו הרבה בפוסט זה.
בחלק השמאלי יש לנו את צ'ק נוריס. צ'ק הוא איש בדיקות מעולה, מעמיק, חוקר, ראש טוב על הכתפיים ושום באג לא מצליח לחמוק ממנו, למעשה הבדיקות אצל צ'ק מתבצעות עוד לפני שהמוצר נכתב 🙂
רק רגע לפני הצלילה לעומקו של ה-Framework , בואו נראה את מקרה הבדיקה:
יש להיכנס ל-Server , להזין נתונים אישיים בשביל שהוא יציג לנו שם משתמש וסיסמא (למקרים בהם שכחנו את הסיסמא).
את שם המשתמש והסיסמא אנחנו אח"כ נכניס לקליינט בשביל להיכנס לאפליקציה – חשבון בנק (פיקטיבי כמובן) ושם אנו נרצה לוודא כי הסכום בעו"ש הינו 100 דולר
מודול ה-Keyword Driven Testing:
צ'ק רוצה להתחיל לעבוד עם Jlenium. את הבדיקות שלו הוא יכתוב בשיטת ה-KDT כשהממשק יהיה מסמכי אקסל (אני מוצא את אקסל ככלי חזק מאוד שיכול לשרת את הבודק להמון צרכים). על הטכניקה של Keyword Driven Testing ניתן לקרוא, בין היתר, כאן בבלוג שלי.
כך למשל מקרה בדיקה יראה (שימו לב, המשמעות של ה-KDT הינה לאפשר לאנשי בדיקות תוכנה ללא רקע בתכנות לבצע בדיקות אוטומטיות):
מה אנחנו רואים פה ?
המסמך מחולק ל-8 עמודות, העמודה הראשונה מתארת את שם הבדיקה.
העמודה השנייה מתארת את שם הפעולה שאנו נרצה לבצע (זוהי רשימה סגורה של פעולות אותן אנו מגדירים מראש כשאנו קובעים את שפת ה-KDT)
העמודה השלישית מתארת את שם האובייקט עליו אנו נרצה לבצע את הפעולה (מהעמודה הקודמת)
העמודה הרביעית והחמישית יתראו את זיהוי האובייקט עליו נבצע את הפעולה
העמודה השישית תגדיר את הפרמטר \ פרמטרים אותם נשלח לפעולה
העמודה השביעית נועדה בשביל לעזור לנו לדבג את הבדיקה , נוכל לקבוע ערכי yes להרצת השורה (Step) או ערך no לדילוג מעל השורה (כמו הכנסת הערה בקוד)
העמודה השמינית תכיל מידע על אותו Step – מה הוא בדיוק מבצע, זוהי עמודה שנועדה לשרת את מסמך האקסל ואת ה-Report, כאשר המערכת יודעת לקרוא את ערך השדה כאן ולהכניס אותו ל-Report
נוכל כמובן ליצור עוד מקרי בדיקה בהמשך גיליון האקסל או ליצור גליונות חדשים (גיליון = סוויטה של בדיקות).
מעבר לזה, נוכל ליצור שכבת בדיקות המתבססת על גישה שונה. גישה אשר מונעת מאותו בודק שמרכיב את תסריטי הבדיקה להיכנס לצד הטכני ולזהות את האלמנטים, זה אומר שהאלמטים יהיו מזוהים כבר בתשתית האוטומציה, שימו לב לתמונה הבאה , זהו אותו מקרה בדיקה, רק שהוא מתואר כתהליך עיסקי (כאמור כאן אין באחריות הבודק להגדיר את זיהוי האלמנטים)
אתם יכולים לראות כי בין כל המילים השמורות, הגדרנו פה עוד 2 תווים, תווים שמורים בשפה שלנו.
התו הראשון הוא ה-$ (שורה 4, עמודה C) והוא מייצג לנו משתנה. משתנה אליו אנו יכולים להכניס ערך
תו ה-% (שורה 7, עמודה C) אומר שהוא קורא את הנתון הזה מתוך טבלה ב-Data Base
מודול ה-MySQL:
כאמור, נוכל להשתמש בשפה שלנו עם תווים מיוחדים אותם נגדיר שישלפו מידע מה-DB (או לחילופין – יכתבו מידע ל-DB) , התו שבחרנו להשתמש הוא ה-% והוא אמור להביא לנו את המידע הרלוונטי מהטבלה הרלוונטית ב-DataBase , במקרה שלנו זהו כתובת המייל
מודול המנועים: Selenium WebDriver , Appium , JUnit:
ראינו כי צ'ק נוריס כתב מקרה בדיקת בשיטת ה-KDT שהיא לא אחרת מאוסף של מילים באנגלית, אבל איך מאותן מילים שמורות בסופו של דבר מתבצעת הפעולה על הדפדפן \ מכשיר סלולרי בפועל ?
אז מאחורי הקלעים ממומשות מחלקות עם פונקציונליות שיודעות לקחת את המילים השמורות הללו ולתרגם אותן לפעולות. זה אומר שהמנגנון עובד כך שהוא רץ בלולאה על תאי האקסל , בכל איטרציה נשלף המידע מהתא, מפורסס וישנה קריאה לפונקציה מתאימה בעקבות המידע הזה. זאת אומרת שאם שלפנו מהתא את הערך "GoToURL" זה אומר שהמערכת תקרא לפונקציה שלנו (בשכבה תחתונה יותר) שהיא תקרא לפקודת הסלניום לפתיחת הדפדפן driver.get(parameter value)
אז כאמור ה-Selenium וה-Appium יתנו לנו להתממשק לקליינט (Web / Mobile) ומי שיהיה אחראי להריץ את הפקודות הללו יהיה ה-Junit. ה-Junit הינו Framework (נוסף) לבדיקות אוטומטיות (בג'אווה) שמספק לנו, בין היתר, מנוע הרצה, אנוטציות, תהליכי בדיקה ווריפיקציות ועוד. על כל אלה, אנו בפרוייקט זה נרתום אותו בעיקר להתממשקות עם כלי אחר חשוב מאוד. ה-JMeter
מודול ה-JMeter:
ה-JMeter הינו כלי לבדיקות עומסים וביצועים, הוא מספק לנו גם שירותים נוספים כמו קריאות API ועוד.
כלי זה משחק תפקיד חשוב ב-Framwork שלנו שכן הוא אחרי לקרוא לאנוטציות ה-JUnit שיפיעיל את הבדיקות הפונקציונליות שראינו במודול הקודם, דרכו נוכל להעמיס את הבדיקות הפונקציונליות הללו וכן לשלוח בקשות לשרת ה-Web של המערכת הנבדקת
מודול ה-Sikuli:
ה-Sikuli הינו כלי לבדיקות וויזואליזציה, למעשה ה-Sikuli חובש שלושה כובעים, האחד הוא IDE עם שפת סקריפטינג משלו , השני הוא ה-API אליו ניתן להתחבר מכל פרוייקט ג'אווה והשלישי הוא מנוע השוואת התמונות אותו צריך להתקין על הסביבה.
אנו נרצה להשתמש עם Sikuli כאשר נרצה לוודא כי האפליקציה שלנו נראית כפי שהיא אמורה להיראות. ישנם דברים שהעין האנושית אינה יכולה להבדיל ואילו מכונה כן. למשל הזחה של טקסט 2 פיקסלים ימינה. ה-Sikuli אמנם אינו בעל מנוע זיהוי התמונה החזק ביותר בשוק, אך הוא הפופולרי ביותר מבין כלי ה-Open Source
בטסט שלנו למשל אנו יכולים להכניס מקרה בדיקה בו אנו רוצים לוודא את התמונה של הלוגו של אתר הבנק הפיקטיבי שלנו
מודול ה-Reoprts:
כל Framework של אוטומציה כיום מגיע עם מערכת להפקת דוחות מרשימה. דוחות זה פיצ'ר מאוד חשוב בעולם האוטומציה ובמיוחד בעולם האג'ילי – עולם שאין לנו יותר מידיי זמן להתעכב על נפילות בבדיקות שלנו (אלא אם כן זה באג), כשיש לנו תשתית דוחות טובה, לא נצטרך להתעכב זמן רב בנסיונות להבין את מקור הנפילה, צילומי מסך בזמן נפילה הן MUST כיום בכל מערכת.
סתם בשביל הכיף, החלטתי להשתמש בשני סוגי דוחות: האחד להרצה על ה-Web, השני להרצה על ה-Mobile
מודול ה-Git וה-Maven:
כמו לכל פרוייקט תוכנה המכבד את עצמו, החלטתי "לחבר" גם את פרוייקט ה-Jlenium למערכת ה-Maven לעידכונים שוטפים של מגוון הקבצים וספריות הקוד שצורפו לפרויקט, החל מספריות ה-Apache POI לקריאת מסמכי האקסל ועד לספריות ה-Sikuli וכמו כן ליצירת פרופילי הרצה שונים.
ובנוסף, הגדרתי את הפרוייקט כפרוייקט Git באקליפס , זאת בשביל לנהל את מערכת קבצי הפרוייקט בצורה מסודרת, על אף שכרגע אני המפתח היחיד של Jlenium ולא צוות מפתחים, אבל זו "הכנה למזגן" וגם הטמעה זולה מצידי, אז למה לא…
מודול ה-Jenkins:
טוב, אז הדבר האחרון שארצה לעשות בפרוייקט ה-Jlenium הוא לבצע בו פעולה ידנית, כמו למשל – להריץ אותו באופן ידני. לא בבית ספרינו.
ה-Jenkins הינו כלי אחד מיני רבים בעולם ה-Continuous Integration והוא נועד בסופו של דבר לדלוור את התוכנה בצורה מהירה יותר, בפועל מה שאנחנו עושים זה מממשקים את פרוייקט האוטומציה שלנו מול פרוייקט המוצר של החבר'ה של מילטון (ההוא מ-Office Space). זה אומר שכשהפרוייקט שלו מתקמפל בהצלחה , הפרוייקט שלנו מתחיל לעבוד עם כל הבדיקות האוטומטיות שצ'ק נוריס כתב לנו עם ה-Jlenium וה-KDT.
אז איך עושים את זה ? בשני שלבים:
א. מייצרים קריאה להרצה משורת פקודה של ה-JMeter (הוא זה שמתחבר ל-Jenkins)
ב. יוצרים ג'וב (או Item) חדש ב-Jenkins קוראים לפקודת ה-Jmeter (אני עובד עם קובץ bat) ומתזמנים אותו למתי שאנחנו רוצים
מודול הקונפיגורציה:
בכדיי להימנע מהגדרות Hard Coded במחלקות השונות, החלטתי להוציא כל מיני פרמטרים החצוה אל קובץ חיצוני. בחרתי להשתמש בקובץ XML
אנו רואים כאן למשל את פרמטר ה-BrowserType בשביל להגדיר על איזה סוג דפדפן אנו רוצים להריץ
פרמטר ה-Wait Time בכדיי להגדיר את החסם העליון של כל מיני סוגי המתנות שנבצע
פרמטר ה-DebugWait בכדיי להגדיר את קצב הריצה, 0 אומר שהטסטים ירוצו ללא עיכוב, במידה והיינו מכניסים 1000 (פועל על מילי-שניות) אז היינו רואים המתנה של שנייה בין כל פעולה ופעולה , זאת על מנת שנוכל לדבג ויזואלית את הריצה שלנו (ריצה של סלניום יכולה להיות מאוד מאוד מהירה ונוכל לפספס דברים רבים).
פרמטר ה-Peth_TetsData וה-File_TestData – שם אנו נגדיר היכן קובץ ה-KDT שלנו ישב ומה יהיה שמו
כמו כן גם היכן קבצי ה-Report יישבו
אנו רואים בקובץ גם התייחסות ל-Connection String שמחבר אותנו ל-MySQL DB כמו כן הגדרת User ו-Pass
ויש לנו גם את ה-ExcelSheet בשביל לקבוע אילו בדיקות אנו רוצים להריץ במסמך האקסל שלנו , האם את הבדיקות בגיליון הראשון, השני, השלישי וכו'
ראינו כאן פירוט על Framework האוטומציה – Jlenium.
כמו שכבר כתבתי, המערכת הזו נכתבה מתוך אהבה לתחום. התחלתי בקטן, ללא יומרות, והתקדמתי הלאה ככל שהזמן הפנוי איפשר לי לעשות זאת. אני חייב לציין על אף שאופיין ומומש כאן הרבה, עדיין המוצר רחוק מלהיות מושלם (יכול להיות שכבר בקריאה כאן על המוצר כנראה אמרתם לעצמכם: רגע, אבל מה עם תמיכה בזה ובזה ? ולמה דווקא ככה ? וכו'). כנראה שצריך להשקיע במוצר עוד לא מעט סופי שבוע בשביל שיהיה ניתן להתחיל לקרוא לו גרסת אלפא.
הדבר החשוב ביותר שרציתי להעביר בפוסט זה, שלא צריך תמיד להמציא את הגלגל מאפס. הצלחתי להרים פה סביבת בדיקות בפרק זמן יחסית קצר. איך יכולתי לעשות קסם כזה ? אין פה שום קסם, פשוט השתמשתי בכלים מובילים בשוק ורתמתי אותם לצרכיי, כלים שכבר מספיק בשלים כדי שאני לא אצטרך לחוות את חבלי הלידה שלהם בפרוייקט שלי.
כל מה שהייתי צריך זה היכרות עם סביבות בדיקות שונות ויכולת לקודד… אה, כן. והרבה מוטיבציה וסבלנות, כי היו גם רגעים של תיסכול (כשלא עבדו דברים)
מקווה שנהניתם לקרוא פוסט זה כמו שאני נהניתי לכתוב אותו
יוני
