Test automation and architecture
- 1. Copyright © SELA Software & Education Labs, Ltd. | 14-18 Baruch Hirsch St., Bnei Brak 51202, Israel | www.selagroup.com SELA DEVELOPER PRACTICE May 23-25, 2017 Arnon Axelrod Test Automation & Architecture
- 2. About myself Senior Architect and Test Automation Team Lead at Sela Group Professional Software Developer since 1995 (and amateur since 1984) Currently writing the book “The Complete Guide to Test Automation” by Apress. E-mail: arnona@sela.co.il Blog: http://blogs.microsoft.co.il/ArnonA Phone: 052-5327296
- 3. Architecture
- 4. Simplistic view on a computer system Processing InputsOutputs
- 5. Simplistic view on Test Automation Processing (SUT) InputsOutputs TestExpected? Pass/Fail
- 6. A more realistic view on computer systems…
- 8. Real-time monitoring of smart meters Communication Server (3rd party) Web server DB Data Aggregator Data Layer Web Client
- 9. Real-time monitoring of smart meters Automated tests Water meters simulator Selenium Web server DB Data Aggregator Data Layer Web Client
- 10. Forex site UI (web) Web server DB Trading proxy (3rd party) Trading server Stock Exchange Stock Exchange Stock Exchange Simulator
- 11. Cars fleet management Communication Server Main DB Web Application Data Transfer Engine Real-time DB
- 12. Cars fleet management Main DB Web Application Data Transfer Engine Real-time DB Automated tests Selenium
- 16. Simulators should be stupid!
- 19. Isolation
- 21. Only use what you create
- 22. Reset state before each run/test
- 23. Cleanup
- 24. Choosing the appropriate test scope UI View Model Client Logic Server Proxy Service Layer Business Logic DAL ORM DBFake DB (e.g. SqlLite)
- 25. Other architectural considerations… Feasibility (e.g. unique UI technology) Importance vs. Risk (e.g. is there BL in the UI?) Speed What’s likely to change? (e.g. UI vs. API) Reliability of the technology Resources (hardware, SW licenses, etc.) Extensibility
- 26. Questions
Editor's Notes
- #4: מה זה בכלל ארכיטקטורה של תכנה? לפי ויקיפדיה יש הרבה הגדרות. אחת מהן היא "מה שחשוב". והדבר הכי חשוב בבדיקות אוטומטיות זה אמינות ויציבות ובזה נתמקד היום. ישנם כמובן אספקטים חשובים אחרים, כגון קלות תחזוקה וכדו', אבל זה נושא נפרד... בשביל להבין למה בכלל יכולות להיות לנו בעיות של יציבות, נתחיל במבט פשטני מאד על מה זאת בכלל מערכת מחשב?
- #5: כפי שבד"כ מלמדים בשיעור הראשון של כל קורס מבוא לתכנות: מערכת מחשב מורכת מקלט, עיבוד ופלט
- #6: באופן פשטני ודומה, בדיקות אוטומטיות הן תוכנה שמזינה קלט מסויים לתוך המערכת הנבדקת, בוחנת את הפלט ומדווחת אם הפלט מתאים לתוצאה הצפויה או לא. באופן עקרוני, הפלט של כל מערכת (והמערכת הנבדקת בפרט) תלוי אך ורק בקלט שלה! בהנתן שזה המצב, אין כל סיבה שבדיקה אוטומטית לא תתן גם היא תמיד את אותה תוצאה עבור כל עוד המערכת הנבדקת לא השתנתה. הבעיה היא שבפועל, רוב המערכות לא נראות כ"כ פשוטות, אלא נראות יותר כמו משהו כזה:...
- #7: למעשה יש לנו כאן אוסף של מערכות שכל אחת מהן מקבלת קלט ממספר מקורות, כולל: § תתי מערכות אחרות § מערכות חיצוניות § בסיסי נתונים § מידע מחיישנים שונים תאריך ושעה... כולל שעון התזמון של מערכת ההפעלה שמשפיע על תזמון של thread-ים... שאלה: מי פה כותב את הבדיקות האוטומטיות על סמך תסריטים שבודקים ידניים מגדירים? (מי מגדיר בעצמו?) מה הבעיה עם זה? □ לבודקים ידניים פחות חשוב העניין של יציבות כי הם יכולים להפעיל שיקול דעת ולהבין אם התוצאה שהם קיבלו שונה מהתוצאה הצפויה בגלל באג או בגלל שאיזשהו "קלט" שהם לא שולטים בו לא היה בדיוק מה שתוכנן. □ בגלל זה בודקים ידניים הרבה פעמים גם לא טורחים להגדיר במדוייק את התוצאה הצפויה, אלא שוב, מסתמכים על השיקול דעת שלהם בזמן הרצת הבדיקה □ לעתים קרובות לבודקים הידניים אין את היכולת לשלוט בקלט שמגיע ממקורות שונים מלבד ממשק המשתמש (ולעתים ה-database) ו/או לבדוק את הפלט שנשלח למקורות אחרים מלבד ה-UI לעומת זאת, באוטומציה, חשוב שנהיה מסוגלים לשלוט בכל מקור קלט שיכול להשפיע על תוצאות הבדיקה! כמו כן, רצוי מאד שנהיה מסוגלים לבחון יעדי פלט אחרים מלבד ה-UI, בעיקר אם זאת המהות של המערכת... § למעשה, אנחנו צריכים "לסמן מסגרת" מסביב לרכיבים שאנחנו רוצים לבדוק, ולזהות את כל מקורות הקלט שיכולים להשפיע על הפלט שאותו אנחנו רוצים לבדוק <תמונה> הערה: אם אנחנו יכולים להבטיח במידה מספיק גבוהה של אמינות שקלט מסויים לא יכול להשפיע על הפלט הנבדק, אז אנחנו לא חייבים לשלוט בו.
- #9: הסתבר שבכלל לא בודקים את ה-Data Aggregator למרות שהוא רכיב מאד חשוב... ולא בדקו תקשורת *אל* המודדים
- #11: קראו לי בגלל בעיות יציבות רציתי לחקור ביום ראשון את התוצאות... בעיה: הטסטים לא רצים ביום ראשון! הטסטים הכילו הרבה לוגיקה... פתרון: סימולטור
- #13: בהתחלה הציעו לעשות נסיעה מיוחדת שעליה נבצע את הבדיקות!
- #14: נתקלתי בכמה פרוייקטים עם Google maps או גרפים (Telerik Kendo)
- #16: אם יש תשתית של UT ו-DI זה עוזר מאד...
- #17: טסטים אוטומטיים לא צריכים דטה מורכב כמו במציאות! הטסטים רק צריכים לקשר קלט לפלט...
- #18: יש עוד בעיה מהותית: כשאמרנו שהפלט של מערכת תלוי אך ורק בקלט שלה, זה נכון רק אם אנחנו מתחילים כל פעם את כל המערכת מחדש. אנחנו יכולים לוותר על ההנחה הזו, אם נאמר שהפלט של מערכת תלוי ב-2 דברים: במצב (state) ובקלט.
- #19: כמעט שאין מערכת שאין לה גם database או קבצים שמאפשרים לה לשמור state. למעשה, DB זה משהו שמאפשר גם קלט וגם פלט, אך מבטיח שנתונים ששלחנו אליו כפלט (מהמערכת אל ה-DB), ניתן לקרוא ממנו בחזרה בצורת קלט (מה-DB אל המערכת). אך אם נתייחס ל-DB כאל חלק מהמערכת (ולא כאל ממשק חיצוני), אז אפשר לאמר שה-DB שומר State לרוב, לא מעשי להחזיר את כל המערכת, כולל ה-DB, למצב ההתחלתי לפני כל טסט וטסט (שרצוי גם שיהיו קצרים...)
- #20: לכן אנחנו צריכים לנהל את זה בצורה חכמה שתבטיח שלכל בדיקה אוטומטית תהיה שליטה מלאה גם על ה-state הרלוונטי של המערכת לתכונה הזו קוראים ISOLATION לכל הפחות Isolation אמור להבטיח לנו: שטסט אחד לא יושפע מזה שטסט אחר רץ לפניו או לא שכשלון של טסט קודם לא ישפיע על הטסט הנוכחי שאם נריץ את אותו הטסט פעמיים הוא תמיד יתן את אותה התשובה בנוסף, אם אנחנו חולקים את אותה הסביבה גם עם בודקים ידניים ו/או מאפשרים לבדיקות אוטומטיות לרוץ במקביל מול אותה מערכת נבדקת, תכנון נכון יכול להבטיח לנו: שהטסטים לא יושפעו מפעולות שבודקים ידניים ביצעו לפני שהטסטים לא יושפעו מפעולות שבודקים ידניים מבצעים במקביל לבדיקה האוטומטית שטסטים אוטו' יוכלו לרוץ במקביל על אותה סביבה מבלי להשפיע האחת על השניה להלן כמה טכניקות:
- #21: מתאים במקרה שלכל משתמש או לקוח יש גישה רק לנתונים שלו להפריד בין סביבה ידנית לאוטומטית! רצוי שלכל מי שמריץ יהיה משתמש משלו!
- #22: כל טסט יוצר את המידע שהוא צריך
- #23: לפני כל ריצה – פותר חלקית אבל יותר מעשי דוגמאות: DB backup VM Snapshot Containers Re-install מחיקת נתונים מטבלאות
- #24: יותר זול מ-Reset כשהטסט עושה משהו יחודי ולא רוצים לשלם את המחיר לכל שאר הטסטים מנגנון... חשוב לציין: אם מפסיקים טסט באמצע – זה לא יתבצע!