אוטומציה מורכבת פחות | לירן יושינסקי
נתחיל ב"למה בכלל צריך אוטומציה?"
אענה על כך במשפט:
כדי להפחית את מאמץ הבדיקה הידנית ב cycle הרגרסיה ובכך להגדיל את החזר ההשקעה (ROI).
קיימות מספר סיבות משמעותיות להשתמש בבדיקות אוטומציה בתהליך הפיתוח והבדיקה של תוכנה. הנה כמה מהסיבות העיקריות:
- חסכון בזמן ומשאבים: בדיקות אוטומציה מאפשרות לבצע בדיקות באופן אוטומטי, מה שמפחית את הצורך בבדיקות ידניות. השימוש בבדיקות אוטומטיות מפחית את הזמן והמאמץ שנדרשים מהצוות לביצוע בדיקות חוזרות ומורכבות.
- דיוק ואמינות: בדיקות אוטומציה יכולות להיות מדויקות ואמינות ביותר. כאשר הם מוגדרים מבוצעים כהלכה, ניתן להיות בטוחים שהתהליך יבוצע בדיוק ולא יתרחשו שגיאות אנושיות. זה יכול לגרום להפחתת באגים ולשיפור איכות התוכנה.
- ניתוח יעיל: בדיקות אוטומציה מאפשרות לבצע ניתוח מקיף ופרקטי של התוכנה. ניתוח זה מאפשר לזהות באגים, למדוד ביצועים, לבדוק פונקציות מסוימות ולבצע בדיקות שונות בצורה מהירה ויעילה.
- חסכון בעלויות: אף על פי שהשקעת המשאבים בהתחלה לפיתוח בדיקות אוטומציה יכולה להיות גבוהה ניתן לזהות באופן מוקדם יותר בעיות ותקלות בתוכנה. זה מאפשר תיקון מהיר ויעיל עוד בשלבים מוקדמים של תהליך הפיתוח, כאשר העלות של תיקון השגיאות עוד נמוכה. בכך ניתן לחסוך בעלויות עתידיות שעשויות להתרחש עקב פעולות תיקון מאוחרות.
- חסכון בטעויות אנוש: בעת ביצוע בדיקות ידניות, ייתכן שיתרחשו טעויות אנוש כתוצאה מטיפול שגוי או שכחת מקרים קצה. הבדיקות האוטומטיות מבצעות את הבדיקות בדיוק לפי ההוראות שהוגדרו, מכך נובעת הפחתת הסיכוי לשגיאות בעת הבדיקה.
- הפחתת סיכון: על יד הפעלה תכופה של הבדיקות.דבר זה מאפשר לאתר באגים ובעיות בתוכנה בשלב מוקדם יותר ולתקן אותם לפני שהם מתרחשים ביישום הפועל.
- תמיכה בריבוי פלטפורמות ומכשירים: בעת פיתוח תוכנה, ייתכן שיש צורך לבדוק את היישום על מגוון רחב של פלטפורמות ומכשירים שונים. בדיקות אוטומציה מאפשרות ליצור בדיקות חוזרות שניתן להריץ במקביל על מספר פלטפורמות ומכשירים, מה שמקל על הבדיקה והפעלת היישום במגוון תנאים.
- יכולת לבצע בדיקות מרובות: בדיקות אוטומציה מאפשרות לבצע מגוון של בדיקות חוזרות בצורה מהירה ויעילה זה מאפשר לזהות בעיות שוב ושוב, לבדוק את הפיתוח החדש בכל ריצה ולוודא שאין השפעה של שינויים קודמים על התוכנה. בנוסף להתאים את הבדיקות לתסריטים שונים ולתנאים שונים.
ולמה להשתמש ב-Automation Framework?
כי אחרת היינו מיישמים הכל מאפס...
הנה כמה מהיתרונות המרכזיים:
- ניהול וניתוח מרוכז: ה-Automation Framework מספק מבנה ותשתית לניהול מרוכז של הבדיקות האוטומטיות. זה כולל את הכלים, התהליכים, מנגנוני הדיווח והמתודולוגיות הנדרשות לביצוע הבדיקות בצורה יעילה ומסודרת.
- חסכון בזמן ומשאבים: ה-automation framework מאפשר כתיבת קוד אוטומציה מבוסס תבניות וגם שימוש בכלים וספריות קיימות. זה מפחית את הזמן והמאמץ הדרוש לכתיבת קוד חדש עבור כל בדיקה ומאפשר שימוש חוזר והפחתת הדרישה למשאבים.
- יכולת רחבה: ה-automation framework מספק פונקציות ותכונות מובנות שניתן להשתמש בהן כדי לממש ולבצע בדיקות מורכבות ומגוונות. זה כולל דרייברים, אסטרטגיות איתור (locators), פעולות דפדפן (actions), אירועי משתמש (events) ועוד.
- יעילות ודיוק: ה-automation framework מבצע אוטומציה תחת תהליכים חוזרים ומנוהלים, מה שמקנה יעילות ודיוק גבוהים בבדיקות.
BDD – Behavior-Driven-development, מה?!?
מתמקד בעיקר בנקודת המבט העסקית ובדרישות התוכנה ופחות ביישום הטכני.
ובנוסף מעודד שיתוף פעולה בין מפתחים, QA ומשתתפים עסקיים, במאמץ לעזור לגשר על הפער העסקי/טכנולוגי.
מעולה, אז מה זה Gauge?
כלי חינמי open source לכתיבה והרצת בדיקות קבלה(acceptance tests) שמאפשר למהנדסי האוטומציה להאיץ את תהליך פיתוח התוכנה.
פותח על ידי חברת ThoughWorks.inc, הידועה בעיקרה כחברת יישומי תוכנה בינלאומית ומחלוצי ה-Selenium.
הרעיון היה לאפשר לאנשי QA ומפתחים ליצור בדיקות בצורה פשוטה ואינטואיטיבית, בלי להיות תלויים בידע עמוק בתכנות. הקונספט המוצלח מאחורי Gauge הוא "תיעוד חי וביצוע", כלומר מסמך שניתן לערוך ולעדכן כל הזמן.
יש לו מספר רב של פיצ'רים ייחודיים אל מול פריימוורקים אחרים, נראה למשל בטבלה את ההשוואה לפריימוורק Cucumber
|
CUCUMBER |
GAUGE |
|
מבוסס על קבצי טקסט עם Given, When Then |
תחביר פשוט, גמיש, קריא ועשיר המבוסס על Markdown
|
|
תומך בכמה סוגים בסיסיים של פרמטרים (int, float, word, string), טבלאות נתונים וסוגי פרמטרים מותאמים אישית שאפשר להצהיר באופן ידני.
|
תומך ב-data driven execution ו external data sources. מאפשר להחדיר טקסט שלם של קובץ או CSV (עם ניתוח אוטומטי לטבלה) ללא תוספת קוד. נפרט עליהן בהמשך. |
|
אין תכונה מובנית כזו זמינה
|
הרצה בקלות של חבילות בדיקה (test suites) על מספר סביבות במקביל. |
|
אין תכונה מובנית כזו זמינה |
בעל יכולת לשלב קבוצות לוגיות של שלבים לשימוש חוזר לתוך יחידה אחת שלscenarios הידועים בשם concepts |
|
רק ה- Background steps זמינים ברמת הfeature. |
שלבי ההקמה (Background steps) וגם שלבי tear down זמינים ברמת ה specification/feature |
|
דורש תוספים נוספים כדי להשיג תכונה זו. |
ביצוע מקביל של scenarios הוא פשוט מאוד ללא תוסף נוסף |
|
אין אובייקט מובנה לאחסון run time data. |
תכונה מובנית לאחסון run time context data. |
|
אין תכונה מובנית לקריאת נתונים מקובץ חיצוני. |
תכונה מובנית לקריאת נתונים מקובץ חיצוני. |
|
אין תכונה מובנית ללכידת צילומי מסך |
תכונה מובנית ללכידת צילומי מסך. |
|
Hooksמוגבלים:
Before/After/BeforeStep/AfterStep. |
הרבה יותר Hooks כמו: BeforeSuite/AfterSuite/BeforeSpec/AfterSpec/BeforeScenario/AfterScenario/BeforeStep/AfterStep נרחיב עליהם בהמשך
|
|
אין תכונה מובנית להרצה חוזרת של טסטים שנכשלו |
תכונה מובנית להרצה חוזרת של טסטים שנכשלו |
|
אין תכונה כזו זמינה |
תכונה מובנת להמשך הריצה גם לאחר כישלון טסט. |
עוד מקבץ פיצ'רים:
- ארכיטקטורה מודולרית
היא גישה בה המערכת מורכבת ממודולים נפרדים שמכילים פונקציות ותכונות ספציפיות. כשמדברים על ארכיטקטורה מודולרית לכיסוי כל קונספט ה-BDD (Behavior Driven Development), מתכוונים לבניית מערכת בדיקות המכילה מודולים שונים שתומכים בתהליכי ה-BDD והפיתוח המבוסס על התנהגות (behavior) של התוכנה. המודולים בארכיטקטורה המודולרית ל-BDD יכולים להיות בנויים בצורה פלגינית, כלומר, ניתן להוסיף ולהשתמש בפלאגינים שונים במערכת הבדיקות. בדרך כלל, הפלאגינים המשתמשים ב-BDD תומכים בשפות תכנות ספציפיות כמו Gauge, שמאפשרת למפתחים כתיבת סקריפטים בצורה קרובה לשפה האנגלית.
בנוסף, עם ארכיטקטורה מודולרית ל-BDD, ניתן לשלב כלים וטכנולוגיות נוספות בצורה קלה וגמישה. לדוגמה, ניתן לשלב את Selenium ככלי אוטומציה לבדיקות ממשק משתמש וניווט בדפים, את Rest Assured לבדיקות API, את Appium לבדיקות יישומים ניידים ואת AutoIt לבדיקות על ממשקי משתמש בווינדוס.
- תמיכה עקבית בין פלטפורמות
הגישה המודולרית מאפשרת לתוכנית הבדיקות להיות ניידת בפלטפורמות שונות כמו לינוקס, מקינטוש ווינדוס. זאת מאפשרת לצוות הבדיקות להריץ את אותן הבדיקות במגוון סביבות עבודה ולוודא שהתוכנה עובדת כמו שצריך בכל אחת מהן. בנוסף, התמיכה בפלטפורמות שונות מאפשרת לצוות להתמודד עם האתגרים הספציפיים של כל פלטפורמה ולבדוק את התוכנה בסביבות מגוונות.
תמיכה בשפות תכנות מרובות
Gauge מאפשר לכתוב קוד בדיקה במגוון שפות תכנות כמו Java, Ruby, C#, Go, JavaScript ו-Python. זה מאפשר לצוות להשתמש בשפה המועדפת עליו ושימוש בכלים וספריות ידועות בשפה הספציפית. זה מבטיח גמישות ואפשרויות מרובות לצוות הבדיקות לכתוב ולתחזק את קוד הבדיקה.
- יצירת חבילות בדיקה (test suites) ניתנות לתחזוקה
ניתן לארוז את הבדיקות לחבילות שונות על פי נושאים, תכליתם או חלקי המערכת השונים שצריך לבדוק. היתרון המרכזי של יצירת חבילות בדיקה הוא היכולת לתחזק ולנהל אותן בצורה יעילה. במקום לנהל מאות או אלפי בדיקות בודדות, ניתן לארוז אותן לחבילות המותאמות לצרכים שונים. כל חבילה יכולה להיות מתוכנתת ונבדקת בנפרד, וכל שינוי או תיקון שיעשו בחבילה לא ישפיע על שאר החבילות. בנוסף, יכולת התחזוקה הנוחה מאפשרת עדכון והוספת בדיקות בקלות. כאשר ישנן שינויים במערכת או נדרש לבדוק תכונה חדשה, ניתן להוסיף בדיקות לחבילה הרלוונטית בלבד ולהריץ אותן כחלק מהתהליך האוטומטי. זה מבטיח תחזוקה קלה ונוחה של הבדיקות, מבלי להשפיע על הבדיקות האחרות בפרויקט.
- Gauge משתלב באינטגרציה רציפה (Continuous Integration)
יכול להיות משולב כחלק מפייפליין ב-Jenkins או כל כלי אחר לניהול אינטגרציה רציפה. דבר נפוץ מאוד להכניס את בדיקות האוטומציה כחלק מתהליך CI/CD, כך שבכל פעם שקוד חדש מתווסף או מתעדכן יוכל להיבדק באופן אוטומטי. בעזרת הפיתוח הרציף והאינטגרציה עם Jenkins, אפשר להפעיל את בדיקות האוטומציה באופן אוטומטי בתהליך הבניה והפרסום של הקוד. כאשר יש שינוי חדש בקוד המקור, Jenkins מפעיל את הבדיקות האוטומטיות באופן אוטומטי ומספק מידע על התוצאות לצוות הפיתוח. זה מאפשר לזהות במהירות בעיות אפשריות ולהבטיח שהשינויים לא פוגעים בתפקוד התוכנה. לפיכך בדיקות אוטומטיות כחלק מתהליך CI/CD מביאות יתרונות רבים, כמו למשל זיהוי ותיקון באופן מוקדם של בעיות.
- Data stores
זהו אחד הפיצ'רים המגניבים ביותר ב- Gauge שבהן ניתן להשתמש כדי לשמור את הנתונים בין הsteps ב Scenario או לשמור נתונים בתוך Scenario בזמן הריצה.
- מנגנון דיווח מותאם ויעיל עם מספר סוגי דוחות
Gauge מספק דוח ביצוע בדיקה live שהוא מאוד ייחודי ל- Gauge ושיעזור לנו לזהות את התקלות מבלי להמשיך לחכות עד להשלמת הביצוע. בנוסף לכך, Gauge מספק את דוח ביצוע הבדיקהבפורמטים HTML, XML ו-JSON.
על ידי הגדרת משתנה סביבה כדי להגדיר את מספר הstreams. דבר שיאפשר לנו multi-threading בהרצת בדיקות במקביל כך ניתן לסיים את הבדיקה במהירות כמובן בהנחה שאפשר להריץ את הבדיקות במקביל.
- ל- Gauge יש פתרון וקבצים משלו לניהול סביבה
אפשר לשים קבצי " properties" של Gauge במבנה הפרויקט המוגדר שלו ולאחר מכן לכוון לשם את הסביבה בזמן הפעלת הבדיקות. אפשרי לייצר מספר פרופילים שונים כמספר הסביבות שנצטרך.
- Hooks
כמו לSelenium גם Gauge מציע hooks רבים כך שנוכל פשוט להשתמש ב annotation מתאים כאשר נרצה שקטע קוד מסוים יופעל. כמו BeforeSpec@, @AfterSpec, @BeforeScenario, @AfterScenario ועוד...
- Rerun Failed Tests
מאפשר לאלץ את Gauge להפעיל מחדש את המבחנים שנכשלו.
- Continue on Failures
בעוד שהתנהגות ברירת המחדל היא שבירת ביצוע בכישלון הראשון בstep, אפשר פשוט לסמן את השלבים כ-"ContinueOnFailure".
צילום מסך של חלק מהפלאגינים שאנו משתמשים בהם:
מקבץ מושגים חשובים ב-Gauge
- Specification
או בקצרה spec
הוא בעצם business test case המתאר תכונה מסוימת של האפליקציה הדורשת בדיקה. כל spec יכול להכיל scenario אחד או יותר, כל spec יכול להיות מסומן עם Labels שמשתמש ב tags
- Scenarios
כל scenario מייצג single workflow בspec מסוים. spec חייב להכיל לפחות scenario אחד. scenario מתחיל אחרי scenario heading או scenario name.
- Steps
הם רכיבי ההפעלה של spec שנכתבים באמצעות תחביר רשימת Markdown.
ב spec, steps יכולים להתקיים בתוך scenario או מחוץ לו.
Steps קיימים גם בתוך Concept.
לכל implementation של step יש קוד שווה ערך לפי הפלאגין של השפה המשמשת בעת התקנת Gauge.
- Concepts
מספקים את היכולת לשלב קבוצות לוגיות הניתנות לשימוש חוזר של steps ליחידה אחת.
כאשר הspec מופעל, כל ה concepts והsteps שלהם מבוצעים בסדר המוגדר.
- Tags
תגיות משמשות לשיוך Labels לspec או ל scenarios. עוזרים בחיפוש או סינון specs או scenarios. תג שהוחל על spec חל אוטומטית גם על scenario.
- Parameters
steps מוגדרים לקחת ערכים כפרמטרים כך שניתן לעשות בהם שימוש חוזר עם ערכי פרמטר שונים. בקובץ ה implementation יהיה לנו אותו מספר פרמטרים כפי שהוזכר בstep.
קיימים מספר סוגי פרמטרים:
- Simple parameters - הם ערכי מחרוזת, המשמשים בstep בתוך מרכאות כפולות.
- Table parameters - משמשים כאשר מבוצע step עבור מספר ערכים בטבלה.
- Dynamic parameters - משמשים כ placeholders במקום ערכים בפועל. אלה
משמשים כאשר מתייחסים לערך עמודת טבלה של טבלת נתונים. - Special parameters - סוגי הפרמטרים המיוחדים הם כדלקמן: *TXT,*CSV,*XML,*JSON
העברת תוכן הקובץ כפרמטר מחרוזת.
דוגמא לקובץ Spec:
דוגמא לקובץ Concept
חשוב:
הקישור בין שני הקבצים נעשה על ידי ה step ב- scenario בקובץ ה- spec
עם ה- scenario heading בקובץ ה- concept
למשל:
החיבור של step מקובץ ה- concept לקובץ ה- implement יעשה על ידי שימוש ב- hook
@step כפי שמופיע בדוגמא הבאה:
דו״ח HTML של Gauge ל- scenario:
Verify default Super Admin can access to Grafana dashboard
שנמצא בדוגמא של קובץ ה spec
תיאור התממשקות הטכנולוגיות שאנו משתמשים כדי לייצר את מערך האוטומציה שלנו:
לסיכום
Gauge הוא כלי מתקדם לבדיקות אוטומטיות שמספק פתרונות לבעיות תחזוקת הבדיקות של ממשק ה-Web שלכם. בעזרת Gauge, אתם יכולים לבצע אלפי בדיקות על ממשק ה UI-וה API, באופן אוטומטי ובקלות.
הוא מאפשר לכם להריץ את הבדיקות על multiple browser, מה שמבטיח את תקינות הממשק בסביבות שונות.
למעשה, Gauge מאפשר לבדוק את הפלטפורמה שלכם באמצעות system tests.
בעזרת הכלים שלו, ניתן לבדוק את תהליכי המערכת ולוודא שהם פועלים כצפוי.
הפריימוורק של Gauge מיועד להיות פשוט לשימוש, גם עבור משתמשים שאינם טכניים. בזכות זה, גם חברים בצוות שאינם מפתחים יכולים להצטרף לתהליך הבדיקה ולתרום בצורה פעילה.
בנוסף, Gauge מתמודד במקצועיות עם בעיות תחזוקת הבדיקות שלכם.
הוא מספק פתרונות לבעיות המתקיימות במערכת הבדיקות, בזכות תורמים מרחבי העולם שמשפרים את הכלים ומקנים להם יכולות חדשות.
כמו כן, ישנה קהילה גדולה שמתפתחת ומגדילה את הכלים ומספקת תמיכה והדרכה למשתמשים. לקבלת מידע נוסף והוראות נוספות, ניתן לבקר בלינק הבא
