בדיקות תוכנה הן תחום מורכב ואינטנסיבי להפליא, כאשר חברות ומפתחים עצמאיים מחפשים כולם לשפר את המוצרים שלהם עם מגוון שיטות בדיקה.
אחת השיטות הנפוצות ביותר שחברות משתמשות בהן כדי לבדוק היא בדיקת קופסה שחורה, טכניקה שיוצרת מרחק בין מפתחים לבודקים כדי לספק תוצאות מדויקות ולבטל הטיה.
למד עוד על מהי בדיקת קופסה שחורה, כיצד להשלים את בדיקת הקופסה השחורה וכמה מהיתרונות של הטמעת בדיקת קופסה שחורה בהנדסת תוכנה עם מדריך מפורט זה.
מהי בדיקת קופסה שחורה?
בדיקת קופסה שחורה מתייחסת לתהליך של בדיקת מערכת או תוכנה ללא ידע מוקדם על אופן הפעולה הפנימי. זה לא רק מתייחס לאי ידיעה על קוד המקור עצמו אלא כרוך בכך שלא ראיתי אף אחד מתיעוד העיצוב סביב התוכנה. בודקים פשוט מספקים קלט ומקבל פלט כפי שמשתמש קצה היה עושה. למרות שזוהי הגדרה פשוטה של בדיקת קופסה שחורה, היא מגדירה את המערכת הכללית.
המטרה של בדיקת הקופסה השחורה היא לגרום למשתמשים לקיים אינטראקציה עם התוכנה בצורה טבעית יותר מהרגיל מבלי שתהיה להם הטיה קיימת שנובעת מכך שהם יודעים כבר על התוכנה.
במתודולוגיה זו, האחראים על השלמת הבדיקות שונים מאלה שפיתחו את התוכנה, מה שיוצר הפרדה בין שני הצוותים.
1. מתי ולמה אתה צריך לעשות בדיקות Black Box בבדיקות תוכנה?
ישנם כמה שלבים במחזור הפיתוח שבהם השימוש בבדיקת קופסה שחורה הוא אידיאלי, כאשר רוב בדיקות הקופסה השחורה מתרחשות בסוף הפיתוח, זמן קצר לפני השחרור.
זה כולל שיטות כמו בדיקות קבלת משתמשים , שבהן התוכנה עוברת לחברי קהל היעד של התוכנה כסוג של בדיקות טרום-שחרור. זה ידוע יותר בשם בדיקות בטא והוא כלי אידיאלי עבור חברה שכן חשיפה גדולה יותר פירושה שאנשים נוטים יותר למצוא באגים פוטנציאליים בתוכנה.
עבודה עם מתודולוגיית הקופסה השחורה לקראת סוף מחזור הפיתוח היא חובה, שכן מדובר בגרסה שסביר יותר שמשתמש ייגש אליה. אתה יכול להשתמש בבדיקת קופסה שחורה עבור פונקציות בודדות, אבל זה יביס את מטרת הבדיקה.
2. כשאתה לא צריך לעשות בדיקת קופסה שחורה
לבדיקת קופסה שחורה יש מעט מאוד מטרה בשלבי הפיתוח המוקדמים ביותר. כאשר חברה בונה את הפונקציונליות הבסיסית של התוכנה שלה, היא משתמשת בבדיקת קופסה לבנה כך שהמפתח יוכל לראות באיזה נקודה בקוד יש בעיות.
כמו כן, אין צורך בבדיקת קופסה שחורה כאשר התוכנה היא קוד פתוח או כלי אינטרנט פשוט יחסית או מיועדת לסייע בפרויקטי קידוד של צד שלישי, שכן יש ממשק משתמש חשוף יחסית, והמשתמש יכול לגשת לקוד המקור של התוכנית בכל מקרה. אם אתה מצפה ממשתמש לגשת לקוד המקור, בדיקת הקופסה השחורה מאבדת את מטרתה העיקרית.
3. מי מעורב בבדיקת קופסה שחורה?
יש הרבה תפקידים עם מעורבות בתהליך בדיקת הקופסה השחורה, חלק מתפקידים אלו תלויים באופי החברה שעושה את הבדיקה.
תפקידים משמעותיים עם מעורבות בתהליך בדיקת הקופסה השחורה כוללים:
· בודק
בודק אחראי על השלמת מקרי בדיקה ידניים בחברה, כתיבת מקרי בדיקה יסודיים הבוחנים את האפליקציה בפירוט לפני ביצועם ודיווח על תוצאות. תפקיד זה קיים בעיקר בתהליך בדיקה ידני, כאשר מערכות אוטומטיות לוקחות את התפקיד שבו קיימת אוטומציה של בדיקות .
· אנליסט QA
אנליסט QA אחראי על תכנות במקרי בדיקה בתהליך QA, בעיקר כאשר החברה משתמשת בתהליך אוטומציה של בדיקות QA .
התהליך כולל הן תכנון מקרי בדיקה יסודיים המבטיחים רמה גבוהה של פונקציונליות והן ביצוע מקרי הבדיקה, אחזור תוצאות כשהם מושלמים.
· מפתח
האחראי לפיתוח התוכנה שצוות ה-QA בודק. מפתח מקבל משוב מצוות הבדיקות ומעדכן את התוכנה בהתאם, עובד כחלק מצוות פיתוח אך נמצא בתקשורת מתמדת עם הבודקים.
· מנהל QA
מנהל QA הוא המנהיג של צוות אבטחת האיכות ואחראי על ניהול כל המשימות שהבודקים מבצעים.
זה כולל סידור לוח הזמנים של הבדיקות, ארגון רשימה של דברים שיש לעשות עבור חברי הצוות ופתרון כל קונפליקטים בצוות. הם גם מסבירים בדיקות קופסה שחורה בהכשרה לעובדים חדשים.
· מוביל פרויקט
האחראי על איכות פרויקט הגמר, מוביל פרויקט מפקח על תהליך הבדיקה וכן על הפיתוח, ודואג שהלקוח יקבל חבילת תוכנה העומדת בכל הבריף.
היתרונות של בדיקת קופסה שחורה
ישנם מספר יתרונות משמעותיים לשימוש בבדיקת קופסה שחורה בעבודת הפיתוח שלך. ככל שאתה מודע יותר ליתרונות הללו כך תוכל להפיק מהם את המרב תוך ניצול כמה שיותר יתרונות מהטכניקה.
כמה מהיתרונות העיקריים של שימוש בבדיקת קופסה שחורה בהבטחת האיכות שלך כוללים:
1. אין צורך בידע טכני
גישת קופסה שחורה פירושה שאין לך כל צורך בידע טכני בעת בחינת אפליקציה.
המטרה מאחורי בדיקת הקופסה השחורה היא לבחון כיצד האפליקציה עובדת עבור משתמש קצה, ולמשתמש הסטנדרטי אין ידע טכני מתקדם ברוב המצבים. זה יכול להפחית את עלות הבדיקה, לעזור לארגון לגלות באגים נוספים בהוצאה נמוכה יותר, ולהיות יעיל יותר מבחינה פיננסית.
2. מודל מדויק של המשתמש
המטרה הסופית של תהליך בדיקת קופסה שחורה היא להבין מהן הבעיות באפליקציה כאשר משתמש מקיים איתה אינטראקציה על בסיס יומיומי.
סוגים מסוימים של בדיקות קופסה שחורה – המתמקדים בשכפול האופן שבו משתמש מתנהג, מדגמים את התנהגות המשתמש בדרגה גבוהה של דיוק. זה במיוחד המקרה עבור בדיקות קבלת משתמשים, שבהן משתמשי קצה חווים את המוצר, לא רק מדגמים או מדמים התנהגות של משתמש אלא ממש מיישמים אותו.
מודלים מדויקים עוזרים לחשוף את כל הבאגים המשפיעים על תהליכי העבודה בפועל של המשתמש.
3. יכולת בדיקות המונים
בדיקת קופסה שחורה היא צורת בדיקה נגישה ביותר הודות לדרישות המיומנות הנמוכות יחסית.
המשמעות היא שלא רק שחברות יכולות לשכור בודקים עם רמה נמוכה יותר של מיומנויות טכניות, אלא שהן יכולות להכניס את הבדיקות שלהן ללקוחות נלהבים. זה נפוץ יותר ויותר בתעשיית המשחקים עם חברות המציעות שחרור גישה מוקדמת, מעדכנות את המשחק לאורך זמן כדי לפתור בעיות שמשתמשים מוצאים.
מציאת באגים במקרה זה היא הרבה יותר קלה, מכיוון שכל התכונות זוכות לרמת חשיפה גבוהה בהרבה.
אתגרים של בדיקת קופסה שחורה
מלבד היתרונות של בדיקת קופסה שחורה, יש כמה אתגרים עיקריים שתצטרך לתת עליהם את הדעת. להיות מודע לאתגרים הללו אומר שאתה יכול להסתגל אליהם, להגביר את רמת הבדיקות שלך על ידי הפחתת ההשפעות המזיקות שיכולות להיות לבדיקות הקופסה השחורה.
חלק מהאתגרים הללו כוללים:
1. קשה למצוא גורמים לבעיה
אחד החסרונות העיקריים של בדיקת קופסה שחורה הוא שיכול להיות קשה יותר למצוא את הגורם לבעיות כאשר לבודקים אין גישה לאף אחד מקוד המקור.
למרות שהם יכולים לתאר מהי השגיאה ומתי היא מתרחשת, אין להם אינדיקציה לגבי איזה חלק בקוד המקור גורם לבעיות או למה.
בודקים יכולים למתן את זה במידת מה על ידי היותם יסודיים ברישום הערות, עם הודעות שגיאה מפורטות מהמפתח המציעות גם תובנות נוספות לגבי כל עדכונים עתידיים.
2. אוטומציה מסובכת יותר
מכיוון שאתה מחפש באופן פעיל לשכפל את האופן שבו משתמש מקיים אינטראקציה עם חבילת תוכנה, זה יכול להיות קשה מאוד להפוך תהליך בדיקת קופסה שחורה לאוטומטי.
הסיבה הראשונה לכך היא העובדה שלבודק אין גישה לקוד המקור, מה שמקשה על קוד מבחן מדויק. זה משתלב עם העובדה שהבדיקה נועדה לשכפל התנהגות אנושית ככל האפשר, עם אוטומציה שתוכננה במיוחד לפעול בצורה רובוטית .
אתה יכול לאזן את הנושא הזה על ידי אוטומציה של משימות קטנות יותר ושילוב של אוטומציה עם בדיקות ידניות במידת האפשר.
3. נאבקים עם בדיקות בקנה מידה גבוה
המאבקים שהוזכרו לעיל עם אוטומציה גורמים לכך שבדיקות בקנה מידה גבוה יותר מסובכות יותר. בדיקות בקנה מידה גבוה מספקות לחברות הרבה יותר נתונים על התוכנה וגורמות לכך שקל יותר למצוא באגים ולשכפל אותם.
הדרישה לבדיקה ידנית בראש סדר העדיפויות פירושה שיכול להיות קשה יותר לארגן בדיקות בקנה מידה גדול יותר. חברות מסוימות מתנגדות לכך על ידי שימוש במערכת “בטא פתוחה”, שבה כל מי שמתעניין במוצר יכול לעזור בבדיקות טרום-שחרור ולתמוך בחברה על ידי מתן משוב על בנייה מוקדמת על בסיס התנדבותי.
מאפיינים של מבחני קופסה שחורה
יש כמה מאפיינים עיקריים של מבחני קופסה שחורה שכדאי להיות מודעים אליהם, שמבדילים את הבדיקה מכל צורה אחרת של אבטחת איכות תוכנה.
מאפיינים אלה כוללים:
1. אין ידע פנימי קודם
מבחני קופסה שחורה אינם דורשים ידע פנימי קודם של התוכנה. זה יכול להיות קשה במקרים מסוימים מכיוון שלבודקים יש מושג מסוים על ההיבטים של התוכנה שהם בודקים וחלק מהתכונות שהם מחפשים, אבל זה מוגדר באופן רחב כחוסר יכולת לראות תיעוד פנימי מכל סוג שהוא. .
במילים פשוטות, אם המידע היה גלוי למשתמש קצה בחנות אפליקציות או בדף ההורדה של אתר אינטרנט, בודק יכול לראות אותו.
2. הפרידו בודקים ומפתחים
את שלבי הבדיקה והפיתוח משלימים אנשים שונים במצב של בדיקת קופסה שחורה. הבידול הזה נובע מחוסר הידע שיש לבודקים, שכן למפתחים יש ידע בקוד המקור בשל העובדה שהם היו האחראים לפיתוחו.
חברות ניגשים לזה בכמה דרכים שונות בהתאם למצב הספציפי שלהן, כאשר חלקן בוחרות להשתמש בארגון חיצוני כדי להשלים בדיקות ולחברות גדולות יותר יש מחלקות ייעודיות של בודקים כדי להשלים את העבודה הזו.
3. בדיקות בשלב מאוחר
זה מתייחס לשלב בפיתוח שבו מתרחשת בדיקה זו. מבחני Black Box מסתמכים על גרסה מתקדמת יחסית של אפליקציה קיימת, עם ממשק משתמש מקיף המאפשר ניווט כולל בתוכנה וגישה לפרונט של כל פיצ’ר.
המשמעות היא שבדיקות קופסה שחורה אפשריות רק בחלק מהשלבים המאוחרים של תהליך הבדיקה, כאשר כל זה פותח בתחילה. בעוד שממשק המשתמש והפקדים עשויים להשתנות ככל שעובר הזמן, הם צריכים להתקיים בצורה כלשהי כדי לאפשר לבדיקות קופסה שחורה לגשת לפונקציונליות.
מה אנחנו בודקים במבחני Black Box
בדיקת קופסה שחורה בוחנת היבטים ספציפיים של חבילת תוכנה, ומספקת מידע נוסף באזורים מסוימים של התוכנה שמוביל לעדכונים המגדילים את איכות החיים הכללית.
חלק מהחלקים העיקריים של חבילת תוכנה שבודקים בוחנים במבחן קופסה שחורה כוללים:
1. פונקציונליות
חלק מהמפתחים משתמשים בבדיקת קופסה שחורה כאמצעי להבטיח שתוכנה פועלת כמתוכנן עבור מישהו ללא ידע קיים.
הרוב המכריע של האנשים שמשתמשים בכל פיסת תוכנה באופן מסחרי עושים זאת מבלי שהם מבינים כלל את פעולתה הפנימית של התוכנה, כך שבדיקה תוך כדי הידע הזה פירושה שאתה יודע דרכים לעקיפת הבעיה לכל בעיה קיימת.
בדיקת פונקציונליות יסודית זו מבטיחה שכולם יחוו את הטוב ביותר שיש לאפליקציה להציע במקום לפגוש באגים שאינם נראים כאשר בדיקת הקופסה הלבנה נמצאת בשימוש.
2. ממשק משתמש
ממשק המשתמש מתייחס לכל דרך שבה המשתמש מקיים אינטראקציה מעשית עם אפליקציה כדי לגרום לה להשלים סדרה של משימות. זה כולל את התפריטים שאיתם משתמש עובד, הכפתורים הספציפיים שקיימים באפליקציה והמיתוג שקיים בכל התוכנה.
מפתחים מבלים את רוב זמנם כדי לוודא שהאפליקציה עצמה פועלת כפי שהם מצפים, מה שאומר שיש פחות תשומת לב בממשק המשתמש.
בדיקת הקופסה השחורה מציגה לבודקים רק את תכונות קצה המשתמש של התוכנה, מה שמביא יותר תשומת לב לממשק המשתמש מאשר ברוב שלבי הבדיקה האחרים.
3. ביצועים
בנוסף לתפקוד רגיל ולהיראות טוב, הדרך בה אפליקציה פועלת חיונית לרצות לקוחות.
ביצועים מתייחסים לכמה גורמים, כולל מהירות האפליקציה בעת התגובה לתשומות משתמשים והמשאבים שהיא צורכת בכל מכשיר נתון.
בעזרת פורמטים של בדיקה כמו בדיקות מקצה לקצה הבודקות את כל התכונות של תוכנה, מפתחים יכולים לראות כמה זיכרון אפליקציה משתמשת ואיזו מהפונקציות מעמיסות הכי הרבה על המכשירים המתאימים, מה שמנחה את היעילות והביצועים -עדכונים קשורים בגרסאות מאוחרות יותר של היישום.
מנקה קצת בלבול:
קופסה שחורה לעומת קופסה לבנה לעומת בדיקת Greybox
בדיקת קופסה שחורה היא מושג שנשמע דומה לבדיקת קופסה אפורה ובדיקת קופסה לבנה, אבל הרעיונות שונים מאוד זה מזה. בלבול ביניהם עלול לגרום לבעיות תקשורת רציניות בתהליך הפיתוח ולגרום להאטה של תהליך העדכון ולהיות פחות יעיל.
המשך לקרוא כדי להבהיר חלק מהבלבול סביב הסוגים השונים של “בדיקות קופסאות”, כיצד הם שונים זה מזה ומתי להשתמש בכל אחד מהם.
1. מהי בדיקת קופסה לבנה?
בדיקת קופסה לבנה ידועה לפעמים בשם “בדיקת קופסאות זכוכית”, והתייחסות לתהליך בדיקה שבו לבודק יש גישה מלאה לכל המידע מאחורי התוכנה. זה כולל גישה לקוד המקור ולמסמכי העיצוב ותדריך הלקוח של החבילה.
לדוגמה, אם בודק עובד בשלבים המוקדמים ביותר של תהליך פיתוח בוחן פונקציה בודדת, היכולת לראות את קוד המקור של הפונקציה פירושו שהוא יכול למצוא את הגורם לבעיה באופן מיידי.
אחד הזמנים הטובים ביותר לשימוש בבדיקת קופסה לבנה הוא במשימות פנימיות בעיקר. זה מתייחס לפיתוח מוקדם של הצד הפונקציונלי של האפליקציה, כאשר תיקונים מהירים הם אידיאליים מכיוון שאין שום תועלת לערפול הקוד כאשר אינך מדמה את חווית המשתמש. בדיקת קוד לבן משמשת גם במערכות קוד פתוח, שכן קוד המקור זמין עבור כל המשתמשים במקרים אלו.
מה ההבדלים בין בדיקת קופסה לבנה לבדיקת קופסה שחורה?
ההבדל התפקודי העיקרי בין בדיקת קופסה שחורה לבדיקת קופסה לבנה הוא רמת הגישה שיש לבוחן לתוכנה, אך יש לכך השפעות משמעותיות הרבה יותר על היבטי הבדיקה כמו התזמון.
בדיקת הקופסה השחורה רואה שימוש עקבי יותר בהמשך התהליך ככל שהמוצר מתקרב להשקה, כאשר שלבי פיתוח בסיסיים יותר נהנים מהשקיפות וההיענות של בדיקות הקופסה הלבנה. כאשר בוחנים מבחן קופסה שחורה לעומת מבחן קופסה לבנה, השניים נבדלים זה מזה גם ברמות המומחיות הנחוצות, שכן בדיקת הקופסה הלבנה דורשת מומחיות בקידוד ופיתוח כדי להיות יעילים יותר.
2. מהי בדיקת תיבה אפורה?
בדיקת תיבה אפורה היא צורת בדיקה שבה למשתמש יש הבנה מסוימת של הקוד מבלי שיש לו גישה מלאה. זה כולל את קוד המקור של הפונקציה הנבדקת או גישה לחלק מתיעוד העיצוב, כך שהמשתמש מבין מה הכוונה הכוללת של חבילת התוכנה.
לדוגמה, אם בודק בוחן רק אחת מהפונקציות בחבילת תוכנה, ייתכן שתינתן לו גישה לקוד המקור של אותו חלק של היישום.
חברות משתמשות בעיקר בבדיקות קופסא אפורה כאשר הן בוחנות את האופן שבו אפליקציה משולבת עם כלי של צד שלישי. הם יכולים לקבל גישה לקוד המקור רק עבור חלק אחד של התהליך, מה שמגביל את יכולתם להשלים בדיקות יסודיות של קופסא לבנה. במקום זאת, הם רואים את הקלט והפלטים של אינטגרציה של צד שלישי ואת קוד המקור האחראי לאינטגרציה.
בודקים משתמשים בזה כדי להעריך אם מתעוררות בעיות כלשהן בגלל התוכנה, יישום הצד השלישי או האינטגרציה בין השניים.
מה ההבדלים בין בדיקת קופסה שחורה לבדיקת קופסה אפורה?
ההבדל העיקרי בין בדיקת קופסה שחורה לקופסה אפורה הוא שוב רמת הגישה למידע, כאשר סוג התוכנה הנבדקת הוא אחד הגורמים המבדילים העיקריים בין סוגי הבדיקות.
בדיקת תיבה אפורה נוטה לכלול כלים של צד שלישי כגון אחסון נתונים בענן או כלי עיבוד חיצוניים, בעוד שמערכות קופסה שחורה נוטות להיות יחידה אחת מגובשת. בדיקות קופסא שחורה רבות אינן מופרעות על ידי צדדים שלישיים, בעוד שלאפליקציות משולבות אין ברירה אלא לעבוד במתודולוגיית בדיקת קופסה אפורה.
3. מסקנה: בדיקת קופסה שחורה לעומת תיבה לבנה לעומת תיבה אפורה
בסופו של דבר, ישנם הבדלים מהותיים בין בדיקת קופסאות שחורות, אפורות ולבנות, הכל מבוסס על האם מידע מאחורי הקלעים מוצג לצוות הבדיקה.
בדיקת קופסה שחורה וקופסה לבנה הם הקיצוניות של הספקטרום הזה, כאשר בדיקת קופסה אפורה מקיפה הכל בחינם, תוך ראיית הכל מלבד קוד מקור של צד שלישי, ועד ליכולת לראות רק את הקוד מאחורי פונקציה ספציפית.
לכל שיטות הבדיקה הללו יש תפקיד בתחום בדיקות התוכנה, עם זאת, לכן הקדשת זמן ותשומת לב ללמידתן וליישם אותן ביעילות היא חובה.
סוגי מבחני קופסה שחורה
ישנם שלושה סוגים עיקריים של בדיקות קופסה שחורה המקיפים את כל הבדיקות שחברה משלימה באמצעות מתודולוגיית הקופסה השחורה. אלו הם:
1. בדיקה פונקציונלית
בדיקה פונקציונלית מקיפה את כל מה שמסביב לאופן שבו האפליקציה פועלת מכנית. זה כולל הבטחה שהיא מטפלת בנתונים בצורה הנכונה, מאפשרת למשתמשים להיכנס עם האישורים הנכונים ומעבדת מידע ותשומות כצפוי.
בדיקת פונקציונליות היא אחד ההיבטים החשובים יותר של התהליך וכוללת הן את הפונקציונליות המקומית של האפליקציה והן את האופן שבו היא מקיימת אינטראקציה עם כלים ותוכניות חיצוניות כגון שירותים מבוססי ענן או כלים לכניסה יחידה.
2. בדיקה לא פונקציונלית
בדיקה לא פונקציונלית מתייחסת לבדיקה הבודקת כל היבט של התוכנה שאינו קשור במפורש לפונקציונליות של האפליקציה. זה כרוך בבירור האם אפליקציה שמישה וקלה להבנה עבור המשתמשים שלה, תואמת למגוון רחב של מכשירים ומערכות הפעלה והאופן שבו היא מתפקדת תחת רמות עומס משמעותיות (אם כי זה יכול להיסחף לבדיקות פונקציונליות בנקודות).
זה קורה בעיקר לקראת סוף תהליך הפיתוח לאחר הידור של האפליקציה השלמה.
3. בדיקת רגרסיה
לאחר עדכון, בודקים בודקים יישום כדי לוודא שהוא השלים את הפונקציה המיועדת ואין תופעות לוואי לא מכוונות שגורמות ליישום להיגרר.
זה ידוע כבדיקת רגרסיה ומהווה חלק מהותי בוודאות שאפליקציה מוכנה לצאת לשוק.
בדיקות רגרסיה משמשות לאחר כל עדכון בודד כדי לוודא שההיבטים התפקודיים והלא-פונקציונליים של האפליקציה עומדים בסטנדרט שהושג קודם לכן.
טכניקות בדיקת קופסה שחורה
כאשר אתה עובר את תהליך בדיקת הקופסה השחורה, יש מגוון רחב של טכניקות שאתה יכול ליישם כדי לשפר את רמת העבודה שלך. כמה מטכניקות בדיקת הקופסה השחורה המשמעותיות ביותר שבהן אתה משתמש בסביבת אבטחת איכות כוללות:
1. בדיקה זוגית
בדיקה זוגית היא סוג של בדיקה המתמקדת בניסיון של כל שילוב של קלט נתונים אפשרי בתוכנה.
לדוגמה, אם המספר 1 עד עשר הם כולם ערכים חוקיים בעמודה אחת עם כל תווי האלפבית באחרת, בדיקה זוגית תבדוק כל שילוב אפשרי מ-1A עד 10Z. זוהי צורת בדיקה שיכולה לקחת למשתמש הרבה זמן ומאמץ להשלים, מה שהופך אותה לאחת הטכניקות הפתוחות ביותר להיפר -אוטומציה פוטנציאלית. זה מאוד יסודי ומוצא בעיות פוטנציאליות בהזנת נתונים.
2. ניתוח ערכי גבול
חלקי תוכנה רבים מסתמכים על הזנת נתונים, כאשר לנתונים יש גבולות ספציפיים שלקוח צפוי לעבוד בתוכם.
לדוגמה, מערכת המיועדת לחישוב מספרים מ-1 עד 100 עשויה להיאבק עם ערכים של 0 או נמוך יותר, או גבוה מ-100.
ניתוח ערכי גבולות כולל בדיקת גבולות אלו, הזנת מספרים בגבולות ובסביבתם שהתוכנה בודקת כדי לבחון האם ישנם באגים בקצה טווח העבודה הצפוי של חבילת תוכנה. זה מועיל בעיקר במערכות מבוססות חישוב ויכול לעזור למפתחים להתאים גבולות או למצוא את הגורם לבעיות כלשהן.
3. בדיקת מעבר מדינה
הרבה תוכניות משתנות בין “מצבים” או “מצבים” שונים ודורשות מעבר משלב אחד של תהליך זה למשנהו. מעברים אלו פועלים כהלכה פירושם שהאתר מתפקד כפי שהמשתמש מצפה ואין עצירות בלתי צפויות.
בדיקת מעבר מצב היא סוג של בדיקה שבוחנת את כל המעברים בין מצבים בתוכנה, מבטיחים שהם פונקציונליים ומספקים ודאות שהמשתמש זורם בתוכנה עובד ללא הפרעות בלתי צפויות.
בדיקת קופסה שחורה במחזור החיים של הנדסת תוכנה
בדיקת קופסה שחורה היא דיסציפלינה שרואה שימוש בעיקר לקראת סוף מחזור החיים של הנדסת תוכנה. זה כולל הכל, החל מבדיקת האופן שבו משתמשים יתקשרו עם התוכנה ועד למתן גישה מלאה לבטא, כאשר בדיקות הקופסה השחורה נכנסות בעיקר ברגע שכל הפונקציונליות פועלת כמצופה.
זה חוסך הרבה זמן ומאמץ בהשוואה לבדיקת קופסה לבנה שדורשת רמה גבוהה של מומחיות, והיא מיושם בצורה הטובה ביותר כאשר אינך זקוק לצוות פיתוח בסביבה כדי לבצע שינויים מיידיים באופן שבו המערכת פועלת.
בדיקות קופסא שחורה ידנית או אוטומטית?
בדיקות תוכנה מגיעות בשני פורמטים נפרדים, כאשר בדיקה ידנית היא הצורה המסורתית המשתמשת בבודקי תוכנה בכל שלב בתהליך. זוהי סתירה נחרצת עם בדיקות אוטומטיות, המשתמשות ברמה הולכת וגוברת של בינה מלאכותית ולמידת מכונה כדי להשלים משימות ללא כל הפרעה אנושית.
המשך לקרוא כדי לגלות עוד על מהן בדיקות ידניות ואוטומטיות, האתגרים של כל אחת מהן ואיזו מהשתיים אידיאלית עבור חברה.
1. בדיקת קופסה שחורה ידנית – יתרונות, אתגרים, תהליך
בדיקת קופסה שחורה ידנית מתייחסת לתהליך של השלמת בדיקות קופסה שחורה באופן עצמאי, תוך שימוש באנשי צוות להשלמת כל המשימות במקום שימוש בפלטפורמת אוטומציה כחלק מערך הכלים של החברה.
כמה מהיתרונות העיקריים של שימוש בבדיקות ידניות בפיתוח תוכנה הם האופן שבו יש לך מידה רבה יותר של גמישות בדרך שבה אתה משלים את הבדיקות והדרך שבה מפתחים יכולים לקבל משוב הרבה יותר יסודי שהוא איכותי באופיו.
עם זאת, ישנם כמה אתגרים טבעיים מולדים בתהליך הבדיקה הידנית. הראשון שבהם הוא העובדה שבדיקה ידנית יכולה לקחת הרבה זמן, כאשר אנשים איטיים יותר מתוכניות אוטומטיות בביצוע המשימות שלהם.
רמה נוספת היא רמה גבוהה יותר של פוטנציאל לטעויות, כאשר לאנשים יש את היכולת לבצע קליקים שגויים או לעשות דברים בסדר לא נכון. זה יכול בסופו של דבר לגרום לאי דיוקים בנתוני הבדיקה.
בדיקה ידנית היא תהליך שמתחיל בלימוד הציפיות של החברה לאפליקציה לפני כתיבת מקרי מבחן המאתגרים את הבריף הזה, ביצוע מקרי הבדיקה ודיווח על התוצאות לצוות הפיתוח.
2. אוטומציה של בדיקות קופסה שחורה – יתרונות, אתגרים, תהליך
בדיקות אוטומטיות מתייחסות לבדיקות שחברה משלימה על חבילת תוכנה על ידי השלמת מקרי בדיקה עם מערכת אוטומטית. אלה משתמשים בפלטפורמות של צד שלישי כדי להפוך את חבילת התוכנה לאוטומטית, עם כל שלב אוטומטי בעקבות מקרי בדיקה שהוכנו במיוחד.
היתרון העיקרי של אוטומציה של בדיקות קופסה שחורה הוא המהירות שלה, עם תוכניות אוטומטיות שלוקחות הרבה פחות זמן לכל ריצה בודדת של בדיקה. זה מצטבר לרווח משמעותי בזמן בבדיקות שלך, אותו תוכל להשקיע בפיתוח האפליקציה.
יתרון נוסף הוא הדיוק, שכן כלי אוטומציה טוב משלים את אותן משימות באותו סדר בכל פעם.
חסרונות עדיין יכולים לגרום לבעיות באוטומציה של בדיקות קופסה שחורה, כאשר אחת הבעיות העיקריות היא התמקדות בנתונים כמותיים. זה נהדר עבור מדדים, אבל אומר שבמבחן קבילות המשתמש, יש מעט מידע בעל ערך שניתן להשיג.
יש גם חוסר יחסי של גמישות בבדיקות אוטומטיות, כאשר אנליסטים צריכים לקודד מקרי בדיקה חדשים לגמרי בכל פעם שהם רוצים לבצע שינוי.
תהליך האוטומציה של הבדיקות מתחיל בתכנון של סדרה של מקרי בדיקה אשר מקודדים למערכת לפני ביצוע הבדיקות, המספקות דוח עם סיום.
3. מסקנה: בדיקת אוטומציה ידנית או שחורה?
בסופו של דבר, הבחירה בין בדיקת קופסה שחורה ידנית ואוטומטית היא אחת מסובכת שתלויה במה שאתה מחפש במערכת.
אם אתם מחפשים מידע איכותני מתקדם שתוכל להשתמש בו כדי לבצע שינויים בעיצוב עבור משתמש קצה, בדיקה ידנית היא ללא ספק האפשרות הטובה יותר, כאשר בדיקות אוטומטיות אידיאליות לשלבי תפקוד וביצועים בתהליך.
חשבו מה אתם מחפשים בכל שלב בתהליך הבדיקה ותוכלו לקבל נתונים מודרכים שמשפרים את הביצועים שלכם בקלות.
מה אתה צריך כדי להתחיל בבדיקת קופסה שחורה?
ישנם כמה תנאים מוקדמים שאתה צריך לקבל גישה אליהם לפני שתתחיל בבדיקת קופסה שחורה, שכל אחד מהם עוזר ליצור תהליך בדיקה קוהרנטי יותר.
כמה מהדברים שיש לפני שתתחיל לעבוד בבדיקת קופסה שחורה כוללים:
1. דרישות תוכנה
דרישות התוכנה מתייחסות לנקודות הספציפיות בתקציר התכנון שהתוכנה נועדה לפגוע בהם. זה יכול לכלול מגוון דברים, החל מהצורך להשלים סט מסוים של משימות ועד למראה ותחושה מסוימים בעת השימוש בו.
מידע זה מספק לך כמה יעדים ספציפיים לשאוף אליהם בבדיקות שלך, כאשר בודקים יוצרים לוח זמנים ותוכנית בדיקות שמביאים למערכת קוהרנטית יותר של תוצאות שמודיעות למפתחים על בעיות בתוכנה.
בחלק מהחברות, מכיוון שמדובר במבחן קופסה שחורה, המפתחים יגבילו את הגישה של בודק לבריף.
2. תוכנת קומפילציה
לפני בדיקת תוכנה, צוות אבטחת איכות צריך לקבל גישה לתוכנה. זה בדרך כלל כרוך במפתחים המספקים את הגרסה העדכנית ביותר של התוכנה, כשהצוות נהנה מכך שיש לו גרסה טרייה לחלוטין של התוכנה לבצע את הבדיקות שלהם.
גרסה עדכנית פירושה שהבדיקות כוללות כמה מהתיקונים האחרונים, מה שאומר שהיא נותנת ייצוג מדויק של ביצועי התוכנה.
3. בדיקת מטרות
בודקים נוטים לגשת לתקופה של בדיקות מתוך מחשבה על כמה מטרות ספציפיות. יעדי הבדיקה הללו מגדירים בדיוק את מה שהם בודקים בתקופה הקרובה, בין אם זה קבילות המשתמש, פונקציונליות מקצה לקצה או השלמת בדיקות חדירה.
מנהלי QA נוטים להציב את המטרות הללו, כאשר השלב הבא של הבדיקה תלוי בדרך כלל במה שצוות הפיתוח עבד עליו ובחלקים בתוכנה שהפיתוחים הללו משפיעים עליהם.
תהליך בדיקת הקופסה השחורה
תהליך בדיקת הקופסה השחורה הוא תהליך מדויק יחסית, כאשר חברות נהנות מביצוע שלבי התהליך מקרוב ככל האפשר. השלבים השונים של תהליך בדיקת הקופסה השחורה כוללים:
1. תכנון מבחן
התחל את תהליך בדיקת הקופסה השחורה עם תהליך תכנון מורכב. זה כרוך בדיון בכל המטרות האישיות שיש לך למבחן, בהיבטים הספציפיים של התוכנה שאתה בוחן והמשאבים שאתה מקדיש לבדיקה.
תכנון יסודי יותר אומר שכולם יודעים מה הם אמורים לעשות ומתי הם אמורים לעשות זאת, כולל השיטות הכרוכות בבדיקות.
2. כתיבת מקרה מבחן
כתיבת מקרה מבחן הוא השלב הבא בתהליך. מקרה בדיקה מתייחס לסדרה של שלבים שיש להשלים בבדיקה, כאשר מקרי בדיקה מפורטים יותר מספקים רמה גבוהה יותר של עקביות עבור המשתמש.
בתהליך בדיקה אוטומטי, זה כרוך גם בקידוד מקרה הבדיקה בכל כלי אוטומציה שאתה מתכנן להשתמש בו.
בדוק שוב את כל מקרי הבדיקה שלך כדי לוודא שהם יסודיים וברורים לגבי השלבים שיש להשלים.
3. ביצוע מקרה מבחן
לאחר שהכנת מקרי הבדיקה שלך, התחל לבצע את מקרי הבדיקה. בעת שימוש באוטומציה, זו יכולה להיות משימה קלה יחסית הכוללת הגדרת התוכנית לדרכה והמתנה לתוצאות. בדיקה ידנית מסתמכת על עובדים שישלימו את מקרי הבדיקה שוב ושוב, עם יותר חזרות המובילות לנתונים עקביים ואיכותיים יותר.
בצע כל מקרה בדיקה בזהירות ככל האפשר, שכן ככל שביצוע מקרי הבדיקה מדויק יותר כך יש לך סיכוי טוב יותר שהנתונים יהיו שימושיים לצוות הפיתוח.
4. דיווח סופי
שלב הדיווח הסופי מתייחס לחלק בתהליך שבו צוות הבדיקות מדווח למפתחים.
התחל בהוספת סיכום פשוט של המידע שנאסף לפני שתוסיף לזה את כל המדדים שהבודקים אספו. זה מספק למפתחים הדרכה ראשונית לגבי הכיוון האידיאלי למחרוזת העדכונים הבאה לפני הצגת הנתונים המלאים, מה שמאפשר להם לקבל הבנה מעמיקה יותר של הבעיות.
שיטות עבודה מומלצות לבדיקת קופסה שחורה
ללא קשר לענף שלך, ביצוע שיטות עבודה מומלצות הוא חובה עבור כל חברה. שיטות עבודה מומלצות מתייחסות לשורה של התנהגויות וטכניקות שהחברה מרוויחה מהשימוש בהן בעבודתה היומיומית, הגברת היעילות של החברה ושיפור רמת התוכנה שבה משתמשת החברה.
חלק מהשיטות הללו שעוזרות לחברה לשפר את איכות בדיקת הקופסה השחורה שלה כוללים:
1. התמקדות בפיתוח מיומנויות
אם אתה מנהל חברה שעובדת על כמה פיסות תוכנה בכל זמן, שקול להתמקד בפיתוח מיומנויות בדיקה והתמחויות . ככל שתשקיעו יותר זמן בהתמחות ובפיתוח מיומנויות מתאימות, כך גדלו הסיכויים שלכם לעקור את כל הבעיות הקיימות במוצרים שלכם.
זה משתלב עם עובדים בעלי מערכת הכישורים הנכונה, אך מתאים ביותר לחברות שמתקיימות בהן בדיקות תוכנה כמעט תמידיות, מכיוון שתמיד יש יתרון ביישום היכולות הללו.
2. איזון עומסי עבודה
כמה צוותי בדיקה יכולים להיות גדולים מאוד, עם עשרות, או אפילו מאות, אנשי צוות, כולם משלימים מקרי בדיקה על בסיס קבוע.
השיטה הטובה ביותר להפיק את המרב מאנשי הצוות הללו היא לקחת את הזמן ולהיות זהיר כאשר אתה מקצה אנשים למשימות ספציפיות. לשחיקה יש היסטוריה רצינית של גרימת בעיות בתעשיית פיתוח התוכנה, אבל זה משהו שניתן להימנע ממנו עם ניהול עומס עבודה טוב יותר.
3. צור תהליכים עקביים
חברות בנויות על תהליכים שאנשי הצוות שלהן משלימים על בסיס יומי, כאשר תהליכי בדיקה כוללים את האופן שבו חברה כותבת את מקרי הבדיקה שלה, משלימה מחקר ומתקשרת פנימית בין המחלקות.
עקביות במקרים אלה היא המפתח, שכן המשמעות היא שאנשים לומדים מהר יותר כשהם נכנסים לחברה. זה מוביל להסתגלות מהירה יותר ולתפוקה טובה יותר הרבה יותר מהר מאשר בחברה ללא עקביות בין המשימות שלה.
אם אתה יכול, צור תהליכים אלה באופן שיכלול צוות בתהליך קבלת ההחלטות, שכן זה מוודא שהם מסכימים עם האסטרטגיה.
7 טעויות ומלכודות ביישום מבחני קופסה שחורה
טעויות הן טבעיות בכל תעשייה, אבל לדעת על טעויות לפני שיש לך הזדמנות לעשות אותן יכולה לחסוך לך הרבה זמן ומאמץ.
כמה מהטעויות והמלכודות הנפוצות ביותר שאליהם נופלים בודקי קופסה שחורה כוללים:
1. היעדר היקף בדיקה מוגדר
חלק מהארגונים מתחילים לבדוק את המוצרים שלהם מבלי לתכנן נכון את התהליכים, וזו טעות משמעותית.
על ידי אי תכנון, חברות עלולות לאבד מעקב אחר היקף הבדיקות. קיום היקף מוסכם עוזר למבחן להיות בקנה מידה הנכון ולהשיג תוצאות ביעילות.
אם אינך מסכים לגבי היקף הבדיקה שלך לפני שמתחילים, קיים סיכון רציני של בדיקה רחבה מדי וייקח יותר מדי זמן כדי לקבל תוצאות פחות רלוונטיות.
2. תהליכי בדיקה נמהרים
בדיקה יכולה להרגיש כמו תהליך שלוקח זמן רב מאוד, במיוחד עם מקרי בדיקה ארוכים שנועדו לבחון אפליקציה שלמה. אנשים מסוימים יכולים להתפתות למהר את הבדיקות שלהם, במיוחד בריצות חוזרות של בדיקות קודמות. זו טעות חמורה. מהירות הבדיקה שלך יכולה להוביל לשגיאות בביצוע מקרי בדיקה, פגיעה בערך הנתונים ובסופו של דבר המשמעות היא שאתה צריך לעשות את אותן בדיקות בכל מקרה.
3. אוטומציה ללא תהליך אימות
אוטומציה של בדיקות מתמקדת בעיקר בלהבטיח שהזנת ערך נתונים תוביל לפלט הנכון בסוף התהליך. אוטומציה של בדיקות אלה פועלת על ידי אימות הפלט של התהליך האוטומטי מול מה שהתוצאות אמורות להיות.
חלק מהבודקים עושים שגיאה משמעותית בכך שהם לא מחשבים את הערך בעצמם, כלומר אין להם דרך לאמת אם הפלט נכון או לא, ועלולים לא למצוא באגים משמעותיים בכל המערכת.
4. אי שימוש בבדיקות היברידיות
בדיקה היברידית מתייחסת לאיזון של אוטומציה עם בדיקה ידנית, שכן שתי השיטות פועלות בצורה שמכסה בצורה מושלמת את הפגמים של זו.
עם זאת, ארגונים מסוימים מעדיפים להתמקד באחת משתי השיטות. על ידי כך אתה פותח את הבדיקות שלך לבעיות חמורות ואי דיוקים.
השלם בדיקות היברידיות כדי לקבל רמת איזון טובה יותר בבדיקות שלך ולהפחית את מספר השגיאות בצורה משמעותית ככל האפשר.
5. לא להשלים בדיקות רגרסיה
בדיקת רגרסיה צריכה להיות תהליך מתמיד בכל מערכת בדיקת תוכנה יעילה, כאשר צורת בדיקה זו קובעת אם עדכוני תוכנה גרמו לבעיות במקומות אחרים במערכת. כשל בהשלמת בדיקות רגרסיה פירושו שפונקציות שבדקת בשלב מוקדם של התהליך עלולות להיכשל מבלי שתבין.
על ידי השלמת בדיקות רגרסיה אתה מבטיח שאתה שולח מוצר באיכות גבוהה יותר מבלי להשקיע יותר מדי עבודה נוספת בתהליך אבטחת האיכות.
6. ציד פעיל אחר באגים
יש הסבורים שהמטרה של בדיקת קופסה שחורה היא למצוא באגים בחבילת תוכנה ולדווח עליהם לצוות פיתוח, ולמרות שזהו היבט אחד, זה לא הפוקוס היחיד. בדיקות קיימות כדי לשפר בדרך כלל את הסטנדרט של חבילת תוכנה.
על ידי התמקדות קשה מדי בבאגים בתוכנה אתה מתחיל להתנדנד מחוץ לזרימות עבודה סטנדרטיות, להגיע אל מחוץ לתחום הבדיקות שלך ולהתעלם מכמה מהבעיות הרלוונטיות יותר בתוכנה בתמורה לחיפוש אחר פגמים שעלולים להיות לא רלוונטיים בקוד.
7. התעלמות מהאינטואיציה שלך
בבדיקה ידנית, לבודק יש את התפקיד כי יש לו חוש קיים של אינטואיציה, וידע בקוד שמנחה אותם לעבר בעיות פוטנציאליות ומודיע להם על תחומים לבחון כאשר הם עובדים.
עם זאת, חלקם בוחרים להתעלם לחלוטין מהאינטואיציה הזו כאשר עובדים על מקרי מבחן. על ידי שימת לב לכל מה שאתה רוצה לבדוק ובדיקתו במקרה מבחן חדש, אתה מקבל את מלוא התועלת מהידע הטכני שלך תוך השלמת מקרי הבדיקה המוכנים.
סוגי פלטים מבדיקות קופסה שחורה
ישנם מספר סוגי פלט שתוכלו לקבל מבדיקת קופסה שחורה, כאשר כל אחד מהם מספק תובנות ייחודיות לחברה המעוניינת לבצע עדכונים רלוונטיים למוצריה ולשפר את האיכות שחווים הלקוחות.
חלק מהסוגים העיקריים של פלטים מבדיקות קופסה שחורה כוללים:
1. נתונים איכותיים
צורת הפלט הראשונה שאתה יכול לקבל ממבחן קופסה שחורה היא נתונים איכותיים. מדובר במידע שמתאר בעיקר את האפליקציה ויוצא מבדיקות כמו בדיקות מקצה לקצה ומבחני שימושיות.
נתונים איכותיים מתארים בדרך כלל את סטנדרט היישום, דנים בניסיונם של אנשים עם היישום ומסבירים את השינויים שבודק ירצה לבצע.
בעת יצירת נתונים אלה, בודק בדרך כלל כותב דוח יסודי המציין את כל ההוכחות לנקודות שלו, ותומך בדעות איכותיות עם תכונות נוספות כגון צילומי מסך של מה שהם מתייחסים אליו.
2. נתונים כמותיים
הכוונה היא לנתונים מספריים ברורים בצורה של מדדים, כאשר חברי צוות הבדיקה שמים לב לחלקים ספציפיים של אפליקציה או מקבלים נתונים מספריים מפרוטוקול בדיקות אוטומציה.
מידע כמותי נוטה להיות שימושי יותר כדי לספק למפתחים תיקונים ברורים, המצביעים על חלקים מהאפליקציה כמו רמת הביצועים שלה, היעילות שלה מבחינת משאבים בשימוש ומספר הבאגים והבעיות שקיימים באפליקציה.
מידע כמותי קל יותר לניתוח ולהערכתו מאשר המקבילה התיאורית שלו, שכן אין צורך בפרשנות כלשהי.
3. הודעות שגיאה
הודעות שגיאה מתרחשות כאשר הפונקציונליות של התוכנה אינה פועלת כצפוי. זה יכול להיות בגלל בעיות חומרה או תוכנה, בדרך כלל מגיע עם תיאור קצר של מהי הבעיה בנוסף לקוד שגיאה.
מפתחים יוצרים מערכת של קודי שגיאה כדי לעזור להם לצמצם בדיוק היכן מתרחשת בעיה במערכת, עם כמה רעיונות ליישום כולל שימוש בספרה הראשונה כדי לצמצם את הפונקציה שחווה בעיה, השנייה כדי לתאר מה ספציפית נכשל ושלישי לציין את סיבת הבעיה.
שימוש במערכת קודי שגיאה זו פירושו שמפתחים יודעים מיד מה הבעיה ויכולים לעבוד על פתרון.
דוגמאות לבדיקות קופסה שחורה
בעוד שהתיאוריה מאחורי בדיקת הקופסה השחורה היא פשוטה יחסית, יישום מעשי שלה יכול להיות תהליך מורכב, במיוחד עבור בודק בפעם הראשונה. הצגת דוגמה לבדיקת קופסה שחורה בפעולה יכולה לעזור להנחות אותך בארגון הבדיקות שלך.
כמה דוגמאות לשיטות בדיקת קופסה שחורה, כולל סוגים מרובים של בדיקות ודרגות שונות של הצלחה, כוללות:
1. בדיקת קבלת משתמשים לא יעילה
חברה מעוניינת לשחרר את המוצר שלה בשבועות הקרובים, כאשר בדיקות קבלת המשתמש עדיין לא יתקיימו. האפליקציה היא הדרכת סריגה לקהל מבוגר.
מפתחים שואפים לזרז את התהליך הזה ולאסוף קבוצה של בודקים במהירות, תוך שימוש בלעדי באנשים שאינם סורגים מאמצע שנות השלושים כדי לבדוק שכן הם היו קבוצה נגישה יותר. קבוצה זו אינה רואה בעיות עם האפליקציה ומאירה אותה באור ירוק לפרסום פומבי.
בשל רמות הידע הטכני הסותרות בין שתי הקבוצות, קהל היעד מבולבל יותר בעת השימוש בתוכנה ואינו יכול לגשת להרבה מהתכונות. כתגובה נאלצת החברה להשלים עדכונים דחופים.
כשלים בבדיקות כגון זה מוכיחים את החשיבות של הכנה יסודית.
2. בדיקות מקצה לקצה מוצלחות
בדיקה מקצה לקצה מתייחסת לבדיקה שמתבצעת לאחר שהפונקציונליות של אפליקציה הורכבה במלואה לחבילת תוכנה אחת בפעם הראשונה.
חברה תכננה בקפידה להשלים את תהליך הבדיקה מקצה לקצה, עם סדרה של אנשי צוות שנשכרה במיוחד כדי להשלים את חובות הבדיקה עם שני עובדים המוקדשים לכל מקרה בדיקה.
לאחר תהליך קפדני, הם משלימים את מקרי הבדיקה שלהם ומציינים את כל הנתונים שהם אוספים, כשמנהל QA אוסף את הנתונים לדוח מגובש בתום הבדיקה.
מפתחים משתמשים בדוח זה כדי לתכנן את סדרת העדכונים והשינויים הבאים באפליקציה, תוך שיפור משמעותי במוצר.
3. בדיקות רגרסיה אוטומטיות
מפתח השלים סדרה של עדכונים לתוכנה שלו שלפני העדכונים פעלו כמצופה. לאחר העדכונים צוות הבדיקות עובר תהליך בדיקות רגרסיה, תוך התמקדות באוטומציה, ומקבל פלטפורמה אוטומטית להשלמת כל הפונקציונליות הבסיסית.
הצוות כותב את הקוד למקרה בדיקה ומבצע את מקרי הבדיקה, קורא את כל תוצאות הבדיקות ומגלה היכן יש בעיות פוטנציאליות.
זה מונע מבעיות להתעורר בגלל שארגון מבצע עדכונים ולא מצליח לבדוק אם יש להם בעיה או לא.
סוגי שגיאות ובאגים שזוהו באמצעות בדיקת קופסה שחורה
למרות שטעויות ובאגים הם לא הכל בתהליך בדיקת הקופסה השחורה, הם חלק משמעותי מהדרך שבה חברות מבצעות בדיקות.
הכרת כמה מהסוגים העיקריים של שגיאות ובאגים בבדיקת קופסה שחורה יכולה לעזור לך לסווג את כל הבעיות שנתקלת בהן ולהבין יותר מדוע הן מתרחשות.
חלק מהסוגים העיקריים של שגיאות ובאגים שניתן לזהות באמצעות בדיקת קופסה שחורה כוללים:
1. שגיאות שמישות
שגיאות שמישות מתייחסות לפגמים בתוכנית שאינם משפיעים בפועל על הפונקציונליות אך עלולות לגרום לבעיות עבור משתמש המנסה ליצור אינטראקציה עם התוכנה.
לדוגמה, אם לאפליקציה יש תקלה גרפית חמורה, היא עדיין מתפקדת מבחינה טכנית אך ללא הסמלים והטקסט הנכונים, משתמש הקצה לא יכול להשתמש בו ביעילות. בעיות אלו נוטות להקיף את עיצוב האפליקציה ואת האופן שבו העיצוב נטען עבור המשתמש, כאשר יישומים מורכבים יותר דורשים יותר גרפיקה מורכבת יותר מאלה שבממשק משתמש פשוט יותר.
2. שגיאות פונקציונליות
שגיאות פונקציונליות מתייחסות לבעיות המתרחשות כאשר חלק מהתוכנית אינו פועל כמצופה.
לדוגמה, אם אתה מפעיל תוכנת מסד נתונים ומנסה למיין את המידע לפי קטגוריה מסוימת, רק כדי לגלות שזה לא עובד. זה המקרה גם לגבי פונקציות שאינן עובדות כלל וגם לאלו שנראה כי פועלות אך עושות זאת בצורה לא נכונה.
אלו יכולות להיות חלק מהבעיות המשמעותיות ביותר עבור אפליקציה, לגרום למשתמשים אי נוחות משמעותית ולהחמיר את המוניטין של המפתח מכיוון שהמוצר אינו פועל כפי שפורסם.
3. קריסות
כאשר תוכנה קורסת, יש בעיה מהותית בתוכנה שמונעת ממנה לפעול. ישנן כמה צורות שונות של קריסות שיכולות להתרחש, כולל כאשר אפליקציה נסגרת בשלמותה או פשוט קופאת בשלב מסוים בתהליך.
קריסה היא אחת הבעיות החמורות ביותר שיכולות להתרחש מכיוון שאין דרך להחזיר את האפליקציה לפונקציונליות מלבד סגירה מלאה ופתיחה מחדש שלה. בעוד שבאפליקציות מסוימות עדיין יש תהליכים המתרחשים ברקע, אין דרך לקיים אינטראקציה עם התוכנה מעבר לנקודה זו.
מדדי בדיקת קופסה שחורה נפוצה
בדיקת קופסה שחורה ידנית מצטיינת ביצירת נתונים איכותיים, אך כאשר אתה מתמקד בנתונים כמותיים אתה צריך להיות מודע למדדים שאתה בודק. הבנה מלאה של מדדים אלה עוזרת לך להבין את הפגמים בפלטפורמה ולתעדף תחומים שונים לעבוד עליהם.
כמה מדדי בדיקת הקופסה השחורה הנפוצים יותר שאתה מוצא בעבודה שלך כוללים:
1. שיעור שגיאות
שיעור השגיאות יכול להתייחס לכמה דברים, או למספר הטהור של שגיאות המתרחשות במחזור הבדיקות של התוכנה או לשגיאות המתרחשות בכל שעת בדיקה. מדדי שעה טובים יותר, מכיוון שהם מייצגים את צפיפות השגיאות בתוכנה במקום פשוט לציין מספר, כאשר יישומים גדולים יותר עשויים להיות מצג שווא.
מפתחים מבקשים להגביל את שיעור השגיאות ביישומים שלהם, שכן ככל שיהיו פחות שגיאות בחבילת התוכנה, כך החוויה של הלקוח בשימוש במערכת הולכת להיות טובה יותר.
2. זמן תגובה
כאשר בודק מחפש לברר יותר על רמת הביצועים שהמשתמש חווה, זמן התגובה הוא אחד ההיבטים העיקריים שיש לקחת בחשבון. הכוונה היא לכמות הזמן שלוקח לתוכנה להשלים משימה לאחר שהמשתמש נכנס להנחיה, כאשר זמני תגובה ארוכים יותר מראים יישום לא יעיל יחסית. זמני תגובה גבוהים יותר מהווים סיבה לדאגה מכיוון שמשתמשים עלולים לאבד סבלנות עם אפליקציה שלוקחת יותר מדי זמן.
3. שביעות רצון המשתמש
רוב המדדים מתמקדים במספרים טהורים שנוצרים על ידי חבילת התוכנה ותוכנת בדיקה במבחן, אך חלק מהמדדים מתמקדים בדעה.
אם חברה משלימה מבחן בטא שמשתמש ב-1000 בודקים, למשל, היא יכולה לאסוף נתונים על מספר האנשים שמרוצים ולהפוך את זה לאחוז. זהו מדד שימושי ביותר שיהיה זמין בסוף מחזור, עם שיעור גבוה יותר של שביעות רצון המשתמשים המוכיח שיותר אנשים נהנים מהתוכנית ומצביע על כך שיש סיכוי גבוה יותר שהיא תצליח בעתיד.
כלי בדיקת הקופסה השחורה הטובים ביותר
בדיקת קופסה שחורה היא סוג של בדיקה שיכולה להסתמך באופן משמעותי על כלים בהישג יד, הן לאוטומציה של בדיקות הקופסה השחורה שלך והן לארגון המידע שאתה מקבל מהבדיקות שלך.
שימוש בשילוב הנכון של כלים יכול לעזור לך ולצוות שלך לעבוד הרבה יותר יעיל ולבנות תהליכים יעילים יותר בכל מחלקת אבטחת האיכות.
ראה כמה מכלי בדיקת הקופסה השחורה הטובים ביותר למטה ולמד כיצד בדיוק כל אחד מאלה יכול לעזור לך לשגשג:
5 כלי בדיקת הקופסה השחורה הטובים ביותר בחינם
לחברות קטנות ומתפתחות, כמו מפתחים עצמאיים, אין תקציב גדול לעבוד איתו בעת יצירת התוכנה שלהן. זה יכול להביא מגוון של אתגרים, כולל מציאת הכלים הנכונים לעבוד איתם.
להלן כמה מהכלים החינמיים הטובים ביותר הזמינים למפתחים עצמאיים המעוניינים לשפר את זרימות העבודה שלהם בתקציב מוגבל:
1. ZAPTEST FREE EDITION
המהדורה החינמית של ZAPTEST היא ההקדמה המושלמת לאוטומציה של בדיקות תוכנה. כלי זה תוכנן במיוחד כדי לתמוך באוטומציה של כל משימה, ועוזר לך לעבוד במהירות וביעילות רבה יותר ללא קשר למשימה שאתה משלים.
הגרסה החינמית של ZAPTEST אורזת כמות עצומה של פונקציונליות לתמיכה באוטומציה של כל יישום… יישום 1SCRIPT חוצה דפדפן, חוצה מכשירים, יישומים חוצי יישום וביצוע מקביל הם אחת התכונות הזמינות.
2. JIRA
מהדורות חינמיות של JIRA הן כלים אידיאליים לרישום באגים, הוספת פרטים עליהם בכרטיסים ותעדוף אותם בעת תקשורת עם צוות פיתוח.
עם זאת, במקום להיות כלי עזר לאוטומציה הכל באחד, זה מתמחה אך ורק בצד ניהול הפרויקטים של תהליך הבדיקה.
3. סלניום IDE
אפליקציית קוד פתוח שמקליטה ומפעילה אוטומציה של בדיקות, זהו כלי טוב לראות מה פלטפורמת אוטומציה רואה בעת השלמת בדיקה.
פגם אחד בסלניום הוא חוסר יחסי בתכונות מתקדמות כמו אינטגרציה בין פלטפורמות של משימות אוטומטיות.
4. AutoHotkey
AutoHotkey היא שפת סקריפטים חינמית לחלוטין וקוד פתוח הזמינה עבור Windows , המסייעת למשתמשים ליצור סקריפטים במגוון גדלים המשלימים סדרה של משימות לאחר הזנת הקשה אחת.
למרות שזה טוב לאוטומציה של משימות פשוטות, AutoHotkey יכול להתחיל להיאבק עם כמה סקריפטים גדולים יותר ודרישות אוטומציה.
5. אפיום
כלי שמצטיין בעיקר באוטומציה של יישומי iOS , זוהי תוכנית אידיאלית לשימוש כאשר מחפשים לשפר את איכות היישומים הניידים שלך.
החיסרון הגדול ביותר של Appium הוא העובדה שאתה מוגבל למגוון קטן מאוד של מוצרים, מה שמצמצם את השוק הזמין שלך באופן משמעותי.
5 הכלים הטובים ביותר לבדיקת קופסה שחורה ארגונית
הכלים החינמיים כולם טובים וטובים, אבל ארגונים וחברות גדולות צריכות לקבל יותר תכונות כדי לבחון ביסודיות את התוכנה שלהם. למרבה המזל, לכמה מכלי בדיקת הקופסה השחורה הארגונית הטובים ביותר יש פונקציונליות מקיפה ועוזרים לעסקים לקבל החזר משמעותי על ההשקעה בתהליכי ה-QA שלהם.
כמה כלים אידיאליים לבדיקת קופסה שחורה לארגונים שכדאי לשקול להשקיע בהם כוללים:
1. ZAPTEST ENTERPRISE EDITION
מהדורת Enterprise של ZAPTEST היא אחד מכלי האוטומציה המשמעותיים ביותר בשוק ויכולה לספק עד פי 10 החזר על ההשקעה עבור המוצר שלך.
תכונות כגון גישה למומחה ZAP במשרה מלאה כחלק מרוחק מהצוות שלך ורישיונות בלתי מוגבלים מבטיחים שתוכל ליישם אוטומציה של מבחני קופסה שחורה ללא צורך בעקומת למידה תלולה, ובעלות קבועה ללא קשר למהירות הצמיחה שלך .
2. TestRail
TestRail היא פלטפורמה המתמקדת בבדיקות בזמן אמת במטרה לחבר את הבדיקות שלך עם פלטפורמת ניהול פרויקטים מגובשת. למרות שזה אידיאלי לריכוז עבודת ניהול הצוות שלך, תכונות האוטומציה רחוקות מלהיות מושלמות עבור צוות פיתוח המחפש דגש רב על בדיקות אוטומטיות.
3. Opkey
Opkey היא פלטפורמה המתמקדת באוטומציה ללא קוד, כלומר אנשים ללא ידע טכני קיים יכולים להתחיל לבצע אוטומציה של שירותי הבדיקה שלהם.
אחד הפגמים העיקריים של Opkey הוא היעדר קהילה פעילה סביב התוכנה, מה שיכול להשאיר אותך תקוע יחסית כשאתה מנסה לבצע אוטומציה בצורה חדשה עבורך.
4. פרפקטו
Perfecto הוא כלי המתמקד בסיוע למשתמשים לבצע אוטומציה של אפליקציות מובייל ללא בעיות רציניות, עבודה על מגוון רחב של מכשירים והתמקדות בעבודת בדיקות מקצה לקצה.
עם זאת, האפליקציה פועלת על מכשירים אמיתיים ולא על מכונות וירטואליות, מה שמוסיף עוד עלות גדולה למה שהוא כבר כלי בדיקה יקר יחסית, עבור פלטפורמות מוגבלות.
5. JIRA Enterprise
מלבד השלמת צד האוטומציה של הבדיקות, ניהול הפרויקטים נשאר חשוב, וזה המקום שבו JIRA נכנס לתמונה. ל- Enterprise JIRA יש יותר אחסון ומאפשרת ליותר משתמשים לגשת לפלטפורמה, אך עלולה לגרום לבלבול פוטנציאלי עם הצורך בהרשאות וגישה מותאמות אישית לכל משתמש בודד. זה לוקח הרבה זמן אדמיניסטרטיבי כדי להשלים.
מתי כדאי להשתמש
כלי Enterprise לעומת Freemium Black Box?
בתור התחלה, רוב החברות יעשו שימוש בכלי קופסה שחורה של freemium. זה הגיוני מנקודת מבט כלכלית מכיוון שאף עסק אינטליגנטי לא רוצה להשקיע במוצר שהוא לא לגמרי מבין אם זה מנקודת מבט של ניהול פרויקטים או אוטומציה.
כלי Freemium אינם כוללים רק אפליקציות חינמיות לחלוטין, אלא יכולים לכלול גרסאות חינמיות של מוצרים ארגוניים שבהם חברה משתמשת כאשר היא לומדת כיצד ליישם את הכלי בתהליכים שלה.
הזמן האידיאלי לארגון לעדכן את בחירת הכלי שלו למהדורה ארגונית הוא כאשר החברה מתחילה לחוות חיכוך בתהליכי הבדיקה שלה בגלל הכלי החינמי. בין אם מדובר בכלי חינמי שמציע רק מספר נבחר של רישיונות או כמות בדיקות, ברגע שאתה מתחיל לחוות חוסר יעילות בתהליכים שלך כתוצאה מכלי הבדיקה שלך, עליך לבצע את המעבר לגרסה ארגונית שמתאימה לכל הצרכים שלך.
רשימת בדיקות לקופסה שחורה, טיפים וטריקים
מכיוון שבדיקת קופסה שחורה היא שיטת בדיקה מורכבת ביותר עם הרבה הזדמנויות לבניית הידע שלך על חבילת תוכנה, יש כמה דברים שאתה צריך לחפש.
כמה טיפים וטריקים חשובים שיש לכלול ברשימת הבדיקות של הקופסה השחורה שלך כוללים:
· הבנת הבריף
לפני שתתחיל לעשות תוכניות כלשהן לבדיקה, וודא שאתה מבין את ההנחיות הרחב יותר לתקופת הבדיקה. זה כולל הבנת התוכנה ככל שמותר לך וללמוד בדיוק מה אתה אמור לבדוק.
· הגהה מקרה מבחן
נסה לגרום לכל מי שמעורב בבדיקה להעריך את מקרי הבדיקה שבהם אתה משתמש בבדיקת קופסה שחורה. ככל שיותר עיניים רואות את מקרה המבחן לפני היישום, כך יש לך סיכוי טוב יותר לבטל שגיאות כלשהן.
· ערכו רשימה של דברים שיש לעשות
הצד הלא טכני של ההכנה לבדיקת קופסה שחורה יכול להיות חשוב לא פחות מהצד הטכני. בעת תכנון, צור רשימה קוהרנטית של דברים שיש לעשות שמסדרת מי בודק איזה חלק של התוכנה באיזה זמן ספציפי. זה מפחית בלבול, שחיקה פוטנציאלית ועיכובים עקב השתלטות על משימות אחרות.
· רשום תוצאות באופן מיידי
רשום כל אחת מהתוצאות שבדיקה מייצרת מיד. על ידי המתנה יותר מדי זמן עם בדיקות ידניות אתה יכול לזכור בעיות בצורה לא נכונה, כך שהערות מיידיות מגדילות את הדיוק באופן משמעותי.
· קשר עם מפתחים
שוחח על מסגרת הזמן והאסטרטגיה של הבדיקה שלך עם מפתחים כדי שיבינו מה קורה ומתי הם יכולים לצפות לעבוד על עדכונים חדשים. זה כולל קביעת תהליכים ברורים שבאמצעותם מחלקות מתקשרות זו עם זו.
· נתונים ניתנים לפעולה
בעת כתיבת דוח, ודא שכל הנתונים שאתה מספק עבור מפתח ניתנים לפעולה. זה עוזר לצוות לפתח מוצר שמגיב לבעיות שלו ולא למפתח שלא מבין את השינויים שהם צריכים לעשות.
· להבין את סדרי העדיפויות שלך
כצוות בדיקות, העדיפות שלך היא בסופו של דבר להבטיח שהחברה תשלח מוצר איכותי למשתמשים שלה. אם הבדיקה אורכת קצת יותר זמן מהצפוי, זכרו שזו תמורה כדאית לעלייה באיכות שהלקוח חווה.
· להכיר את ההיררכיה
בחברת פיתוח אידיאלית, המפתחים והבודקים נמצאים באותה רמה של ההיררכיה, עם אמירה חשובה לא פחות על האופן שבו התוכנה צומחת. הבן את האופן שבו ההיררכיה היא בארגון שלך ובקש לוודא שכולם מבינים את הערך של בדיקות טובות.
· שמור על תיעוד עקבי
שמור עותקים של כל הנתונים והדוחות שאתה מייצר בבדיקה שלך. אתה יכול לעקוב אחר השינויים באפליקציה שצוות הבדיקה אחראי עליהם בנוסף להסתכלות אחורה על באגים ישנים כדי לראות אם הם משוכפלים במהדורות עתידיות.
סיכום
בדיקת קופסה שחורה היא בסופו של דבר אחד החלקים החשובים ביותר בתהליך בדיקת התוכנה. זה עוזר לחברות לוודא שמה שהן שולחות הוא בסטנדרט הגבוה ביותר האפשרי ומנצל שינוי בפרספקטיבה כדי להציע תובנות ייחודיות לגבי הדרך שבה אפליקציה נתפסת ומיושמה על ידי משתמש חיצוני.
כל חברה שלא מצליחה להוסיף בדיקות קופסה שחורה, הן אוטומטיות והן ידניות, לתהליכים שלה, מחמיצה הזדמנות לשפר בצורה ניכרת את איכות היישום שלה. בדוק בצורה חכמה ותקצור את הפירות כאשר הלקוחות שלך יקבלו גישה למוצר שלך.
שאלות נפוצות ומשאבים
לא משנה כמה אתה יודע על בדיקת קופסה שחורה, ייתכן שיש לך שאלות נוספות ותרצה לקדם את הבנתך בשיטה. עיין בשאלות הנפוצות שלנו למטה כדי לקבל מידע נוסף על בדיקת קופסה שחורה ולגשת למגוון משאבים שיכולים לספר לך יותר על המתודולוגיה.
1. הקורסים הטובים ביותר ב-Black Box Test Automation
ישנם מספר קורסים בנושא אוטומציה של בדיקות קופסה שחורה שאתה יכול לעקוב אחריהם, שכל אחד מהם עוזר לאנשים להשיג סטנדרט אחר של בדיקות.
כמה מקורסי בדיקת הקופסה השחורה הנחשבים ביותר הזמינים כוללים:
· “Black-box and White-box Testing” מאת Coursera
· “סדרת בדיקות התוכנה של Black-Box” מאת BBST
· “מבוא לטכניקות בדיקת תוכנה ב-Black Box” מאת Udemy
· “בדיקות אוטומציה של תוכנה” מאת London School of Emerging Technology
· “שלוש טכניקות מפתח לבדיקת קופסה שחורה” מאת Udemy
2. מהן 5 שאלות הראיון המובילות ב-Black Box Testing?
בדיקות תוכנה הן תחום תחרותי ביותר, שרואה הרבה מועמדים המגישים מועמדות לכל משרה פנויה. אם אתה מבטיח ראיון למשרה בבדיקת קופסה שחורה, אלו הן כמה מהשאלות שאולי תרצה להכין כדי לענות עליהן בראיון:
· איזה ניסיון יש לך בעבודה עם בדיקות קופסה שחורה?
· מהם ההבדלים העיקריים בין בדיקת קופסה שחורה לבדיקת קופסה לבנה?
· האם יש לך ניסיון בעבודה עם אוטומציה של תוכנה בתפקידיך הקודמים?
· האם תוכל להודיע לנו על תקופה שבה חווית אתגרים במקום העבודה, וכיצד התגברת עליהם?
· מהו לדעתך העתיד של בדיקות הקופסה השחורה, וכיצד הכישורים שלך מתאימים לקריירה ארוכת טווח בבדיקות תוכנה?
3. מדריכי YouTube הטובים ביותר על בדיקת קופסה שחורה
YouTube הוא אחד ממשאבי הלמידה החשובים ביותר הזמינים לאנשים המגדילים את כישורי בדיקת התוכנה שלהם, מכיוון שהוא מספק מקור מידע חינמי שבו תוכל להשתמש כדי לפתח את הטכניקה שלך.
כמה מהמדריכים הטובים ביותר לצפייה כאשר אתה לומד בדיקת קופסה שחורה הם:
· “מבוא לבדיקת קופסה בשחור-לבן – Georgia Tech – תהליך פיתוח תוכנה” מאת Udacity
· “Black Box and Glass Box Testing” מאת MIT OpenCourseWare
· “7 טכניקות בדיקת קופסה שחורה שכל QA צריך לדעת” מאת The Testing Academy
· “בדיקת קופסה שחורה | מהי בדיקת קופסה שחורה | למד בדיקת קופסה שחורה” מאת Intellipaat
· “מהי בדיקות לבנה לעומת אפורה מול קופסה שחורה?” מאת ITProTV
4. כיצד לשמור על בדיקות קופסה שחורה?
שמירה על בדיקות קופסה שחורה, בין אם אלו בדיקות ידניות או אוטומטיות, היא עניין של לשים לב לבדיקות תוך כדי המשך ולחפש כל הזמן ליישם תיקונים אם יש בעיות.
זה כרוך לוודא שכל מקרי בדיקה פועלים כפי שאתה מצפה בכל פעם ובדיקה שכלים אוטומטיים עוברים את כל השלבים הנכונים. עשה זאת לעתים קרובות ככל האפשר על מנת למנוע החלקה מהסטנדרטים שלך, שכן בדיקת קופסה שחורה מתוחזקת היטב היא כזו שמחזירה את התוצאות המדויקות ביותר האפשריות.
5. הספרים הטובים ביותר על בדיקת קופסה שחורה
בעוד שבדיקות קופסה שחורות ובדיקות תוכנה בכללותן הן תחום שמתפתח כל הזמן, ישנם מספר ספרים שנשארים רלוונטיים ומציעים הרבה תובנות לגבי שיפור עבודת הבדיקה שלך.
כמה מהספרים הטובים ביותר על בדיקת קופסה שחורה כוללים:
· “בדיקת קופסה שחורה: טכניקות לבדיקה פונקציונלית של תוכנות ומערכות” מאת בוריס בייזר
· “בדיקות תוכנה: עקרונות ופרקטיקה” מאת Srinivasan Desikan, Gopalaswamy Ramesh
· “היסודות של בדיקות תוכנה” מאת ראלף ביריג, סטיבן בראון, אדגר גלבן
· “מבוא לבדיקות תוכנה” מאת פול עמאן, ג’ף אופט
