הדגמה של כל סוגי הבדיקות
פרקי ההרצאה: הדגמה של כל סוגי הבדיקות
תמלול ההרצאה: הדגמה של כל סוגי הבדיקות
הטקסט המלא של הדקות הראשונות בהרצאה «הדגמה של כל סוגי הבדיקות» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום לכולם. בסעיף 2.3.5 מבקש חומר ההסמכה הרשמי של ה-STQB להדגים את סוגי הבדיקות ורמות הבדיקה שלמדנו.
נדגים את בדיקות הפונקציונליות, בדיקות לא פונקציונליות, בדיקות קופסה לבנה ובדיקות מבוססות שינוי. לצורך ההדגמה נשתמש באפליקציה בנקאית, לדוגמה האתר הזה.
באתר הזה ניתן לבצע מספר פעולות שרלוונטיות לתחום הבנקאי הלוואות, אשראי, רישום, בדיקת עסקאות וחיובים בכרטיס וכדומה.
בדיקה פונקציונלית ברמת בדיקה של בדיקות רכיבים Unit Test Accept and Acceptance Testing נרצה לבדוק את הרכיב האחראי על חישוב ריבית.
איך נבצע את הבדיקה הזאתי? נבצע את הבדיקה הזאת על ידי בידוד אותו רכיב, הזנת הקומפוננטה או המתודה בנתונים, גובה ההלוואה לדוגמה, ונרצה לראות את חישובי הריבית והתוצאות, האם הן נכונות.
זה שלב מאוד בסיסי בתהליך הפיתוח. עבור בדיקות אינטגרציה של רכיבים, נעצב בדיקות בהתבסס על הדרך בה מידע המשתמש שמתקבל בממשק, המשתמש, מועבר ללוגיקה העסקית.
כלומר, נרצה לבדוק איך ניתן לבצע כניסה לחשבון וקבלת מידע ספציפי של המשתמש שביצע את ההזדהות. לדוגמה, איזה מבצעים והטבות רלוונטיים למשתמש שנכנס למערכת וזוהה על ידי המערכת.
זוהי בדיקת אינטגרציה. בדיקת אינטגרציה נוספת של רכיבים יכולה להיות הזדהות של משתמש, ואחרי כניסה של המשתמש למערכת, לבדוק איזה פעולות ואיזה הלוואות מוצעות לו בהתאם לדירוג שלו, לדירוג של החשבון שלו ולדירוג האשראי שלו.
קבעו בדיקות המערכת, מעוצבות בדיקות בהתבסס על הדרך בה מחזיקי חשבון יכולים לבקש אשראי בחשבונות הראש שלהם, כלומר לבצע את הבדיקה שלנו בהתאם לסיפור המשתמש סיפור הלקוח המבקש לבצע הלוואה בעזרת המערכת בעזרת האפליקציה.
עבור בדיקות אינטגרציה של מערכות מעוצבות בדיקות בהתבסס על הדרך בה המערכת משתמשת במיקרו סרוויס חיצוני כדי לבדוק את דירוג האשראי של מחזיק חשבון, מה הכוונה? הכוונה היא שהמערכת צריכה להתממשק עם מערכת אחרת שלא נמצאת בסביבה שלה, מערכת של נתונים לדוגמה שווה או מערכת דירוג אשראי
אחרת על ידי שימוש במיקרו סרוויס שפונה אל המערכת הזאת ומקבל ציון עבור דירוג האשראי של מחזיק החשבון שנשלח מהמערכת הנבדקת. היכולת של המערכת שלנו לשלוח את פרטי הלקוח ולקבל דירוג אשראי חזרה מהמערכת הרלוונטית, המערכת החיצונית, על ידי מיקרו סרוויס, זאת בדיקת אינטגרציה קלאסית.
עבור בדיקות קבלה מוצבות בדיקות בהתבסס על הדרך בה הבנקאי מאשר או דוחה את הבקשה לקבלת אשראי. זאת אומרת, מבצע איזשהו סיפור שמתחיל מבקשת האשראי וממשיך בשימוש של הבנקאי שמאשר או דוחה את הבקשה לקבלת האשראי ואיך הממשק עם הלקוח מתבצע אחרי פעולת אישור או דחייה של בקשת ההלוואה על ידי הבנקאי.
אלו בדיקות קבלה, בדיקות השלב הסופי בתהליך הפיתוח של התוכנה. הדוגמאות הבאות יהיו לבדיקות לא פונקציונליות. עד עכשיו עסקנו בבדיקות פונקציונליות, בדיקת פעולות עצמם ותוצרים, תוצאות על ידי המערכת.
כרגע אנחנו עוברים לבדיקה לא פונקציונלית. שימו לב להבדל, נובעו בדיקות רכיבים מעוצבות, בדיקות ביצועים להערכת מספר מחזורי המעבד הנדרשים לביצוע חישוב מסובך של ריבית.
נרצה לראות את התנהגות המערכת בזמן מאמץ, בהעמסת המערכת או בהצבת אתגר חישובי למערכת על מנת לוודא את החישוב מסובך של ריבית. עבור בדיקות אינטגרציה של רכיבים מוצבות בדיקות אבטחה ובדיקת חולשה מסוג גלישת חוצץ באפר אוברופלואו עקב
נתונים שעוברים מממשק משתמש ללוגיקה העסקית. בדיקה זו באה לבדוק גלישת זיכרון של המערכת, טיפול לא נכון של המפתחים בהעברת מידע שעובר מממשק המשתמש ללוגיקה העסקית בין השכבות של המערכת.
עבור בדיקות המערכת מוצבות בדיקות ניידות תוכנה או פרוביטביליטי טסטינג שבודקות אם שכבת הייצוג פרזנטיישן לייר עובדת עם כל הדפנים הנתמכים וכל המכשירים הניידים הנתמכים.
בבדיקה זו אני רוצה לראות שהמערכת שלנו לדוגמה האפליקציה הבנקאית עובדת כשורה