פרק 4 - טכניקות בדיקה - בדיקות קופסה שחורה
פרקי ההרצאה: פרק 4 - טכניקות בדיקה - בדיקות קופסה שחורה
תמלול ההרצאה: פרק 4 - טכניקות בדיקה - בדיקות קופסה שחורה
הטקסט המלא של הדקות הראשונות בהרצאה «פרק 4 - טכניקות בדיקה - בדיקות קופסה שחורה» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום לכולם, הגענו לפרק 4, חומר ההסמכה הרשמי להסמכת בודקי תוכנה במסגרת ISTQB. בפרק 4 נכיר מושגים שכבר את חלקם הכרנו במהלך הפרקים הקודמים.
בואו נראה את המושגים שיוזכרו או כדאי להכיר על מנת להיות מוכן לשאלות על פרק 4 בנושא טכניקות בדיקה. טכניקת בדיקה מסוג קופסה שחורה חדשנו סרטון להבדלים בין קופסה שחורה לקופסה לבנה.
כל בודק תוכנה חייב לדעת את ההבדלים בין טכניקת בדיקה קופסה שחורה לטכניקת בדיקה קופסה לבנה. אז בואו ניתן דוגמה לטכניקת קופסה שחורה.
יש לנו את הדף הזה שהוא חלק מאיזשהו דף של חישוב משכנתא, מחשבון משכנתא. כשאנחנו מתייחסים לטכניקת בדיקה מבוססת קופסה שחורה, נתייחס לכל הטופס הזה על השדות שלו כיחידה שהמטרה שלה בסוף זה להוציא חישוב נכון לפי הנתונים שהוזנו אוקיי אז זה מה שאנחנו קוראים
קופסה שחורה אנחנו קובעים סכום משכנתה תקופת שנים שהמשכנתה תפוזר הריבית השנתית שאנחנו נגיד מעוניינים לשלם החזר חודשי אנחנו רוצים לחשב אותו נלחץ ואז יש לנו פה את התוצאה וכבודקי תוכנה אנחנו נבדוק באמת את הכנות של הטופס, את הבהירות של הטקסט, את הוויזואליות, את החוויית משתמש, את האלוגריתם עצמו שהוא נוצר נכון מבחינת
החישוב שלנו, מבחינת הנתונים, אנחנו נבצע את החישוב במקביל אולי, אוקיי?
נראה את הלוח סילוקין וכדומה. לעומת זאת, בטכניקת בדיקה לבנה אנחנו נרצה לדעת ממש את החישוב מאחורי הקלעים, מה קורה, ופחות דרך הגוי.
נרצה לראות מה קורה מאחורי הקלעים, איך כתבו את האלגוריתם הזה שעושה את החישוב של ההחזר החודשי וכדומה. לא נסתפק רק בצד הזה של ה-end user, של לקוח הקצה, אלא נרצה לראות ממש מה קורה שם מאחורי הקלעים מבחינת המחשבון, הנתונים עצמם.
מושג נוסף שנכיר במהלך פרק 4 הוא ניתוח ערכי גבול, טכניקת בדיקה שנקראת גם Boundary Value Analysis. זאת אומרת, מה זה Boundary Value Analysis?
זה אומר, כשאנחנו נרצה, ניגש לבדוק נתונים, אנחנו נרצה לראות מה נתוני הקצה שאותם המערכת יכולה לקבל. זאת אומרת, אם תקופה בשנים יכולה להיות עד 100 שנה, או סליחה עד 30 שנה, אז אנחנו נבדוק מה קורה כשאנחנו נותנים 30 שנה בדיוק או 31 שנה ולראות איך המערכת מגיבה
ונותנת תודעת שגיאה. עכשיו ערכי גבול יש להם את שני הצדדים, יש את ערכי גבול המקסימלי נגיד 30 וערכי גבול מינימלי שזה נגיד 0, אז בוא נראה איך המערכת מגיבה, היא לא נותנת לי לחשב אם אני עושה 1, גבול של 1 היא עדיין לא נותנת לי כי זה מתחת לערך גבול אם אני כותב 5 היא כבר נותנת לי הערך גבול פה הוא לפחות 3 נכון אז אני צריך
מבחינת ערכי גבול מינימליים לתת 3 ולראות שהיא מנטרלת את הפעולה לתת 4 זה כבר ערך גבול חיובי כן אנחנו נכיר את הביטוי הזה עוד בהמשך ויש לנו את הboundary value העליון את ערך הגבול העליון לדוגמה 60 שנה הוא כבר לא נותן לי הוא משנה את זה ל-30, 30 זה המקסימום אם אני נותן לו 31 הוא מאפס לי את זה ל-30.
טכניקות נוספות שנכיר ונשמע עליהן בדיקות מבוססות רשימת ביקורת check list based testing מה זה אומר check list based testing זה אומר כשאנחנו ניגשים לבדוק את הדף אנחנו נכתוב סיפורים שבהם המערכת תצטרך להתמודד לדוגמה לקוח רוצה משכן של 500,000 שקל, תקופה של 20 שנה, ריבית שנתית לא יותר מנגיד 3% ונגיד לו את החישוב החודשי
אז יש לנו פה את התהליך עצמו ואנחנו נוכל לשחק עם זה ולראות את הנתונים איך זה משתנה, כן? זה מחשבון משכנתא להיפותטי למה יקרה אם הריבית השנתית תעלה או תרד, אוקיי?
זה סימולטור בעצם, סימולטור משכנתא. אז אנחנו נוכל לראות את ה... בעצם לעשות את הצ'קליסט הזה לפי סיפורים, האם הסכום משכנתא בשח, האם זה החזר חודשי. אז יש לנו פה החזר חודשי לפי קרן שווה, אז יש לנו את הסכום המשכנתא, כן, אם לקוח רוצה לראות אם הוא יכול לשלם רק 1,000 שקל, האם כמה משכנתא הוא יכול לקבל לפי הגישה הזאתי.
אז אלו סיפורים, זה צ'קליסט, ובעצם אנחנו מכינים רשימה של צ'קליסט של סיפורים, והם ניגשים ומתחילים לבדוק את המערכת מול הצ'קליסט.
טכניקת בדיקה מבוססת על כיסוי, coverage. אנחנו רוצים בעצם לראות שהטסטים שלנו מכסים חלקים מהאפיון, חלקים מה-requirement, מהדרישות, לפי אחוזים, וככה אנחנו מתייחסים בעצם לתהליך שלנו.
גם הקופסה השחורה, גם ערכי גבול, גם בדיקות מבוססות צ'קליסט, רשימות ביקורת, גם הם כולם יכולות להשתלב עם טכניקת ה-Coverage, טכניקה שמבוססת על תצוגת הכיסוי של הבדיקות על המערכת, כיסוי החלטות Decision Coverage, זאת אומרת לבנות תהליך החלטות על ידי משתמש הקצה שאותם אנחנו רוצים לבדוק.
בדיקות טבלת החלטה, Decision Table Testing, זו טכניקה שמבוססת על סוג של צ'קליסט או רשימה של החלטות, אבל בצורת מטריצה, האם הוא ביצע את זה ככה, איך המערכת מתנהגת, ואז בעצם לשחק עם טבלת ההחלטה על מנת להגיע לכיסוי מיטבי.
בואו נראה דוגמה של זה. בואו נניח שנתנו לנו אפליקציה שמבוססת Web, ואנחנו רוצים לבדוק אותה בעזרת טכניקה של טבלאות החלטה או טבלאות בדיקה.
אז מה שאני הכנתי, הכנתי כאן איזושהי מטריצה שבצד שמאל יש מערכות הפעלה, בצד ימין יש בראוזרים, ובעצם אני ארצה לבדוק את ההתנהגות של כל מיני סיפורים שאני אבצע, או כל מיני פעולות ותהליכים שאני אבצע למערכת,
לפי הטבלת ההחלטה הזאת, זאת אומרת Windows 10. אני אבדוק את תהליכי העבודה באפליקציה על Windows 10 וחום על Windows 10 וספארי אני יכול לבדוק את זה גם עם פיירפוקס או אולי נבדוק את זה על סמסונג ונבצע כאן בעצם את הבדיקה אבל לדוגמה על פיירפוקס אני יכול לוותר אז אני ארשום פה שאני לא מבצע ואז בעצם לבנות איזושהי מטריצה של כיסוי קווי רד של הבדיקות
שלנו אני מבצע את הבדיקות לפי המטריצה הזאתי אוקיי אני אני אבדוק את הפיירפוקס כן על מערכות הפעלה מבוססות ה-iOS לדוגמה, כך שיהיה לי בעצם כיסוי על המערכות האלה.
ההיגיון אומר שאנחנו נבחר את המטריצה לפי הפופולריות של כל חלק וחלק, או כל שילוב של בראוזר מסוים במערכות ההפעלה, כן? יש לנו את האנדרואיד, אז באנדרואיד לא נבדוק נגיד ספארי, אבל כן נבדוק את החום ואת הסמסונג בראוזר, סמסונג אינטרנט בעצם על המערכות ההפעלה האלה של האנדרואיד, Firefox לא וחום כן.
אוקיי, אז ככה אני בונה לעצמי את הטבלת עבודה ואז יש לי לוח עבודה שאני יכול להציג לצוות הניהולי כבקרה על תהליכי העבודה במערכת שלנו.
זה גם חשוב לזכור שאנחנו בונים את הטבלאות או את הגישות בדיקה שלנו על פי סטטיסטיקה. זאת אומרת, אנחנו רואים לדוגמה פה באתר StatCounter שיש לנו דירוג של המערכות ההפעלה הכי נפוצות, יש לנו בעצם את ה-Devices הכי נפוצים או את ה-Vendor של ה-Devices הכי נפוצים, אנחנו יכולים לראות גם איזה בראוזר הכי נפוץ,
לדוגמה, אם אני רוצה לבדוק את הבראוזר, אז אני יכול לראות פה שהכי נפוצו חום, ספארי, פיירפוקס, אז אנחנו רואים שחום וספארי מחזיקים בכמעט 80% מהשוק, או יותר מ-80% מהשוק, וכל היתר קצת פחות.
אז אנחנו יכולים לבנות את הטבלה שלנו, כאמור, בהתאם לסטטיסטיקה, ולהראות בעצם למה בחרנו את המטריצה ולמה בחרנו את הבדיקה כמו שבחרנו.
טכניקות נוספות שנכיר במהלך הלימוד על פרק 4, ניחוש שגיאות או גייסינג, זה לפי ניסיון וידיעה מהעבר איפה רוב התקלות נמצאות מבחינת המערכת, מבחינת האפליקציה שאותה אנחנו בודקים.
זה מתבסס על בודקים ותיקים ובודקים שיודעים בעצם איפה הנקודות החלשות של המערכת. בדרך כלל הנקודות החלשות של המערכת יהיו בנקודות של אינטגרציה עם מערכות אחרות.
מחלקות שקילות equivalence partition הטכניקה הזאת מתכתבת עם בעצם טכניקת בדיקה מסוג קופסה שחורה מה שהיא אומרת וגם עם טכניקת של ניתוח ערכי גבול boundary value analysis מחלקת שקילות