כאשר אתה עובד בבדיקות תוכנה, יש לשקול עשרות שיטות בדיקה שונות.
בדיקות תוכנה מסייעות למפתחים לחסל את כל הפגמים העשויים להתקיים בחבילת תוכנה כדי שיוכלו לשלוח מוצר העונה על הצרכים והציפיות של כל בעלי העניין. שימוש בפתרון הבדיקה הנכון מספק לך את כל הידע שאתה צריך, אך בחירת מבחן נכונה יכולה לקחת זמן.
בדיקת תיבה אפורה היא אחת מצורות הבדיקה המגוונות יותר הזמינות לבודקים, ומציעה שפע של תובנות מבלי לגבות משאבים מוגזמים.
למד עוד על מהי בדיקת קופסא אפורה, כמה מהפרטים של אופן הפעולה של בדיקת קופסא אפורה וכמה מהסיבות שחברות משתמשות בשיטת בדיקה זו.
מהי בדיקת תיבה אפורה?
בדיקת קופסה אפורה היא סוג של בדיקה המשלבת בדיקת קופסה לבנה ובדיקת קופסה שחורה, תוך שימוש בהבנה חלקית של העיצוב הבסיסי והדרך שבה המערכת מיושמת.
שילוב זה אומר שהבודק יודע חלק ממה שקורה ברקע מבלי לדעת את הקוד במלואו, מה שמספק יותר תובנה לגבי הגורמים הפוטנציאליים לבעיות בתוכנה כשהן מתעוררות.
השלמת בדיקות קופסא אפורה היא באחריות הבודקים, כאשר צוות אבטחת איכות פועל ללא תלות בצוות הפיתוח בפרויקט.
1. מתי ולמה אתה צריך לעשות בדיקת תיבה אפורה בבדיקות תוכנה?
יש כמה פעמים שחברות משתמשות בבדיקות קופסאות אפורות בתהליך הפיתוח.
לדוגמה, כאשר יישום צריך ליצור אינטראקציה עם כלי של צד שלישי כדי לפעול כהלכה, לבודקים אין גישה לקוד מקור שהוא חלק מהתוכנה החיצונית. זוהי מגבלה אכיפה על גישה לבודקי QA והופכת את הבדיקה לאפורה ללא צורך בבחירה.
2. כשאתה לא צריך לעשות בדיקת תיבה אפורה
יש כמה פעמים בתהליך הבדיקה שבדיקת קופסה אפורה אינה נחוצה, והראשונה שבהן היא בשלב מוקדם של תהליך הפיתוח.
בדיקות פונקציונליות מתרחשות כאשר מפתחים בודקים תחילה כדי לוודא שהקוד שלהם משלים את המשימות הבסיסיות יותר שלו, שיש לה שקיפות מלאה. מכיוון שאין קוד או תיעוד מוסתרים מהבודק, זה לא נחשב לבדיקת קופסה אפורה.
פעם נוספת שאינך זקוק לבדיקת קופסה אפורה היא בעת בדיקה ממש בסוף הפיתוח כאשר יש לך מוצר שלם. זה המקרה כאשר אתה גורם למשתמש הקצה לעזור בבדיקות והוא ידוע גם בשם “בדיקות בטא” או ” בדיקות מקצה לקצה “.
המשתמשים בודקים את האפליקציה ללא כל גישה לקוד או למסמכי עיצוב, במקום זאת לוקחים את התוכנה בזכות עצמה. זוהי צורה של בדיקת קופסה שחורה שכן התהליך אטום לחלוטין.
3. מי מעורב בבדיקת תיבה אפורה?
ישנם מספר אנשים ותפקידים המעורבים בבדיקות קופסא אפורה, כאשר כמה מהתפקידים החשובים ביותר בתהליך כוללים:
· מנהל QA:
מנהל QA, או מנהל אבטחת איכות, הוא חבר צוות בתהליך פיתוח התוכנה שאחראי על הקצאת משימות לצוות הבדיקות.
זה כולל יצירת מחזורים, בחינת דוחות והתמודדות עם קונפליקטים שמתעוררים בצוות.
· בודק:
בודק הוא איש מקצוע האחראי על השלמת מקרי הבדיקה המהווים חלק מתהליך בדיקת הקופסה האפורה.
זה דורש רמה גבוהה של תשומת לב לפרטים בעת כתיבת דוחות וריצה חוזרת של מקרי בדיקה מדויקים.
· מפתח:
המפתחים הם אנשי המקצוע האחראים על יצירת קוד והתאמתו בהתאם לתוצאות של בדיקות התיבה האפורה.
למרות שאלו אינם בהכרח מעורבים בבדיקה עצמה, הם מקבלים הודעות מבוחנים לגבי התוצאות.
· אנליסט QA:
תפקידו של אנליסט QA נפוץ בתהליכי בדיקה המשתמשים באוטומציה רבה. אנליסט כותב קוד מקרה מבחן לבדיקות אוטומטיות בנוסף לניתוח נתונים שהבדיקות חוזרות בסוף התהליך.
היתרונות של בדיקת תיבה אפורה
ישנם כמה יתרונות עיקריים בשימוש בבדיקת קופסא אפורה בעת בחינת תוכנה. על ידי ניצול המרב מהיתרונות הללו, אתה משפר את רמת היישום שלך לאורך זמן.
כמה מהסיבות שחברות משתמשות בצורת בדיקה זו כוללות:
1. הכרת מנגנונים פנימיים עוזרת לתכנן מבחנים
אחד היתרונות העיקריים של שימוש בבדיקת קופסא אפורה במקום העבודה הוא העובדה שאתה יודע על כמה מהמנגנונים הפנימיים באפליקציה. זה כרוך בהבנה של מה כל אחת מהפונקציות עושה ומהם מודולים מהמדף בהשוואה לקוד שנכתב בהתאמה אישית עבור חלק מהתכונות האחרות.
ידיעה על הפונקציונליות הפנימית פירושה שבודק מבין טוב יותר מה הוא בודק ויכול לכוון את הבדיקות הללו לעיצוב האפליקציה. חברות זוכות לתוצאות מדויקות יותר המייצגות את התוכנה בצורה נכונה.
2. מביא לפתרון מיידי של הבעיות
במקרים מסוימים, כאשר מתרחשת בעיה בבדיקה ולבודק יש גישה לקוד מאחורי הבעיה, יכול להיות פתרון מיידי לבעיה.
זה מנוגד למתודולוגיית בדיקת קופסה שחורה, שבה בודקים לא יכולים לראות שום קוד מאחורי הקלעים של התוכנה שהם בודקים. על ידי ראיית הקוד, בודקים בעלי ניסיון רב בפיתוח יכולים להצביע למפתחים על מה בדיוק הבעיה וכיצד עדכון עתידי יכול לפתור אותה.
בדיקת תיבה אפורה חוסכת זמן רב שאחרת היה מושקע בחקירת נושאים ומסייעת לחברות לבלות את זמנן ביעילות רבה יותר.
3. הפרדת בודקים ומפתחים
שימוש בבדיקת קופסה אפורה מותיר הפרדה ברורה בין מפתחי האפליקציה לבין האנשים הבודקים את התוכנה.
הסיבה לכך היא שהשלמת בדיקת קופסה אפורה מסתמכת על בודקים שאין להם ידע קיים על אופן פעולת התוכנה, כאשר המרחק בין השניים הופך הכרח לתוצאות בדיקה מדויקות יותר שאינן מושפעות מהטיה.
בודקים בתרחישי קופסה אפורה נמצאים בצוות שונה לחלוטין מהמפתחים, ומציעים מידע מדויק מבלי שצפיות קיימות ישפיעו על הפלט שלהם.
מפתחים גם נהנים מכך מכיוון שהם מקבלים פרספקטיבה ביקורתית יותר על עבודתם, ועוזר להם לשפר הן את האפליקציה הקיימת והן את כישוריהם לעתיד.
אתגרים של בדיקת תיבה אפורה
ישנם כמה חסרונות עיקריים לשימוש בבדיקת קופסא אפורה בעבודת הפיתוח שלך.
על ידי הבנת החסרונות הללו ועבודה לצמצום בכל מקום אפשרי, אתה מגדיל את הסטנדרט הכולל של העבודה שלך בסוף שלב ה- QA .
כמה מהחסרונות העיקריים של בדיקת קופסא אפורה כוללים:
1. פוטנציאל שלא נראה קוד
בדיקת תיבה אפורה פירושה שיש כמה היבטים של הקוד המוסתרים מהבודק, ובמקרה של בעיות כלשהן המתעוררות בבדיקה זה יכול להוביל לבעיות נוספות.
עם קוד בלתי נראה, חברי הצוות המעורבים בבדיקה נאבקים להנחות את הבדיקות שלהם כדי להפיק את המרב מהאפליקציה ומאבדים את היתרון מלראות את הגורם לבעיה מיד.
תהליך תיקון הבאגים הופך מעורפל יותר, מה שמוביל לכך שזמני עדכון ארוכים יותר הופכים להיות הכרח וחברות מתקשות למצוא את הבעיות בקוד שלהן.
מוצרי קצה יכולים להיות בעייתיים יותר וברמה נמוכה יותר כתוצאה מהקוד הבלתי נראה הזה.
2. בדיקות עלולות להיות לא מדויקות אם הפעולות נכשלות
ביצוע בדיקות מדויקות הוא חובה בכל צורה של בדיקות תוכנה, עם דרגת דיוק גבוהה יותר המפנה צוותים לעבר עדכונים שהם יכולים להשלים בגרסאות עתידיות, בנוסף לעזור לצוות פיתוח להיות בטוח יותר במוצרים שלהם.
דיוק זה מצטמצם כאשר פעולות נכשלות בבדיקת קופסה אפורה. בודקים פשוט מקבלים הודעת “הפעולה נכשלה” מהתוכנה אם אין להם גישה לקוד, מה שמונע מהם להציע משוב על אופן הביצוע שלו.
כדי לקבל מדדים מועילים, מפתחים צריכים לתקן את התוכנה לפני השלב הבא של הבדיקה. אחרת, כל מה שבודק יכול לעשות הוא לציין שהתכונה לא עובדת בצורתה הנוכחית.
3. מאבקים במערכות מבוזרות
מערכות מבוזרות מתייחסות למערכות תוכנה שמתארחות במספר מקומות שונים, או הנשענות על תכונות כגון שירותי עיבוד נתונים ועיבוד בענן.
זה מקשה מאוד על הבדיקות, מכיוון שחלק ניכר מהתוכנה מוסתרת מאחורי גוף צד שלישי כשהבודקים פשוט מקבלים פלט מתהליך לא ידוע.
כאשר מתרחשות בעיות בתוכנה שעושה שימוש במערכות של צד שלישי, יכול להיות קשה לקבוע אם הבעיה היא באפליקציה עצמה, בפונקציונליות של צד שלישי, או בדרך שבה השתיים משתלבות, במיוחד כאשר בודק יכול. לא רואה את הקוד כפי שהוא עובד.
מאפיינים של מבחני תיבה אפורה
ישנם כמה מאפיינים שמבחני קופסה אפורה חולקים זה עם זה, כאשר זיהוי מבחנים אלה עוזר לך להכין אסטרטגיה עבור הארגון שלך.
כמה מהדוגמאות העיקריות למאפייני בדיקת קופסה אפורה, בנוסף לאופן שבו מאפיינים אלה הם חלקים חשובים בתהליך בדיקת הקופסה האפורה, כוללות:
· כיסוי מוגבר:
גישה לחלק מקוד המקור מספקת מידה רבה יותר של כיסוי בבדיקות, כאשר פרטים נוספים מציעים איתור באגים מדויק יותר.
· זרימות נתונים:
מבחני קופסה אפורה רבים מדגישים את זרימת הנתונים והבנה כיצד מידע עובר במערכת.
· לא אלגוריתמי:
בדיקת תיבה אפורה לא עובדת בעת בחינת אלגוריתמים, מכיוון שזוהי רמה נוספת של ערפול לקוד.
מה אנחנו בודקים במבחני תיבה אפורה?
כל סוג אחר של בדיקה מוגשת בצורה הטובה ביותר כאשר ממקדים לחלקים ספציפיים של התוכנה המדוברת. אותו הדבר חל על בדיקות קופסא אפורה, כאשר המתודולוגיה שימושית ביותר בחלקים ייחודיים של אפליקציה.
כמה דוגמאות למה שבודקים מעריכים בעת השלמת מבחני קופסה אפורה כוללות:
1. אבטחת יישומים
מבחני קופסה אפורה הם אידיאליים לבדיקות חדירה הבודקות את האבטחה של אפליקציה. בודקים יכולים לראות את כל הקוד ולחפש נקודות תורפה אפשריות בתהליך.
האקרים אתיים הם בודקים אידיאליים לבדיקת אבטחת יישומים, מכיוון שהם מזהים חולשות ופגמים פוטנציאליים בתוכנה באופן טבעי יותר מאלה שאין להם ניסיון בהפרת אבטחת תוכנה.
2. בדיקת מסדי נתונים
חברות רבות משתמשות בבדיקת קופסה אפורה לבדיקת מסדי נתונים, מכיוון שניתן לעקוב אחר הנתונים דרך כל תת-פונקציה בתוכנה.
בודקים יכולים לראות את כל השינויים שהתוכנה מבצעת ולהעריך אם הם נכונים.
זהו יישום שימושי של בדיקות קופסאות אפורות שכן בדיקות מסד נתונים ניתנות לחיזוי מטבען, כאשר חברות משתמשות בבסיסי נתונים כדי לארגן מידע קיים במקום לייצר נתונים חדשים.
3. יישומי אינטרנט
יישומי אינטרנט נהנים מהשימוש בבדיקת קופסא אפורה בשל הרבגוניות של שיטת הבדיקה.
ניתן להשתמש במבחני תיבה אפורה עבור אבטחה, מסד נתונים, אינטגרציה , ממשק משתמש ובדיקות דפדפן, שכל אחד מהם הוא היבטים מרכזיים של יישומי אינטרנט .
אין צורך לשנות מתודולוגיות בדיקה באמצע הדרך, כך שאתה מרוויח מרמה גבוהה יותר של המשכיות.
מנקה קצת בלבול:
תיבה אפורה לעומת קופסה לבנה לעומת בדיקת קופסה שחורה
בדיקת קופסה אפורה היא סוג של בדיקה הדומה לבדיקת קופסה לבנה וגם לקופסה שחורה, מה שאומר שיש פוטנציאל רב לבלבול בין המתודולוגיות.
גלה עוד על מהן בדיקות קופסה לבנה ושחורה וכמה מההבדלים המהותיים בין אלה לבין בדיקות קופסא אפורה בפיתוח תוכנה:
1. מהי בדיקת קופסה לבנה?
בדיקת קופסה לבנה היא סוג של בדיקת אפליקציה המספקת לבודק מידע מקיף על האפליקציה.
זה כולל גישה מלאה לקוד המקור ולכל מסמכי העיצוב של התוכנה, מה שמספק לבודק הבנה הרבה יותר טובה של אופן פעולת התוכנה.
בודקים משתמשים בהבנה זו כדי לראות יותר מהבעיות הקיימות באפליקציה, ומדווחים על פרספקטיבה מדויקת יותר של אופן הפעולה של האפליקציה עבור המשתמשים.
דוגמה לשימוש בבדיקת קופסה לבנה היא לראות את הזרימה של קלט נתונים ספציפי דרך אפליקציה כדי לראות היכן מתרחשת בעיה בתהליכי האפליקציה, במקום פשוט לראות אם יש בעיה או לא.
יש כמה פעמים בתהליכי הפיתוח שבהם חברות משתמשות בבדיקת קופסה לבנה.
הראשון שבהם הוא בעת השלמת בדיקת יחידה , אשר מעריכה אם כל פיסת קוד או מודול בנפרד בחבילת תוכנה עושה את העבודה שהמפתח מצפה לה.
בדיקת יחידות עוזרת לבודקים למצוא את רוב הבעיות באפליקציה, מכיוון שהיא בוחנת את כל הפונקציונליות באפליקציה.
בדיקת קופסה לבנה עוזרת גם במציאת דליפות זיכרון. על ידי בחינת כל הקוד בפירוט, אנליסט QA מוצא היכן האפליקציה משתמשת בזיכרון של המכשיר ובאזורים פוטנציאליים שבהם היא משתמשת יותר מדי.
זה עוזר לאפליקציה לפעול בצורה מהירה ויעילה יותר באיטרציות עתידיות שכן דליפת הזיכרון מקבלת תיקון בהקדם האפשרי.
מה ההבדלים בין מבחני קופסה אפורה ל-White Box Tests?
ישנם כמה הבדלים עיקריים בין מבחני קופסה לבנה ובין מבחני קופסה אפורה, כאשר רמת המידע שיש למישהו גישה אליו היא השינוי הראשון.
לבדיקת הקופסה הלבנה יש גישה מלאה לקוד המקור ולמסמכי העיצוב של התוכנית, בעוד שלבדיקת התיבה האפורה יש גישה חלקית רק לחלק מהמידע הזה, בעיקר למסמכי עיצוב.
השינוי הזה אומר שיש הבדל גם באנשים שמסיימים את הבדיקות, כאשר המפתחים עצמם אחראים בעיקר על בדיקות הקופסה הלבנה.
לעומת זאת, בדיקת התיבה האפורה היא באחריותו של צוות QA, מכיוון שהבודקים אינם יכולים להיות בעלי ידע אינטימי של הקוד.
בדיקת קופסה אפורה גם לוקחת פחות זמן מבדיקת קופסה לבנה. בדיקת הקופסה הלבנה היא מקצה לקצה ובודקת הן את צד המשתמש של התוכנה והן את הקוד עצמו. זה לוקח הרבה יותר זמן להשלים וזה אומר שתהליך בדיקת קופסה אפורה הוא דרך הרבה יותר מהירה קדימה.
עם זאת, לקופסה הלבנה יש יותר פוטנציאל לאוטומציה, מכיוון שהבודקים יודעים כיצד הקוד הפנימי פועל.
2. מהי בדיקת קופסה שחורה?
בדיקת קופסה שחורה מתייחסת לזמן שבו בודק בוחן חבילת תוכנה מבלי שיש לו הבנה קיימת של הדרך שבה המערכת פועלת.
המשמעות היא שאין גישה לאף אחד מהקודים שמהווים חלק מהאפליקציה או לאף אחד ממסמכי העיצוב או התקצירים הזמינים. לבודקים פשוט יש רשימה של תכונות שהם בודקים וסדרה של מקרי בדיקה להשלים.
דוגמה לבדיקת קופסה שחורה היא בדיקות מקצה לקצה, שבהן בודק מקבל את חבילת התוכנה השלמה ובודק את האפליקציה כולה כדי לוודא שהפונקציונליות פועלת כפי שהיא תוכננה.
רוב מקרי הבדיקה האידיאליים לבדיקת קופסה שחורה הם אלה שלקראת סוף תהליך ומערבים לקוחות ונקודת המבט שלהם על מוצר, עם חוסר גישה לקוד המונע כל הטיה המשפיעה על השקפת המשתמש.
חברות משתמשות בבדיקת קופסה שחורה בעיקר לאחר השלמת כל בדיקות התפקוד באפליקציה. עם סיום כל בדיקות היחידה ובדיקות הפונקציות, מפתחים מבינים שהאפליקציה פועלת כפי שהם מצפים, לפחות כשכל המודולים עובדים בבידוד.
בדיקת הקופסה השחורה מבטיחה שהאפליקציה הכוללת עובדת כצפוי לאחר הקומפילציה, כאשר תיאורטית כל קוד המקור כבר תקין.
מה ההבדלים בין בדיקת קופסה אפורה לבדיקת קופסה שחורה?
ההבדל העיקרי בין בדיקת קופסה אפורה לבדיקת קופסה שחורה הוא כמות הגישה שהבודק מקבל למידע.
במקרים מסוימים, בודק קופסה שחורה יכול לגשת לאפליקציה מבלי שיהיה לו ידע מוקדם על התוכנה כלל, פשוט לעבור את תהליך הבדיקה ולהשתמש בתוכנה כפי שמשתמש רגיל עשוי.
מצד שני, לבודק קופסה אפורה יש גישה לחלק ממסמכי העיצוב ולכן הוא יכול להשוות את מה שהאפליקציה אמורה לעשות עם הביצועים האמיתיים שלה, ולספק למפתחים משוב לגבי חלקים ספציפיים של האפליקציה שאינם עומדים בתקן.
הבדל נוסף הוא משך הזמן שנדרש כדי לפתור בעיה, כאשר בדיקות קופסה אפורות לוקחות קצת יותר זמן.
הצלבת תיעוד וקוד עם האופן שבו אתה חווה את האפליקציה עשויה להימשך זמן מה, מה שמנוגד לדרך שבה פועלים בוחני הקופסה השחורה פשוט על ידי בחינת האפליקציה עצמה יחד עם בעיות פונקציונליות כלשהן. שילוב זה הופך את בדיקת הקופסה השחורה לתהליך אידיאלי לשימוש ממש בסוף תהליך הפיתוח בעת הכנה לשחרור המוצר, כאשר הקופסה האפורה פועלת טוב יותר כשאתה בשלב הפיתוח והקומפילציה של ממשק המשתמש.
3. מסקנה: בדיקת קופסה אפורה לעומת White Box לעומת Black Box
לסיכום, בדיקת קופסה לבנה, קופסה אפורה וקופסה שחורה הם כולם חלק מאותו ספקטרום, שבו הגורם המשתנה הוא רמת הגישה שיש לבודק לאורך כל התהליך.
ככל שצורת בדיקה הופכת “שחורה” יותר, הבדיקה הופכת אטומה יותר והגישה למידע מאחורי התוכנה מוגבלת.
בדיקת הקופסה הלבנה היא אידיאלית לשלבים המוקדמים ביותר של התהליך, כאשר בדיקת הקופסה השחורה מצטיינת לשלבים כמו בדיקות מקצה לקצה שבוחנת את האפליקציה כולה מנקודת המבט של המשתמש.
בדיקת הקופסה האפורה פועלת כאמצעי בין שני המושגים, ועוזרת למצוא בעיות לאורך אמצע תהליך הפיתוח על ידי מתן תובנה רבה יותר תוך שמירה על חלק מקוד המקור מעורפל מהבודק.
טכניקות בדיקת קופסה אפורה
בדיקת תיבה אפורה כוללת מגוון רחב של טכניקות, שכל אחת מהן מעלה את רמת הבדיקות, מוצאת באגים נוספים למפתח ומובילה למוצר שלם יותר בסוף התהליך.
כמה מהטכניקות הנפוצות ביותר לבדיקת קופסאות אפורות בהן משתמשים צוותי QA כוללות:
1. בדיקת מטריקס
בדיקת מטריקס בוחנת את דוח המצב של הפרויקט שנמצא בתהליך. זה כולל מצב PASS/FAIL פשוט במקרים מסוימים, כאשר תהליכים מתמשכים מספקים פרטים נוספים על אופן הפעולה של התהליכים ברציפות.
כאשר בדיקות רבות מתמקדות בכניסות ובפלטים של קטע קוד, בדיקת מטריצה בוחנת את מצב התהליכים עצמם ולא את התוצאות של התהליכים האמורים.
שימוש בבדיקות מטריצות מספק התמקדות רבה יותר באפליקציה עצמה, ועוזר למצוא באגים ובעיות גם אם הפלטים נראים נכונים.
2. בדיקת רגרסיה
בדיקות רגרסיה קיימות כדי לבדוק את התוכנה לאחר מתרחשת סדרה של עדכונים. זה כולל בדיקות פונקציונליות ולא פונקציונליות המבטיחות שהאפליקציה עדיין עובדת ברמה גבוהה מספיק ככל שהקוד משתנה.
בודקים המשתמשים בבדיקות רגרסיה משתמשים בדרך כלל באוטומציה, שכן מבחני רגרסיה גדלים בהיקפם ככל שצוות אבטחת האיכות מוצא יותר ויותר פגמים.
בדיקה ידנית היא הכרח במקרים מסוימים, עם זאת, עם חברות שבודקות את ממשק המשתמש באמצעות בדיקות ידניות כדי לראות כיצד משתמש אנושי מגיב לשינויים שנעשו בתפריטים, כפתורים ואפשרויות ניווט.
3. בדיקת דפוסים
בדיקת דפוס היא צורת בדיקה המתמקדת במעקב אחר דפוס מסוים בכל מבחן שארגון משלים.
צוותי בדיקה מתכננים את הבדיקות הללו כדי למקד לכל תכונה של התוכנה, כאשר כל בדיקה מספקת רמה עקבית של מידע לחברה בנוגע לאופן שבו תכונות בודדות פועלות.
שימוש בבדיקת דפוסים מסתמך לפעמים על שינוי הדפוס ככל שעובר הזמן כדי לוודא שאתה שופט כל אחת מהמערכות הפועלות, אבל ברגע שיש לך דפוס שעובד, הימנע מסטייה כדי לספק יותר עקביות בתוצאות שלך.
4. בדיקת מערך אורתוגונלי
בדיקת מערך אורתוגונלי היא בעיקר טכניקת בדיקה מכוונת קופסה שחורה, המתרחשת כאשר הבודקים משתמשים במספר משמעותי של כניסות גדולות מכדי לבדוק באופן ממצה כל מערכת בודדת בתהליך.
במקרים אלה, כל פיסת מידע אינדיבידואלית מספקת פיסת מידע ייחודית משלה בשל חוסר מתאם פוטנציאלי בין חלקי מידע ספציפיים. זהו ההיבט האורתוגונלי של המערכת, כאשר פיסות מידע ייחודיות משמשות כדי לספק את רמת הנתונים המקסימלית תוך השקעת מאמץ מינימלי.
זמן הבדיקה מצטמצם, ויש לך איזון אידיאלי של נתונים לספק לצוות פיתוח.
בדיקת קופסה אפורה במחזור החיים של הנדסת תוכנה
בדיקת תיבה אפורה נופלת לשלב מסוים של מחזור החיים של הנדסת תוכנה. מחזור חיים זה הוא סדרה מורכבת של שלבים שחברות עוקבות אחריהם בעת פיתוח המוצרים שלהן, כאשר כל שלב מוביל לסטנדרט גבוה יותר של מוצר.
בעוד שבדיקה היא חלק מהתהליך המתרחש ללא הרף, יש זמן מוגבל מאוד לבדיקת קופסא אפורה.
זה מתרחש לאחר השלמת הפונקציונליות הראשונית ונבדקת באמצעות בדיקת קופסה לבנה ולפני שהתוכנה מוכנה לפרסום פומבי, כאשר חברות מעדיפות בדיקת קופסה שחורה בשלבים האחרונים.
תיבה אפורה היא הכלי המושלם לשילוב תכונות יחד ולהבטיח שהן פועלות כראוי במקביל בנוסף לאופן עצמאי.
בדיקות תיבה אפורה ידניות או אוטומטיות?
כמו בכל צורה של בדיקות תוכנה, צוותי אבטחת איכות בוחרים בין השלמת הבדיקות שלהם באופן ידני באמצעות אנשי צוות מומחים או אוטומטית, הכוללת קידוד של סדרה של מקרי בדיקה והשלמתם שוב ושוב כדי להבטיח סט מדויק של תוצאות.
למד עוד על בדיקות ידניות ואוטומטיות, עם כמה מהיתרונות והאתגרים של כל אחת מהן, בנוסף לאיזו משתי צורות הבדיקה היא אידיאלית עבור חברה שרוצה להבין טוב יותר את הבעיות במוצר שלה.
בדיקת קופסה אפורה ידנית – יתרונות, אתגרים, תהליך
בדיקה ידנית היא חלק בסיסי בהרבה סוגי בדיקות, כולל בדיקות קופסא אפורה.
תהליך זה כולל לגרום לבודקים אנושיים לבחון תוכנה, לבחון אם התוכנה פועלת כפי שאתה מצפה, ולהשוות אותה עם מסמכי העיצוב והקוד הקיימים, שגלויים כדי לבדוק אם יש פגמים ברורים במידע הזה שיכולים לגרום לבעיות.
מקרים שבהם בדיקה ידנית נפוצה כוללים תוכנות מסובכות יותר הדורשות מאדם לספק תובנה איכותית.
שימושים אחרים כוללים חברות קטנות יותר המעוניינות להעריך ביסודיות את התוכנה שלהן, שכן יישומים וחבילות קטנות דורשות משאבים מועטים יחסית לחברות להעריך בהשוואה לתוכניות גדולות יותר המיוצרות על ידי עסקים גדולים יותר.
1. היתרונות של בדיקת קופסה אפורה ידנית
ישנם מספר יתרונות של בדיקת קופסה אפורה ידנית עבור כל פיסת תוכנה. הכרת היתרונות הללו פירושה שאתה יכול לכוון את הבדיקות שלך אליהם, לגלות בעיות נוספות בתוכנה שלך ולהגביר את רמת העבודה שלך הודות למשטר בדיקות טוב יותר.
היתרונות העיקריים של בדיקת קופסה אפורה ידנית הם:
משוב מפורט
היתרון הגדול הראשון של שימוש בבדיקות קופסאות אפורות ידניות הוא שבודקים אנושיים יכולים לספק רמה משמעותית של משוב למפתח.
בעת שימוש בבדיקות אוטומטיות, מקרי בדיקה מתוכננים לייצר מדי פעם מדדים מאוד ספציפיים שנותנים לאנליסטים תובנה מתי יש להם זמן להעריך את הנתונים.
זה שונה במקצת כשמשתמשים בבדיקה ידנית, שכן בודק יכול לספק משוב יסודי יותר על התכונה הספציפית שלא עבדה ועל הסיבות הפוטנציאליות לבעיה לאחר השוואתה לתיעוד התכנון.
שימוש במדריכי משוב מפורטים לא רק מעדכן את התכונות הקיימות אלא תכונות חדשות פוטנציאליות שעליהן ממליץ בודק למשתמשים.
פרשנויות טובות יותר
בדיקה אוטומטית פירושה שכל מסקנות הן עניין של הערכת הנתונים שאתה מקבל ממבחן והגעה למסקנה רציונלית לגבי המשמעות של זה עבור התוכנה.
להיפך, לבודקים ידניים יש רמה הרבה יותר גבוהה של תובנה לגבי הדרך שבה האפליקציה עצמה פועלת.
הם יכולים להשוות את קוד הקופסה האפורה למה שקורה בזמן אמת, ולבצע הערכה מדויקת באותו הרגע במקום לבצע ניכויים לאחר מעשה.
פלטפורמות אוטומציה מסוימות יכולות לפעול באופן דומה על ידי הפעלת תכונה חוזרת, אך הדבר עדיין דורש התערבות ידנית.
בדיקה גמישה
אוטומציה של בדיקות כוללת קידוד מקרי בדיקה מאוד ספציפיים לפלטפורמה, מה שאומר שהתוכנה משלימה את מערך המשימות הספציפי הזה שוב ושוב.
למרות שזה אידיאלי לחזרות, זה מציג אתגר ייחודי בכך שאין גמישות בבדיקה.
שימוש בבודק אנושי הוא אידיאלי במקרים אלה, ומוסיף יותר גמישות לתהליך. אם בודק אנושי מבחין בבעיה פוטנציאלית שנמצאת מעט מחוץ למקרה בדיקה מוגדר צר, הוא יכול לבחון אותה ולדווח על התוצאות בסוף התהליך.
זה מספק לחברות כיסוי מקיף יותר של התוכנה, ומגלה באגים שמערכת אוטומטית לא יכולה.
2. אתגרים של בדיקת קופסה אפורה ידנית
בעוד שיש הרבה יתרונות לשימוש בבדיקות ידניות בתהליך פיתוח התוכנה שלך, יש גם כמה חסרונות. אלה משתנים בהתאם לכמה גורמים, כולל התוכנה הספציפית עליה החברה עובדת, גודל צוות הפיתוח וסטנדרט הכישורים שיש לחברי צוותי הבדיקה והפיתוח.
אתגרים משמעותיים בבדיקה ידנית כוללים:
עלויות עבודה גבוהות
עלויות העבודה הן חלק מההוצאות המשמעותיות ביותר שעוברת כל חברה, שכן משתלם להשיג את הצוות הטוב ביותר שזמין כדי שהחברה תוכל לשפר את רמת העבודה שלה.
מכיוון שבדיקה ידנית של קופסה אפורה יכולה לקחת הרבה זמן, החברה צריכה לשלם לבודקים שלה כדי לעבוד לאורך כל התהליך. עבור כמה מהיישומים הגדולים ביותר, זה יכול לקחת שעות ולגרום לעלות של בודקים ידניים לעלות.
מפתחים יכולים לחפש למתן את הבעיה על ידי איזון אוטומציה של בדיקות קופסאות אפורות עם בדיקות ידניות או קיצוץ בעלויות העבודה השעתיות, אבל זה מסתכן בירידה באיכות הבדיקות.
טעות אנוש
בדיקה אוטומטית משלימה תהליכים פשוטים ביעילות, וחוזרת עליהם ברמת דיוק גבוהה באופן שאדם לא יכול.
בני אדם עושים טעויות וטעויות קלות, שיכולות להיות תוצאה של כל דבר, החל מלחיצה בטעות על הכפתור הלא נכון ועד להחלקת תשומת הלב למשך מספר שניות.
שגיאות מסוג זה עלולות להוביל לנתונים לא מדויקים ולגרום למפתחים למקד את תשומת לבם בחלק הלא נכון של התוכנה, לגזול זמן פיתוח יקר ולהחמיר את המוצר.
חפש לפתור זאת על ידי השלמת בדיקות גרייbox חוזרות בכל מקום אפשרי כדי לאמת את התוצאות שלך ככל שהבדיקה נמשכת.
לוקח הרבה זמן
כאשר מחשבים יכולים לבצע משימות ברגע, אנשים לוקחים קצת יותר זמן.
זה נובע מכל דבר, החל מזמני תגובה ועד פשוט לעבוד לאט יותר מהמהירות האופטימלית שלהם בנקודות, כל אלה מאטים את תהליך הבדיקה.
תהליך בדיקה איטי יותר פירושו פחות זמן עבור צוותי הפיתוח לעבוד על ביטול באגים ופגמים מהמוצר, שכן כל הזמן עובר למציאת הבעיות מלכתחילה.
זה לא משהו שקל למתן, כאשר משטר בדיקות היברידי כמו איזון בדיקות ידניות עם בדיקות קופסא אפורה אוטומטיות הוא פתרון פוטנציאלי אחד.
תיבה אפורה מבחן אוטומציה – יתרונות, אתגרים, תהליך
אוטומציה של בדיקות מתייחסת לתהליך השימוש בפלטפורמת אוטומציה כדי להפוך חלק מהחלקים של תהליך בדיקת הקופסה האפורה לאוטומטית.
התהליך פועל על ידי בקשת מתכנני בדיקות ליצור סדרה של מקרי בדיקה עם מנתחי QA או אנשי מקצוע דומים המקודדים את הבדיקות הללו לתוך תוכניות האוטומציה, כאשר חלקם משתמשים באוטומציה רובוטית של תהליכים ככלי נוסף.
במקרים אלה, אנליסטים של QA כבר מבינים חלק מהקוד או מסמכי העיצוב.
סוג זה של בדיקות נפוץ יותר בחבילות תוכנה גדולות בהרבה, מכיוון שלבודקי קופסאות אפורות אין את הזמן לבדוק את כל ההיבטים של התהליך באופן ידני.
לאחר תהליך אוטומטי, הפלטפורמה מחזירה דוח עבור מנתח ה-QA, ומציין היכן יש כשלים וסדרה של מדדים חשובים.
1. היתרונות של בדיקת קופסא אפורה אוטומטית
ישנם כמה יתרונות ברורים של שימוש בבדיקת קופסא אפורה אוטומטית בתהליכים של צוות אבטחת איכות.
על ידי התמקדות ביתרונות אלו והפקת המרב מהם, חברה יכולה להגביר את האפקטיביות של בדיקות הקופסה האפורה שלה ולפתור כמה שיותר בעיות בשלב זה בתהליך העבודה.
כמה מהיתרונות העיקריים של שימוש באוטומציה בעבודת בדיקת הקופסה האפורה שלך כוללים:
בדיקה מהירה
מערכות אוטומטיות נועדו לבדוק במהירות להפליא, לעבור סדרה של תהליכים מהר ככל האפשר. יתרון זה הופך בולט עוד יותר בעת השלמת בדיקות חוזרות של קופסא אפורה, מכיוון שכל ריצה בודדת לוקחת פחות זמן.
משך הזמן שאתה חוסך מהרצה להפעלה גדל באופן משמעותי, כאשר לחברה שלך יש הרבה יותר זמן להשלים משימות דחופות כמו עדכון התוכנה עצמה ומתן משוב ללקוחות וללקוחות פוטנציאליים.
ביצוע בדיקות מהירות יותר שימושי במיוחד כאשר עובדים לאחר ההפצה, שכן דחיפה של תיקוני פונקציונליות בהקדם האפשרי היא הכרחית לשיפור הדרך שבה אנשים רואים את העסק.
מדדים מדויקים
מדדים הם חלק משמעותי מהדרך שבה פועלת בדיקות תוכנה, ומספקות מידע מספרי לבוחן כדי לציין בעיות אפשריות.
מחשבים ופלטפורמות אוטומציה מציעות מדדים מדויקים ביותר, כאשר דברים כמו זמני תגובה נמדדים עד אלפית השנייה.
משמעות המדדים המדויקים יותר היא שתוכל לעקוב אחר תזוזות קטנות באופן שבו האפליקציה פועלת, מה שעוזר לך להבין אם עדכון שיפר את הביצועים או הוביל לכך שזרימות עבודה סטנדרטיות לוקחות יותר זמן.
עלויות מופחתות
אחת העלויות הגדולות ביותר של בדיקה בהגדרת תוכנה לפיתוח קופסה אפורה היא זו של בודקי הקופסה האפורה עצמם.
העסקת מומחי בדיקות תוכנה היא יקרה, במיוחד כאשר אתה מחפש בודקי קופסה אפורה, הדורשים מגוון גדול יותר של מיומנויות, כדי לספק את הסטנדרטים הגבוהים ביותר האפשריים עבור הארגון שלך.
אוטומציה פירושה שיש פחות אנשים שמשלימים בדיקות קופסא אפורה ידניות, מה שמבטל הרבה עלויות כוח אדם מהתהליך.
בעוד שלפלטפורמות אוטומציה יש כמה עלויות, שרובן גובות מנוי על בסיס חודשי, זה הרבה יותר נמוך מהצורך לשלם לעובדים שיעשו את העבודה בשבילך.
2. אתגרים של בדיקת קופסה אפורה אוטומטית
יש הרבה אתגרים לשימוש באוטומציה בתהליכי בדיקת הקופסה האפורה שלך.
בעוד שארגונים מסוימים מתמקדים ביתרונות, יש הרבה יתרונות להכיר את האתגרים של בדיקות קופסאות אפורות ולהתייחס אליהם תוך כדי עבודה.
אתה יכול ליישם בדיקות קופסא אפורה בצורה שתמנע את האתגרים ומונעת ממך להיאבק במגבלות קדימה.
האתגרים העיקריים של בדיקת קופסא אפורה אוטומטית הם:
הגדרה ראשונית
הגדרה ראשונית היא אחד האתגרים הגדולים ביותר בתהליך האוטומציה. הכוונה היא לזמן שלוקח למעבר לפלטפורמת בדיקות חדשה, כולל התקנת הפלטפורמה, לימוד משתמשים כיצד לעסוק בה וקידוד בדיקות מוקדמות בתוכנה.
כל זה הוא זמן לא פרודוקטיבי שחברה תרצה להגביל ככל האפשר.
שימוש בתוכנת אוטומציה פרימיום עם מומחים בהישג יד כאשר אתה צריך הוא אידיאלי במקרה זה, מכיוון שיש לך תמיכה של צד שלישי המוודא שאוטומציית הקופסה האפורה שלך, וסוגים אחרים של בדיקות לעניין זה, יעברו בצורה חלקה מההתחלה.
דרישות מיומנות גבוהות
למרות שבדיקות ידניות דורשות רמות גבוהות של מיומנות, אנליסטים של QA שעובדים עם אוטומציה עדיין צריכים להיות בעלי רמה גבוהה של מיומנות.
זה מגיע בצורה של כישורי קידוד, המשמשים בעיקר ליצירת מקרי מבחן ולקריאת הקוד הזמין בתרחיש הקופסה האפורה.
מפתחים יכולים להפחית זאת על ידי שכירת בודקים ספציפית שיש להם ניסיון בפיתוח או שעבדו עם פרויקטי קידוד בעבר. אתה מגביל את זמן ההכשרה במקום העבודה ומבטיח שלכל שכירה חדשה יש את היכולת להסתגל לדרישות של בדיקות אוטומטיות בקופסה אפורה.
חברות מסוימות שואפות להשתמש במערכת אוטומציה ללא קוד כדי לבצע בדיקות קופסא אפורה כחלופה, אך זה יכול להוביל לגמישות פחותה במקום העבודה.
פיקוח מתמיד
בדיקות אוטומטיות קיימות חלקית כדי להוריד את הדגש מהסתמכות על אנשים, כאשר לבדיקות ידניות יש מעורבות אנושית מתמדת בתהליכים.
זה לא אמור להיות המקרה עם אוטומציה של בדיקות, אבל לחברות עדיין יש צורך ברמת פיקוח טובה.
פיקוח כולל בחינת התוצאות של מבחני הקופסה האפורה ותחזוקתן כדי לוודא שהכל עדיין עובד כפי שהמפתח מצפה.
חברות יכולות לעזור לשפר את רמת הפיקוח הזמינה בכמה דרכים, כאשר איש מקצוע יחיד אחראי לפיקוח על בדיקות הוא אידיאלי.
זה מוביל לרמה גבוהה יותר של התמחות, כאשר אותו חבר צוות הופך לבוחן מומחה לקופסאות אפורות בעבודה עם אוטומציה בצורה מהירה ויעילה יותר.
מסקנה: תיבה ידנית או אפורה בדיקת אוטומציה?
לסיכום, לבדיקת קופסה אפורה ידנית ולבדיקה אוטומטית יש את מקומם בתהליך בדיקת התוכנה.
חברות קטנות יותר וסטארטאפים נהנים מהטמעת בדיקות ידניות בתיבה אפורה כאשר הקוד שלהן קטן יחסית וניתן לניהול, כאשר האוטומציה הופכת שימושית יותר ויותר ככל שהאפליקציות ממשיכות לצמוח ולהכיל יותר תכונות.
עם זאת, תמיד יהיה מקום לבדיקה ידנית הודות לרמה המוגברת של התובנה, הפירוט והגמישות שהיא מציעה לחברות.
פתרון הקופסא האפורה האידיאלי עבור כל חברה הוא דגם היברידי, המשתמש בבדיקות ידניות ואוטומטיות בנקודות שונות כדי להסביר את החוזקות והחולשות של שתי הטכניקות.
גישה הוליסטית חושפת יותר מהבעיות שיש לחבילת תוכנה, עוזרת לתקן את התוכנה בצורה יעילה יותר ובסופו של דבר מספקת ללקוחות מוצר הרבה יותר טוב בסוף הפיתוח.
מה אתה צריך כדי להתחיל בבדיקת תיבה אפורה?
יש כמה תנאים מוקדמים שחברות דורשות לפני שמתחילות את תהליכי בדיקת הקופסה האפורה שלהן. ביצוע אלה מאפשר את תהליך הבדיקה או הופך את בדיקות התוכנה לפשוטות בהרבה עבור צוות אבטחת האיכות מכיוון שיש להם יותר נכסים זמינים.
התנאים המוקדמים להשלמת בדיקת קופסה אפורה כוללים:
1. עיצוב מסמכים או קוד מקור
הדבר הראשון שאתה צריך כדי להתחיל את תהליך בדיקת הקופסה האפורה הוא תיעוד העיצוב או קוד המקור. בודקים צריכים להיות מסוגלים לגשת למידע זה כדי שהבדיקה תיחשב כמבחן קופסה אפורה, המציעה תובנה מסוימת לגבי פעולתה הפנימית של התוכנה עצמה.
מידע זה נוטה להיות רלוונטי ככל האפשר, למשל, מחרוזת הקוד עבור הפונקציה הספציפית שהבודק בוחן.
כאשר אתה משתמש בקופסה אפורה ולא בבדיקת קופסה לבנה אתה מספק רק חלק מהקוד ותיעוד העיצוב, אז היזהר לגבי רמת הגישה שאתה מספק.
2. תמצית מוצר
בריף מוצר או בריף יישום הוא מסמך שחברות משתמשות בו כדי לקבל הבנה מלאה של מה הלקוח מחפש בחבילת תוכנה. זה מפרט בצורה מפורטת את הפונקציונליות המדויקת שלקוח מחפש מהתוכנה, העיצוב שהלקוח רוצה וכל מפרט אחר הדרוש.
קריאת תקציר מוצר פירושה שבודק קופסה אפורה יכול לחפש את כל התכונות שלקוח רוצה, לוודא שהן נמצאות בתוכנה ולהבטיח שהמוצר מתאים לכל המטרות שיש לחברה עבור היישום שלה.
חברות מסוימות מגבילות את כמות המידע שבודקי קופסאות אפורות יכולים לראות, בהתאם למדיניות הסודיות בחברה.
3. מטרות מבחן
למפתחים ולחברות יש מטרות ספציפיות בעת השלמת בדיקות, המכונה לפעמים מפרט בדיקה. זה חשוב מאוד בתהליך בדיקת הקופסה האפורה, שכן המשמעות היא שמפתחים יכולים לספק לבודקי הקופסה האפורה את כל המידע הנכון, כאשר צוות אבטחת האיכות מעצב בדיקות התואמות את מטרות תהליך הבדיקה.
כולם עובדים בצורה יעילה יותר במקרה זה, מכיוון שהם יודעים מה הם מחפשים וכיצד להשיג את היעדים הללו בצורה הטובה ביותר.
תהליך בדיקת קופסה אפורה
בדיקת הקופסה האפורה עוקבת אחר תהליך עקבי יחסית, עם שלבים ברורים המציינים את השלבים הבודדים שעל החברה להשלים כדי להשיג את יעדי הבדיקה שלה.
מעקב אחר התהליך באופן ברור ועקבי מספק תוצאות מדויקות ועקביות המודיעות למפתחים היכן יש בעיות וכיצד ניתן לפתור אותן.
השלבים העיקריים במבחן קופסה אפורה הם:
1. קביעת תשומות ותפוקות
השלב הראשון בתהליך הוא קביעת התשומות והתפוקות שאתה מצפה מהאפליקציה.
בחר קלט שהוא בגבולות מה שבדרך כלל ניתן לצפות מהאפליקציה לטפל כדי להפוך אותו למבחן הוגן ולחשב את הפלט שאתה מצפה מאותו קלט.
על ידי השלמת תחזית זו בתחילת הפרויקט אתה יודע אם משהו השתבש בסוף הבדיקות.
2. זיהוי זרימות ראשוניות
זרימות ראשוניות הן המסלולים שהנתונים עוקבים אחריהם בתוכנה כדי להגיע לפלט הסופי שלו.
זיהוי הזרימה הראשית פירושה שאתה יכול לעקוב טוב יותר אחר האופן שבו המידע עובר בתהליכים של תוכנה, לבסס אזורים פוטנציאליים להתרחשות פגמים ולעבוד על תיקונם אם יש בעיה בתוכנה.
3. זיהוי פונקציות משנה, עם כניסות ויציאות
פונקציות משנה הן פעולות בסיסיות בתוך זרימה ראשונית. כל תת-פונקציה מוזנת על ידי פונקציה אחרת ומוזנת אל הבאה, מה שמוביל בסופו של דבר לפלט סופי מהתוכנה.
קבע מה צריך להיות הקלט לכל תת-פונקציה, יחד עם הפלט החזוי עבור כל אחת מהן.
פעולה זו ברמת תת-פונקציה מספקת רמה נוספת של תובנה בעת איתור בעיות תוכנה כלשהן.
4. פתח מקרה מבחן
מקרה מבחן מתייחס למכלול אירועים המתרחשים בתוכנה שבודקים האם האפליקציה פועלת כפי שאתה מצפה.
ודא שמקרה המבחן האפור הזה בוחן כראוי את החלק בתוכנה שאתה מסתכל עליו.
התמקד גם בעקביות, וודא שקל לשכפל את מקרה הבדיקה כדי לקבל תוצאות מדויקות יותר מבדיקת הקופסה האפורה שלך.
5. הפעל את מקרה הבדיקה
התחל להפעיל את מקרה המבחן.
זה כרוך בהזנת התשומות לכל אחת מתת-פונקציות ולראות מהן התפוקות, לרשום את כל התוצאות.
בבדיקת קופסה אפורה אוטומטית, תהליך ההקלטה הוא אוטומטי, כאשר בודקים ידניים רושמים את כל הכניסות והיציאות בעצמם.
אם אתה יכול, בדוק את כל פונקציות המשנה בנפרד לפני הפעלת הזרימה כולה בבת אחת כדי לבדוק שכל פונקציה פועלת באופן עצמאי.
6. אמת את התוצאות
לאחר שתקבל את הנתונים ממקרה הבדיקה, התחל לאמת את התוצאות הללו.
זה אומר להסתכל על התפוקות שאתה מקבל מהתוכנה ולהשוות אותם לתפוקות שציפית להן בתחילת התהליך.
אם יש הבדל כלשהו בין השניים, זה מצביע על כך שיכול להיות באג בתוכנה מכיוון שהיא לא מתפקדת בצורה שחיזית בתחילה.
7. צור דוח
בסיום תהליך בדיקת הקופסה האפורה, צור דוח על תוצאות הבדיקה.
זה כולל סיכום בסיסי של מה היו הבעיות בתוכנה, הערכה של כמה פתרונות פוטנציאליים לבעיות, ובמידת האפשר, כל הנתונים שהבדיקות הניבו.
השימוש במבנה זה נותן שיעור כותרת לקורא לפני שהוא מספק את כל הראיות הדרושות, בסופו של דבר הוא מסמך מגובש המציע שפע של הדרכה.
שיטות עבודה מומלצות לבדיקת Greybox
שיטות עבודה מומלצות מתייחסות לתהליכים, משימות ועקרונות שעובדים משלימים במבחן QA על מנת להשיג את הסטנדרטים הגבוהים ביותר האפשריים.
חלק מהשיטות המומלצות הללו עבור צוותי QA המעוניינים להגביר את רמת עבודתם כוללים:
1. עבדו בזהירות
כמו בכל שיטת בדיקה, קח את הזמן שלך ועבוד בזהירות. טעות בודדת עלולה לבטל תוקף של בדיקה, לכן איטי ויציב כדי להבטיח שהעבודה שלך מדויקת חוסך לך זמן בטווח הארוך תוך שיפור רמת התוכנה. זה נכון במיוחד בבדיקת תיבה אפורה, מכיוון שאינך יודע עם אילו חלקים של קוד המקור אתה עובד בכל עת.
2. לתקשר כל הזמן
צריכה להיות שרשרת מתמדת של תקשורת בין מפתחים לבודקי קופסאות אפורות. זה נותן למפתחים משוב מיידי על כל באג שצוות הבדיקות מגלה ופירושו שהבודקים יודעים ממה להיזהר.
אם הבאג הוא חלק מההיבט הגלוי של התיבה האפורה, תן למפתחים לדעת היכן הוא נמצא.
3. הגדר גבולות נוקשים
כאשר בדיקת הקופסה האפורה משתמשת בהגבלות מלאכותיות על מידע, כאשר החברה עצמה מחליטה איזה מידע לתת לבודקים, ודא שיש לך מגבלות נוקשות.
תן לצוות ה-QA רק את ההרשאות הדרושות לו או שאתה מסתכן בכך שהם “מסתכלים מאחורי הווילון” ותראה חלק מקוד המקור או מסמכי הפיתוח שאתה מנסה להסתיר.
7 טעויות ומלכודות ביישום מבחני תיבה אפורה
עם מאות אלפי יישומים שעוברים את תהליך הבדיקה מדי שנה, יש כמה טעויות ומלכודות שצוותי QA נופלים אליהם.
הידיעה על אלה פירושה שאתה יכול להימנע מהם ביעילות, לשפר את עבודתך ולהפחית את הסיכוי לבזבוז משאבים על אסטרטגיות בדיקה גרועות.
כמה מהטעויות והמלכודות הנפוצות ביותר במבחני קופסה אפורה כוללים:
1. בדיקת מערכות מבוזרות
בדיקת תיבה אפורה דורשת גישה לקוד מקור, ושרתים מבוזרים משתמשים בקוד ממקומות אחרים. זה גורם לבעיות בבדיקת קופסא אפורה, מכיוון שמשמעות הדבר היא שיש בעיות שהבודקים לא יוכלו לראות.
2. השלמת בדיקות לא עקביות
בדיקה לא עקבית מתייחסת למצב שבו מקרה בדיקה משתנה בין ריצות. זה יכול לגרום לתוצאות לא מדויקות, כאשר מפתחים מתמקדים אז בשיפור הביצועים על סמך מדדים שגויים.
הפוך כל בדיקה לזהות במידת האפשר כדי להגביר את הדיוק והדיוק של הבדיקה.
3. למהר במבחנים
אם תאריך שחרור מוצר מוצע מתקרב, צוותי QA יכולים להתפתות להאיץ בתהליכי בדיקת קופסאות אפורות.
עם זאת, זה סימן לתכנון גרוע, ואסור להגיב עליו עם עוד החלטות גרועות. בדיקות מהירות מובילות לתוצאות לא מדויקות ולבזבוז זמן בהמשך שלב הפיתוח.
4. לא ליישם ידני ואוטומציה ביחד
לא בדיקה ידנית ולא בדיקה אוטומטית הן שיטות מושלמות לבדיקת קופסה אפורה.
השימוש בשניהם זה לצד זה פירושו שאתה יכול להסביר את הבעיות של כל אחד מהם, ובסופו של דבר לעבוד בצורה יעילה יותר.
לכל הפחות, שקול לשלב את שתי השיטות לבדיקה טובה יותר.
5. עבודה ללא כלים
כלי בדיקה נועדו להפוך את העבודה כבוחן קופסה אפורה לקלה ככל האפשר. עבודה ללא כל כלים מגבילה את היכולות שלך ללא צורך.
חקור ביסודיות ורכש כל כלים שיכולים לעזור לפיתוח שלך להגביר את היעילות ולהפחית את הפוטנציאל לטעויות.
6. תקשורת לקויה
תקשורת פנימית בין מחלקות יכולה להיות מאבק, אבל תקשורת ברורה ככל האפשר היא חובה בין מחלקות בדיקות ופיתוח.
תקשורת טובה יותר פירושה שמפתחים יודעים את השיפורים שיש לבצע באופן מיידי ולפתור בעיות מבלי להיות מוטעים בהודעות פנימיות לקויות.
7. מחפש באגים באופן פעיל
בדיקות גריי Box קיימות כדי למצוא באגים היכן שהם קיימים, אבל גם כדי לבחון את הביצועים הכלליים של התוכנה.
לבזבז זמן רב מדי עם עין על מציאת באגים יכול לקחת הרבה זמן ולהסיח את הדעת מהמטרה העיקרית של שיפור אופן הפעולה של אפליקציה.
סוגי פלטים מבדיקות תיבה אפורה
מבחני תיבה אפורה מייצרים מספר סוגים שונים של מידע בסופו של תהליך. זה לא מתייחס לתפוקות מהתוכנה עצמה, אלא לנתונים שמפתחים יכולים להשתמש בהם כדי לשפר את התוכנה.
סוגי הפלט העיקריים הם:
1. הודעות PASS/FAIL
הודעת PASS/FAIL פשוטה המודיעה למפתח האם פעולת התוכנה הייתה מוצלחת.
סוג פלט זה אינו מספק למפתח הרבה תובנות, אך השימוש בבדיקת קופסה אפורה פירושו שבודק יכול לראות באיזו נקודה ספציפית התוכנה נכשלה ומדוע, מה שעוזר לפתור את הבעיה.
2. מדדים
מדדים מתייחסים לסטטיסטיקה פשוטה שמתארת אירוע, כמו משך הזמן שלוקח להשלים משימה ספציפית עד אלפית השנייה. אלה נפוצים בבדיקות קופסאות אפורות אוטומטיות, כאשר פלטפורמות מחשב אוספות מידע זה באופן אוטומטי לרמת דיוק גבוהה יותר ממה שבודק ידני יכול.
מידע זה שימושי לביסוס הביצועים של אפליקציה.
3. נתונים איכותיים
מידע תיאורי שאתה מקבל מבוחן קופסא אפורה מהניסיון שלו עם התוכנה. בלתי ניתן לכימות, מה שמקשה על הניתוח, אך מספק רמה טובה יותר של תובנה על חווית המשתמש וגורם ללקוחות להיות נוחים יותר עם התוכנה.
דוגמאות למבחני תיבה אפורה
במקרים מסוימים, הכרת התיאוריה סביב צורת בדיקה אינה מספקת מספיק תובנה ואינה מספקת הבנה נכונה. הכרת כמה דוגמאות של מבחני קופסה אפורה היא חיונית כדי לשפר את ההבנה שלך לגבי אופן הפעולה של מתודולוגיית הבדיקה.
ראה כמה דוגמאות של מבחני קופסה אפורה למטה המספקות פרטים נוספים על מבחנים בעולם האמיתי וכיצד התיאוריה חלה על מקומות עבודה מעשיים.
1. דוגמה לבדיקות אבטחה מוצלחות
חברה יוצרת מסד נתונים עם הרבה נתונים אישיים ומתכננת בדיקות אבטחה כדי לוודא שנתוני המשתמש מוגנים.
בודק ידני עובר את התהליך, מחפש פגמים פוטנציאליים בקוד והזדמנויות לגשת לחלקים מהאפליקציה.
לאחר מציאת חולשה, הבוחן מודיע למפתח היכן נמצאת החולשה וכיצד ניצלו אותה.
לאחר תיקון התוכנה, הבוחן משלים את אותה בדיקה שוב כדי לוודא שהמערכת מאובטחת.
2. דוגמה לבדיקת מסד נתונים נכשל
למפתחים שיוצרים מסד נתונים יש דד-ליין קצר לשחרור וצריכים לבדוק במהירות.
הבודקים ממהרים יחדיו כמה מקרי בדיקה בסיסיים ומשלימים אותם במהירות, עושים טעויות בביצועם, לא מכינים תחזיות פלט ולא מצליחים לבחון פונקציות משנה.
מכיוון שהם לא מכינים תחזיות תפוקה, הם לא מבינים בעיות תפוקה, ומשלוחים מוצר שלא עובד כמו שצריך כתוצאה מכך.
סוגי שגיאות ובאגים שזוהו באמצעות בדיקת תיבה אפורה
אחת המטרות העיקריות של בדיקת קופסא אפורה היא למצוא שגיאות ובאגים בתוכנית, כאשר חברות מעוניינות לספק אפליקציות מתקדמים שלקוחותיהן יכולים לסמוך עליהם בכל מקום אפשרי.
ישנם כמה סוגים ספציפיים של שגיאות ובאגים שהבודקים יכולים למצוא בתהליך בדיקת הקופסה האפורה, שכל אחד מהם יכול להצביע על בעיה אחרת בקוד.
סוגי השגיאות והבאגים שזוהו בבדיקת קופסא אפורה כוללים:
1. כשל בתהליך
הצורה הראשונה של שגיאה היא כשל בתהליך.
זה מתייחס למצב שבו הבדיקה לא מחזירה שום צורה של תוצאה ופשוט קורסת.
קיימות מספר סיבות פוטנציאליות לבעיות אלו, ובמקרה אידיאלי, בודק קופסה אפורה יכול לקבוע מאיפה הבעיה מגיעה וכיצד מפתח יכול לקודד תגובה.
2. פלט שגוי
שגיאות מסוימות בבדיקת קופסה אפורה מתרחשות כאשר הפלט של תהליך אינו זה שהמפתחים צופים.
מדובר בבעיה חמורה במקרים כמו מאגר מידע, בהם החזקה מאובטחת של מידע נכון היא הכרח.
3. שגיאות אבטחה
שגיאות אבטחה מתרחשות כאשר האפליקציה של חברה אינה מאובטחת במקצת ומאפשרת גישה לצד שלישי למידע המוחזק בתוכו.
ליקוי אבטחה באפליקציה יכול להיות בעיית GDPR ולגרום לכך שהאפליקציה אינה עומדת בשורה של תקנות בינלאומיות.
מדדי בדיקת תיבה אפורה נפוצה
מדדים מתייחסים למדידות קבועות הבודקות אירוע מסוים או סדרה של התרחשויות, בדרך כלל בצורה של נתונים כמותיים.
על ידי שימוש במדדים, בודקים וצוותי אבטחת איכות יכולים לבחון את התוכנה שעוברת בדיקת גרייbox ולראות בדיוק מה משתבש, בין אם זה בצורה של עוד שגיאות שמתרחשות או תכונות שונות שלוקח יותר זמן לטעון אותן.
כמה מדדי בדיקת הקופסה האפורה הנפוצים ביותר שבהם משתמשים בוחני QA בעת הערכת תוכנה כוללים:
· זמן לפלט:
משך הזמן שלוקח לאפליקציה להפיק פלט לאחר תחילת הבדיקה.
· זמן לתגובה:
משך הזמן שלוקח לתוכנה להגיב לקלט המשתמש, בין אם בצורה של תוצאה או פשוט אישור על הקלט.
· מספר שגיאות:
המספר הטהור של שגיאות שיש לתוכנה בתהליכים שלה.
· שגיאות לכל פונקציה:
מספר השגיאות הקיימות חלקי מספר הפונקציות בתוכנה, המשמשות לקביעת צפיפות השגיאות.
כלי בדיקת התיבה האפורה הטובים ביותר
בדיקת תיבה אפורה יכולה להסתמך על כלים חיצוניים כדי לשפר את איכות העבודה שלך, אוטומציה של חלק מהתהליכים ולתמוך בך בעת יצירת תיקון לכל באג שתמצא.
ככל שכלי הבדיקה שבו אתה משתמש טוב יותר, כך תחשוף יותר בעיות ורמת המוצר הסופי שלך תהיה טובה יותר, כל זאת תוך חיסכון בזמן ומשאבים לאורך הבדיקה.
ראה כמה מכלי בדיקת הקופסה האפורה הטובים ביותר להלן, בנוסף ליתרונות והחסרונות של השימוש בכל פלטפורמה.
5 הכלים הטובים ביותר לבדיקת תיבה אפורה בחינם
כאשר חברה קטנה יותר מעוניינת להתחיל בבדיקת קופסאות אפורות, יש צורך בכלים הנכונים הזמינים, אך יש להם אותם במחיר סביר יכול להיות חשוב לא פחות. כל שקל נחשב בעסק קטן, ומפתח אפליקציות אינו שונה, עם תקציבים צפופים המובילים להחלטות קשות.
שימוש בכלי בדיקת קופסא אפורה בחינם מושלם לאבטחת איכות עם משאבים מינימליים.
כמה מכלי בדיקת הקופסה האפורה החינמית הטובים ביותר כוללים:
1. ZAPTEST FREE EDITION
המהדורה החינמית של ZAPTEST מציעה חווית אוטומציה איכותית למשתמשים שלה, עם אוטומציה של תוכנה מלאה התומכת בבדיקות מתחילת הפיתוח.
עם ביצוע מקביל, אתה יכול להשלים כמה בדיקות בכל פעם כדי להאיץ את התהליכים שלך, וכשאתה מוכן לעשות את הקפיצה לשלב הבא, מהדורת Enterprise הופכת את המעבר לפשוט ככל האפשר. כיתרון נוסף, ZAPTEST מציעה גם טכנולוגיית RPA מתקדמת, ללא עלות נוספת.
הבחירה המושלמת עבור מישהו בימים הראשונים של הבדיקה שלו.
2. אפיום
כלי בדיקה יסודי שנועד לעזור לוודא שהאפליקציות לנייד עומדות בסטנדרט , ל-Appium יש קהילת תמיכה פעילה אך מבצעת בדיקות לאט יחסית. בשילוב עם מערך מאתגר, זה לא הכלי החינמי הטוב ביותר עבור הרבה חברות.
3. כלי פיתוח של Chrome
Google Chrome מציע מגוון כלי פיתוח עבור אפליקציות אינטרנט , ועם שילוב בדפדפן הפופולרי ביותר, זה נראה כמו חובה.
עם זאת, הוא מוגבל לבדיקת רכיבי קופסא, מה שהופך אותו לכלי בדיקה מגביל.
4. JUnit
JUnit היא מסגרת קוד פתוח המאפשרת למשתמשים לבצע בדיקות חוזרות שוב ושוב בג’אווה, ומגבילה אותה לשפה יחידה אחת.
כשלעצמה, מגבלה זו אינה מהווה בעיה, אך היעדר ממשק API וממשק פשוטים עלולים להפוך אותה לבלתי נתפסת עבור בודקים חדשים יותר.
5. DBUnit
DBUnit מתמקדת בתמיכה בפרויקטים מוכווני מסד נתונים, תוך שימוש במצבים ידועים כדי לאמת את התוצאות במדויק ולבחון את התוצאות באופן מקיף.
זה מושלם עבור מסדי נתונים ויישומים דומים, אבל חוסר תמיכה באינטגרציה פירושו שהוא מתקשה במשימות חוצות פלטפורמות.
5 הכלים הטובים ביותר לבדיקת תיבה אפורה ארגונית
ככל שמפתחים גדלים, כך גם דרישות הבדיקות שלהם עולות, כאשר לחברות גדולות יש יישומים גדולים יותר ודורשות חבילות בדיקה מקיפות יותר כתוצאה מכך.
קיימים כלי בדיקת קופסאות אפורות ארגוניות כדי לתמוך בחברות במצב זה, ולספק גישה רבה יותר לתכונות מתקדמות שמפתחים חובבים וקטנים עשויים שלא להזדקק להם.
כמה מכלי הבדיקה הטובים ביותר ברמת הארגון בעת ביצוע בדיקת קופסה אפורה כוללים:
1. ZAPTEST ENTERPRISE EDITION
מהדורת Enterprise של ZAPTEST מספקת יכולות בדיקה גדולות יותר מהגרסה החינמית, כאשר אחד היתרונות העיקריים הוא גישה מתמדת למומחה ZAP. מומחה ZAP פועל באופן יעיל כיועץ וחבר בצוות שלך מרחוק, ותומך בכל צורכי הבדיקות של החברה שלך.
מפתחים שמשקיעים במהדורת ZAPTEST Enterprise יכולים לראות עד פי עשרה את ההחזר על השקעתם הודות לטכנולוגיות מתקדמות של Computer Vision , 1SCRIPT, חוצה פלטפורמות, חוצה מכשירים, ביצוע חוצה דפדפנים, ובעיקר רישיונות בלתי מוגבלים.
הרישיונות הבלתי מוגבלים, בנוסף לטכנולוגיית הבדיקות וה-RPA המתקדמות ביותר, פירושם שארגונים נהנים מעלות קבועה, ללא קשר לכמה מהר וכמה הם גדלים.
2. TestRail
פתרון לניהול מקרה מבחן המאפשר לך לפצל את כל הבדיקות שתבצע לפי מקרה מבחן, תוך רישום מדויק יותר של נתונים.
עם זאת, TestRail אינה בהכרח אידיאלית עבור בדיקות קופסאות אפורות, מכיוון שהיא מתקשה לאזן בין בדיקות ידניות לבין הקלטה אוטומטית של בדיקות.
3. עדות
פלטפורמת בדיקות המתמקדת בהצעת בדיקות מותאמות אישית יציבות, תוך הטמעת מקרי בדיקה מקודדים וחלופות לא מקודדות.
מכיוון שזה בחינם רק למספר מוגדר של בדיקות בחודש, ארגונים גדולים יותר יכולים להתקשה להפיק את המרב מהפלטפורמה הזו.
4. TestRigor
TestRigor היא פלטפורמה נחשבת נרחבת המשתמשת במנוע AI להשלמת בדיקות, כאשר תחזוקת בדיקות AI היא אחת התכונות האטרקטיביות יותר.
עם זאת, זה מגיע בנקודת מחיר משמעותית, כאשר פלטפורמות אחרות נותנות החזר טוב יותר על ההשקעה.
5. קוביטון
Kobiton היא פלטפורמת בדיקות גמישה יחסית בתמחור, האוטומציה של בדיקות על בסיס משתמש לאחר השלמת ניסיון חינם.
דאגה אחת שיש לחלק מהמשתמשים סביב קוביטון היא חוסר יחסי של תמיכה מקוביטון בכל הנוגע לפתרון שאילתות בודקים.
מתי כדאי להשתמש בכלי תיבה של Enterprise לעומת Freemium Grey?
גם כלי הקופסה האפורה של הארגון וגם Freemium מספקים למשתמשים שלהם יתרונות רבים. חברות באופן אידיאלי מתחילות עם מוצר freemium כדי ללמוד את תהליך הבדיקה לפני מכן להתקדם למהדורה ארגונית ככל שהצרכים שלהן גדלים.
זה מכניס רמה של המשכיות לפרויקט, ומגביל את כמות ההכשרה מחדש שעובר הצוות.
נקודת המעבר משתנה מעסק לעסק, אך בנקודת זמן מסוימת, ההחזר על ההשקעה של מוצר ארגוני הופך לבלתי נמנע.
רשימת בדיקה לבדיקת קופסה אפורה, טיפים וטריקים
השלמת בדיקת קופסא אפורה היא תהליך מורכב למדי, כך שהצגת רשימת בדיקה לעבודה מסייעת להרגיע אותך שעשית את כל מה שאתה צריך בבדיקה.
חלק מהמאפיינים העיקריים של רשימת תיוג אפורה, בנוסף לכמה טיפים לשיפור איכות הבדיקה שלך, כוללים:
1. תכנון יסודי
תכנון מקיף הוא אחד הדברים הראשונים שיש לסמן במבחן, שכן לוודא שאתה מתכנן לחלוטין כל היבט של מבחן הוא חובה.
ככל שתתכנן יותר כך יש יותר מבנה מאחורי הבדיקות שלך, מכיוון שאנשים יודעים אילו בדיקות הם מסיימים ומתי הם מסיימים אותם.
זה גם מוביל לנתונים עקביים , שהוא אידיאלי עבור פתרונות מפתחים טובים יותר.
2. דיווח נתונים מיידי
כשאתה עובד על תהליך בדיקת קופסה אפורה, נסה לדווח על נתונים באופן מיידי. על ידי יצירת דוחות בהקדם האפשרי, אתה מגדיל את הדיוק של תהליכי הדיווח שלך מכיוון שכל המידע טרי בראשך.
זה נכון במיוחד לגבי מידע איכותי, מכיוון שהוא צריך להיכתב על ידי הבוחן ולא פשוט לאחסן בפלטפורמת בדיקה.
3. הגדר אחריות
לאורך תהליכי הבדיקה, ודא שכולם במקום העבודה מתמקדים באחריות ספציפית. על ידי הגדרת אחריות בדרך זו, כל אחד יודע מה תפקידו במקום העבודה ומבין כיצד לבצע את המשימות שלו בצורה פרודוקטיבית ובמינימום הפרעות.
למרות שזוהי יותר תפיסה ניהולית מאשר נקודת בדיקה לבדיקה, יש לה השפעה רבה על התוצאות.
4. השוואה מתמדת
השווה את התוצאות שלך למספר דברים על בסיס כמעט קבוע. נקודות ההשוואה כוללות את תיעוד התכנון הראשוני, תוצאות בדיקות קודמות וציר הזמן של הארגון להשלמת הפרויקט.
קיום מסגרות התייחסות אלה מודיע לך באופן עקבי כיצד מתקדם תהליך פיתוח התוכנה, תחומים לשיפור והתאמות פוטנציאליות לבצע.
סיכום
לסיכום, בדיקת קופסה אפורה היא אחת מצורות הבדיקה המגוונות ביותר הקיימות, המשלבת את הפונקציונליות של הקופסה הלבנה עם מגבלת ההטיה של מבחני הקופסה השחורה.
על ידי שילוב של שיטות בדיקה ידניות ואוטומטיות במאמצי הקופסה האפורה שלך, חברות יכולות להתחיל להפחית משמעותית את השפעת הבאגים על התוכנה שלהן על ידי חקיקת תיקונים שיובילו למוצר טוב יותר.
בדיקת תיבה אפורה היא הכלי המושלם עבור כל מפתח, והטיפים לעיל יכולים להבטיח שאתה משתמש בו כראוי.
שאלות נפוצות ומשאבים
אם יש לך שאלות כלשהן לגבי בדיקת קופסא אפורה, עיין בכמה מהשאלות הנפוצות שלנו כדי ללמוד עוד ולשפר את ההבנה שלך בסוג זה של מבחן:
1. הקורסים הטובים ביותר ב-Gray box Test Automation
ישנם קורסים מעטים יחסית המכוונים ספציפית לאוטומציה של מבחני קופסה אפורה, כאשר קורסי בדיקות תוכנה כלליים אלה הם דרך אידיאלית להתחיל:
· “קרן לבדיקת תוכנה עם בחינה”- עסקאות הדרכה
· “הכשרת יסודות בדיקות תוכנה 6 שבועות”- Futuretrend Technologies Ltd
· “קורס בדיקות תוכנה”- קורס מלכותי
· “בדיקת קופסה שחורה וקופסה לבנה”- Coursera
· “בדיקות תוכנה – אסטרטגיות Black-Box ובדיקות White-Box”- NPTEL
2. מהן 5 שאלות הראיון המובילות בנושא בדיקת תיבה אפורה?
· איזה ניסיון יש לך בעבודה עם בדיקות קופסאות אפורות, ואיך מצאת אותה?
· מדוע חברות משתמשות בבדיקת קופסאות אפורות, ובאיזה שלב בתהליך?
· השווה בין בדיקת קופסה לבנה, קופסה אפורה ובדיקת קופסה שחורה
· מהם כמה מהאתגרים הגדולים ביותר של בדיקת קופסא אפורה וכיצד ניתן להתגבר עליהם?
· כיצד פועלת אוטומציה של בדיקות?
3. מדריכי YouTube הטובים ביותר על בדיקת תיבה אפורה
· “מהי בדיקת תיבה אפורה? מהן הטכניקות המשמשות בבדיקת תיבה אפורה? עם דוגמה מוסברת”- פריצות לבדיקת תוכנה
· “בדיקת קופסה אפורה | הנדסת תוכנה |”- Education 4u
· “בדיקת קופסה שחורה, קופסה לבנה ותיבה אפורה”- נס חינוך
· “עצה לבודקי QA ידניים חדשים | עבודה עם מפתחים + דברים שלמדתי בתור בודק תוכנה”- מדליין איליין
· “מהי בדיקת תיבה אפורה? (שאלת ראיון מס’ 54 לבדיקת תוכנה)”- QA Fox
4. כיצד לשמור על מבחני תיבה אפורה?
שמירה על מבחני הקופסה האפורה שלך היא תהליך פשוט למדי. לבדיקה ידנית, ודא שאנשי הצוות מאומנים היטב וממלאים את אותן המשימות בכל פעם מחדש. לבדיקות אוטומטיות, קרא את כל הקוד למקרי בדיקה ובדוק את התוצאות, תוך שימוש בפיקוח מתמיד על התהליכים בכל מקום אפשרי.
5. הספרים הטובים ביותר על בדיקת תיבה אפורה
חלק זה מכיל מאמרי כתב עת בנוסף לספרים, על מנת לספק את הסטנדרטים הגבוהים ביותר האפשריים של סיוע בכתב לבודקי QA:
· “טכניקת גריי-בוקס של בדיקות אינטגרציה של תוכנה על בסיס מסר” – TanLi M. et al
· “מחקר השוואתי של טכניקות בדיקה של קופסה לבנה, קופסה שחורה ותיבה אפורה” – Ehmer, M., Khan, F.
· “אסטרטגיות בדיקה מבוססות FSM-קופסה אפורה”- Petrenko, A.
· “הנדסת תוכנה” – סאלח, ק”א
· “כנס בינלאומי ליישומי מחשב 2012” – קוקולה קרישנה הארי ק.
