בדיקות תפקודיות כגון האם רכיב הזה עובד או לא עובד כפי נדרשת פונקציונליות שלו, כאשר בודקים את המערכת בתוך הקוד – מבפנים.
לעומת זאת גישת קופסה שחורה אומרת שיש לבצע בדיקות תפקודיות ללא הבנה איך הכל עובד בתוך הקוד או חומרה.
מפתחי תוכנה מחפשים באגים בקוד תוך הרצת הקוד עד שורה שיש שם עצירה ומתקנים באגים.
Data flow testing
בדיקות מסוג קופסת לבנה שבה יש טרנספורמציה של סגמנט הקוד לתרשים זרימה שבה מצב אחד תלוי בשני.
Data Flow Diagram = DFD
A: int x,y,a,b;
B: scanf("%d %d",&x,&y);
C: a=x;
D: b=y;
E: while(a!=b) {
F: if(a>b)
G: a-=b;
H: else b-=a;
I: } printf("%d",a);
כיסוי משפטים (statement coverage) – זה אחוז המשפטים שהתבצעו בפועל על ידי סדרת בדיקות מתוך כלל משפטים בתוכנה. כלומר יש לחלק מספר המשפטים שהורצו במספר המשפטים שיש בקוד.
Code coverage is:
בדיקה עד כמה כוסו (בוצעו) חלקי התוכנה על-ידי בדיקות.
לדוגמה: אם נעשים BREAK-POINT בשורה 23 אז על-ידי הרצת קומפיילר אנו נבדוק את השורות …15, 16..22, 23 וכך הלאה ככל שנבדוק יותר שורות בקוד (סגמנטים בקוד) כך CODE COVERAGE יהיה גדול יותר.
נניח שבקוד יש 16-30 שורות ⇐ 15 שורות ונניח שבדקנו שורות 22-25: 4 שורות.
לכן Code coverage: 4/15*100=~26%
1 TEST SET
Test 1: x=2,y=3
ב-TEST 1 יוצא ש Z=8 לכן יש כיסוי של השורות 1-5
2 TEST SET
Test 2: x=0,y=25
ב-TEST 2 יוצא ש Z=50 לכן יש כיסוי של השורות 1-5
3 TEST SET
Test 3: x=47,y=1
ב-TEST 3 יוצא ש Z=49 לכן יש כיסוי של השורות 1-5
אם נבצע רק את 1 TEST SET אז בצענו רק 5 שורות מתוך 6 לכן 5/6*100=~83%
מקרה אחר:
4 TEST SET
Test 1 x=20,y=25
אז מספיק רק TEST SET 4 כדי לכסות כל השורות כלומר Z=70 לכן ביצענו כל 6 השורות ולכן זה 100% של כיסוי משפטים (statement coverage).
TEST SET 1
Test 1_1: x=20, y=15
אז Z=-10 ולכן יש כיסוי של כל 6 שורות שזה אומר שיש 100% כיסוי משפטים (statement coverage).
אבל בשביל שיהיה גם 100% כיסוי של החלטות (decisions coverage) יש להתחשב גם בהחלטה שיהיה Z גדול מ-0 לכן בואו נצייר control flow diagram:
לפי control flow diagram ניתן לראות ש Test 1 לא מכסה ב-100% כל כיסוי של החלטות (decisions coverage) ולכן אם נוסיף: Test 2: x=10, y=2 אז נקבל Z=6 ובכך נקבל 100% כיסוי של החלטות (decisions coverage).
לסיכום: אם ל-Decision coverage יש כיסוי של 100% אז גם ל- statement coverage יש כיסוי של 100%. אבל כיסוי של 100% statement coverage לא אומר שיש כיסוי 100% של Decision coverage.
הערכה עד כמה טוב בדקנו לפי סה”כ באגים שדווחו כנגד לבאגים אשר פתרו.
Test efficiency=x/y a=באגים אשר פתרו b=סה"כ באגים שדווחו Testing Efficiency=[a/b]*100
ב-Pairwise testing במקום לבדוק כל קומבינציות בין מרכיבים שונים, בודקים רק את הקומבינציות בין רכיבים סמוכים.
נניח שיש 6 מקרי בדיקה לצורך בדיקת: Sign-up, כלומר יש תרחיש (TEST SCENARIO) ששם יש לבצע שישה מקרי בדיקה:
1) הרשמה לאתר אם נתונים לא נכונים
2) הרשמה לאתר אם ניתוקי אינטרנט
3) הרשמה לאתר כמשתמש קיים (Error exists user)
4) הרשמה לאתר תחת עומסים
5) הרשמה לאתר כמשתמש עם מוגבלות ראיה
6) הרשמה לאתר תקינה
ונניח שלכל מקרה בדיקה (TEST CASE) יש בערך 5 דקות זמן ביצוע.
אז סה"כ יש 5X6=30 דקות לביצוע כל בדיקות אבל ללא קומבינציות שונות בטבלה מעלה.
ועם קומבינציות שונות:
OS: WIN, IOS, LIN
Browser: Chrome, Firefox, IE, Opera
Device: Desktop, Mobile, Tablet, TVbox
Localisation: Eng, Heb, Rus
מכיוון שרוב הבאגים נמצאים במקומות הגבוליים אז ניתן לקצר את הקומבינציות :
שלב א)
נסדר לפי אופציות, עמודות עם יותר אופציות יהיו שמאלה יותר:
שלב ב)
לכן:
אז קצרנו ל- 16 קומבינציות שזה אומר 30X16=480 minutes
שזה הרבה פחות מ- 4320 דקות!
בדיקה מסוג קופסה שחורה שבה יש פעולות בין מערכת למשתמש. כך שלכל פעולות הזאת יכולה להיות תוצאה חיובית או שלילית ובהתאם לכך תהיה פעולה הבאה.
לדוגמה:
כפי שניתן לראות לכל מקרה שימוש יש תוצאה מוצלחת (1-5 STEPS) וגם תוצאה אשר לא מוצלחת (STEPS 2a,4a,4b).
בדומה לדיאגרמת מצבים ב-Use case testing יש תלות מצב הבא בקודם לו!
אבל אני אישית מעדיף את
State transition מאשר
Use case testing כי
ב-State transition(דיאגרמת מצבים) ניתן קל יותר לראות את מקרי בדיקות אשר יש לכתוב אשר תלויים אחד בשני.
.
בדיקות מסוג קופסת שחורה שבה יש תלות מצב אחת בשני.
דוגמה:
דיאגרמת מצבים עוזרת לבנות סטי של מקרי בדיקה (test suites) כאשר יש מספר אופציות בדרך למטרה. זאת אומרת שיש תלות תנאי הבא בתנאי שקודם לו בתהליך של פעולה, לדוגמה הוצאת כסף ב-ATM.
הערה: לעומת טבלת מצבים ששם יש מספר תנאים (כל תנאי יכול להיות נכון או לא נכון והם לא תלויים אחד בשני) ,בדיאגרמת מצבים יש תלות בתנאי הבא או שקודם לו.
.
טכניקת קופסה שחורה – בדיקות טבלאות החלטה: מקרי הבדיקה מעוצבים תוך שימוש בצירופי הקלט המוצגים בטבלת החלטה.
לדוגמה:
בדוגמה הזו אנחנו בונים מקרי הבדיקה (test cases) ובכך בודקים לפי תוצאה הצפויה (אם הכל מתקיים).
כאשר מספר אפשרויות (מספר עמודות RULES ניתן לחשב לפי נוסחה:
2^n where n is inputs (New Customer, VISA CARD, Coupon => 3 inputs) In our example: 2^3=8 rules
לסיכום:
טוב להשתמש בטבלת החלטות כאשר צריכים לבנות מקרי בדיקה עבור וריאציות שונות של תנאים ולכל תנאי יש רק שתי אופציות TRUE או FALSE.
כאשר יש צורך בהכנסת נתונים עבור מקרי בדיקה, אז משתמשים בטכניקות של קופסה שחורה שנקראת בדיקות ערכי גבול וקבוצות שקילות.
בדיקות ערכי הגבול לפי טכניקת קופסה שחורה.
Just below the minimum Minimum Just above the minimum A nominal value Just below the maximum Maximum Just above the maximum
לדוגמה יש STRING שיכול להכיל מ-1 עד 30 סימנים. אז יש לבדוק במקרים הבאים:
בדיקה שמכסה את כל השילובים של מחלקות שקילות, למעשה זו טכניקת קופסה שחורה – מקרי הבדיקה מיוצבים כך שיכסו לפחות פעם אחת מחלקות שקילות שונות.
לדוגמה:
בדוגמה הזאת יש לחלק ל-4 תחומים, כאשר יש לקחת מכל תחום מדגם ולבדוק כגון:
לסיכום: טוב להשתמש בטכניקות של BVA & EP כאשר יש לבחור מתוך טווח גדול של ערכים שיהיו כנתוני כניסה עבור מקרי בדיקה.
ב-AGILE יש מספר גישות, נתרכז בגישה שנקראת SCRUM. ב-SCRUM יש הרצה של ספרינט אחרי ספרינט עד שמשלימים את הפיתוח של המוצר. בדרך כלל ספרינט אחת נמשך 1-4 שבועות, כאשר בתחילת כל ספרינט יש פגישה של – SPRINT PLANNING.
שלב א) מנהל המוצר – PRODUCT MANAGER מציג את המשימות שזה למעשה דרישות הלקוח (User Stories) שיש לממש לצוות הפיתוח ובודקי תוכנה ומעביר אותם ל-PRODUCT BACKLOG.
שלב ב) במהלך SPRINT PLANING (בהתחלה של הספרינט) SCRUM MASTER בוחר מספר משימות מ- PRODUCT BACKLOG ומעביר אותם ל-SPRINT. כאשר- SCRUM MASTER מקשר את PRODUCT MANAGER ל- DEV TEAM.
כאשר החלטה איזו משימות (User stories) להעביר מ- PRODUCT BACKLOG ל-SPRINT במהלך SPRINT PLANNING, נובעת מפגישה של מנתח עסקי, מפתחים, מנהל המוצר ובודקי תוכנה ורמת הקושי של ה-user story.
* בדרך כלל SCRUM MASTER הוא גם Team Lead.
במהלך SPRINT PLANNING (תכנון SPRINT) קובעים כמה משימות להעביר מ-Backlog על סמך נקודות משקל.
לכל משימה יש נקודות משקל( user story points) ועל סמך נקודות משקל האלו, ניתן להעריך בערך רמת הקושי של משימה עבור-SPRINT.
לאחר מכן בזמן של SPRINT כל צוות נפגש לצורך –
DAILY STANDUP / DAILY SCRUM MEETING ששם כל אחד מהצוות אומר מה הוא עשה ומה הבעיות שיש, DAILY STANDUP נמשך כ-15 דקות – בדרך כלל כל יום בשעות הבוקר, לפני תחילת עבודה או לאחר יום עבודה.
כאשר לפי Burn down chart – גרף שריפת נקודות (לכל משימה- User Story ב-PRODUCT BACKLOG יש נקודות Story Points ) אפשר לראות את הקצב התקדמות של פיתוח המוצר/תוכנה.
שלב ג) לאחר כל SPRINT מפתחים מציגים SPRINT DEMO כאשר בודקי תוכנה, בודקים את המימוש של SPRINT DEMO.
* בודקי תוכנה משתלבים לא רק בסוף של SPRINT כאשר בודקים SPRINT DEMO אלא הם עושים בדיקות סטטיות של דוקומנטציה וכתיבת מקרי בדיקה, checklists במהלך כל SPRINT עבור הרצת בדיקות ל-SPRINT DEMO
** כך חוזרים על כל השלבים שוב ושוב, ספרינט אחרי ספרינט עד שמשלימים פיתוח המוצר.
שלב א)
מנהל המוצר – PRODUCT MANAGER מציג את המשימות (User Stories) שיש לממש לצוות הפיתוח ו-Test Team ומעביר אותם ל-PRODUCT BACKLOG.
לצורך זה, בואו נדגים ב-DEMO פרויקט, אז יש לנו SPRINT שנקרא לו "Sprint 2" שיש לממש אותו בין התאריכים כפי שמופיע בתמונה למטה.
במהלך SPRINT PLANNING (בהתחלת של הספרינט) SCRUM MASTER בוחר מספר משימות מ- PRODUCT BACKLOG ומעביר אותם ל-"Sprint 2".
כאשר לכל USER STORY יש POINTS
בואו נתרכז Active Sprint
עכשיו בואו נצפה ב-Burn down chart גרף – שריפת נקודות
בואו נתבונן איך נראה USER STORY ב-Jira
