שלב הבדיקה במחזור חיי התוכנה

admin

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

מודל פיתוח

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

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

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

פרמטרים אחרים של הבדיקה

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

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

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

סוג הבדיקה

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

יישום

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

Leave a Reply