מדוע אסור להשתמש בסלניום ובמלפפון ביחד

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

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

לפני שאעמיק, בואו נסקור קצת מידע רקע.




מהו סלניום?

סֵלֶנִיוּם הוא כלי לבדיקת אוטומציה של דפדפנים המסוגל לתקשר עם אלמנטים ה- HTML של יישום אינטרנט כדי לדמות פעילות משתמש.

ב- Selenium WebDriver אנו יכולים לכתוב סקריפטים במספר שפות תכנות ויכולים להוות נכס נהדר לבדיקות מערכת הפעלה מרובות ודפדפני אינטרנט.




מה זה מלפפון?

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

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

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



סלניום ומלפפון

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


סיפורים נכתבים בדרך כלל מנקודת מבט של משתמש, למשל:

תכונה: פונקציונליות התחברות

כמשתמש באתר abc.com

אני רוצה שלקוחות יוכלו להתחבר לאתר


כדי שיוכלו להציג את פרטי החשבון שלהם.

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

תרחיש 1: כניסה חוקית

בהתחשב בכך שאני נמצא בדף הכניסה של abc.com


כשאני מזין אישורים תקפים

ואז אני מנותב לדף החשבון שלי

וכך תוכלו להוסיף תרחישים נוספים לבדיקת שילובי נתונים שונים.

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


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

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

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

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

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

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

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

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

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

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

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

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

לאיזה קובץ תכונות צריך תרחיש זה לעבור כעת? בקובץ 'סנן לפי דירוג כוכבים' או בקובץ 'סנן לפי מחיר'? מה דעתך אם אוסיף כעת תרחיש להחלת מיון על התוצאות המסוננות שלי כדי למיין לפי הקולות הגבוהים ביותר?

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

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

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

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

אז מה הדבר הגדול עם השימוש בסלניום ובמלפפון יחד?

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

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

מסע משתמשים טיפוסי יכלול:

1 - נווט לדף הבית של אתר abc.com

2 - חפש מוצר מדף הבית

3 - דפדף ברשימת תוצאות החיפוש

4 - החל מסנן ו / או מיון

5 - קרא את פרטי המוצר

6 - הוסף את המוצר לסל

7 - המשך לבדוק ...

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

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

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

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

סיכום

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

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

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

המאמר שלי מבוסס על הסקת עובדות!

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

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

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

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

זה רק לצורך כניסה; נסה לכתוב מבחן מקצה לקצה במלפפון!

בדיקות ממשק המשתמש צריכות לכסות נסיעות משתמשים שהן בדרך כלל מקצה לקצה ומפעילות תכונות מרובות של יישום.

יש הרבה מה שקורה במסע משתמש יחיד ברחבי היישום.

מלפפון הוא בהחלט לא הכלי הנכון לבדיקת תרחישים של משתמשים / עסקים.