בהנדסת תוכנה, מקרה בדיקה (באנגלית: Test case) הוא אוסף של תנאים ומשתנים שלפיהם בודק תוכנה קובע האם אפליקציה (application) או תוכנה (software) פועלת בצורה נכונה בנקודה מסוימת. המנגנון הקובע האם תוכנה או מערכת צלחה או נכשלה בבדיקה נקרא test oracle (נביא הבדיקה). במקרים מסוימים, הנביא הוא דרישה או מקרה שימוש (באנגלית: use case), בעוד במקרים אחרים הנביא הוא היוריסטיקה מסוימת. ייתכן ויידרשו המון מקרי בדיקה על מנת לקבוע כי תוכנה או מערכת נבחנו מספיק לשם הפצתם. לעיתים מקרה בדיקה מיוחס לתסריט בדיקה (באנגלית: test script), בעיקר בזמן שנכתב. מקרי בדיקה כתובים בדרך-כלל מאוגדים לחבילת בדיקה (באנגלית: test suite).
לשם בדיקה כי כל הדרישות של אפליקציה מסוימת אכן ממומשות, חייבים להיכתב לפחות שני מקרי בדיקה לכל דרישה: אחד חיובי ואחד שלילי. אם לדרישה קיימות תתי-דרישות, לכל תת-דרישה חייבים להיכתב לפחות שני מקרי בדיקה. שמירה על הקשר בין מקרה בדיקה לבין הדרישה עבורה נכתב מתבצעת לרוב על ידי מטריצת מעקב (באנגלית: traceability matrix).
כתיבה פורמלית של מקרה-בדיקה מאופיינת על ידי קלט ידוע ופלט צפוי, שנקבעים לפני הרצת הבדיקה. הקלט הידוע בוחן את תנאי הקדם (pconditions) והפלט הצפוי בוחן את תנאי הסיום (postconditions).
עבור אפליקציות או מערכות ללא דרישות פורמליות, מקרי הבדיקה יכולים להיכתב על סמך פעולתן הנורמלית של אפליקציות או מערכות מסוג דומה. ישנן אסכולות בדיקה בהן מקרי בדיקה לא נכתבים כלל, הפעולות והתוצאות מדווחים לאחר שהבדיקה רצה. בבדיקת תרחיש (scenario testing) נעשה שימוש בסיפורים היפותטיים על-מנת לסייע לבודק לחשוב על בעיה מורכבת או על מערכת מורכבת. תרחישים אלו לרוב אינם נכתבים בפירוט. התרחישים יכולים להיות פשוטים כמו דיאגרמה של סביבת בדיקה, או מורכבים כמו פרוזה. בדיקת התרחיש האידיאלית הוא סיפור מניע, אמין, מורכב, וקל להערכה. בדיקות התרחיש בדרך-כלל נבדלות ממקרי הבדיקה בכך שמקרי הבדיקה הם צעדים בודדים בעוד תרחישים מכסים מספר צעדים.
מקרה בדיקה הוא בדרך-כלל צעד בודד (או לעיתים רצף צעדים), לבדיקת התנהגות/פונקציונליות נכונה של תכונה כלשהי של האפליקציה. נהוג לציין גם את הפלט הצפוי ואת התוצאה בפועל. מידע נוסף שניתן לכלול:
מקרי בדיקה גדולים יכולים להכיל בדרישות הקדם שלהן מצבים/צעדים מסוימים, ותיאורים. מקרה בדיקה כתוב צריך לכלול את פלט הבדיקה בפועל. נהוג לשמור את מקרי הבדיקה במסמכים של מעבדי תמלילים, גיליונות אלקטרוניים, מסדי נתונים, או כל מאגר משותף אחר. במסדי נתונים (באנגלית: database) ניתן לרוב לראות תוצאות של בדיקות שבוצעו בעבר, מי יצר אותן, ואת קונפיגורציית המערכת ששימשה להרצת הבדיקות שנתנו תוצאות אלו. בדרך-כלל תוצאות בדיקה ישנות ישמרו בטבלה נפרדת. מלבד תיאור הפונקציונליות שיש לבדוק וההכנות הדרושות לשם הרצת הבדיקה, החלק שאורך הכי הרבה זמן ביצירת מקרה הבדיקה הוא יצירת הבדיקות עצמן ושינויים בהתאם כאשר המערכת משתנה. במקרים מיוחדים יידרש צוות של מומחים לבחינת והערכת תוצאה של בדיקה וקביעה האם עברה או נכשלה. מצב זה קורה לרוב בעת קביעת ערכי ביצועים של מוצר חדש. הבדיקה הראשונה נלקחת כבסיס עבור הבדיקות הבאות/מחזורי שחרור הבאים.
בדיקות קבלה (באנגלית: acceptance tests), שהן בעצם כתיבת מקרי הבדיקה מהצד של המשתמש, לרוב נכתבים על ידי קבוצה של משתמשי קצה (end users) או לקוחות המערכת על-מנת להבטיח כי המערכת שפותחה עונה על החוזה/הדרישות שהוגדרו עבורה. בדיקות הקבלה נבדלות ממקרי הבדיקה בכך שהן מורכבות ברובן מ"מסלולים שמחים" (תרחישים תקינים ולא חריגים, באנגלית: happy paths) ובדיקות חיוביות. במקרים קיצוניים אינן מכילות כלל בדיקות שליליות.
מקרי בדיקה פונקציונליים (גישת הקופסה השחורה, באנגלית: black-box) . מקרי בדיקה אלו נכתבים על-סמך המפרט של התוכנית בלבד ללא היכרות עם המימוש שלה. בשימוש בסוג זה של מקרי בדיקה מניחים כי התוכנית הוא פונקציה הממפה את ערכי הקלט לערכי הפלט. שיטות לייצור מקרי בדיקה פונקציונליים:
היתרונות של מקרי בדיקה אלו: כאשר מימוש התוכנית משתנה מקרי הבדיקה עדיין תקפים ואין צורך לכתוב אותם מחדש. בנוסף מאחר שאינם תלויים במימוש ניתן לכתוב אותם במקביל לפיתוח התוכנית. החסרונות של מקרי בדיקה אלו: תיתכן יתירות במקרי הבדיקה. ייתכן גם שמקרי הבדיקה לא יכסו את כל התוכנית.
מקרי בדיקה מבניים (גישת הקופסה הלבנה, באנגלית: white-box) . מקרי בדיקה אלו נכתבים על-סמך מבנה הקוד של התוכנית. שיטות לייצור מקרי בדיקה מבניים:
היתרונות של מקרי בדיקה אלו: ניתן לייצר מקרי בדיקה ספציפיים ומעמיקים יותר לתוכנית. בנוסף ניתן להגדיר את אחוז כיסוי התוכנית על ידי מקרי הבדיקה. החסרונות של מקרי בדיקה אלו: הם מתייחסים רק למקרים שמומשו בתוכנית.