יחידה 2 / 11

תרחיש בדיקה ויצירת מקרי בדיקה: מדרישה לבקרה מקיפה

רווחים:

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

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

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

שלב אחר שלב: מדרישה לסט מבחן

שלב 1 - הבהיר את הדרישה. אסוף קריטריוני קבלה (תנאים שעבודה חייבת לעמוד בהם כדי להיחשב כ"סתיימה") לפני שנותנים ל-AI את הדרישה הגולמית. "הסיסמה חייבת להיות ניתנת לאיפוס" אינו מספיק; כללים כמו "איפוס קישור תקף ל-30 דקות", "לא ניתן לעשות שימוש חוזר באותה סיסמה" הם המקור למבחן האמיתי.

שלב 2 - יישום טכניקות בדיקה. אל תגיד סתם "כתוב תסריט" על AI; בקש טכניקות עיצוב מבחן קלאסיות בשם:

  • מחלקות שקילות (חלוקה שווה ערך): חלוקת תשומות לקבוצות שצפויות לייצר את אותה התנהגות. לדוגמה, עבור שדה הגיל, "טווח חוקי", "קטן מדי" ו"גדול מדי" הן מחלקות; מספיקה לבדוק דוגמה אחת מכל מחלקה.
  • ניתוח ערכי גבולות: בדיקת ערכי סף על סמך העובדה שהטעויות מתרחשות לרוב בגבולות. זה כמו לבדוק 17, 18, 19 בנפרד עבור מגבלת הגיל 18.
  • טבלת החלטות: טבלאות שילובים של מספר תנאים והתוצאה הצפויה של כל שילוב.
  • מעבר מצב: בדיקת מעברי המערכת ממדינה למדינה (לדוגמה, הזמנה: נוצר ← בתשלום ← נשלח) ומעברים לא חוקיים.

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

שלב 4 - תעדוף וגזום. בינה מלאכותית יכולה ליצור 60 תרחישים; לא כולם בעלי ערך שווה. תן עדיפות לבעלי סיכון גבוה (כסף, אבטחה, אובדן נתונים) ושלב את אלה שהם כפולים.

טיפ: שלח בקשה נפרדת ל-AI באומרה "צור 5 מקרי קצה בלתי מתקבלים על הדעת מהדרישה הזו". התרומה החשובה ביותר של AI היא שלעתים קרובות הוא מזכיר לך מצבים יוצאי דופן שהתעלמתם מהם.

הנחיה חלשה / הנחיה חזקה

חלש: "כתוב מקרי בדיקה לאיפוס סיסמה."
חזק: "צור מקרי בדיקה עבור התכונה 'איפוס סיסמה' עם קריטריוני הקבלה הבאים: קישור תקף ל-30 דקות, שימוש חד פעמי, לא ניתן לעשות שימוש חוזר ב-3 סיסמאות אחרונות, החשבון ננעל למשך 15 דקות לאחר 5 ניסיונות שגויים. החל מחלקות שקילות וניתוח ערכי גבול. תן מקרים חיוביים, שליליים וקצה בכותרות נפרדות, תנאי קדם, תוצאה משויכת, אישור בדיקה, קבל כותרות נפרדות, תוצאה צפויה: הדגש על תרחישי אבטחה/נעילה.

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

פורמט פלט של מקרה מבחן

בקש פורמט מובנה שניתן לייבא ישירות לכלי ניהול הבדיקות של הצוות שלך (למשל TestRail, Zephyr, Xray). הטבלה הבאה מציגה את המרכיבים של מקרה מבחן טוב:

אזור

תיאור

דוגמה

תעודה מזהה

מזהה ייחודי

TC-PWD-014

כותרת

מטרה קצרה

קישור שפג תוקפו יידחה

תנאי מוקדם

מצב נדרש לפני בדיקה

קישור לאיפוס נוצר לפני 31 דקות

צעדים

פעולות עוקבות

1. לחץ על הקישור 2. הזן סיסמה חדשה

נתוני בדיקה

נעשה שימוש בערכים קונקרטיים

קישור ישן, סיסמה חדשה "Abc!2345"

תוצאה צפויה

התנהגות שיש לאמת

שגיאה "פג תוקף הקישור", הסיסמה לא משתנה

קריטריוני קבלה

קישור לעקיבות

AK-3: הקישור תקף למשך 30 דקות

עדיפות

רמת סיכון

גבוה

ארבע תבניות הניתנות להעתקה

1) ייצור תרחיש מבוסס טכני:

התפקיד שלך: מעצב בדיקות בכיר. צור מקרי בדיקה עבור תכונה: [תכונה וקריטריונים קבלה]. החל: מחלקות שקילות, ניתוח נקודות שבירה, טבלת החלטות. לספק פלט ב-3 קבוצות: מקרה חיובי / שלילי / Edge. כל מקרה: מזהה, תנאי מוקדם, שלבים, נתוני בדיקה, תוצאה צפויה, קריטריוני קבלה משויכים, עדיפות (גבוה/בינונית/נמוכה).

2) צייד מקרה קצוות:

רשום 10 מקרי קצה שבדרך כלל מתעלמים מהם עבור התכונה הבאה: [תכונה]. כתוב במשפט אחד למה זה מסוכן לכל אחד. חשבו על צירים כמו ריק/null, קלט ארוך מדי, במקביל, פסק זמן, שגיאות פורמט, Unicode/emoji, שלילי/אפס, הפסקת רשת.

3) ייצור טבלת החלטות:

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

4) בקרת עקיבות:

בהתחשב ברשימה הבאה של קריטריוני הקבלה ובמקרי המבחן הבאים: [קריטריונים] / [מקרים]. הצג בטבלה אילו קריטריוני קבלה מתקיימים על ידי מקרי מבחן NO (פער כיסוי) ואילו מקרים אינם מתקיימים על ידי קריטריונים כלשהם (מקרה מיותר).

שלושה מיני תיקים

מקרה 1 - ערך מצבי קצה. מומחה מצוות פינטק כתב 18 סקריפטים עבור תכונת העברת הכסף. הוא יישם את תבנית "צייד המקרים הקצה" על AI; AI הזכיר את המצב של "העברת אותה יתרה משני מכשירים בו זמנית" (במקביל). כאשר התרחיש הזה נבדק, נמצאה פגיעות של הוצאה כפולה ונסגרה לפני העלייה לאוויר. מצב שוליים בודד מנע הפסד פוטנציאלי בן שש ספרות.

מקרה 2 - חיתוך הבליטה. צוות גרם ל-AI לייצר תסריט לטופס החברות ו-74 מקרים הגיעו. הפעלת תבנית העקיבות מצאה ש-74 מקרים עמדו רק ב-9 קריטריוני קבלה, כאשר רבים מהם בחנו מחדש את אותה מחלקת שקילות. הסט צומצם מ-74 ל-23 מקרים משמעותיים; זמן הריצה ירד ב-68%, הכיסוי לא ירד.

מקרה 3 - הנחה שגויה. ה-AI הציע לבדוק תאריכים לא חוקיים כמו "31 בפברואר" עבור שדה תאריך, אך לא ידע שרכיב לוח השנה שבו הצוות משתמש כבר חסם זאת. המומחה ביטל 4 מתוך 6 תרחישי התאריכים שהופקו על ידי ה-AI כמיותרים בהקשר של המוצר. בינה מלאכותית יצרה אפשרויות; ביצעה בחירת מידע על המוצר.

טעויות נפוצות

  • בקשת תסריט מבלי לתת קריטריוני קבלה. מבלי לדעת מה נכון, בינה מלאכותית מייצרת תרחישים שטחיים שלעתים קרובות מחמיצים את הסיכון האמיתי.
  • רק מסתפק בבדיקות חיוביות. בפירוש לא רוצה מקרים שליליים וקצה. כאן טמונות לעתים קרובות טעויות.
  • לקבל את מה שמיוצר כפי שהוא. שוכחים שה-AI לא מכיר את הקשר המוצר ומשאיר תרחישים מיותרים או בלתי אפשריים על הסט.
  • עקיפת יכולת המעקב. אי קישור מקרים לקריטריוני קבלה; כתוצאה מכך, לא נראה איזה קריטריון לא נבדק (פער כיסוי).
  • כשל בכמות. להיות שמח כי "שוחררו 60 תסריטים". הערך אינו במספר, אלא בהיקף המכסה את הסיכון.

לסיכום

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

משימת יישום

בחר תכונה מהפרויקט שלך ורשום את קריטריוני הקבלה. בקש מה-AI ליצור מקרי בדיקה עם התבנית "יצירת תרחישים מבוסס טכניקה". לאחר מכן החל את התבניות "צייד מקרים קצה" ו"בדיקת עקיבות". כתוצאה מכך: (1) הוסף לפחות 3 מקרים קצה שה-AI מדלג עליהם, (2) גזום מקרים שאינם מתחברים לאף קריטריון קבלה, (3) כתוב מקרים חדשים אם יש קריטריוני קבלה שלא נבדקו. יוצקים את הסט הסופי לגיליון אלקטרוני.

רשימת בדיקה

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