שיטות של בדיקות תוכנה ולהשוות אותם. שיטת בדיקה של בדיקות "קופסה שחורה" ושיטת "קופסה לבנה"

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

שיטות

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

שיטות אימות תוכניות (בדיקות) ניתן לחלק סטטי ודינמי.

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

טכניקות דינמיות הן:

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

בדיקות שקופות

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

בדיקת תוכניות על ידי קופסא לבנה יש את היתרונות הבאים:

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

חסרונות:

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

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

הזנים העיקריים:

1) בדיקת בקרת הזרימה - אסטרטגיה מבנית באמצעות מודל תזרים תוכנת שליטה וכתוצאת העדפת דרכים פשוטות יותר ופחות מורכבים יותר;

2) הסניף נועד ללמוד באגים כל אופציה (אמת או שקר) של כל מפעיל מלא, הכולל גם פתרון משולב;

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

4) בדיקת זרם הנתונים - אסטרטגית בקרת זרימה של מחקר על ידי ההסברים לספור מידע על המודעה ולהשתמש במשתני התכנית;

5) מחזורים של בדיקות - התמקד באופן מלא על הניתוח הנכון של תהליכים מחזוריים.

ניפוי התנהגותי

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

יתרונותיה של גישה זו:

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

שיטת בדיקת תוכנת קופסא שחורה יש את החסרונות הבאים:

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

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

קטגוריה זו יכולה לכלול טכניקות בדיקת התוכנות הבאות:

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

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

3) fuzzing - המשמש ליישם את החיפוש על ידי הזנת שגיאות או poluiskazhennyh נתונים פגום במצב אוטומטי או אוטומטי למחצה;

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

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

6) בדיקת כל זוגות - טכניקה שבה מערכת של ערכים במבחן כוללת את כל השילובים האפשריים בינארי של כל זוג פרמטרים קלט;

7) מעבר למצב איתור באגים - טכניקה יעילה לבדיקת מעמדם של המכונה, כמו גם כדי לנווט GUI המשתמשים.

בדיקות קופסה שחורה: דוגמאות

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

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

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

כמה בדיקות צריך לעשות כדי לבדוק את כל הערכים האפשריים עבור הדגל 4 חלונות שדה חד פעמי, להגדיר את הזמן בשניות? בשלב חישוב מהמבט הראשון הוא פשוט: 4 שדות עם שני מצבים אפשריים - 24 = 16, אשר חייב להיות מוכפל במספר עמדות האפשר 00 עד 99, דהיינו 1600 בדיקות אפשריות.

עם זאת, החישוב הזה הוא טועה: אנחנו יכולים לקבוע כי השדה שתי נקודות יכול להכיל גם מרחב, כלומר זה מורכב משני תפקידים אלפאנומרי ויכול להכיל תווים אלפאנומריים, תווים מיוחדים, מקומות, וכו 'לכן, אם .... המערכת הוא מחשב 16 סיביות, לפנות 216 = 65,536 אחד עבור כל מיקום של מקרי מבחן 4294967296 כתוצאה כי יש מוכפל 16 שילובים של דגלי שנותן סך של 68,719,476 736. אם הם מבצעים ב 1 מבחן לשנייה, את המשך הכולל בדיקות olzhitelnost הן 2 177.5 שנים. במשך 32 או 64 סיביות מערכות, משך עוד יותר.

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

מחיצות שקילות

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

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

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

לדוגמא, ב (1 / x) ^1/2 באמצעות שלושה רצפי נתונים, שלוש מחיצה שווה:

1. כל התייחסות חיובית יטופלו באותו אופן וצריך לתת תוצאות נכונות.

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

3. אפס יטופלו בנפרד ולתת את "חלוקה באפס" שגיאה. זהו קטע עם ערך יחיד.

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

ערך ניתוח גבול

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

• שימוש לא נכון של מפעילים יחסיים (<,>, =, ≠, ≥, ≤);
• שגיאה אחת;
• בעיות מחזורים ו איטרציות,
• סוגים טועים או גודל של משתנים ששמשו לאחסון מידע;
• מגבלות מלאכותיות הקשורים סוגי נתונים ומשתנים.

בדיקות שקופות

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

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

• מודל אדריכלי;
• Unified Modeling Language (UML);
• מודל מדינה (אוטומט סופי).

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

יש שיטות בדיקה אלה את היתרונות הבאים:

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

חסרונות:

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

שם נוסף עבור טכניקות התיבה האפורות - באגים שקופים.

קטגוריה זו כוללת שיטות כאלה של בדיקות:

1) מערך מאונך - השימוש משנה של כל השילובים האפשריים;

2) ניפוי מטריקס באמצעות המדינה של נתוני התוכנית;

3) בדיקה רגרסיבית שנערכה השינויים החדשים בתוכנה;

4) מבחן תבנית שמנתחת את העיצוב והאדריכלות של יישום טוב.

השוואת טכניקות בדיקות תוכנה

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

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

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

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

אוטומציה

שיטות אוטומטיות של בדיקות תוכנה היא הרבה לפשט את התהליך של בדיקה, ללא תלות בסביבה הטכנית ואת ההקשר של. הם משמשים בשני מקרים:

1) כדי להפוך את המשימות משעממות, חוזרות על עצמו או מוקפדות כמו השוואת קובץ כמה אלף שורות כדי לשחרר זמן הריכוז של בודק נקודות חשובות יותר;

2) לביצוע מעקב או משימות שלא ניתן לבצע בקלות על ידי אנשים כמו אימות ביצועים או זמן תגובת ניתוח שיכול להימדד מאיות שנייה.

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

• ניהול בדיקה, הכולל תמיכה וניהול פרויקט, הגירסות, תצורות, ניתוח סיכונים, מעקב בדיקה, שגיאות, ליקויים, וכלי דיווח;
• דרישות הנהלה, הכוללת דרישות אחסון ומפרטים, לבדוק אותם על שלמות עמימות, העדיפות שלהם ואת יכולת המעקב של כל בדיקה;
• סקירה ביקורתית וניתוח סטטי, כוללים ניטור זרימה, ומשימות, הקלטה ואחסון של תגובות, זיהוי פגם וקישורים וניהול תיקונים מתוכננים רשימות וכללים, מעקב מסמכי מקור תקשורת וניתוח קוד סטטי כדי לזהות פגמים, כדי להבטיח עמידה בסטנדרטים של כתיבת קוד, ניתוח של מבנים ויחסי תלות, חישוב פרמטרים מטרי של קוד ואדריכלות. בנוסף, להשתמש מהדרים, מנתחים, גנרטורים ויחסים של הפניות מקושרות;
• דוגמנות, הכוללת כלים להתנהגות עסקית דוגמנות ולבדוק מודלים;
• פיתוח בדיקה מבטיח ההדור של הנתונים צפויים על בסיס תנאים ומודלי ממשק המשתמש וקוד, מצליח ליצור או לשנות קבצים ובסיסי נתונים, הודעות, אימות נתונים על בסיס הכללים של ניהול, ניתוח סטטיסטי של התנאים והסיכונים;
• מבט ביקורתי על ידי הזנת הנתונים דרך קו ממשק, API משתמש גרפי, הפקודה באמצעות משווים כדי לסייע בזיהוי בדיקות מוצלחות ולא מוצלחות;
• סביבת באגים תמיכה המאפשר לך להחליף את החומרה או התוכנה חסר, ב Vol. h. ציוד סימולציה המבוססת על תת פלט נחוש, אמולטורים הטרמינל, טלפונים ניידים וציוד רשת, הסביבה לשפות בדיקת, מערכות הפעלה חומרה ידי החלפת הנהג רכיבים חסרים, פיקטיבי מודולים, וכו ', כמו גם כלים ללכידת ושינוי OS מבקשים הגבלת סימולצית CPU, RAM, ROM, או רשת .;
• .. השוואת קבצי נתונים, מסדי נתונים, לבדוק את התוצאות הצפויות במהלך ואחרי השלמת הבדיקה, כולל דינמית והשוואה יצווה, אוטומטי "אורקל";
• ציפוי מדידה עבור הלוקליזציה של דליפות זיכרון ומערכת הערכת התנהגות שליטתו שגויה תחת יישומי עומס יצירת עומס מדומים, מסדי נתונים, רשתות או שרתים בתרחיש של צמיחה ריאלי עבור דו"ח משאבים מדיד, ניתוח ואימות של מערכת;
• אבטחה;
• בדיקות ביצועים, עומסים וניתוח דינמי;
• כלים אחרים, ב Vol. h. כדי לבדוק את האיות ותחביר, אבטחת רשת, את הזמינות של כל דפי האתר ואחרים.

פרספקטיבה

עם שינוי המגמות בתעשיית התוכנה, התהליך של ניפוי כפוף גם לשנות. ישנן שיטות חדשות של בדיקות תוכנה, כגון ארכיטקטורת השירות-orientirovannae (SOA), טכנולוגיות אלחוטיות, שירותים ניידים, וכן הלאה. E., נפתח דרכים חדשות של תוכנות בדיקה. חלק מהשינויים הצפויים בענף בשנים הקרובות מפורטים להלן:

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

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