סוגי בדיקות
פרקי ההרצאה: סוגי בדיקות
תמלול ההרצאה: סוגי בדיקות
הטקסט המלא של הדקות הראשונות בהרצאה «סוגי בדיקות» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
טסט טייפס סוגי בדיקות בהרצאה הזאתי אנחנו נדבר קצת על החלוקה למשפחות של סוגי בדיקות lesson objectives מטרות השיעור טסטינג 3 נדבר על עץ הבדיקות static and dynamic testing ההבדלים בין בדיקות סטטיות לדינמיות שזה משפחה זה שתי משפחות של סוגי בדיקות functional and structural על טסטינג, נדבר על בדיקות מבניות ועל בדיקות פונקציונליות.
ויידבוקס טסטינג, אנחנו נזכיר בקצרה מה זה בדיקות קופסה לבנה ויש קורס שלם על נושא של ויידבוקס טסטינג. נדבר מה זה בלאקבוקס טסטינג, קופסה שחורה שזה המהות של כל נושא הבדיקות האוטומטיות והידניות.
נדבר על בלאקבוקס טסטינג טייפס, סוגים של בדיקות קופסה שחורה. בלקבוקס טסטינג מתודס, נדבר על שיטות לבלקבוקס וטסט טייפס אנד מתודס ריליישנשיפס, נדבר על הקשר בכל סוג של בדיקה איזה מתודות בדיקה אפשר לעשות.
טסטינג טרי, עץ הבדיקות. יש לנו, עץ הבדיקות הוא מורכב למעשה מהאבא שזה טסטינג, זה בדיקות שמתחלקות לשתי משפחות, סטטיק ודינמיק, כלומר בדיקות סטטיות ובדיקות דינמיות, ובדיקות דינמיות מתחלקות גם הן לשתי משפחות לפונקצ'נל ו-structural כלומר בדיקות פונקציונליות ובדיקות
מבניות. Static and Dynamic Testing מה זה בדיקות סטטיות ודינמיות? Static Testing Investigate source code without execute the code Investigate project documents בדיקות סטטיות זה למעשה לבדוק את הקוד עצמו בלי להריץ את הקוד זאת אומרת לעשות מיין קוד ריוויו שבו עוברים שורה
שורה על הקוד ומדברים האם הוא כתוב נכון האם הוא כתוב לא נכון אבל לא מריצים את זה בפועל לא לא רואים את התוצר הסופי של הקוד, לא רואים את הקוד בזמן ריצה.
רואים אותו על דפים או על מסך בלי להריץ אותו ובלי לדבק אותו. Investigate Project Documents עושים בדיקה של מסמכי הבדיקות. בודקים את מסמך האפיון, בודקים את מסמך ה-STP, את מסמך ה-STD, את מסמך דרישות הלקוח.
זאת אומרת, זו בדיקה שאין לה, היא לא מערבת את התוכנה עצמה. Dynamic Testing, בדיקות דינמיות Investigate the Software Behavior while it is Executing.
אוקיי, זה בדיקות שאנחנו מבצעים על התוכנה כשהתוכנה רצה, כשהתוכנה באמת עובדת. אנחנו רואים את התוכנה עובדת מול העיניים שלנו.
אנחנו לא רואים את הקוד או שאנחנו יכולים לראות גם את הקוד שלה, אבל זה פחות מעניין אותנו, מעניין אותנו ההתנהגות של התוכנה בפועל.
Functional and Structural Testing בדיקות פונקציונליות ובדיקות מבניות Functional Testing ובדיקות פונקציונליות Testing the functionality of the program known as black box testing אז בדיקות פונקציונליות ולמעשה לבדוק שהפונקציות שהתוכנה עושה את מה שהיא אמורה לעשות קוראים לזה גם בדיקות קופסה שחורה כי בדרך כלל לא מעניין אותנו הקוד שבפנים מעניין אותנו ההתנהגות מעניין אותנו שאם היא צריכה לעשות א' היא באמת עושה
א' מעניין אותנו שאם אנחנו מכניסים לה כקלט כאינפוט סטרינג מסוים היא אמורה לתת לנו כאוטפוט לשלוף לנו רשומה מהדאטאבייס או כל מיני דברים כאלה.
white-structural testing ובדיקות מבניות testing the logic of the program known as white-box testing אז פה אנחנו בודקים את הלוגיקה של השורות קוד אנחנו למעשה בודקים שהשורות קוד הן באמת נכונות שאנחנו כותבים שורות קוד שיבדקו שורות קוד של התוכנה מה זאת אומרת נניח ויש לי לולאת for בתוכנה עצמה אני אכתוב איזושהי
פונקציית בדיקה שתריץ את הלולאת for הזאת ותראה שהיא באמת עובדת נכון והבדיקות האלה ידועות בשם של בדיקות קופסה לבנה whitebox testing וההבדל בין זה לבין static testing שפה אנחנו חוקרים את הקוד רק מלהסתכל עליו אנחנו לא כותבים קוד שיריץ את הקוד המקור לעומת זאת בטרקטורל טסטינג אנחנו כותבים קוד שיבדוק את הקוד של התוכנה whitebox testing מה זה בדיקות קופסה לבנה
coverage every מטרה של קופסה שחורה קופסה לבנה סליחה זה לבוא ולבדוק כל שורה כל שורת קוד שכתובה במערכת צריך לבדוק אותה כל פונקציה שכתובה במערכת צריך לכתוב פונקציה שתבדוק אותה כל מתודה מתודה אחרת או פונקציה שתבדוק את המתודה כך אנחנו בונים מעין פרויקט בדיקות שבודק את הקוד שהמתכנת בדרך כלל זה נעשה על ידי המתכנת המתכנת כל פעם שהוא עושה שינוי בקוד
הוא יריץ את סט הבדיקות הזה והוא יראה אם הוא לא פגע בשום דבר. זה לא בודק לוגיקה של מערכת, זה לא בודק דרישות של מערכת, זה בודק את הקוד של המערכת.
Usually done by the programmer and not the tester. בדרך כלל מי שעושה בדיקות קופסה לבנה זה מתכנתים. כל מתכנת בדרך כלל בודק את הקוד שלו וכותב תסריטי, כותב קוד שיבדוק את הקוד שהוא כתב.
Each programmer do his own whitebox testing unitest for his written code. כל מתכנת בודק את הקוד שלו וזה למעשה השם ויידבוקס טסטינג זה השם האחר ליוניטס, שיוניטס זה בדיקות יחידה שמבוצעות על ידי המתכנת.
Based on knowledge of the internal logic of the system. כל היוניטס, כל הבדיקות קופסה לבנה מבוססות על זה שהמתכנת יודע מה הוא כתב, איזה פונקציות הוא כתב, איך הן מתקשרות ביניהן, איזה פרמטרים הם צריכים לקבל.
יש פונקציות שלפעמים כותבים בתוכנה שהן לא קשורות ישירות לדרישת המערכת, הן ממשות חלק מדרישה, אבל הן לא קשורות לדרישה פיזית. 4 Types of White Box Technique יש 4 טכניקות לבדיקות של קופסה לבנה Statement Testing – בדיקה של משפטים Loop Testing – בדיקה של לולאות ולולאות מקוננות Path Testing – בדיקות של מסלולים
עץ מסלולים ו-Branch Testing – בדיקות של ענפים Unit Test – Testing Individual Atomic Units to ensure that they ולעבוד כמו שצריך לעבוד. Unitest, או קופסת בדיקה לבנה, זה למעשה להבטיח שכל יחידה קטנה, קרי שורה, לולאה, פונקציה,
קלאס, עובדים כמו שהם צריכים לעבוד. The Whitebox Unitesting is being covered in another course, Whitebox Testing Course.
יש קורס אחר שמתעסק בבדיקות של Whitebox Unitesting. זה קורס בפני עצמו, זה עולם בפני עצמו. הרבה מאוד מתכנתים לא כל כך יודעים לעשות unit testing שגם פה מגיע הערך המוסף של אנשי QA טובים שאם הם יודעים קוד ויודעים לעשות unit testing הם יכולים ללמד את המתכנתים ולהרצות להם וללמד אותם ולהסביר
להם ולעזור להם לעשות unit testing. אם מתכנתים יעשו unit testing בזמן שהם כותבים את הקוד זה יחסוך זמן, זה יחסוך כאב ראש לכולם כי הרבה מאוד באגים שוליים או לא שוליים הם יגלו מיד כי הם כותבים את הקוד והם כותבים לו מיד את ה-unit testing והם ישר מגלים את הבעיה ומתקנים לפני שזה
מגיע לצוות ה-QA ואז צוות ה-QA מחזיר את זה למתכנת והמתכנת עושה דיבאגינג ומוצא איפה הבעיה. זה עוד חלק מלעמוד בלוחות הזמנים, לחסוך זמן, לחסוך כסף.
אבל שוב, הרבה מתכנתים לא מכירים את כל המתודולוגיות ואת כל המתודות ואת כל השיטות של וייטבוקס. זה משהו שנוגעים בו מעט מאוד יחסית גם בלימודים גבוהים ולכן יש בדיקות טוב שידע את זה וישלוט בזה גם בצורה טובה.
יעשה את זה יוכל להסביר לארגון שלו להנהלה שלו למתכנתים שלו איך לעשות את זה בצורה טובה בלק בוקס טסטינג טוב אז בלק בוקס אנחנו פשוט יש לנו איזושהי קופסה שחורה מבחינתנו זו התוכנה אנחנו לא רואים את הקוד שלה לא מעניין אותנו הקוד שלה גם מעניין אותנו בגדול איך היא כתובה אבל לא לא אנחנו לא יורדים לרמת
השורה הבודדה ומה שמעניין אותנו זה שאנחנו מכניסים איזשהו input איזשהו קלט אנחנו מצפים לראות אאוטפוט מסוים ואז אנחנו בודקים שבאמת האאוטפוט שקיבלנו זה האאוטפוט הרצוי black box testing we don't know the process inside the code the box אוקיי אנחנו לא יודעים מה התהליכים שקורים בפנים אנחנו לא יודעים איזה פונקציה קורית לאיזה פונקציה זה גם לא כל כך מעניין אותנו וזאת הקופסה השחורה למעשה
אנחנו כן יודעים מה קורה מחוץ לקופסה זאת אומרת מה היא צריכה לקבל מה היא צריכה לתת we don't care what has happened inside the code and now it was reading by the programmer אז שוב לא מעניין אותנו מה המתכנת כתב בפנים, לא אכפת לנו עד כמה זה מסובך, לא אכפת לנו אם יש שם 100 פונקציות או 10 פונקציות,
לא אכפת לנו אם יש שם פונקציה שרצה על עץ בינארי או לא רצה על עץ בינארי, אנחנו לא בודקים את זה. כל הדברים האלה נבדקים ב-whitebox testing ובבדיקות סטטיות.
We want to test the system functionality as users. אותנו מעניין בבלקבוקס טפטינג לבוא ולהסתכל על התוכנה ולדעת אוקיי זה מה שהיוזר רצה אלה הדרישות זה מה שהתוכנה צריכה לעשות האם היא עושה את זה או לא עושה את זה.
אנחנו מסתכלים מהעיניים של המשתמש אבל של המשתמש החכם שגם יודע להסיק מסקנות ולהגיד מה עוד צריך לעשות או איזה דברים צריך לשפר או עד כמה זה קרוב לדרישות שהיוזר רצה. test cases based on requirements and functionality using the following documents: requirements documents, specification documents, design documents.
אוקיי, אז אנחנו בודקים, כותבים תסריטי בדיקות שמבוססות על דרישות המערכת, ואנחנו בודקים את הפונקציונליות של המערכת, זאת אומרת, האם הכפתורים עושים את מה שהם עושים, האם המערכת עושה את מה שהיא עושה, האם כשהיא מקבלת א' היא עושה ב', ג', ד'.
אנחנו מתבססים על מסמך הדרישות של הלקוח, על מסמך הספציפיקציות, על מסמך הדיזיין, האפיון של המערכת. כל אלה נותנים לנו את הכלים כדי לבוא ולכתוב טסט קייסס נכונים וטובים שבאמת בודקים את הכל.
בתוך הטסט קייסס וזמן הכתיבה אנחנו נשתמש במתודולוגיות, בכל מיני מתודולוגיות בדיקה, קולפרס, קבוצות שקילות וכדומה, כדי לצמצם ולהגיע למצב שיש לנו את מספר תסריטי הבדיקה המינימלי כדי לעמוד בלוחות הזמנים ולהבטיח מקסימום איכות.
Black Box Testing Types. אוקיי סוגים של בדיקות קופסה שחורה אינטגריישן אינטרפייס טסטינג בדיקות אינטגרציה או אינטרפייס We need to check if the linked components work with each other מה זה בדיקות אינטגרציה בדיקת אינטגרציה זה לבוא ולהגיד אוקיי המתכנתים
קבוצה א' של המתכנתים בנתה את מודול A קבוצה ב' בנתה את מודול B עכשיו צריך לחבר את שני המודולים ביחד ולראות שהם יודעים לדבר אחד עם השני שהם עובדים טוב כשהם מחוברים ביחד אז זה בדיקות אינטגרציה, זה הלב של בדיקות האינטגרציה.
Two components that have passed all their tests, when connected to each other, produce one new component, full of folds.
אוקיי, אז יש לנו שני קומפוננטות, כמובן שכל קבוצת מתכנתים עשתה unit test על כל קומפוננטה, ואולי אפילו הביאו לנו, לאנשי הבדיקות, לבדוק כל קומפוננטה בפני עצמה, והכל עובד יופי.
עכשיו מחברים אותם כדי שהם ידעו לדבר אחד עם השנייה, ופה זה הופך להיות קומפוננטה חדשה, היא מורכבת משתי קומפוננטות בדוקות, מה שלא נבדק זה הקשר בין שני הקומפוננטות.
עכשיו צריך לבוא ולבדוק את הקשר הזה ולכתוב לו בדיקות ולראות שהוא תקין. בדרך כלל הרבה פעמים יש נקודות שהן בגלל שזה שתי קומפוננטות שחיברו ביניהן, שהכרחו לחבר כל מיני דברים, שהכרחו להתייחס לכל מיני מקרי קצה, ופה התפקיד שלנו זה לבוא ולגלות את הבעיות האלה.
Interface Testing is focused on how the modules communicate with each other as specified in the System Design Document. אוקיי, אז כל הרעיון של אינטגרשן טסטינג או אינטרפס טסטינג זה לבוא ולהגיד איך המודולים, בוא נבדוק את התקשורת בין המודולים.
תראה שמודול א' באמת מעביר למודול ב' את המידע. בוא נראה שחיברנו שני מודולים שלא מדברים ביניהם ובאמת הם עובדים ולא פתאום מישהו יצר איזושהי תקשורת שגורמת לבאג.
כל הנתונים על המודולים ואיזה מודול מדבר עם איזה מודול אנחנו מוצאים בסיסטם דיזיין דוקימנט, במסמך האפיון של המערכת. אינטגרשן אינטרפס טסטינג המשך.
The system design defines relationships between components and this involves stating what a component can expect from another component in terms of services, how the services will be asked for, how they will be given, how to handle non-standard conditions, example errors.
אוקיי, במסמך האפיון אנחנו נראה, נלמד קודם כל איזה קומפוננטות יכולות לבקש