תוכניות בדיקה - תהליך איתור שגיאות במוצר התוכנה

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

מה נקרא מבחן?

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

אפקטיבי

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

גישה לעבודה

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

מהו המבחן?

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

אמנויות פתרון בעיות

תוכניות קרובות שואפות לעבוד עם ערכות נתונים ענקיות. האם יש צורך ליצור לחלוטין? מס נרחבת רכש את הנוהג של "מיזעור" של התכנית. במקרה זה יש ירידה סבירה של נפח נתונים בהשוואה לזמן כדי לשמש. בואו נסתכל על דוגמא: יש תכנית, אשר יוצרת מטריצה של 50x50 גודל. במילים אחרות - אתה חייב להזין באופן ידני את ערכי 2500. זה בהחלט אפשרי, אבל זה ייקח הרבה מאוד זמן. אבל כדי לבדוק את הפונקציונליות, התוכנה מקבלת מטריצה שהממדים שלהם 5x5. כדי לעשות זאת, אתה צריך להיכנס יותר 25 ערכים. אם, במקרה זה, פעולה רגילה, ללא שגיאה, זה אומר שמכיל בסדר. למרות שיש ממלכודות נעוצות בעובדה כי עם מצב מזעור מתרחש, וכתוצאה מכך שינוי מובלעת ונעלמים באופן זמני. זה גם מאוד נדיר, אבל עדיין קורה הוא כי ישנם באגים חדשים.

מטרות רדפו

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

בדקו בתנאים שונים

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

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

בדיקה: סוגים

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

השלמת הבדיקה

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

בדיקות בעזרת מחשב

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

מפולת

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

קליי

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