PracticU

בדיקות קופסא לבנה

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

בדיקות קופסא לבנה
בדיקות קופסה לבנה מתבצעות ברמת שורות הקוד והארכיטקטורה של המערכת. כדי לבצע אותן צריך היכרות עם אופן כתיבת הקוד, והן מאפשרות לבדוק את המערכת ברמה הפנימית שלה.
בדיקה סטטית של קופסה לבנה
1. הרעיון: סקירה שיטתית של הקוד והארכיטקטורה בלי להריץ את התוכנה. הבדיקה נקראת גם Structural Analysis.
2. מטרה: לאתר באגים כבר בשלב הפיתוח, כדי למנוע עלות יקרה יותר של איתור הבאג בשלב מתקדם.
Formal Reviews
3. תהליך רשמי: מתכנתים ואנשי QA עוברים על הקוד, מגדירים כללי בדיקה, מחלקים תפקידים ומפיקים דוח ממצאים.
4. עזרה לבדיקה השחורה: התוצאות עוזרות לבודקי הקופסה השחורה להגדיר מקרי מבחן במקומות הבעייתיים יותר בתוכנה.
5. יתרונות נוספים: מתכנתים צעירים לומדים ממפתחים מנוסים, המתכנת כותב קוד זהיר יותר כשהוא יודע שהוא נבדק, ומנהלי הפרויקט מקבלים תמונה על התקדמות הפרויקט.
6. לא להפוך לאופנה: אין לבצע סקירה רשמית רק בגלל שזה נהוג. הערך נמצא בעצם הביצוע ובמה שהוא מאפשר.
תקנים וגופים
7. גופי תקנים: בתחום קיימים גופים שמפרסמים תקנים, כמו ANSI, IEEE ו-ISO. מסמכי בדיקה, מסמכי פיתוח ותקנים אחרים מתפרסמים שם.
מעמד הבודק
8. שילוב נדיר: רוב החברות מגייסות בודקים ברמה נמוכה, שאינם מבינים קוד. השילוב המבוקש הוא בודק שמסוגל לתכנת ולבצע בדיקות ברמת קופסה לבנה.
בדיקות דינמיות של קופסה לבנה
9. הרעיון: בודקים כל יחידה קטנה קודם, כמו שורה, לולאה או פונקציה. רק אחר כך בודקים את המודול כולו ואת המערכת.
בדיקת קופסה לבנה מתבצעת בעיקר על ידי מתכנתים, בשיתוף פעולה הדוק עם צוות ה-QA.
השיעור הבא בקורס: בדיקות קונפיגורציה

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

  1. 00:00

    בדיקה ברמת שורות הקוד והארכיטקטורה

  2. 00:44

    סקירה שיטתית של הקוד ללא הרצה

  3. 01:18

    מציאת באגים כבר בשלב הפיתוח

  4. 01:53

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

  5. 02:32

    סקירות ככלי ללמידה ובקרה

  6. 03:29

    תקנים וגופים שקובעים סטנדרטים

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

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

  1. 00:05

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

  2. 00:30

    לדבר הזה קוראים בדיקות קופסה לבנה עכשיו, בדיקות ברמת התוכנה פנימה, כלומר בדיקות שמעורבות ברמת שורות הקוד זה נקרא Static Whitebox Testing שזה בעצם בדיקות קופסה לבנה סטטיות הרעיון של זה זה בעצם לעבור ולסקור בצורה שיטתית לעשות ריוויו לקוד ולארכיטקטורה מבלי לבצע פעולת Executing שזה פעולת הוצאה של התוכנה כאילו שתעבוד

  3. 01:01

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

  4. 01:27

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

  5. 01:40

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

  6. 01:53

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

  7. 02:13

    במיקומים שנראים כבעייתיים יותר בתוכנה. כלומר, התהליך של ה-Formal Reviews עוזר לי לבצע את ה-Equivalent partitioning. עצם התהליך הרשמי והמסודר של סקירת קוד עוזר לי בעצם לאתר באקים עוד בשלב הראשוני. מדוע?

  8. 02:32

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

  9. 02:46

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

  10. 03:03

    בתוך הזה גם מאפשר למנהלי הפרויקט לקבל כלי מהקו איך הפרויקט הזה מתקדם, אז זה התפקיד של ה-Formal Reviews. זה כמו איזה סוג של Brain-Storming ממוסמך, כל המתכנזים הצעירים מנהלי הפרויקטים מרוויחים מזה.

  11. 03:18

    גיידלנד וסטנדרטס, כדי לדעת איך בכלל לעבוד עם מדריכים וסטנדרטים בתעשייה הזאת, כשל-QA יש איזה שלוש אגודות, שלוש עמותות ה-NC, טכנולוגי אמריקן ניישנל סטנדרט אינסטיטוט, ה-IEEE שזה Institute of Electrical and Electronics Engineers הם קובעים סטנדרטים בתעשייה הזאת, אתם יכולים

  12. 03:43

    לראות את הכתובות שלהם פה, וגם ה-ISO נתונה של Organization for Standardization, זה ISO אז שם אם אתם רוצים לבדוק איזה מסמכי בדיקה יש האחרונים, מהם התקן למסמכים של הבדיקות, מהו התקן למסמכים של פיתוח, כל הנתונים האלה בדרך כלל נמצאים דווקא באדר השלישי ב-IEEE

לקורס המלא: קורס בדיקות תוכנה אונליין

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

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

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

  • בדיקות קופסה לבנה
  • בדיקות אוטומטיות מול ידניות - ובדיקות קופסא שחורה
  • סוגי בדיקות
  • בדיקות ידניות

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

  • קורס Load Runner - בדיקת עומסים
  • Quality Center
  • מבחן QA לדוגמא