אילו סוגי בדיקות תוכנה יש לקחת בחשבון

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

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

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

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

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

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

בדיקת מערכת – זה מבוסס על מפרט הדרישות הכולל; מכסה את כל החלקים המשולבים של המערכת.

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

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

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

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

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

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

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

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

בדיקת תאימות – בדיקה עד כמה התוכנה מתפקדת בחומרה/תוכנה/מערכת הפעלה/רשת/וכו' מסויים. סביבה.

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

בדיקת השוואה – השוואת חולשות ויתרונות תוכנה למוצרים מתחרים אחרים.

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

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

בדיקת מוטציות – שיטה לקביעת קבוצה של נתוני בדיקה או מקרי בדיקה שימושית או לא, על ידי הכנסת שינויי קוד שונים ('באגים') בכוונה ובדיקה חוזרת עם נתוני/מקרי הבדיקה המקוריים כדי לקבוע אם ה'באגים' מזוהים.



Source by Jerry Ruban

You may also like...

כתיבת תגובה

האימייל לא יוצג באתר.