בחלק זה, אנו הולכים להבין את הסוגים השונים של בדיקות תוכנה, שניתן להשתמש בהן בזמן מחזור החיים של פיתוח התוכנה.
כידוע, בדיקות תוכנה הוא תהליך של ניתוח הפונקציונליות של האפליקציה בהתאם לדרישת הלקוח.
אם ברצוננו לוודא שהתוכנה שלנו נטולת באגים או יציבה, עלינו לבצע את סוגי בדיקות התוכנה השונים מכיוון שבדיקה היא השיטה היחידה שהופכת את האפליקציה שלנו ללא באגים.
הסוגים השונים של בדיקות תוכנה
הסיווג של בדיקות תוכנה הוא חלק מפעילויות בדיקה מגוונות, כגון אסטרטגיית בדיקה, תוצרי בדיקה, יעד בדיקה מוגדר וכו' . ובדיקת תוכנה היא ביצוע התוכנה כדי למצוא פגמים.
המטרה של קיום סוג בדיקה היא לאשר את AUT (יישום בבדיקה).
כדי להתחיל בבדיקה, צריך שיהיה לנו א משאבים דרושים, מוכנים ליישום, זמינים . כדי לשמור על אחריות, עלינו להקצות מודול מתאים למהנדסי בדיקה שונים.
בדיקות התוכנה התחלקו בעיקר לשני חלקים, שהם כדלקמן:
מהי בדיקה ידנית?
בדיקת כל תוכנה או אפליקציה על פי צרכי הלקוח ללא שימוש בכלי אוטומציה מכונה בדיקה ידנית .
במילים אחרות, אנחנו יכולים לומר שזה הליך של אימות ואימות . בדיקה ידנית משמשת לאימות התנהגות של אפליקציה או תוכנה בניגוד למפרט הדרישות.
איננו דורשים ידע מדויק בכל כלי בדיקה כדי לבצע את מקרי הבדיקה הידניים. אנו יכולים להכין בקלות את מסמך הבדיקה תוך ביצוע בדיקות ידניות בכל אפליקציה.
כדי לקבל מידע מפורט על בדיקות ידניות, לחץ על הקישור הבא: https://www.javatpoint.com/manual-testing.
סיווג בדיקות ידניות
בבדיקות תוכנה, ניתן לסווג עוד יותר בדיקות ידניות שלושה סוגים שונים של בדיקות , שהם כדלקמן:
להבנה טובה יותר, בואו נראה אותם אחד אחד:
בדיקת קופסה לבנה
בבדיקת קופסה לבנה, המפתח יבדוק כל שורת קוד לפני מסירתה לצוות הבדיקה או למהנדסי הבדיקה הנוגעים בדבר.
מחרוזת java ריקה
לאחר מכן, הקוד בולט למפתחים לאורך כל הבדיקות; זו הסיבה שהתהליך הזה מכונה WBT (בדיקת קופסה לבנה) .
במילים אחרות, אנו יכולים לומר כי מפתח יבצע את בדיקת הקופסה הלבנה המלאה עבור התוכנה המסוימת וישלח את האפליקציה הספציפית לצוות הבדיקה.
מטרת הטמעת בדיקת הקופסה הלבנה היא להדגיש את זרימת הקלט והפלטים על התוכנה ולשפר את האבטחה של אפליקציה.
בדיקת קופסה לבנה ידועה גם בשם בדיקת קופסא פתוחה, בדיקת קופסאות זכוכית, בדיקות מבניות, בדיקת קופסא שקופה ובדיקת קופסא שקופה .
כדי לקבל את הידע המעמיק על בדיקת קופסה לבנה, עיין בקישור הבא: https://www.javatpoint.com/white-box-testing.
בדיקת קופסה שחורה
סוג נוסף של בדיקה ידנית הוא בדיקת קופסה שחורה . בבדיקה זו, מהנדס הבדיקה ינתח את התוכנה מול דרישות, יזהה את הפגמים או הבאג, וישלח אותם בחזרה לצוות הפיתוח.
לאחר מכן, המפתחים יתקנו את הפגמים הללו, יבצעו סבב אחד של בדיקת White Box, וישלחו אותו לצוות הבדיקה.
כאן, תיקון הבאגים פירושו שהפגם נפתר, והתכונה המסוימת פועלת בהתאם לדרישה הנתונה.
המטרה העיקרית של יישום בדיקת הקופסה השחורה היא לציין את הצרכים העסקיים או את דרישות הלקוח.
במילים אחרות, אנו יכולים לומר שבדיקת קופסה שחורה היא תהליך של בדיקת הפונקציונליות של אפליקציה לפי דרישת הלקוח. קוד המקור אינו גלוי בבדיקה זו; לכן זה ידוע בשם בדיקת קופסה שחורה .
למידע נוסף על בדיקת קופסה שחורה, עיין בקישור הבא: https://www.javatpoint.com/black-box-testing.
סוגי בדיקות קופסה שחורה
בדיקת הקופסה השחורה מחולקת עוד יותר לשני חלקים, כפי שנדון להלן:
בדיקה פונקציונלית
מהנדס הבדיקה יבדוק את כל הרכיבים באופן שיטתי מול מפרטי הדרישה המכונה בדיקה תפקודית . בדיקה תפקודית ידועה גם בשם בדיקת רכיבים .
בבדיקה פונקציונלית, כל הרכיבים נבדקים על ידי מתן הערך, הגדרת הפלט ואימות הפלט בפועל עם הערך הצפוי.
בדיקה פונקציונלית היא חלק מבדיקת הקופסה השחורה שכן הדגשים שלה על דרישת היישום ולא על הקוד בפועל. מהנדס הבדיקה צריך לבדוק רק את התוכנית במקום את המערכת.
כדי לקבל את המידע המפורט על בדיקות פונקציונליות, עיין בקישור הבא: https://www.javatpoint.com/functional-testing .
סוגי בדיקות פונקציונליות
בדיוק כמו שסוג אחר של בדיקות מחולק לכמה חלקים, גם בדיקות פונקציונליות מסווגות לקטגוריות שונות.
המגוון סוגי בדיקות פונקציונליות מכילים את הדברים הבאים:
עכשיו, בואו נבין אותם אחד אחד:
1. בדיקת יחידות
בדיקת יחידות היא הרמה הראשונה של בדיקות פונקציונליות על מנת לבדוק כל תוכנה. בכך, מהנדס הבדיקה יבדוק את המודול של אפליקציה באופן עצמאי או יבדוק את כל פונקציונליות המודול שנקראת בדיקת יחידה .
המטרה העיקרית של ביצוע בדיקת היחידה היא לאשר את רכיבי היחידה עם הביצועים שלהם. כאן, יחידה מוגדרת כפונקציה יחידה הניתנת לבדיקה של תוכנה או אפליקציה. וזה מאומת לאורך שלב פיתוח האפליקציה שצוין.
לחץ על הקישור למטה כדי לקבל את המידע המלא על בדיקת יחידות: https://www.javatpoint.com/unit-testing.
2. בדיקת אינטגרציה
ברגע שנצליח ליישם את בדיקת היחידה, נעבור לבדיקות אינטגרציה. זוהי הרמה השנייה של בדיקה פונקציונלית, שבה אנו בודקים את זרימת הנתונים בין מודולים תלויים או ממשק בין שתי תכונות נקרא בדיקות אינטגרציה .
מטרת ביצוע בדיקת האינטגרציה היא לבדוק את דיוק ההצהרה בין כל מודול.
סוגי בדיקות אינטגרציה
גם בדיקות האינטגרציה מחולקות לחלקים הבאים:
בדיקת אינטגרציה מצטברת
בכל פעם שיש קשר ברור בין מודולים, אנחנו הולכים לבדיקות אינקרמנטליות. נניח שניקח שני מודולים וננתח את זרימת הנתונים ביניהם אם הם עובדים בסדר או לא.
אם המודולים האלה עובדים בסדר, נוכל להוסיף עוד מודול אחד ולבדוק שוב. ואנחנו יכולים להמשיך באותו תהליך כדי להשיג תוצאות טובות יותר.
במילים אחרות, אנו יכולים לומר שחיבור הדרגתי של המודולים ובדיקת זרימת הנתונים בין המודולים ידוע בשם בדיקות אינקרמנטליות .
סוגי בדיקות אינקרמנטליות
בדיקות שילוב מצטברות יכולות לסווג עוד יותר לשני חלקים, שהם כדלקמן:
בואו נראה הקדמה קצרה של סוגי בדיקות אינטגרציה אלה:
1. בדיקת שילוב מצטבר מלמעלה למטה
בגישה זו, נוסיף את המודולים צעד אחר צעד או בהדרגה ונבדוק את זרימת הנתונים ביניהם. עלינו להבטיח שהמודולים שאנו מוסיפים הם ילד של הקודמים .
2. בדיקת שילוב מצטבר מלמטה למעלה
בגישה מלמטה למעלה, נוסיף את המודולים בהדרגה ונבדוק את זרימת הנתונים בין המודולים. כמו כן, ודא שהמודול שאנו מוסיפים הוא הורה של הקודמים .
בדיקת שילוב לא מצטבר/שיטת המפץ הגדול
בכל פעם שזרימת הנתונים מורכבת וקשה מאוד לסווג הורה וילד, נלך על גישת האינטגרציה הלא אינקרמנטלית. השיטה הלא אינקרמנטלית ידועה גם בשם שיטת המפץ הגדול .
כדי לקבל את המידע המלא על בדיקות אינטגרציה וסוגן פנה לקישור הבא: https://www.javatpoint.com/integration-testing .
3. בדיקת מערכת
בכל פעם שסיימנו עם בדיקות היחידה והאינטגרציה, נוכל להמשיך בבדיקת המערכת.
בבדיקות מערכת, סביבת הבדיקה מקבילה לסביבת הייצור. זה ידוע גם בשם מקצה לקצה בדיקה.
בבדיקות מסוג זה נעבור כל תכונה של התוכנה ונבדוק אם תכונת הקצה עובדת בהתאם לדרישה העסקית. ולנתח את מוצר התוכנה כמערכת שלמה.
לחץ על הקישור למטה כדי לקבל את המידע המלא על בדיקות מערכת: https://www.javatpoint.com/system-testing.
בדיקה ללא תפקוד
החלק הבא של בדיקת הקופסה השחורה הוא בדיקה לא פונקציונלית . הוא מספק מידע מפורט על ביצועי מוצרי תוכנה וטכנולוגיות משומשות.
בדיקות לא פונקציונליות יעזרו לנו למזער את הסיכון של ייצור ועלויות נלוות של התוכנה.
בדיקה לא פונקציונלית היא שילוב של ביצועים, עומס, מתח, שימושיות ובדיקת תאימות .
למידע נוסף על בדיקות לא פונקציונליות, עיין בקישור הבא: https://www.javatpoint.com/non-functional-testing.
סוגי בדיקות לא פונקציונליות
בדיקות לא פונקציונליות מסווגות לחלקים שונים של בדיקה, עליהם נדון בהמשך:
1. בדיקת ביצועים
בבדיקות ביצועים, מהנדס הבדיקה יבדוק את פעולת האפליקציה על ידי הפעלת עומס מסוים.
בסוג זה של בדיקות לא פונקציונליות, מהנדס הבדיקה יתמקד רק במספר היבטים, כגון זמן תגובה, עומס, מדרגיות ויציבות של התוכנה או האפליקציה.
סיווג בדיקות ביצועים
בדיקת ביצועים כוללת את סוגי הבדיקות השונים, שהם כדלקמן:
בזמן ביצוע בדיקות הביצועים, נפעיל עומס מסוים על האפליקציה המסוימת כדי לבדוק את ביצועי האפליקציה, המכונה בדיקת עומס . כאן, העומס יכול להיות קטן או שווה לעומס הרצוי.
זה יעזור לנו לזהות את נפח הפעולה הגבוה ביותר של התוכנה וצווארי בקבוק.
כדי לקבל את המידע המלא הקשור לבדיקת העומס, עיין בקישור הבא:
https://www.javatpoint.com/load-testing.
הוא משמש לניתוח הידידותיות והחוסן של התוכנה מעבר למגבלות הפונקציונליות הנפוצות.
בעיקר, מבחני מאמץ משמשים עבור תוכנות קריטיות, אך ניתן להשתמש בהן גם עבור כל סוגי יישומי התוכנה.
מפנה לקישור הבא לידע מעמיק בבדיקות מאמץ: https://www.javatpoint.com/stress-testing.
לניתוח, ביצועי היישום על ידי שיפור או הפחתת העומס באיזונים מסוימים ידועים בשם בדיקת מדרגיות .
בבדיקת מדרגיות, אנו יכולים גם לבדוק את מערכת, תהליכים או יכולת מסד הנתונים כדי לענות על צורך כלפי מעלה. ובזה, ה מקרי מבחן מתוכננים ומיושמים ביעילות.
לחץ על הקישור הבא כדי לקבל את המידע המפורט הקשור לבדיקת המדרגיות:
https://www.javatpoint.com/scalability-testing.
בדיקת יציבות היא הליך שבו אנו מעריכים את ביצועי היישום על ידי הפעלת העומס למשך זמן מדויק.
הוא בודק בעיקר את בעיות הקביעות של האפליקציה ואת היעילות של מוצר שפותח. בבדיקה מסוג זה נוכל למצוא במהירות את הפגם של המערכת גם במצב מלחיץ.
כדי לקבל מידע מפורט על בדיקת היציבות עיין בקישור הבא:
https://www.javatpoint.com/stability-testing.
2. בדיקת שמישות
סוג אחר של בדיקה לא פונקציונלית הוא בדיקת שמישות . בבדיקת שמישות, ננתח את ידידותיות המשתמש של אפליקציה ונזהה את הבאגים בממשק משתמש הקצה של התוכנה.
הנה, המונח ידידותיות למשתמש מגדיר את ההיבטים הבאים של יישום:
- האפליקציה צריכה להיות קלה להבנה, מה שאומר שכל התכונות חייבות להיות גלויות למשתמשי הקצה.
- המראה והתחושה של האפליקציה צריכים להיות טובים, כלומר האפליקציה צריכה להיות נעימה למראה ולהרגיש למשתמש הקצה להשתמש בה.
למידע נוסף על בדיקות שמישות, נוכל לעיין בקישור הבא:
https://www.javatpoint.com/usability-testing.
3. בדיקת תאימות
בבדיקת תאימות, נבדוק את הפונקציונליות של אפליקציה בסביבות חומרה ותוכנה ספציפיות. ברגע שהיישום יציב מבחינה תפקודית אז רק, אנחנו הולכים על בדיקת תאימות .
כאן, תוֹכנָה פירושו שנוכל לבדוק את האפליקציה במערכות ההפעלה השונות ובדפדפנים אחרים, וכן חוּמרָה פירושו שנוכל לבדוק את היישום בגדלים שונים.
כדי לקבל ידע מעמיק בבדיקות תאימות עיין בקישור הבא:
https://www.javatpoint.com/compatibility-testing .
שנה את שם ספריית לינוקס
בדיקת תיבה אפורה
חלק נוסף של בדיקה ידנית הוא בדיקת קופסה אפורה . זה שיתוף פעולה של בדיקת קופסה שחורה ובדיקת קופסה לבנה .
מאז, בדיקת הקופסה האפורה כוללת גישה לקידוד פנימי לתכנון מקרי בדיקה. בדיקת תיבה אפורה מתבצעת על ידי אדם שיודע קידוד כמו גם בדיקה.
במילים אחרות, אנחנו יכולים לומר שאם צוות של אדם אחד עשה את שניהם בדיקת קופסה לבנה ובדיקת קופסה שחורה , זה נחשב בדיקת קופסה אפורה .
כדי לקבל מידע מפורט על בדיקת תיבה אפורה, נוכל להפנות לקישור הבא:
https://www.javatpoint.com/grey-box-testing.
בדיקת אוטומציה
החלק המשמעותי ביותר של בדיקות תוכנה הוא בדיקות אוטומציה. הוא משתמש בכלים ספציפיים כדי להפוך מקרי בדיקות עיצוב ידני לאוטומטיים ללא כל הפרעה אנושית.
בדיקות אוטומציה הן הדרך הטובה ביותר לשפר את היעילות, הפרודוקטיביות והכיסוי של בדיקות תוכנה.
הוא משמש להפעלה מחדש של תרחישי הבדיקה, אשר בוצעו באופן ידני, במהירות וחוזרות.
במילים אחרות, אנו יכולים לומר שבכל פעם שאנו בודקים יישום באמצעות כמה כלים ידוע בשם בדיקות אוטומציה .
נלך לבדיקות אוטומציה כאשר מהדורות שונות או מספר מחזורי רגרסיה עוברים על האפליקציה או התוכנה. איננו יכולים לכתוב את סקריפט הבדיקה או לבצע את בדיקות האוטומציה מבלי להבין את שפת התכנות.
למידע נוסף על בדיקות אוטומציה, נוכל לעיין בקישור הבא:
https://www.javatpoint.com/automation-testing.
כמה סוגים אחרים של בדיקות תוכנה
בבדיקות תוכנה, יש לנו גם כמה סוגים אחרים של בדיקות שאינם חלק מבדיקות כלשהן שנדונו לעיל, אך בדיקות אלו נדרשות בזמן בדיקת תוכנה או אפליקציה כלשהי.
בואו נבין את סוגי הבדיקות הללו אחד אחד:
ב בדיקת עשן , נבדוק את התכונות הבסיסיות והקריטיות של אפליקציה לפני שנעשה סבב אחד של בדיקה עמוקה וקפדנית.
אוֹ לפני בדיקת כל הערכים החיוביים והשליליים האפשריים מכונה בדיקת עשן . ניתוח זרימת העבודה של הליבה והפונקציות העיקריות של האפליקציה היא המטרה העיקרית של ביצוע בדיקת העשן.
למידע נוסף על בדיקות עשן, עיין בקישור הבא:
https://www.javatpoint.com/smoke-testing.
בדיקת שפיות
הוא משמש כדי להבטיח שכל הבאגים תוקנו ושלא נוצרו בעיות נוספות עקב שינויים אלה. בדיקת שפיות אינה מתואמת, מה שאומר שאיננו יכולים לתעד אותה. הוא בודק את נכונות התכונות והרכיבים החדשים שנוספו.
כדי לקבל מידע מפורט על בדיקות שפיות, נוכל להפנות לקישור הבא:
https://www.javatpoint.com/sanity-testing.
בדיקות רגרסיה
בדיקות רגרסיה הן הסוג הנפוץ ביותר של בדיקות תוכנה. הנה, המונח נְסִיגָה מרמז שעלינו לבדוק מחדש את אותם חלקים של אפליקציה שאינה מושפעת.
בדיקת רגרסיה היא הבדיקה המתאימה ביותר לכלי אוטומציה. לפי סוג הפרויקט ונגישות המשאבים, בדיקות רגרסיה יכולות להיות דומות ל בדיקה חוזרת .
בכל פעם שמתוקן באג על ידי המפתחים ולאחר מכן בדיקת התכונות האחרות של היישומים שעלולים להיות מדומים בגלל תיקון הבאגים, ידועה בשם בדיקות רגרסיה .
במילים אחרות, אנחנו יכולים לומר שבכל פעם שיש מהדורה חדשה לפרויקט כלשהו, אז אנחנו יכולים לבצע בדיקות רגרסיה, ובשל תכונה חדשה עשויה להשפיע על התכונות הישנות במהדורות הקודמות.
כדי לקבל ידע מעמיק הקשור לבדיקות רגרסיה, עיין בקישור הבא:
https://www.javatpoint.com/regression-testing .
בדיקות קבלת משתמש
בדיקת קבלת המשתמש (UAT) נעשית על ידי הצוות הבודד המכונה מומחה/לקוח בתחום או הלקוח. והכרת הבקשה לפני קבלת המוצר הסופי נקראת כ בדיקות קבלת משתמש .
בבדיקות קבלת משתמשים, אנו מנתחים את התרחישים העסקיים, ואת התרחישים בזמן אמת על הסביבה הייחודית הנקראת סביבת UAT . בבדיקה זו, נבדוק את האפליקציה לפני UAI לאישור הלקוח.
למידע נוסף על בדיקת קבלת המשתמש, לחץ על הקישור הבא:
https://www.javatpoint.com/acceptance-testing.
בדיקות חקרניות
בכל פעם שהדרישה חסרה, נדרשת איטרציה מוקדמת, ולצוות הבדיקות יש בודקים מנוסים כאשר יש לנו אפליקציה קריטית. מהנדס בדיקה חדש נכנס לצוות ואז אנחנו הולכים על בדיקות חקרניות .
כדי לבצע את הבדיקה החקרנית, נעבור תחילה על האפליקציה בכל הדרכים האפשריות, נכין מסמך בדיקה, נבין את זרימת האפליקציה ולאחר מכן נבדוק את האפליקציה.
לחץ על הקישור הבא כדי לקבל את המידע המלא על בדיקות חקרניות:
https://www.javatpoint.com/exploratory-testing.
בדיקות אדהוק
בדיקת האפליקציה באופן אקראי ברגע שה-build נמצא ברצף המסומן ידוע בשם בדיקות אד-הוק .
זה נקרא גם בדיקת קופים ובדיקת גורילות . בבדיקות Adhoc נבדוק את האפליקציה בניגוד לדרישות הלקוח; לכן זה ידוע גם בשם בדיקה שלילית .
משתני nginx
כאשר משתמש הקצה משתמש באפליקציה כלאחר יד, והוא/היא עלולים לזהות באג. ובכל זאת, מהנדס הבדיקה המתמחה משתמש בתוכנה באופן יסודי, כך שהוא/היא עלולים שלא לזהות זיהוי דומה.
מתייחס להלן כדי לקבל מידע מפורט על בדיקות Adhoc:
https://www.javatpoint.com/adhoc-testing.
בדיקות אבטחה
זהו חלק חיוני של בדיקות תוכנה, המשמש לקביעת החולשה, הסיכונים או האיומים ביישום התוכנה.
ביצוע בדיקות אבטחה יעזור לנו להימנע מהתקיפה הנבזית של גורמים חיצוניים ולהבטיח את אבטחת יישומי התוכנה שלנו.
במילים אחרות, אנו יכולים לומר שבדיקות אבטחה משמשות בעיקר כדי להגדיר שהנתונים יהיו בטוחים ויחזיקו מעמד בתהליך העבודה של התוכנה.
כדי לקבל את הפרטים המלאים על בדיקות אבטחה, עיין בקישור הבא: https://www.javatpoint.com/security-testing.
בדיקות גלובליזציה
סוג אחר של בדיקות תוכנה הוא בדיקות גלובליזציה. בדיקות גלובליזציה משמשות לבדיקת התוכנה שפותחה עבור מספר שפות או לא. הנה, המילים גלובליזציה פירושו להאיר את האפליקציה או התוכנה לשפות שונות.
בדיקות גלובליזציה משמשות כדי לוודא שהאפליקציה תתמוך במספר שפות ותכונות מרובות.
בתרחישים הנוכחיים, אנו יכולים לראות את השיפור במספר טכנולוגיות כאשר היישומים מוכנים לשימוש גלובלי.
עיין בקישור הבא כדי לקבל את המידע המלא הקשור לבדיקות הגלובליזציה:
https://www.javatpoint.com/globalization-testing.
סיכום
במדריך, דנו בסוגים שונים של בדיקות תוכנה. אבל עדיין יש רשימה של יותר מ-100+ קטגוריות של בדיקות. עם זאת, כל סוג של בדיקה אינו בשימוש בכל סוגי הפרויקטים.
דנו בסוגים הנפוצים ביותר של בדיקות תוכנה כמו בדיקת קופסה שחורה, בדיקת קופסה לבנה, בדיקות פונקציונליות, בדיקות לא תפקודיות, בדיקות רגרסיה, בדיקות Adhoc וכו' .
כמו כן, ישנם סיווגים או תהליכים חלופיים המשמשים בארגונים מגוונים, אך הרעיון הכללי דומה בכל מקום.
סוגי הבדיקות, התהליכים וגישות הביצוע הללו ממשיכים להשתנות כאשר הפרויקט, הדרישות וההיקף משתנים.