שליטה ידנית של חלל הרחם. שליטה ידנית בתוכנה למה תמיד יש שליטה ידנית ב-bsk

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

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

ו תְפוּקָה. בְּדינמי - לבצע בדיקה ידנית.,כלומר, הם מדמים באופן ידני את תהליך ביצוע התוכנית על נתונים ראשוניים נתונים.

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

ו וכו', ולשלבים מאוחרים יותר - אלגוריתמים וטקסטים של תוכניות, וכן ערכות מבחן.

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

השיטות העיקריות לשליטה ידנית הן:

בדיקות טקסט מקור,

דרך השקפות,

בדיקת שולחן,

הערכות תוכנית.

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

חברי הקבוצה מקבלים מראש פירוט של התוכנית ומפרט עבורה;

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

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

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

אני. בקרת גישה לנתונים

האם כל המשתנים מאותחלים?

האם חרג מהגדלים המקסימליים (או האמיתיים) של מערכים ומיתרים?

האם שורות ועמודות מתערבבות במהלך העבודהעם מטריצות?

האם יש משתנים עם שמות דומים?

האם נעשה שימוש בקבצים? אם כן, האם השלמת הקובץ נבדקת בעת קלט מקובץ?

האם סוגי הערכים הנכתבים והקריאה תואמים?

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

2. בקרת חישוב

האם הביטויים כתובים נכון (סדר האופרטורים)?

האם חישובים מבוצעים נכון על משתנים שאינם אריתמטיים?

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

האם אפשר להעלות על גדותיו את רשת הסיביות או את המצב של מכונה אפס?

האם החישובים עומדים בדרישות הדיוק שצוינו?

האם יש השוואות בין משתנים מסוגים שונים?

3. העברת בקרת

האם הלולאות יסתיימו כהלכה?

האם התוכנית תושלם?

האם יש לולאות שלא יפעלובגלל הפרת תנאי הכניסה? האם החישובים יימשכו כהלכה?

האם יש מחזורי חיפוש? האם מצבי "האלמנט נמצא" מטופלים בצורה נכונה?

ו "אלמנט לא נמצא"?

4. שליטה בממשקים בין-מודולים

האם רשימות הפרמטרים והארגומנטים תואמות בסדר, סוג, יחידות?

האם תת-השגרה משנה טיעונים שלא אמורים להשתנות?

האם יש הפרת היקף של משתנים גלובליים ומקומיים בעלי אותו שם?

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

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

חברי הקבוצה מקבלים מראש פירוט של התוכנית ומפרט עבורה;

למשתתפי המפגש מוצעים מספר מבחנים;

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

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

בְּ רוב ההליכים מוצאים פחות באגים בעת הפעלת המבחנים עצמם מאשר בעת ראיון עם מתכנת.

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

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

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

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

9.3. בדיקות מבניות

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

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

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

לגישה המבנית לבדיקה יש מספר חסרונות. אז חבילות הבדיקה שנבנו לפי האסטרטגיה הזו:

אל תזהה מסלולים שהוחמצו;

אל תזהה שגיאות בהתאם לנתונים המעובדים, לדוגמה, במשפט if (a - b).< eps - пропуск функции абсолютного значения abs проявится только, если а < Ь;

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

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

הליך m(a, b: rea1; var x: real); התחל

אם (a1) ו-(b=0) אז x: =x/a; אם (a=2) או (x>1) אז x: =x+1;

היווצרות ערכות בדיקה למסלולי בדיקה יכולה להתבצע על פי מספר קריטריונים:

כיסוי מפעיל;

סיקור החלטות (מעברים);

תנאי כיסוי;

סיקור החלטות/תנאים;

סיקור קומבינטורי של תנאים.

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

עבור הפרגמנט שהאלגוריתם והגרף שלו מוצגים באיור. 9-2, ניתן יהיה לבצע כל משפט פעם אחת, נתון כנתוני קלט a = 2, b = 0, x = 3. אבל התנאי השני מרמז שהמשתנה x יכול לקבל כל ערך, ובגרסאות מסוימות של שפת פסקל ערך זה לא ייבדק (!).

חוץ מזה:

אם בעת כתיבת תוכנית במצב הראשון היא צוינה: (a > 1) או (b = 0), אז השגיאה לא תתגלה;

אם נכתב x > 0 במקום x > 1 במצב השני, גם שגיאה זו לא תתגלה;

ישנו נתיב 1-2-4-6 (ראה איור 9.2ב) בו x אינו משתנה כלל ואם יש שגיאה, היא לא תתגלה.

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

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

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

התוכנית שהאלגוריתם שלה מוצג באיור. 9.2, א, ניתן לבדוק בשיטת כיסוי הפתרון עם שתי בדיקות המכסות את כל הנתיבים: 1-2-4-6, 1-2-3-4-5-6, או נתיבים: 1-2-3-4- 6, 1-2-4-5-6, לדוגמה:

a \u003d 3, b \u003d 0, x \u003d 3 - נתיב 1-2-3-4-5-6;

a \u003d 2, b \u003d 1, x \u003d I - נתיב 1-2-4-6.

עם זאת, הנתיב שבו x לא משתנה ייבדק בהסתברות של 50%: אם בתנאי השני, במקום התנאי x > 1, נכתב x< 1, то этими двумя тестами ошибка обнаружена не будет.

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

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

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

בדיקות העונות על תנאי זה:

א = 2, b = 0, x = 4 - נתיב 1-2-3-4-5-6, תנאים: 1 - כן, 2 - כן, 3 - כן, 4 - כן;

a \u003d 1, b \u003d 1, x \u003d 1 - נתיב 1-2-4-6, תנאים: 1 - לא, 2 - לא, 3 - לא, 4 - לא.

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

a = 1, b = 0, x = 3 - נתיב 1-2-3-6, תנאים: 1 - לא, 2 - כן, 3 - לא, 4 - כן;

a \u003d 2, b \u003d 1, x \u003d 1 - נתיב 1-2-3-4-5-6, תנאים: 1 - כן, 2 - לא, 3 - כן, 4 - לא

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

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

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