PracticU

פרמידת הבדיקות

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

פרמידת הבדיקות
רמות בדיקה הן קבוצות פעילויות בדיקה שמאורגנות יחד ומתאימות לשלב בפיתוח. כשמציירים אותן זו על זו מקבלים פירמידה, שהבסיס שלה רחב ביותר.
הרמות מהבסיס לקודקוד
1. בדיקות רכיבים (Unit / Component): הבסיס הרחב. בודקים כל רכיב, מתודה, פונקציה או טבלה בנפרד. לעיתים המפתחים עצמם בודקים זה את זה.
2. בדיקות אינטגרציה ומערכת (Integration / System): בודקים שהחלקים עובדים זה עם זה, ואחר כך את המערכת כולה מקצה לקצה. מספר הבדיקות כאן נמוך יותר.
3. בדיקות קבלה (Acceptance): הקודקוד הצר. בודקים את סיפורי המשתמש לפני המסירה ללקוח הסופי, עם מעט בדיקות וקומפוננטות.
דוגמה: מערכת ATM
בבדיקות הרכיבים בודקים את הקידוד והשאילתות. ברמת המערכת בודקים את הזדהות המשתמש והגישה לחשבון. בבדיקת הקבלה בודקים את משיכת הכסף כמכלול, כפי שהמשתמש יחווה אותה.
ככל שעולים בפירמידה, יש פחות בדיקות, והן מכסות מערכת שלמה יותר.
השיעור הבא בקורס: Component Testing

פרקי ההרצאה: פרמידת הבדיקות

  1. 00:00

    מבוא: רמות הבדיקה ופירמידת הבדיקות

  2. 00:58

    בסיס הפירמידה: פיתוח ובדיקות יחידה

  3. 01:36

    דוגמה: מערכת ATM ובדיקת רכיבים

  4. 02:31

    בדיקות אינטגרציה ובדיקות מערכת

  5. 03:25

    יחס מספר הבדיקות בין הרמות

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

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

  1. 00:03

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

  2. 00:18

    דיברנו על Software Development Lifecycle, המחזור חיים של פיתוח התוכנה. יש לנו דוגמה לאיזושהי סכמה פשוטה של Software Development Lifecycle, יש לנו את שלב התכנון, שלב הפיתוח הבסיסי, שלב העיצוב של התהליך, שלב ההספקה בעצם, שלב ה-Maintenance, שלב ההספקה ללקוח. לכל אחד ואחד מהשלבים שראינו יש את הרמות בדיקה

  3. 00:43

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

  4. 01:00

    מהי פירמידת הבדיקות? הבסיס הרחב הוא שלב הפיתוח, שלב ה-Development, הפיתוח המאסיבי של כל הקומפוננטות, כל המתודות, הפונקציות, הקלאסים, הטבלאות, הקישור ל-DataBase, השאילתות.

  5. 01:16

    כל השלב הזה מתבצע בחלק הראשון של ה-Software Development Lifecycle, ופה הרמת בדיקה היא Unit Test או Component Test, רמה של בדיקות רכיבים, כל רכיב שהולך להיות חלק מהקוד, חלק מהמערכת, חלק מהפרויקט, שבסוף ייצר את המוצר הסופי למשתמש הקצה.

  6. 01:38

    בואו נדמה את התוכנה שלנו, נשתמש בדוגמה של מערכת ATM, מערכת למשיכת כסף בבנק. אז בשלב הזה בעצם אנחנו נבצע את כל הקידוד, את כל הטבלאות, את כל הקישוריות למערכת של האשראי, מערכת החשבונות של הבנקים.

  7. 01:57

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

  8. 02:11

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

  9. 02:28

    לעיתים קרובות השלב הזה לא יבוצע על ידי הבודקים עצמם, אלא על ידי מפתחים שיבדקו מפתחים אחרים. השלב השני הוא שלב האינטגרציה או ה-System Test.

  10. 02:39

    Integration Test ו-System Test זה שלב שבו כבר אנחנו יכולים לבצע איזושהי בדיקה, בשלב אמנם מוקדם, לפני שהלקוח הסופי יכול להיחשף למערכת, אבל כבר של חלקים במערכת בצורה מוגמרת, כולל גוי, כולל הקצה אל קצה, הנקודה שבה המשתמש יוכל לבצע פעולות בצורה שלמה. דיברנו על סיפורי לקוח, סיפורי משתמש, המשתמש שלנו רוצה להיכנס ולקבל דיווח על מצב

  11. 03:07

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

  12. 03:24

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

  13. 03:31

    אז הכמות הכי גבוהה היא בשלב ה-unit test, והכמות הנמוכה יותר היא בשלב האינטגרציה. והשלב האחרון, שבו הלקוח כבר יכול להיחשף אל התוכנה שאנחנו מפתחים, ה-acceptant test. ב-acceptant test אנחנו רוצים בעצם לבדוק את סיפורי המשתמש.

  14. 03:48

    בחלק הזה, שימו לב, ויש את הכי פחות טסטים והכי פחות קומפוננטות.

לקורס המלא: קורס הכנה למבחן ISTQB אונליין

ההרצאה הקודמת: מודלים למחזור חיי תוכנה

ההרצאה הבאה: Component Testing

הרצאות קשורות מקורסים אחרים

  • צוות הבדיקות - QA
  • איש הבדיקות כשחקן צוות
  • הגדרת תוספים במייבן לדוגמה תוסף הבדיקות

קורסים נוספים במסלול

  • קורס בדיקות ידניות - QA
  • קורס בדיקות ידניות - Manual Testing