חלוקת שוויון בבדיקות תוכנה היא טכניקת בדיקת קופסה שחורה המסייעת לך לבנות מקרי בדיקה יעילים מבלי להתפשר על כיסוי הבדיקה.
במאמר זה, נבחן מהי חלוקת מחלקות שקילות, מדוע היא שימושית, ונחקור כמה מהתהליכים והגישות שבהן תוכל להשתמש כדי לפתוח את היתרונות של טכניקה זו.
מהי חלוקת מחלקות שקילות
בבדיקות תוכנה?
לכל התוכנה יש תנאי קלט מסוימים. בהקשר של בדיקות תוכנה, תנאי קלט אלה מתארים את הערכים או הנתונים שבהם בודק חייב להשתמש כדי לאמת את האיכות והפונקציונליות של התוכנה שלו. כניסות אלה יכולות להיות משהו פשוט כמו לחיצת עכבר, עד לטקסט ומספרים.
מחיצה שוות ערך בבדיקת תוכנה חוקרת את התשומות השונות הנדרשות לשימוש בתוכנה ומקבצת אותן למחלקות שקילות, כלומר, קבוצות של תשומות שתהיה להן השפעה שווה על התנהגות התוכנה.
אם אתה יודע איך כל קבוצת תשומות תתנהג, אז אתה לא צריך לבדוק כל נציג של הקבוצה. ככזה, חלוקת מחלקות שקילות היא דרך מצוינת לעזור לבודקים להפחית את התדירות של בדיקות מיותרות. בעולם פיתוח תוכנה היפר-תחרותי עם מועדים הדוקים יותר ויותר, חיסכון בזמן ומאמץ במחזור החיים של בדיקות תוכנה (STLC) הוא חיוני.
לבסוף, ראוי לציין שבדיקת שקילות היא טכניקת בדיקת קופסה שחורה. בקיצור, זה אומר שהבודקים לא צריכים לדעת על הקוד הפנימי של התוכנית או על פעולתה הפנימית. הבדיקות מבוססות על תשומות, פלטים והתנהגויות חיצוניות. ככאלה, בדיקות אלו מתמקדות מאוד בהתנהגות המשתמש בזמן השימוש בתוכנית.
1. חלוקת שוויון בדיקת תוכנה בקצרה
חלוקת שוויון מחלקת את נתוני הקלט של בדיקת תוכנה לשני מחנות: קלט תקף ולא חוקי. הערכים בתוך כל מחיצה חייבים לגרום לתוכנה להציג את אותה התנהגות. לדוגמה:
- אם התנאי של ערך אחד במחלקה A הוא נכון, כך גם הערכים האחרים במחלקה A חייבים.
- באופן דומה, אם התנאים של ערך אחד במחלקה A הם שקריים, גם הערכים האחרים במחלקה A חייבים להיות שקריים.
בהקשר של בדיקה, כל מחיצה חייבת להיות מכוסה לפחות פעם אחת. באופן הגיוני, זה אומר שאם כניסה אחת במחיצה A נכשלת, אז גם כל שאר הקלטים ייכשלו. תהליך זה אמור לחסוך זמן מכיוון שבמקום לבדוק כל קלט שנמצא במחיצה A, בודקים יכולים לבדוק רק אחד ולהוציא את התוצאה על סמך המאפיינים המשותפים שלו.
2. מדוע חשובה בדיקת כיתות שוויון בבדיקות תוכנה
לפני שניכנס ליתרונות הישירים של בדיקת מחלקת שקילות בבדיקות תוכנה, עלינו להגדיר מדוע הגישה חשובה.
כל הבודקים מבינים שבדיקת תוכנה דורשת פשרות. הזמן והתקציבים מוגבלים, מה שאומר שהבודקים צריכים להפיק את המרב מהמשאבים שלהם. חלוקת שוויון בדיקות תוכנה עוזרת לצוותים למצוא איזון בין יעילות ואמינות בבדיקות שלהם על ידי הפחתת מספר התשומות.
היתרונות של חלוקת שוויון
בבדיקות תוכנה
מחיצה מקבילה בבדיקות תוכנה מועדפת על ידי צוותי בדיקה ממגוון סיבות. הנה כמה מהמשכנעים ביותר.
1. יעילות
היתרון הגדול של בדיקת מחיצות שקילות טמון ביעילות שלה. כאשר בודקים משתמשים במחיצות שווי ערך, הם יכולים להפחית את מספר מקרי הבדיקה שהם דורשים מבלי להתפשר על כיסוי הבדיקה. על ידי בחירת מקרה קלט מכל מחלקה שקילות, בודקים יכולים להרגיש בטוחים שהם מבינים כיצד התוכנה שלהם עובדת עם מגוון קלטים.
2. פשטות
יתרון גדול נוסף של מחיצות שקילות לבדיקת תוכנה הוא הפשטות. פירוק מערך מגוון של תשומות הן בנתונים תקפים והן בנתונים לא חוקיים פירושו שתכנון הבדיקות הוא הרבה יותר פשוט. בדיקת כל קלט בנפרד דורשת תיעוד ותיאום רב. צמצום זה לדוגמא מייצגת אחת מייעל את תהליך הבדיקה.
כיסוי משופר
שימוש בשיעורי שוויון בבדיקות מאפשר לך גם לנצל את זמן הבדיקה שלך בצורה יעילה יותר. צמצום כניסות הבדיקה למחלקות אומר שאתה יכול לבדוק כל מחלקה בצורה יסודית יותר. גישה מקיפה זו תהיה בלתי אפשרית למען האמת אם תבדוק כל קלט בנפרד. חלוקת שוויון מאפשרת לצוותים לקבל יסודי ולבדוק נתונים תקפים ולא חוקיים, מקרי קצה, ערכי גבול ועוד.
3. שימוש חוזר
הזמן הראשוני שאתה משקיע בהקמת כל מחלקה שקילות בבדיקות תוכנה משתלם בהמשך הדרך אם אתה עושה שימוש חוזר במחלקות אלה עבור מבחני קלט עתידיים. אמנם לא כל המחיצות יהיו רלוונטיות לבדיקות עתידיות, אך אלו יחסכו לך זמן רב עם פרויקטים עתידיים או אפילו במצבי בדיקות רגרסיה .
חסרונות של חלוקת שוויון
בבדיקות תוכנה
בעוד שחלוקת שוויון מציעה כמה יתרונות עיקריים, זה לא הפתרון האידיאלי לכל תרחיש. בואו נחקור כמה מהמגבלות שלו.
1. סדר הזנה
במצבים מסוימים, סדר קלט הוא חלק קריטי בבדיקת הפונקציונליות של יישום. זה לא משהו שאתה באמת יכול לצמצם על ידי שימוש בחלוקת שוויון. הבודקים חייבים להישאר מודעים למצבים אלה ולהשתמש בטכניקות חלופיות כדי לספק כיסוי טוב.
2. תלות מורכבת בקלט
תוכנה מורכבת עם תלות מורכבת בקלט היא תחום נוסף בו נחשפות המגבלות של חלוקת השוויון. למשל תוכנה המפיקה חישובים על סמך תשומות שונות. בתרחיש זה, הבודקים יצטרכו להשתמש במגוון טכניקות כדי להפחית פיצוץ קומבינטורי ולהגדיל את הסבירות לבידוד פגמים.
גישות חלופיות להשלמת ה
מגבלות של בדיקת שוויון
בעוד שבדיקת מחיצות שקילות מתאימה לתרחישי בדיקה רבים, תוכנה מורכבת ביותר עם תלות מורכבת בין ערכי קלט יכולה לדרוש גישות משלימות נוספות.
כשמדובר בכתיבת מקרי מבחן עבור תוכנות מורכבות, שימוש בשילוב של גישות אלו הוא רעיון מוצק.
1. בדיקה זוגית
בדיקה זוגית היא טכניקת בדיקת תוכנה הבודקת את כל השילובים האפשריים של כל זוג פרמטרים קלט. גישה זו מבטיחה שכל זוג פרמטרים נבדק ביחד לפחות פעם אחת.
2. בדיקת טבלת החלטות
טבלת החלטות מסייעת לבודקים למפות באופן שיטתי שילובי קלט שונים. זוהי דרך טובה להבטיח כיסוי שיטתי כאשר קיימות תלות מורכבות.
3. בדיקת מעבר מדינה
סוג בדיקה זה מודד כיצד התוכנה עוברת בין מצבים שונים בתגובה לשילובי קלט שונים.
4. בדיקה מבוססת מודלים
גישה זו דורשת יצירת מודל המבוסס על הלוגיקה הפנימית של התוכנה ושימוש בכלי אוטומציה ליצירת מקרי בדיקה המבוססים על מודל זה. טכניקה זו מיומנת בטיפול במורכבות ובהבטחת כיסוי הולם.
דוגמאות לבדיקת חלוקת מחיצות בכיתה שקילות
הדרך הטובה ביותר להבין חלוקת שוויון היא לבחון כיצד והיכן אתה יכול להשתמש במחלקת שוויון בבדיקות תוכנה. הנה כמה דוגמאות שיעזרו לך לדמיין את הרעיון.
1. דוגמה מס’ 1 לבדיקת חלוקת מחיצות של מעמד שווה
טופס הזמנה מקוון הוא דוגמה טובה לשיעורי שוויון בבדיקות תוכנה.
נניח שאתה בונה אפליקציה עבור קמעונאי מקוון של ציוד נייח. קיים טופס הזמנה טיפוסי לערבות של נייר A4. הנה איך אתה יכול להשתמש בשיעורי שוויון כדי לבדוק טופס זה.
שיעורי שוויון:
כמויות נייר A4 הן בטווח מסוים של, למשל, 1 עד 100. אז שלושת הכיתות הן:
- 1 עד 100
- מספרים מתחת ל-1
- מספרים מעל 100.
מקרי מבחן:
יש להפעיל שלושה מקרי בדיקה, עם התוצאות הצפויות הבאות
- כל מספר בין 1 ל-100 = הזמנה מעובדת
- מספרים מתחת ל-1 = הודעת שגיאה
- מספרים מעל 100 = הודעת שגיאה
2. דוגמה לבדיקת מחיצות שקילות מס’ 2
שיעור שקילות בבדיקות תוכנה יכול להתמודד עם יותר מסתם מספרים. בדוגמה זו, נחקור כיצד תוכל להשתמש באותו עיקרון כדי לאמת פורטל העלאת קבצים. נניח שאתה צריך לבדוק אתר שדורש מהמשתמשים להעלות מסמכי זהות, אבל אתה יכול לקבל רק פורמטים ספציפיים.
שיעורי שוויון:
- המסמכים הנתמכים הם PDF ו-JPEG.
- מסמכים שאינם נתמכים הם כל שאר הפורמטים של המסמכים
- אין מסמך
מקרי מבחן:
- בדיקה על ידי העלאת PDF או JPEG = העלאה מוצלחת
- בדוק על ידי העלאת פורמט לא נתמך = הודעת שגיאה
- בדיקה ללא העלאת קובץ = הודעת שגיאה
כיצד ליישם חלוקת שוויון
גישת בדיקות תוכנה
אם אתה רוצה להשתמש בשיעורי שוויון בבדיקות, אתה צריך לנקוט בגישה אסטרטגית. להלן מדריך שימושי צעד אחר צעד ליישום חלוקת שוויון בבדיקות תוכנה.
שלב מס’ 1: זיהוי משתני קלט
כל תוכנה מגיבה למגוון משתני קלט. עבור תוכנות מורכבות, משתנים אלה יכולים להיות עצומים. לכן, עברו על דרישות התוכנה ומפרטי התוכנה ודאו במדויק את כל המשתנים שיש להם השפעה על התנהגות התוכנה.
חלק מהכניסות הברורות ביותר יכללו טפסי קלט של משתמשים. עם זאת, עליך לשקול מגוון רחב יותר של תשומות עבור הרשימה שלך. אתה יכול גם לשקול משתנים סביבתיים, קריאות API, חישובים פנימיים וכו’.
בשלב הבא, עליך להבין את הסוגים השונים של נתונים משתנים. אתה יכול לסווג את המשתנים האלה כמספר שלם, בוליאני, מחרוזת וכו’, כדי להגדיר את המחיצות המתאימות.
לבסוף, עליך לחקור את אילוצי הקלט. אלה יהיו דברים כמו אילו תווים מותרים, פורמטים מוגדרים וערכי מינימום/מקסימום.
שלב 2. קבע מחיצות חוקיות ולא חוקיות
תסתכל על כל משתנה קלט והתחל לחלק אותם לפי תוצאות חוקיות ולא חוקיות. אלו יהיו שיעורי השוויון שלך בבדיקות.
1. מחיצות תקפות
ניתן לפצל מחיצות תקפות לשתי מחלקות.
שיעורי שקילות חיובית:
ערכים שאתה מצפה שהתוכנה שלך תטפל בהצלחה. לדוגמה, עבור תוכנה שמתעדת ציונים באחוזים, כל דבר בין 0 ל-100 תקף.
מחלקות שקילות שלילית:
קטגוריה זו תהיה עבור ערכים שנמצאים מחוץ לגבולות הקלט הצפוי אך התוכנה שלך צריכה לטפל בהם עם הודעת שגיאה. לדוגמה, הקלט הוא 110 עבור ציון אחוז, מה שמבקש מהתוכנה להחזיר הודעת שגיאה האומרת, “כל הערכים חייבים להיות 0 עד 100”.
2. מחיצות לא חוקיות
מחלקות שקילות אלו יכללו תשומות שיפעילו שגיאות או התנהגויות בלתי צפויות. בדוגמה שלנו למעלה, זה יכול לכלול ניסיונות להזין A+ או B או תשומות דומות לציון האחוז. בעוד שהקלטים הללו יכולים להיות נכונים מבחינה טכנית, הם מחוץ לציפיות המספריות.
#3. כתיבת מקרי מבחן יעילים
בשלב הבא, עליך לתכנן מקרי בדיקה שיכסו כל מחיצת שוויון לפחות פעם אחת. כפי שהוזכר קודם לכן במאמר, זה מבטיח כיסוי מתאים למבחן.
ראשית, עליך לבחור ערכים מייצגים בתוך כל מחיצת שקילות שיכולים לכסות נתונים תקפים ולא חוקיים.
טיפים לכתיבת מקרי מבחן מוצקים
- חשוב על ערכי גבולות: ודא שאתה בודק את הגבולות של המחיצות שלך. מינימום, מקסימום, כולל, בלעדי וכו’, מכיוון שתחומים אלו הם מועמדים חזקים לבאגים. לדוגמה, אם ציפיות הקלט שלך הן בין 0 ל-100, בדוק אם יש ערכים שליליים, כמו גם מספרים כמו 101.
- שקול תרחישי בדיקה חיוביים ושליליים עבור מקרי הבדיקה התקפים והבלתי חוקיים שלך.
- בדיקת שילוב היא רעיון טוב. השתמש בכמה גישות שונות כפי שמתואר בגישות החלופיות שלנו כדי להשלים את המגבלות של סעיף בדיקת השקילות לעיל.
- תעדו את הרציונל שמאחורי הסיבה לכך שערכי קלט חולקו למחיצות ספציפיות, ותארו בבירור את ההתנהגות הצפויה של כל בדיקה
- היכן שניתן, השתמש בכלים חזותיים כדי להביא תחושה של בהירות ואובייקטיביות למקרי הבדיקה שלך על ידי שימוש בדיאגרמות או טבלאות למיפוי המחיצות שלך.
#4. תזמן ובצע את מקרי הבדיקה שלך
תעדוף את המשימות שלך על סמך גורמים כמו:
- באילו אזורים יש סבירות גבוהה ביותר פגמים
- אילו תרחישים צפויים לגרום לתרחישים חמורים, כגון קריסות או הקפאה
לאחר מכן, בצע את הבדיקות שלך ותעד את הפלטים ואת כל השגיאות המתרחשות. עבור תוכניות מורכבות עם הרבה כניסות, אתה יכול להשתמש בכלי RPA כדי לחקות פעולות משתמש.
#5. נתח את התוצאות
אסף את נתוני הבדיקה שנאספו ונתח את התוצאות. כמה שיטות שאתה צריך להשתמש הן:
- עיין בכל מקרה מבחן והשווה את התפוקות בפועל עם התפוקות הצפויות שלך
- מצא אי התאמה, חקור ודווח על באגים ופגמים.
# 6 עצות נוספות
למרות שטיפים אלה לא יחולו בכל תרחיש, הם יוכיחו שהם שימושיים עבור בדיקות תוכנה מורכבות.
- טבלאות החלטה הן דרך מצוינת לדמיין את מחיצות השקילות שלך ושילובי קלט שונים שאולי תרצה להשתמש בהם
- אתה יכול למזג מחלקות שקילות אם הם מפגינים התנהגות כמעט זהה, ולמטב עוד יותר את תהליך הבדיקה
- השתמש בבדיקת ערכי גבול כדי לשפר את זיהוי הפגמים
- במידת האפשר, הפוך את מקרי בדיקת חלוקת השוויון שלך לאוטומטיים
חלוקת שוויון וניתוח ערכי גבולות
חלוקת שוויון מבוססת על ההנחה שכל בדיקה בתוך מחיצה תפיק את אותה תוצאה. למרות שזה נכון במצבים רבים, זה לא תמיד יעבוד. לדוגמה, כל כניסות שנוספו למחיצה בטעות עלולות להיעלם מהסימון, מה שיוביל לכיסוי מופחת ולאי יציבות פוטנציאלית של תוכנה בהמשך הדרך.
הפתרון לבעיה זו הוא בדיקת ערכי גבולות. זה מאפשר לצוותי בדיקות תוכנה להתמקד בתחומים שסביר להניח שיכילו סיכונים ובודק את התוכנה על בסיס זה. בקיצור, הוא מציע שסביר להניח שסיכונים יתרחשו בקצוות או בגבולות של מחיצות הקלט שלך. לכן, בודקים יכולים לכתוב מקרי מבחן בגבול העליון והתחתון של התשומות, בנוסף למקרי המבחן האחרים של מחלקות השקילות.
חלוקת שוויון ואוטומציה עם ZAPTEST
כלי אוטומציה של בדיקות תוכנה, כמו ZAPTEST , יכולים לעזור לצוותים לבצע אוטומציה של חלוקת שווי ערך הן במהלך יצירת הבדיקה והן במהלך הביצוע.
הבה נחקור כיצד ZAPTEST יכול לעזור לך לפתוח את היתרונות של גישת בדיקת קופסה שחורה שימושית זו.
1. בחירת כלי
חשוב לבחור בכלי המתאים לעבודה. רוב כלי אוטומציית הבדיקות מתמחים בבדיקות אינטרנט, נייד או שולחן עבודה. ZAPTEST מסוגלת לטפל בבדיקות על פני פלטפורמות ויישומים שונים, מה שהופך אותה לבחירה מוצקה.
2. כתוב וביצוע מקרי מבחן
ZAPTEST 1Script מאפשר לך לסרוק את ממשק המשתמש כדי לבנות אוטומציה של בדיקות. בנוסף, אתה יכול גם לסרוק דגמי אפליקציות אם אתה בשלב מוקדם של פיתוח. באמצעות התכונה Scan GUI, ZAPTEST יסרוק את כל אובייקטי הבדיקה ויוסיף אותם לרשימת האובייקטים.
מכאן, אתה יכול להוסיף אובייקטים לתרשים ולבנות את שלבי הבדיקה.
ZAPTEST מאפשר לך להפוך את כתיבת המקרים לאוטומטית בעזרת ממשק גרירה ושחרור פשוט. אתה לא צריך מומחיות בקידוד כדי לבנות מקרי בדיקה עם ZAPTEST. אז, מכאן, אתה יכול לבחור את הפעולה הרלוונטית מתוך שיטה נפתחת ולבנות מקרה מבחן המבוסס על ערכי הקלט הדרושים לממשק שלך. לאחר מכן, אתה יכול לבנות מקרי בדיקה עבור כל שקילות ולבצע את מקרי הבדיקה שלך. אתה יכול אפילו לעשות שימוש חוזר במקרי בדיקה ולערוך אותם בעורך Step, ולחסוך הרבה זמן.
3. דיווח וניהול תיקי מבחן
ZAPTEST מאפשר לך להריץ מקרי בדיקה במקביל, וחוסך זמן רב. זה יכול לעזור לך להפעיל מספר רב של מחיצות שקילות שונות בבת אחת או להפעיל קבוצות מסוימות של בדיקות.
קל לאסוף תוצאות הודות לדוחות מפורטים שנכשלו/עברו, צילומי מסך, יומני ביצוע ומדדי ביצועים הקשורים לכל מקרה בדיקה.
4. תחזוקת מקרה מבחן
אתה יכול גם פשוט לעקוב ולתחזק את מקרי הבדיקה שלך הודות ליכולות בקרת גרסאות איכותיות. יתרה מכך, משתמשי ZAPTEST יכולים לשכפל בדיקות ולהשתמש בהן מחדש כדי להשיג רמה חדשה של יעילות.
ZAPTEST מציע הרבה יותר פונקציונליות מלבד אוטומציה של מקרי בדיקה. עם חבילה של כלי RPA , ZAPTEST מציעה פונקציונליות 2 ב-1, המגשרת על הפער בין DevOps ל-BizOps בעתיד המסומן על ידי היפר-אוטומציה, שבו כל מה שניתן לאוטומטי יהיה אוטומטי.
מחשבות אחרונות
חלוקת שוויון היא פתרון אלגנטי למצבים שבהם הבודקים חייבים למצוא איזון בין יעילות ודיוק. עם תוכנות מסוימות המאפשרות מגוון כמעט אינסופי של כניסות, חלוקת מחלקות שקילות מסייעת לצוותים לפרק את נתוני הבדיקה לנתחים ניתנים לניהול, בגודל ביס, שניתן לבדוק כל אחד מהם ביסודיות.
