סוגים רבים של שיטות בדיקה תוכנה

האם תהית אי פעם מה קורה מאחורי הקלעים לפני התוכנה הולך הציבור? מתכנתים מודעים היטב לכמות העבודה הנכנסת ליצירת התוכנית. שעות בילה מנסה לגהץ כל באג קטן משאיר רבים מושכים את השיער שלהם החוצה. ועד שהמוצר יספק את כל בעלי העניין, הוא לא יהיה זמין לשימוש מסחרי.

חברות תוכנה ענקיות, כמו גוגל, מצליחות למרות באגים בעדיפות נמוכה בתוכנות שלהם, אבל לחברות קטנות יותר וסטרט-אפים אין את המותרות.

-> ->

לקוחות מצפים למוצרים לעשות את מה שהם טוענים בדף המכירה, או בתיעוד. עם כל כך הרבה אפשרויות שם בחוץ, הם לא יחשבו פעמיים על קפיצה הספינה אם המוצר מבזבז את זמנם וכסף. לכן, התוכנה עוברת בדיקות קפדניות לפני השחרור כדי:

• הדגשת הבדלים בין הרעיון המקורי לבין הפלט הסופי

  -> ->

• לוודא שהתוכנה פועלת באופן שבו מתכננים מתכננים

• לאמת את המוצר הסופי - המוצר חייב לעמוד בדרישות הלקוח

• הערכת תכונות ואיכות

בדיקה עוקבת אחר תכנית קפדנית. זה מייעל את השימוש במשאבים יקרי ערך - מיומנויות, זמן וכסף, תוך מתן מידע לבעלי העניין עם מידע חיוני כדי לקחת את המוצר קדימה. המטרה היא להקל על חוויית משתמש קצה טובה באמצעות תוכנית אבטחת איכות חזקה. עם ההימור כה גבוה, מנהלי QA הם חלק מן המרוויחים המובילים בתחום הטכנולוגיה. הבדיקה בדרך כלל עוקבת אחר השלבים הבאים:

1. ניתוח הדרישה שבו מנהלים המתווה תוכנית לשים אסטרטגיית הבדיקה המתאימה במקום.

2. בדיקות להתחיל ותוצאות לעבור ניתוח.

3. כל הפגמים מתוקנים, והתוכנה עוברת בדיקות רגרסיה - מערכת לבדיקת התוכנית עדיין פועלת לאחר שינויים.

4. דוח סגירת הבדיקה מפרט את התהליך כולו ואת התוצאות.

שיטות בדיקות תוכנה

להלן השיטות השונות המשמשות לשפוט התנהגות המוצר והביצועים.

תיבת שחור בדיקות קופסה לבנה הן שתי שיטות בסיסיות.

• בדיקות קופסה שחורה - המכונה גם בדיקות פונקציונליות או מבוססות מפרט, שיטה זו מתמקדת בפלט. הבוחנים אינם עוסקים במנגנונים הפנימיים. הם רק לבדוק את התוכנה עושה מה זה אמור. הידע של קידוד אינו הכרחי, בודקים לעבוד ברמת ממשק המשתמש.
• בדיקות קופסה לבנה - שיטה זו משתמשת בקידוד ידע כחלק מהליך הבדיקה. כאשר מוצר נכשל, בודקי ללכת עמוק לתוך הקוד לפי הצורך כדי למצוא את הסיבה. מפתחי התוכנה לעשות זאת בעצמם מאז הם קובעים כיצד המוצר צריך לעבוד. מבנה מבוסס זכוכית בדיקות זכוכית הם שמות אחרים עבור שיטה זו.
• בדיקה סטטית - בודקים בודקים את קוד התוכנה ואת התיעוד אך אינם מבצעים את התוכנית.בדיקות סטטיות מתחילות בשלב מוקדם בפיתוח המוצר במהלך תהליך האימות.
• בדיקה דינמית - התוכנה מבוצעת עם תשומות שונות, והבוחנים משווים פלט עם התנהגות צפויה בשיטה זו.
• בדיקה GUI - זה בודק תכונות GUI - עיצוב טקסט, תיבות טקסט, לחצנים, רשימות, פריסה, צבעים, גופנים, גדלי גופנים וכן הלאה. בדיקות GUI הוא זמן רב, וחברות צד שלישי לעיתים קרובות לקחת על עצמו את המשימה במקום מפתחים.

רמות בדיקה

אלה נחוצות כדי לזהות תחומים של חולשה וחפיפה בכל שלב במחזור החיים של פיתוח התוכנה.

• בדיקות יחידה - מפתחים לבדוק את החלקים הבסיסיים ביותר של קוד כמו כיתות, ממשקים, פונקציות / נהלים. הם יודעים איך הקוד שלהם צריך להגיב יכול לבצע התאמות בהתאם פלט.
• רכיב בדיקה - שמות אחרים הם מודולים או בדיקות תוכנה. הדבר דומה לבדיקת יחידה, אך מכיל רמה גבוהה יותר של אינטגרציה. מודולים של התוכנה נבדקים עבור פגמים כדי לאמת את הפונקציה האישית שלהם.
• בדיקות אינטגרציה - זה מזהה שגיאות כאשר מודולים משולבים. בדיקות אינטגרציה שונות הן מלמטה למעלה, למעלה ולמטה פונקציונלי.
• מערכת בדיקה - רכיבי הפרויקט נבדקים בכללותה בסביבות שונות בשיטה זו. הוא נופל תחת שיטת הקופסא השחורה והוא אחד המבחנים הסופיים בתהליך. היא קובעת אם המערכת פועלת כפי שהיא צריכה לענות על הצרכים העסקיים והמשתמשים.
• אלפא בדיקות - צוות פנימי לבדוק את התוכנה באתר של היזם בסביבה מדומה או בפועל. לאחר מכן, מפתחים לתקן באגים ובעיות אחרות.
• בדיקות ביתא - ידוע גם בדיקות שדה, כמו גם, הלקוח בודק את המוצר באתר שלהם בתנאים אמיתיים. הלקוח עשוי להציע לקבוצה של משתמשי קצה את ההזדמנות לבדוק את התוכנה באמצעות גרסאות קדם-קדם או גירסאות ביטא. משוב על שיפורים אפשריים נשלח אל היזם.
• בדיקות קבלה - גם תחת היקף בדיקות קופסה שחורה, הלקוח בודק תוכנה כדי לברר אם היזם יצר את התוכנית לפי המפרט הרצוי.

סוגי בדיקה

בדיקות תוכנה אלה מתמקדות ביעדים ספציפיים.

• בדיקות התקנה - מהנדס בדיקות התוכנה ומנהל התצורה מבצעים בדיקה זו כדי להבטיח שהמשתמש הסופי יוכל להתקין ולהפעיל את התוכנית. הוא מכסה אזורים כמו קובצי התקנה, מיקומי התקנה וזכויות ניהול.
• פיתוח בדיקות - זה מיישם מגוון של אסטרטגיות מסונכרנות כדי לזהות ולמנוע פגמים. הוא כולל ניתוח קוד סטטי, סקירת קוד עמית, ניתוח עקיבות וערכים. המטרה היא לצמצם סיכונים ולחסוך בעלויות.
• בדיקות שמישות - חוויית המשתמש נמצאת תחת הזרקור במבחן זה. זה מודד כמה טוב GUI נועד וקלות השימוש. הבדיקה בודקת דיוק ויעילות של פונקציות ותגובות רגשיות של נבדקים הבדיקה.
• בדיקות שפיות - זה מציין אם התוכנה שווה את הזמן ואת העלות כדי להמשיך בדיקות נוספות.יותר מדי פגמים ומבחנים אגרסיביים יותר אינם פועלים.
• בדיקות עשן - בדיקות עשן חושף כשלים בסיסיים כי הם רציניים מספיק כדי למנוע שחרור. כאשר זה מתבצע על לבנות חדש, זה נקרא מבחן אימות לבנות.
• בדיקות רגרסיה - כאשר המערכת עוברת שינוי, בדיקות רגרסיה עוקבות אחר התנהגות בלתי צפויה. זה מצביע על השפעות שליליות על מודולים או רכיבים.
• בדיקות הרסניות - בודקי קלט ערכים חריגים ולבחון את היכולת של התוכנה לנהל קלט בלתי צפוי. זה מראה למפתחים כמה חזק התוכנית היא על ניהול השגיאה.
• בדיקה לשחזור - כאשר חומרה או פונקציות אחרות נכשלים, בדיקה זו מראה עד כמה התוכנה יכולה לשחזר ולהמשיך בפעולה.
• בדיקה אוטומטית - פעולה זו מבצעת פעולות לביצוע באופן ידני. היא משתמשת בתוכנה ספציפית כדי להפעיל את הבדיקות ולספק נתונים על התוצאות בפועל לעומת הצפוי.
• תאימות בדיקות - התוכנה חייבת לפעול בסביבות מחשוב שונות, ולכן זה בודק תאימות עם מערכות שונות. לדוגמה, האם התוכנה עובדת עם מערכות הפעלה ודפדפני אינטרנט שונים?
• בדיקות ביצועים - זהו בדיקה מעמיקה שבוחנת את ביצועי התוכנה בתרחישים שונים. מידע על היענות, יציבות, הקצאת משאבים ומהירות נאסף. יתר על כן, בדיקות משנה כגון נפח, קיבולת, בדיקות ספייק לשחק חלק בתהליך זה.
• בדיקות אבטחה - מודד את יכולת התוכנה להגן על אבטחת המשתמשים. משמעות הדבר היא פונקציות אישור, אימות, סודיות, יושרה, זמינות, ולא דחייה.
• בדיקות נגישות - זה לא אותו דבר כמו בדיקות שמישות. זה קובע את המידה שבה משתמשים ביכולות שונות - למידה ונכויות פיזיות כלולות, יכולים להשתמש בתוכנה.
• בדיקות בינאומיות ולוקליזציה - תוצאות מראות כיצד התוכנה יכולה להסתגל לשפות שונות ולדרישות אזוריות. זה כולל הוספת רכיבים עבור מיקומים ספציפיים ותרגום טקסט.

בדיקות תוכנה היא חלק חיוני של הבאת מוצר לשוק. ובלי בודקים, מגוון רחב של תוכנות זמינות לא היה קיים. להיות בודק תוכנה מוסמך באמצעות ארגונים כגון BCS, המכון Chartered עבור IT, ISTQB ® (International Software Testing Qualifications Board), ו ASQ (לשעבר האגודה האמריקנית לאיכות).