נתחיל ביסודות! היכרות עם שני מצבי הבדיקה הכלליים ושלושה סוגים נפוצים של אוטומציה לבדיקה.
כולנו מכירים את זה: מהו מם מתכנת חוזר שמתרחש לעיתים קרובות מדי בחיים האמיתיים?
המם הזה מסכם את זה יפה: כל מגירה פועלת מצוין בנפרד, אבל בשילוב עם חלונית ההזזה השנייה הן חוסמות אחת את השנייה ולא מצליחות. חשוב ששתי המגירות יפעלו היטב אחת עם השנייה ותוכלו לתפעל אותן בו-זמנית.
יישמו את זה בפיתוח אתרים: כתבתם כמה בדיקות, אולי אפילו השגתם 100% כיסוי בדיקות, אבל האפליקציה שלכם עדיין צריכה לפעול ברגע שחלקים אחרים יסתדרו. היחידות עשויות לפעול היטב בפני עצמן, אבל לא באופן יחסי. כתיבה של כמה בדיקות היא חיונית, אבל היא רק חלק אחד מהגדרת הבדיקה האידיאלית לפרויקט שלכם. כשלב ראשון, עליך לקבוע אילו חלקים של איכות האפליקציה עליך להבטיח וכיצד תוכל להשיג זאת.
במילים פשוטות, צריך תוכנית לפני שמתחילים לכתוב את קוד הבדיקה בפועל. כדי לגשת לנושא של בדיקה מעשית, נתחיל בדף חדש ונענה על שתי שאלות בסיסיות:
- איך ברצונך לבדוק?
- מה ברצונך לבדוק?
המאמר הזה מתמקד בדברים הכלליים שצריך לדעת כדי לענות על השאלה הראשונה. תחילה נלמד אילו מצבי בדיקה קיימים, ולאחר מכן נתמקד בסוגי הבדיקות הנפוצים. במאמרים הבאים נענה על השאלה השנייה, נשלב את התשובות ונמצא את אסטרטגיית הבדיקה המתאימה ביותר לפרויקט שלכם. קדימה 🙌
מתחילים ביסודות: מצבי בדיקה כלליים
בתשובה לשאלה איך לבצע בדיקה, הנקודה הראשונה להבהיר היא מופשטת מאוד. האם כדאי לבצע את הבדיקה באופן ידני או לתת למחשב להשתלט על המחשב? עם זאת, חשוב לא ליפול כאן לחשיבה בינארית.
בדיקה ידנית לעומת בדיקה אוטומטית
אם מבקשים ממהנדסי בקרת איכות להגדיר את הבדיקה, סביר להניח שהם יחלקו אותה לשני "מצבים" קודם:
- בדיקה ידנית. זוהי שיטת בדיקה אופיינית שמתבצעת על ידי אנשים בפועל. מהנדס בקרת איכות לוחץ על האפליקציה, בודק אם היא פועלת ובו-זמנית מנסה לשבור אותה. הדרך הנפוצה ביותר היא בדיקה שבה המהנדס חוקר את היישום באמצעות הידע שלו לגבי האפליקציה, מול נתיב מוגדר מראש או רשימת משימות.
- בדיקות אוטומטיות. זהו סוג של בדיקה שמבוצעת על ידי מחשב. מהנדסי בקרת איכות מטמיעים את הכלי כדי למנוע בדיקות שחוזרות על עצמן ומונוטוניות באופן אוטומטי.
סדרת המדריכים הזו תתמקד בעיקר בבדיקות אוטומטיות. עם זאת, אל תתמקד רק בדרך אחת של בדיקה. גם אם האוטומציה חוסכת הרבה זמן ומאמצים, בדיקות אנושיות ובדיקות ידניות תמיד ימלאו תפקיד חיוני. במקום זאת, האוטומציה של בדיקות אמורה לאפשר לאנשים להתמקד בבדיקות מחקר ובפתרון בעיות יצירתי. לדוגמה, הבטחת איכות של חוויות משתמש או הגנה על הלוגיקה העסקית בסיכון גבוה. במילים אחרות, האוטומציה דואגת לכם. ❤️
תיבה אטומה לעומת תיבה שקופה
אז הגדרת את המצבים הכלליים של הבדיקה. עם זאת, עדיין לא מספיק. כדי לתכנן את אסטרטגיית הבדיקה, יש לענות על שאלה אחת נוספת: האם תוכל לדעת איך היישום שלך פועל בפועל או שעדיף לבדוק אותו ללא ידיעת המידע הזה? לפי התשובה, יש שני הליכים לגיקור ולבחירת מקרי בדיקה:
- בדיקת קופסה אטומה (או בדיקת קופסה שחורה). היא מבוססת על ניתוח דרישות (מפרטים) פונקציונליות או לא פונקציונלית של רכיב או מערכת, בלי להביא בחשבון את המבנה הפנימי שלהם.
- בדיקת קופסה ברורה (או בדיקת קופסה לבנה) היא תהליך שמביא בחשבון את המבנה הפנימי של התיבה שצוינה. במילים אחרות, איך האפליקציה פועלת במסגרת תפקידכם.
אפשר להחיל את שני התהליכים האלה על בדיקות ידניות ואוטומטיות. עם זאת, היבטים מסוימים של מצבי הבדיקה הכלליים עשויים להתמקד יותר באחד מהשניים – נעסוק בכך בהמשך. בינתיים, נפרט את האוטומציה של בדיקות לפי סוגים.
סוגי בדיקה אוטומטית: איך ברצונך לבצע את הבדיקה?
ככל שתתקרב למענה על השאלה "איך", כבר החלטתם לבצע בדיקות ידניות. עם זאת, הבחירה ויישום של סוגי אוטומציה לבדיקה הוא קצת יותר מאתגר. הסוגים של בדיקות האוטומציה קשורים באופן הדוק למדדים שאתם רוצים ליצור בפרויקטים. אז בואו נסתכל מקרוב על הפרטים החשובים ביותר.
כפי שמתואר ב-meme שהוזכר קודם, כבר נתקלת בשני סוגים: בדיקת יחידה ובדיקת אינטגרציה. בדיקה מקצה לקצה היא הבדיקה השלישית בחשיבותה. אבל זה לא הכול. הבה נבחן את הנושא מקרוב.
בדיקת יחידה
בדיקת יחידה היא סוג בדיקה שבו חלקים או יחידות קטנים של אפליקציה, שניתן לבדוק אותם בנפרד, נבדקים בנפרד ובאופן בלתי תלוי כדי לוודא שהם פועלים כראוי. ההיקף של היחידות האלה יכול להשתנות, מפונקציות, מחלקות או ממשקים ועד לשירותים או לרכיבים שלמים. המאפיינים העיקריים שלהן הם מהירות הביצוע, בידוד ותחזוקה נוחה. אם אתם רוצים להתעמק בנושא של בדיקת יחידות, אפשר לעיין במדריך לבדיקת יחידות.
בדיקת שילוב
בדיקות שילוב מתמקדות באינטראקציות בין רכיבים או מערכות. במילים אחרות, על האופן שבו הם פועלים יחד. דוגמאות אופייניות לבדיקות שילוב הן בדיקות API או בדיקות רכיבים.
בדיקות מקצה לקצה
הבדיקות האלה נקראות לעיתים קרובות בדיקות ממשק משתמש, ושם זה מסביר את הפונקציה שלהן בצורה טובה יותר. הבדיקות האלה מבצעות אינטראקציה עם ממשק המשתמש של האפליקציה שלכם, כולל סטאק האפליקציות המלא, ובודקות את האפליקציה מקצה אחד לשני.
הם דומים לבדיקת מערכת אם מדברים על התיאוריה של הבטחת איכות. הבדיקות האלה מדמות משתמש אמיתי ואת האינטראקציות שלו. בדיקות מקצה לקצה נמשכות יותר זמן ריצה כי הן מערבות את כל המערכת, ויותר זמן ריצה דורש יותר כוח מחשוב. כתוצאה מכך, המאמץ הנוסף הזה גורם לעלויות תחזוקה גבוהות יותר.
בדיקה של ממשק המשתמש החזותי
קטגוריית משנה מעניינת של בדיקות ממשק משתמש היא בדיקות חזותיות. הבדיקות האלה הן בדיקות מורחבות מקצה לקצה שמאפשרות לאמת את הפלט הגלוי של האפליקציה. בבדיקה כזו מתבצע צילום מסך לאחר שינוי וצילום מסך נוסף שמכיל את "סטטוס קוו" (או הקובץ המוזהב), ולאחר מכן מספק את התוצאות האלה לבודק אנושי לצורך בדיקה ובדיקה. במילים אחרות, הוא עוזר לאתר "באגים ויזואליים" במראה של דף, לא רק באגים פונקציונליים בלבד ולא לרשום אותם במפורש בטענות נכונות.
ניתוח סטטי
יש עוד דבר אחד להציג כאן: ניתוח סטטי. זה לא סוג של בדיקה במובן של ספר הלימוד. עם זאת, זה יהיה היבט חיוני באסטרטגיות להבטחת איכות בהמשך. אפשר לדמיין שהיא פועלת כמו פונקציה של בדיקת איות: היא סורקת את הקוד כדי לאתר פגמים משמעותיים יותר ושגיאות תחביר בלי להפעיל את התוכנה, וכך לזהות בעיות בסגנון הקוד. הפעולה הפשוטה הזו יכולה למנוע באגים רבים. זוהי נקודה טובה ללמוד על ניתוח סטטי אם אתם רוצים להכיר אותו לעומק.
בדיקה בכל הצורות: איך כל זה עובד יחד?
כשאתם מחפשים תשובות לכל השאלות האלה, יכול להיות שתמצאו פתרון אפשרי בכמה אנלוגיות. בקהילות האינטרנט ובקהילות הבדיקה ספציפית, מפתחים נוטים להשתמש באנלוגיות האלה כדי לתת לכם מושג לגבי מספר הבדיקות שכדאי לכם לבצע מכל סוג.
חמש האסטרטגיות הבאות שמוצגות בתמונה הן הנפוצות ביותר:
- פירמידה של בדיקה
- יהלום בדיקה
- Test Ice Cone (מוכר גם בשם Test Pizza)
- בדיקת חלת דבש
- גביע בדיקה
זה הרבה מידע שצריך לעבד. איך מומלץ לבחור אסטרטגיית התאמה לבדיקת ההתאמה על סמך כל הגורמים האלה? אל דאגה, אין בעיה. במאמר הבא נדון באסטרטגיות השונות האלה בפירוט רב יותר ונסביר איך לבחור את האפשרות המתאימה ביותר לפרויקט שלכם. עדכונים נוספים בקרוב! 🔥