PROFILPELAJAR.COM

הנדסת תוכנה
ערך זה שייך לקטגוריית הנדסת תוכנה
פעילויות ושלבים
דרישות • ניתוח • אפיון • ארכיטקטורה • עיצוב • תכנות • ניפוי שגיאות • בדיקה • אימות • בנייה • פריסה • תפעול • תחזוקה
מתודולוגיות
זריזות • מפל המים • תכנת ותקן • Crystal Clear • Scrum • Unified Process • Extreme Programming • אינטגרציה רציפה • DevOps
תחומים תומכים
ניהול פרויקטים • ניהול תצורה • תיעוד • הבטחת איכות • Profiling
כלים
מהדר • מקשר • מפרש • IDE • ניהול גרסאות • אוטומציית בנייה

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

הקדמה

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

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

בדיקות תוכנה ותהליכי הבטחת איכות תוכנה באים לידי ביטוי באופנים שונים במתודולוגיות פיתוח שונות. בחלק ממתודולוגיות פיתוח התוכנה, מקומן של הבדיקות הוא בסוף תהליך הפיתוח (לדוגמה מודל מפל המים). באחרות, משימות הבטחת איכות משולבות לאורך מחזור הפיתוח השלם של היישום. דוגמה לכך הוא מודל ה-V שבו לכל שלב במהלך פיתוח התוכנה קיים שלב מקביל של בדיקות (איסוף הדרישות נבדק על ידי בדיקות קבלה, עיצוב מקביל לבדיקות מערכת, עיצוב מפורט מקביל לבדיקות השילוב וכו'). יש מתודולוגיות נוספות, חדישות יותר, בהן הבדיקות משולבות בתהליך הפיתוח (למשל פיתוח מונחה בדיקות, מתודולוגיית Scrum וכדומה).

סוגי הבדיקות

בהתאם למודלים של פיתוח תוכנה כגון: מפל המים, מודל V, מודל W ואחרים; קיימים 4 שלבים מרכזיים בבדיקות תוכנה:

בדיקות יחידה (Unit) – בדיקות ברמת יחידת תוכנה (מודול). לרוב מבוצעות על ידי מפתח התוכנה.^[1]
בדיקות אינטגרציה (Integration) – בדיקת שילוב יחידות תוכנה בהיקפים שונים, החל משתי יחידות ועד לכלל היחידות במערכת.
בדיקות מערכת (System) – בדיקת המערכת בכללותה, בדרך כלל בראיית המשתמש של יכולות המערכת.
בדיקות קבלה (Acceptance) – בדיקות הנעשות על ידי המשתמש או הלקוח במטרה לוודא כי המערכת פועלת בהתאם לדרישות שהוגדרו במסמך הדרישות המקורי ובשינויי דרישה (change request) שהועברו במהלך מחזור חיי הפיתוח.

בנוסף מקובל לסווג את הבדיקות גם לפי החלוקה שמתבססת על אופי הבנת המערכת ורמת הירידה של הבודק לפרטים:

בדיקות קופסה לבנה (White Box) – בדיקות אלו מתבססות על הכרת קוד המקור של התוכנה ובניית תוכניות בדיקה המותאמות לנתיבי הזרימה האפשריים של הקוד. בדיקות יחידה עשויות להיות בדיקות מסוג קופסה לבנה. בסוג בדיקות זה, על הבודק להכיר את הלוגיקה של הקוד, וכן, עליו להיות בעל ידע בשפת התכנות בה כתובה התוכנה.
בדיקות קופסה שחורה (Black Box) – בדיקות אלו אינן מכירות את המבנה הפנימי של המערכת ומתבססות על בדיקת הפלט הצפוי לקלט מסוים בהתאם לתכנון מוקדם כלשהו. בדיקות קבלה מתבצעות בשיטה זו בדרך כלל. בסוג בדיקות זה, הבודק חייב לדעת את פירוט דרישות המערכת, וכן, עליו לדעת לאיזה פלט מהתוכנה עליו לצפות עבור קלט מסוים. עם זאת, הבודק אינו חייב להכיר את הלוגיקה של הבעיה או אפילו לדעת את שפת התכנות בה היא כתובה.
בדיקות קופסה אפורה (Gray Box) – בדיקות אלו מכירות במבנה הפנימי של המערכת אך משתמשות בידע זה על מנת לבצע בדיקות בסגנון קופסה שחורה. כך לדוגמה שינוי של מאגרי הנתונים לבדיקת פלט מסוים או שימוש בהנדסה הפוכה על מנת לאתר את גבולות הפעולה של המערכת, אלו הן דוגמאות נפוצות לבדיקות בשיטה זו.

סוגי בדיקות עיקריים

בדיקות פונקציונליות (Functional) – לאימות פעילות המערכת. בדיקות אלו מבוססות על מסמך הדרישות ומסמך האפיון ומטרתן לבדוק כי המערכת עושה את מה שהיא צריכה ולא עושה את מה שאינה צריכה לעשות (valid and invalid testing).
בדיקות לא פונקציונליות (Non functional) – בדיקות אלו בודקות איך פועלת המערכת וכוללות בדיקות עומסים, ביצועים, שימושיות וסוגי בדיקות רבים נוספים (שחלקם מפורטים למטה).
בדיקות שימושיות (Usability) – בדיקות נוחות השימוש ויעילות העיצוב של האפליקציה ונגישות לבעלי מוגבלויות. לדוגמה: נוחות השימוש בתפריטים, ניווט נוח והתמצאות באתר.
בדיקות בינלאומיות (Internationalization and Localization) – בדיקות המתמקדות בשימוש בתוכנה בממשקים בשפות שונות. למשל – אתרי אינטרנט רבים (כמו ויקיפדיה) בהם יש דפים בשפות שונות, מבצעים בדיקות מהסוג הזה.
בדיקות ממשק לקוח (GUI) – בדיקות הפקדים והשדות במסך. התנהגות תקינה, פורמט של שדות, בהתאם לחוקיות המוגדרת ברמת המסך ולא הלוגיקה העסקית. לדוגמה: בדיקת מינימום ומקסימום תווים בשדה.
בדיקות שילוב מערכת (Compatibility) – לאימות יכולת שילוב התוכנה/רכיב תוכנה במערכת קיימת/חדשה (למשל – תאימות של התוכנה לעדכוני מערכת הפעלה, דפדפנים שונים, תוכנות אחרות שהתוכנה אמורה לעבוד בשילוב עימן, וכדומה).
בדיקות אלפא/בתא (Alpha/Beta) – בדיקות שמבוצעות על ידי קבוצת משתמשים מוגדרת סגורה (אלפא) או פתוחה (בתא) אשר משתמשים במוצר ומדווחים על תקלות הצפות תוך כדי שימוש שוטף.
בדיקות שפיות (Sanity) – בדיקות בסיסיות המאפשרות לזהות במהירות וביעילות אם הפונקציונליות הבסיסית של המוצר פועלת כנדרש, והמוצר במצב יציב.
בדיקות עשן (Smoke) – סוג נוסף של בדיקות הנועד לזהות במהירות את מצב היציבות של המוצר, על ידי גילוי מוקדם של תקלות המראות על כשל חמור ברכיב כלשהו במוצר. בניגוד לבדיקות שפיות, בדיקות עשן בדרך כלל מבוצעות בצורה יותר אינטואיטיבית וגמישה, ולא בהכרח לפי תסריטים קבועים מראש.
בדיקות הרס (Destructive) – בדיקות אלו נעשות במטרה להכשיל ולהרוס חלקים שונים של המערכת הנבדקת ובכך לבדוק את יכולת השרידות שלה, בדיקות אלו נעשות בשלב מאוחר של התהליך כאשר המערכת נמצאת במצב עמיד ויציב. בשוק קיימים מספר כלים המאפשרים לדמות בדיקות הרס. לדוגמה: Winner.
קיימים סוגי בדיקות נוספים המותאמים למאפייני הנדסת תוכנה נוספים (ilities).
בדיקת תאימות (Compatibility) – בדיקות הבודקות שהתוכנה יכולה להתאים את עצמה למערכות הפעלה שונות כמו Windows XP/7/8/10 או אם האתר תומך בדפדפנים שונים כמו Chrome/Firefox/Explorer.
בדיקת תחזוקתיות ׁ(Maintainability) – בדיקה שבודקת שאפשר לעדכן או לתקן את התוכנה אחרי הוצאתה לאור, בדיקה זו בודקת גם אם הקוד כתוב בצורה פשוטה.
בדיקת ביצועים ועומסים (Performance and Load) – בסוג בדיקות זה נבדקת יכולת התגובה של צד השרת במערכות שרת/לקוח בהן צפויים משתמשים רבים בו זמנית. בדיקות אלו מתמקדות במדידת זמני התגובה ובמציאת "נקודת השבירה" של המערכת. מלבד עומס הנובע מ"משתמשים וירטואליים" מדומים גם עומסים הנובעים מטרנזקציות וג'ובים המורצים ברקע, שלא כתוצאה ישירה מתהליכים עסקיים. בשוק קיימים מספר כלים המאפשרים לדמות משתמשים רבים, לדוגמה: LoadRunner, WebLoad, TeamSystem. בבדיקת ביצועים יש שלושה סוגי בדיקות: LOAD, STRESS ו-VOLUME. ב-LOAD בודקים אם המערכת עובדת עם מספר משתמשים רגיל ותחת זרימת נתונים נורמטיבית (לא חריגה), ב-STRESS בודקים אם המערכת עובדת עם מספר משתמשים הגבוה בהרבה מהרגיל וכמו כן שימוש במידע רב, תוך גרימת זעזועים (לדוגמה: ניתוק וחיבור משתמשים, שימוש וביטול פונקציונליות במערכת), זאת במטרה לאבחן מהן נקודות הקצה של המערכת. האחרונה, VOLUME, היא בדיקה שבודקת את התנהגות וגבולות המערכת תחת הצפת המערכת בנתונים וכמו בבדיקה הקודמת – בודקת את קצוות המערכת בשימוש בכמויות אדירות של מידע.
בדיקת מבניות (Structural)
פרק זה לוקה בחסר. אנא תרמו לוויקיפדיה והשלימו אותו. ייתכן שתמצאו פירוט בדף השיחה.
.
בדיקות הקשורות לשינויים/רגרסיה – בבדיקה זו יש שני סוגי בדיקותː
- בדיקות אי פגיעה Regression .Regression & Re-Testing – רגרסיה, בדיקה חוזרת על מקומות שכבר נבדקו בהצלחה (גם איפה שאף פעם לא הייתה תקלה) . בדיקה זו מבצעים אחרי הטמעה של פיצ'ר חדש במערכת (בדרך כלל בגרסה חדשה), כדי לבדוק שהשינויים שביצעו בקוד לא קלקלו מה שהיה תקין בעבר.
- Re-Testing – בדיקה חוזרת (נקראת גםː בדיקות אישור או וידוא). בדיקה חוזרת על מקום ספציפי לשם וידוא תיקון תקלה.

אופי הבדיקות

בדיקות תוכנה ידניות (Manual Testing) – בדיקות תוכנה הנעשות על ידי עובד שהוכשר לכך בדרך כלל על פי תוכנית בדיקות מסודרת ומוסכמת.
בדיקות תוכנה ממוכנות (Automation Testing) – בדיקות תוכנה הנעשות בצורה אוטומטית, רצוי עם מינימום התערבות אנושית.