בדיקת מוטציות, או מוטציית תוכנית, היא טכניקת בדיקת קופסה לבנה המסייעת לחברות לפתח מגוון בדיקות תוכנה חדשות תוך ביקורת על התהליכים הנוכחיים של הפרויקט. זוהי גישה חדשה יחסית, כזו שמבטיחה שגם מפתחים וגם בודקים עובדים ברמה גבוהה.
יישום מוצלח או טוב כמו נהלי אבטחת האיכות שלו – כלומר חיוני שארגונים יאמצו יותר מסוג אחד של טכניקת בדיקה.
למידה על בדיקת מוטציות יכולה לעזור לצוותי הבדיקה להגביר את כישוריהם ואת הרפרטואר הכללי שלהם – ולאפשר להם לשפר את מהימנות הבדיקות הללו. בדיקת מוטציות היא תהליך מורכב ורגיש, ולכן חיוני שהבודקים יחקרו ביסודיות את היתרונות, האתגרים ותוכניות צד שלישי שיכולות להבטיח יישום מוצלח.
במאמר זה, אנו בוחנים בדיקות מוטציות וכיצד הן משפרות את הבטחת האיכות, כמו גם שיקולים מרכזיים אחרים עבור צוותי בדיקות תוכנה.
מהי בדיקת מוטציות בבדיקת תוכנה?
בהקשר של תוכנה, בדיקת מוטציות פירושה כאשר צוות אבטחת איכות מכניס באגים – או ‘מוטציות’ – בכוונה לקוד של אפליקציה כדי לראות כיצד הצוות מגיב. המטרה היא ליצור שגיאה ולוודא שחבילת הבדיקות מסוגלת לזהות כל שינוי באפליקציה.
בעת עריכת קוד התוכנית, בודק מוטציות עשוי להחליף ביטוי נכון/לא נכון, למחוק משפט או פשוט לשנות ערך. שגיאות אלו יכולות להתבטא במספר דרכים במהלך בדיקות תוכנה אחרות; כל אלה ניתנים לזיהוי בקלות על ידי צוות בדיקות מיומן ומנוסה.
המוטציות עצמן הן לעתים קרובות מאוד מינוריות, מה שמאפשר לבודק שמשנה את הקוד לראות כיצד הצוות מגלה את השינויים הללו. שינויים משמעותיים יהיו ברורים אפילו במבט חטוף – כך שטעויות קלות הן בדרך כלל הדרך הטובה ביותר להבטיח שהחברה משתמשת בשיטות בדיקה חזקות.
טכניקה זו בוחנת במיוחד את האפקטיביות של מקרי בדיקה של צוות; המסמכים המכילים את מידע הבדיקה. הצוות עשוי גם להשתמש בתוכנת אוטומציה של צד שלישי כדי להפעיל את הבדיקות הללו, ובמקרה זה בדיקת מוטציות בוחנת עד כמה פלטפורמה זו יכולה לזהות תקלות בקוד התוכנית.
1. מתי צריך לעשות בדיקת מוטציות?
מכיוון שמטרת בדיקת המוטציות היא לאמת ולשפר את בדיקות אבטחת האיכות הנוכחיות, חיוני לצוותים לבצע זאת בשלב מוקדם של הבדיקה. המשמעות היא שאם חבילת הבדיקות אינה מסוגלת לזהות ו’להרוג’ את המוטנטים, יש מספיק זמן לבצע שינויים מפליגים בכל קנה מידה בהליכי הבדיקה של הארגון.
מכיוון שזו שיטה רב-תכליתית, בדיקת מוטציות ניתנת ליישום כמעט לכל סוג של תוכנה, כולל תוכניות אינטרנט , נייד ושולחן עבודה . זה עובד הכי טוב בשלב בדיקת היחידה – שבוחן את הרכיבים הקטנים ביותר של אפליקציה.
2. כאשר אין צורך לבצע בדיקת מוטציות
יש עדיין כמה תרחישים שבהם מוטציה ובדיקת קופסה לבנה כללית אינם מתאימים לתוכנית; זה יכול לנבוע מסיבות שונות.
לדוגמה, אם הבודקים מכוונים רק לבדוק עם בדיקת קופסה שחורה – במקרה זה הם יתמקדו במקום הקצה הקדמי של אותה הפעלה או אפילו בשלב הבדיקה הכולל.
ישנן כמה חברות הרואות בבדיקת הקופסה הלבנה כמייגעת וגוזלת זמן, מה שעלול לגרום להן לדלג על התהליך. מקרי בדיקה חזקים ונבדקים היטב עשויים גם לעקוף את הצורך בבדיקת מוטציות שכן הדבר מראה על חריצותו ומחויבותו של הצוות להליכי בדיקה מדויקים.
3. מי מעורב בניתוח מוטציות?
ישנם מספר תפקידים שונים המעורבים בניתוח מוטציות, כולל:
• בודקי מוטציות
הם משנים את הקוד על ידי הצגת פגמים קלים שונים כדי להבטיח שתהליך הבדיקה עובד כמצופה. בודקים אלה הם בדרך כלל חברים קיימים בצוות אבטחת האיכות.
• בודקי אפליקציות
הם בודקים את הקוד באופן קבוע עבור כל בעיה, מזהים ומתקנים כל מוטציה שהם מוצאים. הם עורכים בדיקות קופסה לבנה כדי למצוא שגיאות קידוד – אבל גם משתמשים בטכניקות אחרות.
• מפתחי אפליקציות
הם מעצבים את תכונות התוכנית וכותבים את הקוד הראשוני. הם גם מתקנים את כל הבעיות שהבודקים מוצאים, ומבטיחים שהתוכנה במצב יציב לשחרור.
• מנהלי פרויקטים
הם מציעים הנחיות לגבי היישום ועשויים לעבוד לצד בודקי המוטציות כדי לראות את היעילות של הצוותים שלהם. הם מבטיחים סטנדרטים חזקים בכל שלב של פיתוח.
מה אנחנו בודקים עם מבחני מוטציה?
בדיקת מוטציות מתמקדת יותר בתהליכי בדיקה במקום באפליקציה. לשם כך הוא בוחן את הדברים הבאים:
1. מקרי מבחן
מקרי בדיקה הם מסמכים המכילים מידע מפורט על כל בדיקה, כולל התוצאות שהבודקים מצפים מכל בדיקה בודדת. מקרי בדיקה עקביים ומדויקים מספקים לחברי צוות QA מושג לגבי תקינות האפליקציה וכיצד הביצועים שלה מתאימים לציפיות המשרד.
המידע במקרי בדיקה אלו יכול לקבוע את יכולתו של הבוחן לזהות פגמים מסוימים – כולל אלה שבדיקת מוטציות גורמת.
2. תקני בדיקה
מבחני מוטציות בודקים מקרוב את הליכי הבדיקה הנוכחיים כדי להבטיח שחברי הצוות יכולים לזהות אפילו בעיות קטנות שעלולות להשפיע על תפיסת המשתמש את התוכנה.
החריצות והכשירות של הבודקים עשויים אפילו להיות הגורמים העיקריים שעסק מעריך עם בדיקות אלו. ללא תשומת לב חזקה לפרטים בכל שלב, הבודקים עלולים לפספס מוטציות רציניות שקיימות בתוכנית.
3. יחידות קוד בודדות
בדיקות מוטציות נפוצות במהלך חלק בדיקת היחידה של הפיתוח. זה בוחן רכיבים בודדים כדי לשמור על התמקדות חזקה בכל בדיקה, תוך אופטימיזציה משמעותית של התהליך כולו על-ידי לוודא שהבודקים עובדים רק עם שורות הקוד הרלוונטיות.
מכיוון שבדיקות מוטציות הן לעתים קרובות בשלב מוקדם של הבטחת האיכות ויכולות להוות מקדים לבדיקות בקנה מידה מלא, גישה זו יכולה להגביר את המהירות מבלי להתפשר על הדיוק.
4. עדכוני תוכנית
עדכוני תוכנה כוללים בדרך כלל הפעלה מחדש של תהליך הבדיקה כדי לוודא שאין תקלות חדשות וששגיאות קודמות אינן צצות מחדש.
חזרה על בדיקות מוטציות היא חלק מרכזי בכך ועוזרת לקדם תקני בדיקה עקביים לאחר שינויים גדולים בתוכנה.
צוות הבדיקה עשוי לשקול בדיקות יסודיות לאחר עדכון כמיותרות, אך מוטציית קוד יכולה להבטיח שהם מבינים את חשיבות הבדיקה בכל שלב של פיתוח.
5. תוכנת אוטומציה
חברות גם עורכות בדיקות מוטציות כדי לבדוק את חבילות הבדיקות האוטומטיות שלהן ולוודא שהן מסוגלות להבחין בקוד שעבר מוטציה, בין היתר.
אם אפליקציית בדיקה של צד שלישי יכולה לזהות שינויים חיצוניים בתוכנית ואולי אפילו לתקן אותה, פירוש הדבר שהארגון יכול לסמוך על התוכנה שתהפוך את הבדיקות לאוטומטיות.
חיוני שחברות יאשרו את גישת האוטומציה שלהן; זה נותן שקט נפשי לכל בוחן.
6. אסטרטגיית אוטומציה
האופן שבו החברה משלבת אוטומציה בתהליכים חשובה לא פחות מהתוכנה שהיא מעסיקה; לדוגמה, הוא עשוי להחליט ליישם היפר-אוטומציה . זה מאפשר לחברה להחליט בצורה חכמה אילו בדיקות מוטציה ותוכנה לבצע אוטומציה.
ללא אסטרטגיית אוטומציה חזקה המתאימה למגוון העצום הקיים בקוד של אפליקציה, בדיקות מסוימות עשויות להיות בלתי תואמות לאוטומציה – מה שמגביל את יכולות הפלטפורמה.
7. הבקשה
בעוד שבדיקת מוטציות מתמקדת בצוות הבדיקה יותר מאשר באפליקציה, היא עדיין עשויה להדגיש מידע משמעותי על תוכנית זו.
לדוגמה, בדיקת מוטציות מראה כיצד תוכנה מגיבה לשינויים בקוד שלה, כולל אם היא מסמנת את הבעיות הללו בצורה שהצוות מצפה לה.
גישה זו אינה טכניקת בדיקת תוכנה אך עדיין מסוגלת להציע נתונים מעניינים על הפעולות הפנימיות שלה.
מחזור חיים של מבחני מוטציות
מחזור החיים הרגיל של בדיקת מוטציות הוא כדלקמן:
1. ניתוח דרישות
השלב הראשון של כל מחזור חיים של בדיקת מוטציות הוא להבין בדיוק מה דורש אימות ואילו חלקים מהקוד של האפליקציה היו מרוויחים יותר מבדיקות אלו.
הצוות עשוי לדבר עם מפתחים ומנהלים כדי לקבוע את החששות שלהם ולהתחיל לטפל בהם.
2. תכנון מבחן
לאחר מכן, הבודקים מתחילים לפתח את הבדיקות המדויקות שהם מתכוונים ליישם – במקרה זה, המוטציות שיציעו את התובנה הטובה ביותר.
שלב זה קובע את אסטרטגיית בדיקת המוטציות הכוללת וכיצד הצוות מתכוון ליישם ביעילות את מוטציות הקוד המיועדות.
3. פיתוח מקרה מבחן
בדיקת מוטציות כוללת תיעוד בדיקה נפרד משלה, כולל מידע על הקוד שעבר מוטציה וכיצד הם מצפים מהבודקים לתקן את הבעיה.
רישום טוב מבטיח שהבדיקות יתקיימו כמתוכנן ויכול לעזור לצוות לשמור על מחויבותו לסטנדרטים גבוהים של בדיקות.
4. בדיקת הגדרת הסביבה
הבודקים מוודאים שהאפליקציה מוכנה עבורם לשינוי – ושיש להם נוהל לטפל בבעיות הללו אם חברי צוות אחרים אינם מסוגלים לזהות אותם.
כחלק מכך, בודקי המוטציות מקימים שרת בדיקה ומשתמשים בו כקנבס למוטציות שלהם.
5. ביצוע בדיקה
לאחר השלמת ההכנות, הבודקים משנים את הקוד בכמה מרכיבים של האפליקציה; לאחר מכן הם ממתינים לבוחנים אחרים שישימו לב לבעיות ויתקנו אותן.
גם בודקי המוטציות וגם בודקי האפליקציות חייבים לתעד זאת בהרחבה כדי לוודא שהרשומות שלהם תקינות.
6. סגירת מחזור בדיקה
לאחר השלמת הבדיקה, בודקי המוטציות בודקים פעמיים שכל השינויים שהם ביצעו מתוקנים על ידי בודקי האפליקציה או על ידי עצמם.
לאחר מכן הם סוגרים את מחזור הבדיקה ומנתחים את התוצאות, דנים כיצד הבודקים הגיבו לשגיאות השונות לצד יכולתם לתקן אותן.
7. חזרה על מבחן
לאחר סגירת מחזור הבדיקה, ייתכן שיהיה צורך להפעילו מחדש לאחר עדכוני תוכנה עתידיים.
כל שינוי באפליקציה משנה את הפונקציונליות שלו בדרך כלשהי, וכתוצאה מכך לאפשרויות חדשות שהצוות חייב לתת עליהן את הדעת על מנת להבטיח שתהליך הבדיקה שלו מספיק קפדני.
היתרונות של בדיקת מוטציות
ישנם יתרונות רבים לביצוע בדיקות מוטציות, כולל:
1. מאמת את תהליך הבדיקה
היתרון העיקרי של בדיקת מוטציות הוא היכולת שלה להראות כיצד הבודקים של החברה ניגשים לתוכנה – והיכולת שלהם לזהות בעיות קידוד. זה גם מבטיח שמקרי הבדיקה של הצוות יהיו מספיק מקיפים ומכסים את כל הבדיקות הנדרשות.
מבחני מוטציות בודקים את הליך הבדיקה הכולל של ארגון כדי להבטיח שהוא פועל כמצופה.
2. מבטיח אוטומציה חזקה
בדיקת מוטציות מסייעת לצוות לבדוק אם פלטפורמת אוטומציית הבדיקות של צד שלישי מסוגלת לזהות כראוי שגיאות בתוך הקוד ולטפל בהן בצורה הנכונה.
אם התוכנה הזו לא מצליחה לזהות אותם גם לאחר הכיול הדרוש, אולי כדאי להחליף את הפלטפורמה בפלטפורמה שיכולה לעבור בקלות את הבדיקות הללו.
3. כיסוי טוב
כל תהליך בדיקת תוכנה חייב להיות מסוגל לכסות באופן נרחב את האפליקציה כולה כדי להבטיח שכל היבט יקבל את רמת תשומת הלב הדרושה.
בודקי מוטציות יכולים לשנות כל חלק בקוד של תוכנית; יישום טוב מאפשר לבדיקות אלו להקיף כל תכונה מרכזית. זה מלמד בודקים לחפש בעיות בכל האפליקציה.
4. בוחן את קוד המקור
מכיוון שבדיקת מוטציות כוללת עבודה עם הקוד וביצוע שינויים ישירים במידת הצורך, שיטה זו יכולה גם להדגיש סקריפטים לא אופטימליים הקיימים באפליקציה.
בודקי תוכנה רשאים לאשר את התוכנית ולערוך את סבב הבדיקות הרגיל שלהם רק אם הקוד של התוכנה מתאים; בדיקות אלו מאפשרות לבודקים להדגיש בעיות עתידיות פוטנציאליות.
5. מוביל לתוכנה טובה יותר
בדיקת מוטציות עוזרת לוודא שתהליכי הבדיקה של האפליקציה מתאימים לדרישות התוכנית.
אם ניתוח מוטציות מגלה שצוות אבטחת האיכות אינו פועל לפי הנהלים הנכונים או שמקרי הבדיקה אינם מספקים, הבודקים יכולים לפעול לשיפור זה. ללא בדיקת נאותות זו, הארגון עשוי לשחרר מוצר פגום מבלי שיודעת זאת.
6. יעיל לשפות שונות
לא משנה השפה שצוות הבדיקות משתמש עבור היישום שלו, ישנן אפשרויות תוכנה זמינות שיכולות להציע ניתוח מוטציות באיכות גבוהה.
זה כולל מספר תכונות של איכות חיים הספציפיות לשפה, ומייעלות את הבדיקות לאמינות רבה יותר. גישה מותאמת אישית לשפות שונות משפרת את האיכות של כל מבחן בנפרד.
7. כלים נגישים במיוחד
רבות מפלטפורמות המוטציות המובילות הן קוד פתוח לחלוטין – כלומר הן מציעות יותר התאמה אישית ומגוון מקיף של תכונות בחינם או בעלויות נמוכות באופן דרסטי.
עם פחות מחסומים בהשוואה לצורות רבות אחרות של בדיקות, מוטציית קוד היא דרך שימושית ונוחה לעסקים להעריך, או אפילו לשפר, את גישת אבטחת האיכות שלהם.
אתגרים של בדיקת מוטציות
תהליך זה כולל גם אתגרים רבים, כגון:
1. דורש ידע בתכנות
כדי שהבודקים יבצעו את הבדיקות הללו, עליהם להיות בעלי הבנה מקיפה של התוכנית והקוד, מה שמקשה על בודקים פחות מנוסים לתרום.
עסק יכול לבחון תוכנה רק בדרכים שמתאימות לכישורים הקיימים של הבודקים; במיוחד, היכולת שלהם לערוך אפליקציה וליצור שגיאת קידוד הניתנת לתיקון.
2. לא מתאים לבדיקת קופסה שחורה
בדיקת Black-box כוללת בעיקר הסתכלות על הקצה הקדמי של אפליקציה מבלי לבדוק את פעולתו הפנימית והקוד – זה למעשה אינו תואם לבדיקת מוטציות.
כתוצאה מכך, בדיקות אלו מועילות רק עבור בדיקות מסוימות בהשוואה לשיטות אחרות; רבים מהם יכולים להציע כיסוי הרבה יותר גדול של כל שלב הבדיקה.
3. תכנון מבחני מוטציה לוקח זמן רב
מוטציית קוד יכולה להיות תהליך מייגע בגלל שהצוות צריך למצוא רכיבים בודדים שכדאי לבצע מוטציה. ההחלטה אילו מוטציות לחקק עשויה להימשך זמן רב; זה יכול להיות בעייתי כאשר סוגי בדיקות אחרים ממתינים למעשה לבדיקות אלה כדי לאמת את גישת הבדיקות של החברה.
4. עשוי לדרוש מוטציות קוד רבות
בהתאם לקווים דומים, פרויקטים מורכבים מצדיקים באופן טבעי מספר גבוה יותר של מוטנטים כדי להבטיח גישת בדיקה מקיפה. זה מוסיף יותר זמן לשלב המוטציה ויכול לכלול שינויים ידניים רבים בקוד האפליקציה.
ללא תוכנת אוטומציה איכותית של בדיקות עם יכולות מוטציות של תוכניות, זה עלול להיות קשה לבודקים ליישם בהצלחה.
5. בודקים עשויים שלא להבחין בשגיאות
הדאגה הגדולה ביותר שיש לבודקי מוטציות ומנהלי פרויקטים לעתים קרובות בעת יישום הבדיקות הללו היא האפשרות שבוחני תוכנה (ידניים או אוטומטיים) פשוט לא יבחינו בבעיות.
זה עשוי לדרוש שיפוץ מלא של נהלי הבדיקה של המשרד – אם כי זה עדיין עשוי לספק לבודקים מידע חיוני על תקני אבטחת האיכות שלהם.
6. יכול להיות עתיר זיכרון
בדיקת מוטציות דורשת בדרך כלל כמות גבוהה של כוח עיבוד, אם כי זה יכול להיות תלוי באפליקציה שהבודקים משתמשים בה.
אם לארגון יש מספר מצומצם של מכונות או שלמכשירים אלה יש מפרט נמוך, הם עלולים להתקשה להפעיל יותר מדי מוטציות בו-זמנית. זה משפיע על כמה בדיקות הם יכולים לבצע לפני ששלב הבדיקה מסתיים.
7. דיווחים עשויים להיות צפופים במידע
למרות שזה תלוי בעיקר בממשק של כלי בדיקת המוטציות של צוות, הדוחות שהם יוצרים יכולים להיות קשים לניתוח.
זה אומר שלוקח זמן למיין אותם באופן ידני ולמצוא את תוצאות הבדיקה הנכונות; תוכניות מסוימות מאפשרות למשתמשים להתאים אישית את תהליך הדיווח בפועל; זה משתנה מיישום אחד למשנהו.
מאפיינים של מבחני מוטציה
המאפיינים העיקריים של בדיקות מוטציות יעילות הן:
1. מקיף
בדיקות אלה מכסות כל היבט מרכזי של התוכנה; חברות עם מספיק משאבים עשויות אפילו לתכנן בדיקת מוטציה לכל מקרה בדיקה רגיל.
בעוד שהמספר המדויק תלוי ביכולות והעדפות הארגון, בדיקות מוטציות יעילות מכסות מגוון רחב של תכונות מקודדות.
2. אסטרטגי
מוטציות בתוכנית צריכות לפעול באופן דומה על פי מבנה ברור ומתוכנן היטב המאפשר את מטרות הבדיקה הכוללות של הארגון.
לדוגמה, השגיאות שהם מייצרים עשויות להעריך כשלים ריאליסטיים בבדיקה המאפשרים לבודקים לצפות את הבעיות הללו אם הן מתרחשות באופן טבעי, מה שמשפר משמעותית את תהליך הבדיקה של החברה.
3. בונה
מטרת בדיקת המוטציות היא לזהות חסרונות בבדיקה – להראות כיצד הצוות יכול לשפר את הבדיקות ולתקן שגיאות קלות כשהן מופיעות.
בודקי מוטציות חייבים לתעדף מוטנטים ‘לא חוקיים’ המשפיעים על הפונקציונליות של התוכנה, מה שמאפשר שיפורי בדיקה ברורים יותר בכל הפרויקט.
4. מנע
בדיקות אלו קיימות כדי לאמת את האסטרטגיה הכוללת של הצוות; המשמעות היא שבדיקת מוטציות עובדת טוב יותר בשלבי ההתפתחות המוקדמים.
אם הבודקים מבחינים בפגמים משמעותיים בגישת אבטחת האיכות שלהם, זה נותן להם את הזמן הדרוש לשנות את מקרי הבדיקה שלהם כדי לוודא שהם מתאימים.
5. עקבי
בדיקת מוטציות על פני איטרציות שונות של יישום אמורות להחזיר תוצאות עקביות, תוך הוספת בדיקות נוספות כדי להתאים לשינויי תוכנה.
בדיקות עוקבות חייבות לכלול את אותה תשומת לב לפרטים על מנת לשמור על יעילותן – ללא דיוק זה, בדיקות המוטציה יכולות להיות פחות מדויקות.
6. עדין
בדיקות מוטציות מטרתן לבחון את יכולתו של צוות אבטחת האיכות לזהות פגמי קוד באמצעות הבדיקות והפלטפורמות של צד שלישי.
המשמעות היא שהבדיקות לא אמורות להיות ברורות מיד לכל מי שבודק את התוכנה; המטרה היא לבחון כיצד בודקים מגיבים לבעיות קוד קלות.
7. שיתוף פעולה
כמו בכל בדיקת תוכנה, מוטציית קוד היא תהליך שדורש בדרך כלל עבודת צוות ותקשורת כדי להבטיח את הצלחתו. שמירה על אווירה שיתופית עוזרת להימנע ממגורות מידע, שעלולות לגרום לתקשורת שגויה – זה גם מבטיח שכל בודק יישאר ממוקד במשימות העומדות בפניו.
סוגי בדיקות מוטציות
שלושת הסוגים העיקריים של בדיקות מוטציה הם:
1. מוטציית ערך
מוטציות ערכים משנות ישירות את הערכים בתוך הקוד, ומשנות מספר או אות אחת לאחרת באופן שמשפיע על הפונקציונליות של האפליקציה.
לדוגמה, הבוחן יכול לשנות את הפרמטרים המדויקים של התוכנית, כגון המספרים שהוא מגיב אליהם. בודקי מוטציות עשויים לכוון ספציפית לערכים הקבועים של תוכנה, שכן אלה נשארים תמיד זהים במהלך פעולות רגילות.
2. מוטציית החלטה
מוטציות החלטה משנות אופרטורים אריתמטיים ולוגיים, ומשנות למעשה את האופן שבו האפליקציה מגיבה למצבים ספציפיים.
לדוגמה, החלפת אופרטור גדול מאת (> ) עם פחות מאופרטור (< ) באופן טבעי משפיע על הפלט של התוכנית. בודקים עשויים גם להחליף ‘או’ ב’ו’ או להיפך, ולשנות מהותית את התוכנה הזו ואת האופן שבו היא מפרשת את המידע שבודקים אחרים ומשתמשים אפשריים מספקים.
3. מוטציה בהצהרה
מוטציות בהצהרות משנות את ההצהרות בפועל של הקוד, ומשנות את הכללים שבהם משתמש יישום כדי לקבל החלטות. בודקים עשויים לשנות את התוכן של שורות אלה, לשכפל אותם, או אפילו למחוק אותם כדי לבדוק כיצד התוכנית המוטנטית משפיעה על פונקציונליות התוכנה.
מוטציות אלו משנות את אבני הבניין של תוכנית, עלולות להסיר פונקציות שלמות או למנוע מהן לפעול בדרך אחרת.
מנקה קצת בלבול
– בדיקת מוטציות לעומת בדיקת רגרסיה
בדיקת מוטציות ורגרסיה הן שתיהן גישות שימושיות לבדיקות תוכנה – הבנה של כל אחת מהטכניקות הללו יכולה לשפר את אבטחת האיכות הכוללת של החברה.
1. מה זה בדיקת רגרסיה?
בדיקת רגרסיה היא כאשר בודקים בוחנים תוכנה בין איטרציות שונות כדי לוודא שהיא עדיין פועלת למרות שינויים בקוד.
אפילו שינויים קלים עלולים לגרום לבעיות חמורות ללא בדיקות אלה, שעלולות לגרום לבאגים קודמים להופיע מחדש. זה בדרך כלל דורש אוטומציה בשל האופי המורכב של בדיקה חוזרת של כל רכיב; חברות רבות מוותרות על מבחני רגרסיה מסיבה זו.
בודקים יכולים לבצע את הבדיקות הללו על יחידות בודדות, רכיבים בודדים או המוצר כולו – הבדיקות המדויקות הנדרשות תלויות בעיקר בפרויקט ובהיקף שלו.
2. מה ההבדל בין מבחני מוטציה ורגרסיה?
בדיקות רגרסיה מתמקדות בעיקר בבדיקת התוכנית והפונקציונליות שלה , בעוד מוטציית קוד בוחנת במקום זאת כיצד הבודקים מגיבים לבעיות.
הראשון גם מתרחש במידה רבה לאחר איטרציות מרובות של תוכנית בעוד שבדיקות מוטציות יכולות להיות בכל שלב של התפתחות – אם כי בדרך כלל בחלקים המוקדמים של שלב הבדיקה.
הן מבחני רגרסיה והן מבחני מוטציה יכולים להתמודד עם יחידות קידוד בודדות וכיצד שינויים קלים עלולים לגרום לבעיות משמעותיות שהבודקים חייבים לעבוד כדי לתקן.
3. מסקנה: בדיקת מוטציות לעומת בדיקה אוטומטית
אוטומציה היא לעתים קרובות חלק מרכזי בבדיקת מוטציות בשל רוחב הבדיקות והיחידות – זה הופך אותה לפעמים חיונית לתהליך בדיקה מוצלח ומקיף.
חברות משתמשות בדרך כלל במוטציות קוד כדי לבחון את פלטפורמת האוטומציה של צד שלישי שלהן ועד כמה היא מזהה סקריפטים בעייתיים.
שילוב של קטלוג יסודי של בדיקות מוטציות עם תוכנה אוטומטית יכול להגדיל משמעותית את הכיסוי של המשרד ולהבטיח תוצאות חזקות יותר.
למרות שמדובר בשתי שיטות בדיקה נפרדות, הן אינן חייבות להתנגד זו לזו. שילוב אוטומציה של תהליכים רובוטיים , למשל, יכול להגביר את אסטרטגיית בדיקת המוטציות של חברה.
מה אתה צריך כדי להתחיל בדיקת מוטציות בהנדסת תוכנה?
הדרישות הרגילות לבדיקת מוטציות מקיפות כוללות:
1. אסטרטגיית בדיקה ברורה
על צוות הבודקים לקבוע אסטרטגיה לבדיקת מוטציות, לרבות אילו רכיבים ויחידות הכי חשוב לבחון.
לדוגמה, היבטים מסוימים של הקוד עשויים להיות חלק בלתי נפרד מההצלחה והפונקציונליות של יישום; הבודקים צריכים לוודא שיש מספיק מוטציות כדי להכיל זאת.
לוח הזמנים של בדיקות המוטציות של החברה הוא גם שיקול חיוני שכן זה מבטיח שלבודקים יהיה מספיק זמן לחקור את הקוד.
2. אין זחילת היקף
אפילו עם אסטרטגיה יסודית שמגדירה את גישת החברה לבדיקת מוטציות, ייתכן שמספר בדיקות גבוה משמעותית מהנדרש.
היעילות היא ערך עליון לאורך הליך זה, במיוחד מכיוון ששלבי בדיקה אחרים עשויים לחכות לצוות כדי למצוא ולהרוג את המוטציות. הבודקים חייבים להגדיר בבירור את היקפם לפני שהם מתחילים לשנות את הקוד; זה מבטיח שהכל ניתן לניהול בתוך מסגרת זמן מעשית.
3. תיעוד קפדני
כל תהליך בדיקה נהנה מתיעוד מלא – לרוב בצורה של מקרי בדיקה המפרטים את הבדיקות הבודדות ואת כל המוטנט הרלוונטי.
זה ממחיש את ההתקדמות הנוכחית של הצוות לאורך המבחנים, וזה שימושי במיוחד עבור מנהלים ומנהלים. תיעוד כל מוטציית קוד גם עוזר לבודקים לשמור על רישומים ברורים לגבי השינויים שהם מבצעים.
אם צוות אבטחת האיכות מתקשה למצוא את המוטציות הללו בזמן הבדיקה, המסמכים הללו משמשים למעשה כמפתח תשובה.
4. בודקים מיומנים
הבודקים שמשנים את הקוד חייבים להיות בעלי הבנה טובה של התוכנה – כולל הדרכים הרבות שבהן הם יכולים לבצע מוטציה או אפילו לשבור אותה.
בודקי מוטציות יודעים בערך כיצד השינויים שלהם ישפיעו על האפליקציה וכיצד חברי צוות אבטחת איכות אחרים יכולים לזהות את הקוד המוטנטי.
זה בדרך כלל דורש רמה טובה של ידע בתכנות. כדי שניתוח מוטציות יהיה יעיל, בודקי התוכנה צריכים גם להיות בעלי מיומנויות מפותחות וניסיון בבדיקות.
5. תוכנת אוטומציה
תוכנת אוטומציה של צד שלישי עשויה להיות הכרח לפני בדיקת מוטציות בשל מספר הבדיקות שתהליך זה דורש לעתים קרובות. זה נכון במיוחד עבור יישומים מסובכים עם יותר קוד ותכונות שצוות אבטחת האיכות יוכל לבחון.
חברות עשויות לבצע בדיקות אלו במיוחד כדי לבדוק כיצד תוכנות אוטומציה מגיבות לשגיאות קידוד. זה יכול להיות חלק מרכזי בתהליך הניסיון של החברה כדי להחליט אילו תוכניות הן השימושיות ביותר.
תהליך בדיקת מוטציות
השלבים הרגילים שהבודקים מבצעים בדרך כלל בעת ביצוע ניתוח מוטציות הם:
1. הכינו את המבחנים
ההכנה היא השלב הראשון בכל תהליך בדיקה. זה כולל משא ומתן על הבדיקות המדויקות ליישום וקבלת כל אישור נדרש – כגון מנהלי החברה ומבעלי עניין.
על הבודקים לפתח את הבדיקות הללו בצורה שתתאים לציר הזמן של הפרויקט ועדיין לכסות כל מרכיב מרכזי. התכנון של הצוות יכול לקבוע את היעילות של מוטציות הקוד שלהם.
2. הציגו מוטנטים ותקלות
לאחר השלמת ההכנות, צוות הבדיקה מתחיל לשנות את הקוד, לשנות אותו בהתאם לתוכנית שלהם להציג תקלות ספציפיות. שגיאות אלו צריכות להיות מינוריות יחסית מכיוון שהדבר מאפשר לבודקים לאמוד את שאר היכולת של הצוות לזהות בעיות קידוד.
תקלות קלות יכולות גם לעזור לארגון לבדוק את הרגישות של תוכנת האוטומציה של הצד השלישי שלו.
3. החל את מקרי הבדיקה
מקרי הבדיקה חייבים להסביר כל נקודת כשל אפשרית באפליקציה – הדבר עשוי לדרוש שכתוב אם התוכנית המוטנטית מסוגלת לתפקד ללא שגיאות.
מקרי הבדיקה של תוכנית מייצגים את כל רוחב הבדיקות שמבצעים בודקים; כל אחד מהם צריך לעזור לבודקים לחשוף כל מוטציות נסתרות ולהיות חלק בלתי נפרד מהשימושיות של האפליקציה.
4. השוו את התוצאות
לאחר הוספת שגיאות מוטציות לתוכנית ויישום מקרי הבדיקה של הצוות, הצוות חייב להשוות את התוצאות הן מהתוכניות המקוריות והן מהתוכנות המוטנטיות.
התקווה היא שלכל בדיקה מוצלחת במקור, תהיה גם שגיאה ביישום המוטנטי. זה מדגים את היכולות של הבודקים וגם של הכלים שהם משתמשים בהם.
5. לפעול לפי תפוקות שונות
אם יש פלטים שונים בין התוכניות המקוריות והמוטנטיות כפי שהבודקים מצפים, זה אומר שמקרה הבדיקה יכול להרוג את המוטנט בהצלחה על ידי הדגמת נוכחותו.
לאחר מכן הבודקים יכולים להמשיך בביטחון במתודולוגיה שלהם וביכולתם לזהות בעיות קידוד. אין צורך בשינויים במקרי הבדיקה עבור בדיקות ספציפיות אלו.
6. שנה את המקרים במידת הצורך
מוטציות מסוימות בקוד עשויות לגרום למסקנות זהות בין התוכניות השונות, מה שמצביע על כך שמקרי הבדיקה אינם מסוגלים להדגיש בהצלחה כל שגיאה אפשרית ביישום.
במקרים אלה, המוטנט נשאר ‘חי’ ויכול להמשיך ולהשפיע על התוכנה בדרכים שלבודקים אין מסגרת לטפל בהם – זה מוביל ליצירת מקרי בדיקה טובים יותר.
כיצד ליצור תוכניות מוטציות
תוכניות מוטנטיות זהות למעשה לתוכניות המקוריות, למעט שינוי קטן אחד שיכול להשפיע על הפונקציונליות של יישום בדרכים קטנות אך מורגשות.
מקרי בדיקה מקיפים ומפורטים עוזרים לבוחן או לחבילת תוכנה לאתר את השינויים הללו ואת התקלות הנובעות מהם. כל מקרה שהחברה בודקת מצריך תוכנית מקורית וגם מוטציה, המציגה את ההשפעות של כל שינוי בבידוד.
התוכניות בדרך כלל משכפלות שגיאות מציאותיות, כגון שגיאות כתיב בקידוד. כמו כן, חשוב לבודקים להימנע ממוטנטים “מתים שנולדו” המונעים את ביצוע האפליקציה – זה ברור מדי לבודקים.
מה לשנות בתוכנית מוטנטית?
כמו במשתני בדיקות תוכנה רבים, השינויים המדויקים שהבודקים מבצעים תלויים באפליקציה ובקוד שלה.
ישנן שלוש קטגוריות המקיפות את רוב מבחני המוטציה: אופרנדים, ביטויים והצהרות. שינוי כל אחד מאלה יכול ליצור תוכנית מוטנטית יעילה – מראה כיצד הערכים או הכללים השונים משפיעים על עצם ההיגיון שתוכנית משתמשת בו.
קטגוריות אלו מתייחסות לשלושת הסוגים העיקריים של מוטציות שהבודקים חוקרים; אלו הן מוטציות החלטה, ערך והצהרה בהתאמה. השינויים צריכים להיות מינוריים ואסור להם למנוע לחלוטין את ביצוע הבדיקה.
שיטות עבודה מומלצות לבדיקת מוטציות
בעת ביצוע בדיקות מוטציות בהקשר של בדיקת תוכנה, ישנן שיטות עבודה מסוימות שכדאי לעקוב בהן המבטיחות תוצאות חזקות, כגון:
1. למקסם את ציון המוטציה
ציון המוטציות של תוכנית הוא אחוז המוטנטים שצוות או אפליקציה יכולים לזהות או ‘להרוג’ בהצלחה.
לדוגמה, אם בסבב של בדיקת מוטציות יש 40 מוטציות והבודקים מוצאים 36, ציון המוטציה הוא 90% – המטרה של הצוות היא תמיד להבטיח ציון של 100%.
2. בחר מוטנטים באופן אקראי
למרות שזה יכול לעזור לתעדף רכיבים מסוימים ולבדוק אותם בצורה יסודית יותר, זה גם שימושי לבודקים לבחור באקראי אילו מוטנטים להוסיף – במיוחד בדד-ליין קצר.
כל עוד בדיקות אלו מייצגות כל סוג משמעותי של מוטציה, צוות אבטחת האיכות יכול לאמת את אסטרטגיית בדיקת התוכנה הכוללת שלו.
3. שמרו על השינויים קטנים
מוטציות הקוד צריכות לייצג סטיות מינוריות מהתוכנית המקורית שכן הדבר ממחיש את מידת הסבירות שבודק יזהה שגיאות מסוימות; בעיות קידוד קלות גם מדגימות עד כמה התוכנה שלהם רגישה.
זה חיוני שבוחני מוטציות ימצאו איזון המאפשר לשינויים הקטנים הללו עדיין לייצר תקלות ניכרות.
4. מוטציה אחת לתוכנית
בדיקת מוטציות בוחנת מקרי בדיקה בודדים בבודדים כדי לבדוק עד כמה הם מקיפים. כדי לעזור עם זה, כל תוכנית שעברה מוטציה צריכה להיות רק שינוי אחד מהמקור.
ייתכן שתוכניות עם מוטציות מרובות לא יוכלו להתאים ביעילות למקרי בדיקה; המוטציות עלולות להתנגש זו בזו.
5. שקלו היטב תוכנות אוטומציה
חברות משתמשות לעתים קרובות במוטציית קוד כדי לאמת את השימוש של הצוות בתוכנת אוטומציה ולוודא שהוא מסוגל לזהות שגיאות ביעילות כמו בודק אנושי.
המשמעות היא שבחירה בפלטפורמת האוטומציה הנכונה יכולה להיות שיקול חשוב, כמו גם האפשרות לשלב אוטומציה רובוטית של תהליכים .
6. השתמש בפיתוח מונחה מבחן
פיתוח מונחה בדיקה (TDD) מתייחס לטכניקה ספציפית הלוקחת בחשבון דרישות בדיקה בכל שלב של פיתוח.
זה עוזר להבטיח שמקרי הבדיקה תואמים לחלוטין לתוכנה – מה שמאפשר לה לעבור בקלות בדיקות מוטציות וליצור תוכנית טובה יותר המסתנכרנת עם תהליכי אבטחת איכות.
סוגי פלטים ממבחן מוטציה
ישנם מספר תפוקות שבדיקות מוטציות מייצרות, כולל:
1. תוכנית מוטנטים
התוכניות המוטנטיות הן פלט טבעי של בדיקות אלה; הבודקים יוצרים אותם כדי לשקף את מקרי הבדיקה הנוכחיים שלהם ואת הבעיות שהם עוזרים לזהות. התוכניות בדרך כלל חורגות מהמקבילה המקורית שלהן רק בדרך אחת מינורית אך משמעותית כדי להבטיח אמינות רבה יותר.
2. מוטציה חיה או מתה
לאחר הבדיקות, מוטציה ‘נהרגת’ או נשארת ‘חיה’ – זה פשוט מתייחס לשאלה אם הבוחן (או התוכנה שלו) מזהה בהצלחה בעיית קידוד או לא.
אם המוטנט יישאר בחיים, מקרי הבדיקה עשויים להזדקק לשינויים רציניים.
3. מקרה מבחן מוטציה
צוות אבטחת האיכות משתמש במקרי בדיקה נפרדים ספציפיים למוטציה שמתעדים מידע על התוכניות המוטנטיות שלהם.
זה עוזר להבטיח שלצוות יש רישומים מקיפים עבור כל בדיקה; מסמכים אלה כוללים פרטים על המוטציות והשפעותיהן על התוכנית.
4. ציון מוטציה
המטרה הסופית של כל מבחן מוטציה היא להגיע לציון מוטציה של 100%, כאשר נוהלי הבדיקה של החברה מאתרים והורגים כל מוטציה בהצלחה. כל דבר פחות מזה מצביע על כך שמקרי הבדיקה והתהליכים הכלליים שלהם דורשים שיפור כדי לזהות קוד בעייתי.
דוגמאות לבדיקת מוטציות
להלן שלוש דוגמאות לבדיקת מוטציות:
1. דוגמה למוטציית ערך
מוטציות ערך כרוכות בשינוי קבוע או פרמטר שיכולים לשנות את גבולות התוכנית. לדוגמה, תוכנה של מכונת קופה אוטומטית עשויה להשתמש במשקל של פריט מזון כדי לקבוע את מחירו.
הבודקים עשויים לשנות את הקוד שמאחורי תוכנית זו כדי לשנות את פרמטרי המשקל, ולהפוך את המזון ליקר בהרבה לכל אונקיה או קילו. הבוחן או פלטפורמת הבדיקה אמורים להיות מסוגלים לזהות את ההשפעות של הערך השונה על תוכנית זו.
מכיוון ששגיאה זו משנה את אחת התכונות העיקריות של התוכנה, מקרי הבדיקה צריכים להבחין בשגיאה זו ולהתריע לצוות.
2. דוגמה למוטציית החלטה
מוטציות החלטה כרוכות בשינוי אופרטור אריתמטי או לוגי, היפוך או שינוי אחר של האופן שבו יישום זה מגיב לקלט המשתמש. אם נחזור לדוגמא של קופה עצמית, מכונות אלו יכולות לסמן פריט עם משקל גבוה באופן בלתי צפוי, אולי בגלל שגיאת משתמש.
הקוד של המכונה יכול לעשות זאת באמצעות “אם (א> החלטה ב)” – כאשר ‘ב’ משקף את המשקל הצפוי, ו-‘a’ מתאים למשקל בפועל. הצוות עשוי לשנות את זה ל-“if (a≤b)”, מה שישנה את אופן התגובה של התשלום; זה יסמן את הפריט אפילו במשקל הצפוי.
3. דוגמה למוטציה בהצהרה
מוטציות של הצהרות כרוכות בשינוי כלל או פלט – זה עשוי לכלול אפילו מחיקה של הצהרות מהאפליקציה לחלוטין. מוטציות אלו עשויות להיות בולטות יותר מאחרות, בהתאם לתדירות ההצהרה הספציפית; חיוני שהבודקים יבחרו את ההצהרה בחוכמה.
לדוגמה, מכונת קופה עצמית עשויה להציג אזהרה אם משתמש מנסה לרכוש פריט עם הגבלת גיל. ללא ההצהרה המתאימה, המכונה עלולה לקרוס או לאפשר לכל לקוח לקנות פריט כלשהו.
על ידי שינוי ההצהרה והדגשתה בפני הצוות, הבודקים יכולים לוודא שהגישה שלהם מתאימה לבעיות אלו.
סוגי שגיאות ובאגים שזוהו באמצעות בדיקת מוטציות
מבחני מוטציה חושפים בעיקר בעיות בתהליך הבדיקה עצמו. עם זאת בחשבון, הנה מגוון בעיות שבדיקות אלה יכולות לעזור לזהות:
1. מקרי מבחן לא ברורים
אם ניתוח מוטציות מגלה ציון מוטציה נמוך (או אפילו כל ציון מתחת ל-100%), זה מצביע על כך שמקרי הבדיקה של הצוות אינם מסוגלים להסביר כל תקלה אפשרית שעלולה להשפיע על יישום.
ייתכן שהם לא ספציפיים או רחבים מספיק כדי להתאים לדרישות הצוות. מסמכים אלה צריכים להקיף כל אפשרות שהצוות עלול להיתקל בה בעת בדיקת התוכנה כדי להבטיח אמינות.
2. צוות בדיקות לא מאומן
מבחני מוטציות יכולים גם להמחיש את היכולות של הצוות, כולל עד כמה הם מזהים באופן אישי מוטציות ותקלות אחרות. אם הם לא יכולים לאתר את המוטנטים על פני התוכניות למרות מקרי בדיקה ברורים ומפורטים, ייתכן שהדבר נובע מכך שהבודקים לא יישמו מקרים אלה בצורה נכונה.
תוכניות מוטנטיות יכולות להראות בעיות לאורך כל תהליך הבדיקה – זה עשוי לכלול גם בודקים לא מיומנים או לא מאומנים.
3. תוכנת בדיקה לא מספקת
אם חברה משתמשת בבדיקות אלה כדי לבדוק את פלטפורמת הבדיקה שלה, היא עשויה לגלות שהתוכנה אינה יכולה לזהות או להרוג במדויק קוד מוטנטי.
החברה עשויה להגיב על ידי חקירת בחירות אחרות עד שתמצא אחת שתואמת את מקרי הבדיקה שלה. אם תוכנת האוטומציה לא מצליחה למצוא קוד בעייתי, סביר להניח שהיא תתקשה לזהות בעיות אחרות המשפיעות על התוכנה.
4. קוד לא מותאם
בדיקת מוטציות יכולה לחשוף בעיות שכבר קיימות בתוכנה. לדוגמה, בודקים עשויים לנסות לשנות את הקוד אך לחשוף פגמים קריטיים בעצמם.
זה משמש כנקודת מבט חשובה נוספת של התוכנית, המראה שמוטציית קוד מספקת יתרונות מעבר לתהליך הבדיקה. ככל שהבודקים יבדקו את הקוד הזה בכל תפקיד, כך הצוות יכול לחשוף ולתקן יותר בעיות במהלך שלב הבדיקה.
מדדי מבחן מוטציה נפוצים
המדדים העיקריים שבהם משתמשים במבחני מוטציה כוללים:
1. הרגו מוטנטים
זה מתייחס למספר המוטנטים שהבודקים או התוכנה הצליחו לזהות, מסמנים את קיומם כדי להבטיח שהצוות יכול למצוא תקלות קלות כמו אלה.
כמות המוטנטים שהבודקים הורגים תלויה בחוזק מקרי הבדיקה שלהם.
2. מוטנטים חיים
מוטנטים חיים הם אלו שהבודק או התוכנה לא מצליחים לזהות – המראים פערים שעלולים להתקיים באסטרטגיית אבטחת האיכות של הצוות. אם זה קורה, הבודקים צריכים לכייל מחדש את התהליך שלהם ולבדוק מקרים כדי להכיל את המוטנטים האלה ולהרוג אותם בבדיקות עתידיות.
3. מוטנטים תקפים
מדד זה קובע את כמות המוטציות שהתוכנית הצליחה לכלול בהצלחה ללא שגיאת זמן ריצה שתבטל את הבדיקה ואת יעילותה.
מוטנטים תקפים הם כאלה שהבודק ותוכנת האוטומציה יכולים לבחון; זה נובע מכך שהמוטציות מינוריות יחסית.
4. מוטנטים לא חוקיים
מוטציות משמעותיות עשויות להשפיע על היישום מספיק כדי להפוך את הבדיקה לבלתי מעשית או אפילו בלתי אפשרית – כך שזה עוזר לעקוב אחר כמה מוטנטים ‘לא חוקיים’ קיימים בתוכנית המוטציה.
זיהוי אלה מאפשר לבודקים לערוך או אפילו להסיר אותם, ומבטיח שהבדיקות כוללות רק מוטציות חוקיות.
5. סה”כ מוטנטים
מספר המוטציות ללא קשר לתקפותן הוא מדד נוסף שהבודקים עוקבים אחריו; זה מאפשר להם לעקוב אחר המוטנטים ולתעד את מצבם.
מכיוון שכל מוטציה כרוכה בדרך כלל בבדיקה נפרדת, הסכום הכולל משמש גם כספירה למספר מוטציות הקוד הכוללות.
6. ציון מוטציה
המדד המועיל ביותר לניתוח מוטציות הוא בדרך כלל ציון המוטציות, שהוא למעשה אחוז המוטנטים התקפים שהבודק או חבילת האוטומציה הצליחו לזהות.
כל דבר פחות מ-100% זיהוי יכול להיות סימן להליכי בדיקה לא נאותים.
7 טעויות ומלכודות ביישום בדיקות מוטציות
בדיקת מוטציות היא תהליך מורכב שחברות חייבות ליישם בחוכמה על מנת למנוע בעיות או טעויות חמורות. להלן שבעה מלכודות שהבודקים צריכים לפעול כדי להימנע מהם בעת ביצוע בדיקות מוטציה:
1. קנה מידה מוטציה לא תקין
קנה המידה הוא שיקול חשוב במהלך ניתוח מוטציות, שכן תהליך זה קיים כדי לוודא שהבודקים מזהים תקלות קלות בתוך יישום. אם המוטציה ברורה מדי לבודקים, ייתכן שזו לא דרך יעילה לבדוק את יכולתם להבחין בבעיות תוכנה או להתמודד עם אותן.
2. מוטציות לא חוקיות או חיות
אפילו בקנה המידה הנכון, מוטציות רבות מציעות יעילות מוגבלת בלבד – למשל, אם הן לא מובילות לתקלה, או שהן גורמות לבעיה שעוצרת את האפליקציה מלפעול.
בודקים צריכים להיות מודעים לאופן שבו כל שינוי בקידוד יכול להשפיע על התוכנה כולה.
3. מקרי בדיקה לא תואמים
מקרי הבדיקה והמוטציות חייבים להתאים זה לזה בצורה מושלמת כדי להבטיח בדיקה עקבית והרמונית. כאשר מחליטים אילו מוטציות להוסיף או אפילו בזמן תכנון מקרי הבדיקה הראשוניים, צוות אבטחת האיכות עשוי לפעול כדי להבטיח שהן משתלבות יחד ומובילות לבדיקות זורמות יותר בסך הכל.
4. מועדים ולוחות זמנים
שלבי הבדיקה משתנים באורך אך תמיד צריכים לעמוד בלוחות זמנים של החברה הפנימית. חברות שלא מצליחות לתזמן כראוי את בדיקות המוטציה שלהן עשויות שלא לסיים את התהליך בזמן.
לפני שפרויקט מגיע לשלב הבדיקה, הצוות חייב לוודא שלוח הזמנים של הבדיקות הוא מקיף כראוי.
5. כיסוי מבחן לא מספק
עסקים עשויים לבחור ליישם את מוטציות הקוד שלהם באופן אקראי – אבל עדיין חשוב שהם יכסו מגוון רחב של נושאים.
כדי לוודא שגם הבודקים וגם התוכנה יכולים לזהות כל סוג של מוטציה, הבדיקות צריכות לכלול לפחות כמה מוטציות של ערכים, החלטה והצהרות.
6. שימוש במוטנטים לבדיקת התוכנה
למרות שבדיקת מוטציות מציעה נקודת מבט חדשה על יישום, צוותים חייבים להשתמש בשיטה זו רק כדי לבדוק את תהליך הבדיקה שלהם. החברה צריכה להבין את היכולות והמגבלות המדויקות של בדיקת מוטציות; טכניקה זו יכולה להצליח רק לצד בדיקות תוכנה אחרות.
7. יותר מדי מוטנטים
חשוב ביותר שחברות יבטיחו כיסוי בדיקות רחב, אך הן עלולות ליישם יותר מדי מוטנטים בתהליך. כל תוכנית מוטציות דורשת כמות משמעותית של כוח חישוב – מגביל כמה ארגון יכול לנהל בו זמנית.
הפעלת יותר מדי מוטציות יכולה גם להקשות על עמידה בלוחות זמנים של בדיקות.
רשימת בדיקה, טיפים וטריקים לבדיקת מוטציות
ישנם מספר טיפים נוספים שיכולים לעזור לכל צוות לשפר את הצלחת תהליך בדיקת המוטציות שלו, כגון:
1. בדוק תאימות לשפת תכנות
גם כלי בדיקת מוטציות בחינם וגם בתשלום מתמחים בדרך כלל בשפת קידוד אחת – מה שחשוב שהבודקים יבחרו בכלי התואם לפלטפורמת בדיקת היישומים והתוכנה.
צוות הבדיקה צריך לחקור אפשרויות רבות כדי להבטיח שהם משתמשים בתוכנית המתאימה לתקציב שלהם כמו גם לשפת הקידוד המועדפת עליהם.
2. חלקו מבחנים בחוכמה
סביר להניח שחברים שונים בצוות הבדיקות יסתכלו על היבטים שונים של היישום, בדרך כלל בהתאמה לחוזקות, לחולשות ולניסיון הכולל שלהם.
כאשר הצוות מקצה בדיקות מוטציה לכל בוחן, עליהם לזכור זאת כדי לקבל מושג על בקיאותו; זה מראה עד כמה בדיקות נוספות צפויות לעבור.
3. בחרו תקלות בקפידה
אם באיטרציה האחרונה של התוכנה היה באג הכולל ערך או הצהרה, זה עשוי לעזור לשכפל זאת ולבחון כיצד הצוות או התוכנית מגיבים.
זה עוזר להבטיח את אורך החיים של האפליקציה וממחיש את היכולת של הצוות להבחין בשגיאות קודמות אם הן חוזרות על עצמן – זהו מרכיב מרכזי בבדיקות רגרסיה .
4. למקסם את כוח החישוב
מכיוון שבדיקות מוטציות עשויות לדרוש כוח חישוב רב כדי להפעיל אותן, הן עוזרות להפיק את המרב מהחומרה של החברה.
לדוגמה, אם למכונות מסוימות יש מפרט חזק יותר, זה יכול להיות מועיל להפעיל את המוטנטים במכשירים אלה. זה מאפשר לחברה למנוע עיכובים משמעותיים שמכונות איטיות יותר עלולות להוביל אליהם.
5. אל תבטל מוטציות בחיים
אפילו עם לוח זמנים קפדני, בודקים צריכים לעבוד כדי לשנות ולהרחיב את מקרי הבדיקה שלהם כדי להילחם בכל המוטציה ששורדת את התהליך.
למרות ששגיאות אלו עשויות להיראות לא משמעותיות אם התוכנה או הבוחן לא חושפים אותן, הן עדיין מייצגות כשל של מקרי הבדיקה לזהות את כל בעיות הקידוד.
6. חקור תוכנת אוטומציה חדשה
אם מקרי הבדיקה של הצוות מפורטים מספיק אך חבילת הבדיקות האוטומטיות שלהם לא יכולה להשתמש בהם בהצלחה כדי לזהות כל מוטציה, הם עשויים להפיק תועלת מתוכנות שונות.
יש הרבה פלטפורמות חינמיות ותשלום זמינות, וחברות צריכות לבדוק כל אפשרות כדי לוודא שיש להן את התוכנה המתאימה ביותר למקרי הבדיקה שלהן לטווח ארוך.
7. סנכרון כל תהליך בדיקה
שיתוף פעולה הוא מרכיב מרכזי בכל אסטרטגיית בדיקה – זה עוזר לוודא שכל תהליך יכול להשתלב בקלות כפי שהצוות מתכוון.
לדוגמה, צוות הבדיקות יכול לפתח את מקרי הבדיקה שלהם מתוך מחשבה על מוטציה כדי להבטיח רמה גבוהה יותר של תאימות, מה שיקל על הבודקים לאמת את האסטרטגיה שלהם.
8. השתמש בבדיקת יחידות
בדיקת יחידות מאפשרת לצוות אבטחת האיכות לבדוק פיסות קוד במנותק, לייעל באופן מסיבי את הבדיקות ולהקל על הצוותים לזהות בעיות.
שילוב זה יכול להיות מועיל במיוחד אם הבודקים מודאגים לגבי מועדים, ומעניק להם הזדמנות לפשט את הבדיקות ולשפר את הכיסוי הכולל – מה שמוביל למבחני תוכנה חזקים הרבה יותר.
9. כתבו מקרי מבחן מפורטים
מקרי בדיקת מוטציות צריכים להכיל מידע הולם על המוטנט והשפעתו על התוכנית וכן כיצד צוות הבדיקה או הפלטפורמה איתרו תקלות אלו.
על ידי מתן פרטים רבים ככל האפשר, בודק יכול לאמת באופן אישי את מקרה הבדיקה ולוודא שהצוות יודע בדיוק כיצד להבטיח בדיקה חלקה.
5 הכלים הטובים ביותר לבדיקת מוטציות
יש מגוון רחב של כלים זמין שיכולים לעזור לחברות עם דרישות בדיקת המוטציות שלהן. כפי שקורה לעתים קרובות ביישומי בדיקת תוכנה, המחירים והתכונות משתנים מפלטפורמה אחת לאחרת, מה שהופך את זה חיוני שארגונים יבחרו בזו המתאימה ביותר לצרכיהם.
חלק מהתוכניות הללו יכולות להציע עמיתים בחינם או להיות קוד פתוח לחלוטין; אם כי בדרך כלל יש צורך לשלם עבור נוחות רבה יותר.
עם זאת בחשבון, הנה חמשת הכלים הטובים ביותר לבדיקת מוטציות.
1. סטרייקר
Stryker מתמחה במוטציה ב-JavaScript, מייעלת תהליך זה באופן משמעותי כדי להבטיח שאין תוצאות חיוביות כוזבות ולהפחית את כמות המאמץ הכוללת שהבודקים יצטרכו להגיש אחרת עבור כל בדיקות המוטציות.
פלטפורמת Stryker מעריכה את התוכנה בצורה חכמה ומשתמשת במידע שהיא אוספת כדי להבין את המחרוזות או מקטעי הקוד שיועילו למוטציה. יישום זה מגיע עם כתב טקסט ברור שמוציא סיכום של המוטנט, כולל אם סטרייקר הצליח להרוג אותו.
2. PITest
PITest היא בחירה פופולרית מאוד ברחבי העולם בשל יכולתה לשנות קוד בתים של Java ולבצע אלפי מוטציות בשנייה. יישום זה משתמש בנתוני כיסוי מקרי בדיקה כדי ללמוד באופן מיידי אילו בדיקות עלולות להרוג מוטציה.
הוא מריץ רק בדיקות שהוא יודע שיהיו רלוונטיים, ומגבילים את כוח החישוב שההליך הזה צורך בדרך כלל. PITest תואם גם לרוב הצורות של תוסף הבדיקה של יחידת Surefire אך יכול להתקשה בניהול יעיל של תלות של סדרי בדיקה.
3. לבטח++
ל-Insure++ יכולות בדיקה רבות, כולל ניתוח מוטציות, המאפשרות לפלטפורמה לזהות אי בהירות בתוכנית. ביציאה מבדיקות מוטציות קונבנציונליות, Insure++ מוותרת על יצירת מוטנטים פגומים ובמקום זאת יוצרת מוטציות שוות תפקוד התואמות את קוד המקור של הפרויקט.
זאת כדי להימנע מהנחות מרומזות שעלולות להגביל בטעות את תהליך הבדיקה ועשויות שלא לשקף סביבות בדיקה מציאותיות. כפי שהשם מרמז, הפלטפורמה תואמת בעיקר לתוכניות C++, וכל תכונה מכוילת לשפה זו.
4. ערבוביה
יישום זה מתמחה במסגרת JUnit JavaScript, עם אינדיקטורים ויזואליים מקיפים של איך הקוד מגיב לניתוח מוטציות. Jumble היא פלטפורמת קוד פתוח ופועלת בתוך קוד הבתים של יישומי Java כדי להפחית את הזמן של כל מחזור בדיקה.
יישומים דומים המשתמשים באופן בלעדי בקוד המקור של תוכנית עשויים לפעמים לקחת זמן רב יותר לבצע את הבדיקות הללו עקב תהליך ההידור מחדש שלהם.
Jumble גם עושה שימוש בהיוריסטיקה כדי לייעל עוד יותר את בדיקות המוטציות, מה שהופך את ריצות הבדיקה הבאות לפשוטות יותר.
5. MutPy
MutPy תומך במבחני מוטציות עבור יישומים מבוססי Python, ומציע תמיכה מלאה למוטציות מסדר גבוה כמו גם ניתוח כיסוי מקיף. הממשק של תוכנית זו קל לשימוש במהלך שלב הפלט, אשר מציג בבירור למשתמשים כל פרט חיוני במבחני המוטציה של הצוות.
MutPy מציע אפשרויות רבות בהתאמה אישית לבודקים – מה שמאפשר להם לכייל את התוכנה הזו באופן ספציפי לדרישותיהם. הפלטפורמה משתמשת בעצי תחביר מופשטים המספקים מבנה ברור של קוד המקור של האפליקציה, ומעניקים לבודקים אמון רב יותר במוטציות שלהם.
סיכום
למוטציית קוד יש יישומים כמעט לכל תהליך בדיקת תוכנה, המציעים מספר יתרונות ברורים לחברות המיישמות טכניקה זו – במיוחד בשלב מוקדם יותר בשלב הבטחת האיכות.
אין מתודולוגיה ללא אתגרים; זה אומר שחובה שארגונים ישקלו בחוכמה את היתרונות של ניתוח מוטציות תוך הבטחה שהוא מתאים לציר הזמן הרגיל שלהם לפיתוח תוכנה.
מוטציות אלו נותנות לצוותי בדיקה הזדמנות לבחון את הגישה שלהם ולקבוע את יעילותה לאיתור ותיקון שגיאות בתוך קוד המקור. טכניקה זו תואמת במיוחד להליכי אוטומציה, ומאפשרת לחברות לאמת את התוכנה שהם סומכים עליה כדי לטפל בהמחאות שלהן.
בדיקת מוטציות מציעה דרך מקיפה לצוותי אבטחת איכות לפתח הבנה טובה יותר של התהליכים והתוכנה שלהם, כולל הבעיות שאחרת לא היו מצליחים לזהות.
כתוצאה מכך, חיוני שצוותי הבדיקה יחקרו מקרוב את הטכניקה הזו כדי להעריך אם היא תואמת את צרכי הארגון – כולל אם כלי המוטציה שהם בוחרים תואם באופן מלא לשפת התכנות שלהם. תוכנת הבדיקה האוטומטית ZAPTEST מתגאה בתכונות רבות המאפשרות לה לעבור בדיקות מוטציות, מה שמבטיח לצוותים אמון מלא ביכולותיה.
גם גרסאות ה-Free וגם ה-Enterprise מציעות תהליך בדיקה באיכות גבוהה שיכול להכיל מוטציות קוד בקלות.
שאלות נפוצות ומשאבים
1. הקורסים הטובים ביותר בנושא בדיקת מוטציות
קורסים מקוונים יכולים לעזור לבודקים לראשונה ללמוד את היסודות של מוטציית קוד או לחזק את המיומנויות הקיימות מראש של אנשי צוות אבטחת איכות מנוסים. שיעורי בדיקות תוכנה כלליים יכולים גם להציע יתרונות רבים לבודקים. הקורסים המקוונים הטובים ביותר לבודקי מוטציות כוללים:
• ‘בדיקת מוטציות ב-Java עם PITest’ של PluralSight בוחנת באופן ספציפי כיצד לשנות את קוד Java ואת הדרכים שבהן גישה זו יכולה להועיל לתהליכי בדיקת תוכנה מעשיים.
• ‘The Complete Software Testing Bootcamp לשנת 2023’ של Udemy הוא קורס עדכני במיוחד הממחיש כל מרכיב מרכזי במבחני תוכנה, כולל בדיקות White-box.
• ‘בדיקת תוכנה – אסטרטגיות בדיקת מצב ובדיקת מוטציות’ של אליסון היא חינמית ובוחנת מקרוב כיצד ליישם בחוכמה בדיקות מוטציות.
• ‘יסודות בדיקות יחידה’ של PluralSight בוחן את היתרונות והתכונות של בדיקת יחידות, ועוזר להבטיח שהתלמידים מבינים את התהליך המדויק לכתיבת מבחני יחידה חזקים.
• ‘מבוא לבדיקות יחידות’ של Udemy הוא קורס חינמי נוסף המספק פירוט ברור של בדיקות יחידות כמו גם את החשיבות של אסטרטגיות פיתוח מונעות מבחן.
2. מהן 5 שאלות הראיון המובילות בנושא בדיקת מוטציות?
ישנן מספר שאלות שחברות יכולות לשאול מועמדים במהלך ראיון כדי לאמת את הניסיון או ההבנה שלהם בבדיקת מוטציות לצד עקרונות הליבה שלה. זה מאפשר לחברה לוודא שהם שוכרים בודק מוסמך שיכול לגשת בקלות לתרחישים שונים הקשורים למוטציות.
השאלות המדויקות משתנות אך עשויות לכלול בקשת דעות משלהם או דוגמאות למיומנויות מוטציות הקוד שלהם.
חמש שאלות הראיון המובילות לבדיקת מוטציות הן:
• באילו כלי בדיקת מוטציות יש לך ניסיון קודם, אם בכלל? מה היו המאפיינים העיקריים של תוכנה זו?
• בעת ביצוע מוטציית קוד, כיצד תפעל כדי להבטיח איזון בריא בין מהירות הבדיקה לעומק?
• באילו מצבים ניתוח מוטציות יהיה בלתי אפשרי? כיצד היית בודק את הליך הבדיקה בתרחישים אלה?
• אם מוטציה ערכית תצליח לשרוד את תהליך הבדיקה, מה תהיה דרך הפעולה שלך כדי למנוע את זה שוב?
• איזה מידע תכלול במקרה של בדיקת מוטציה על מנת להבטיח לעמיתיך יש את הנתונים שהם צריכים?
3. מדריכי YouTube הטובים ביותר על בדיקת מוטציות
מדריכים בחינם, סמינרים מקוונים וסרטונים אחרים זמינים ב-YouTube כדי לעזור לשפר את ההבנה של בודק לגבי בדיקת מוטציות. כמה מהסרטונים והסדרות המועילים ביותר בנושא כוללים:
• ‘בדיקת מוטציות לתוכניות’ של Software Testing, המספקת דוגמאות מעשיות לאופן שבו מוטציית קוד מסייעת לתוכניות, לצד איך לכתוב מקרי בדיקה יסודיים.
• ‘בדיקת מוטציות: האם הבדיקה שלי שברה את הקוד שלי?’ של Devoxx, אשר בוחנת כיצד ניתוח מוטציות משפר את הליכי הבדיקה הכוללים עבור כל מיני פרויקטי תוכנה.
• כנסים של NDC ‘הרוג את כל המוטנטים! Intro to Mutation Testing’, החוקר כיצד חבילות בדיקה מסוגלות להפיק תועלת ממוטציית קוד ומהתקלות שהיא עוזרת ליצור.
• בדיקת מוטציות ב-Python של GOTO Conferences, הבוחנת באופן ספציפי כיצד יישומים מבוססי Python יכולים ליישם ניתוח מוטציות כדי להגיע למטרות בדיקה ספציפיות.
• ‘בדיקת מוטציות ג’אווה עם PITest’ של דייגו פאצ’קו, הממחישה באופן דומה תוכנת JavaScript משתמשת במוטציית קוד – עם התמקדות בתוכנית המוטציות PITest.
4. איך לשמור על מבחני מוטציה?
שילוב של ניתוח מוטציות עם בדיקות רגרסיה ואסטרטגיות ארוכות טווח אחרות מאפשר לחברות להבטיח סטנדרט חזק של אבטחת איכות גם לאחר השחרור.
עדכונים הבאים יכולים להוביל לשינויי קוד הדורשים בדיקות נוספות. בדיקת מוטציות מראה שתוכנת האוטומציה והבודקים עקביים בין גרסאות שונות של אותה תוכנה, ומאמתות מחדש את הגישה הספציפית שלהם.
פונקציות חדשות מחייבות מקרי בדיקה חדשים יותר, במיוחד אם תכונות אלו מקיימות אינטראקציה עם תכונות קיימות.
בנוסף לכך, השימוש בפיתוח מונחה מבחן מאפשר לחברי הצוות לתכנן את אורך חיי התוכנה ותאימות לבדיקות כחלק ממחזור הפיתוח שלה.
