מילון

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

ATP

תוכנית בדיקות נקראת בשפה המקצועית ATP
Acceptance   Test   Plan  
ATP מורכב מתרחישים רבים (Scenarios).
התרחישים השונים צריכים לכסות על כל המקרים המופיעים בדרישות (Specifications), ובדגש מיוחד על מקרי הקצה.

 

 

Black box

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

 

 

Bug

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

המושג באג (חרק) מגיע מגיע מעולם המחשבים של פעם. חרק שחדר לתוך מחשב ענק גרם לבעיות רבות.

הבאג הראשון
דוגמאות לבאגים...

 

 

Bug Verificationes

כאשר מתקבלת גרסה חדשה יש להתחיל קודם כל בוידוא שהבאגים הקודמים תוקנו (ע"פ מה שכתוב במסמך המלווה את הגרסה - VDD)

 

 

Build

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

 

 

Change request

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

בשום אופן אין להכניס שינויים בתוכנה על סמך שיחות טלפון וכד'.

 

 

Debug

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

אחד הכלים הנוחים לעבודה עם פלט של דיבאג הוא Procomm עליו אפשר לקרוא בפרק כלים

 

 

Full QC

ביצוע כל הבדיקות הנכללות ב ATP על גירסה מסויימת

 

 

Functional spec

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

 

 

MTBF

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

 

 

Platform

סביבת חומרה ותוכנה במחשב מסויים.
יש הבדל מהותי בין סביבת העבודה במערכת מבוססת Unix למערכת מבוססת Windows.

 

 

QA - Quality Assurance

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

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

 

 

QC

התהליך ההביצועי של התאמת מוצרים ותהליכים כך שיעמדו בדרישות האיכות.
יש לוודא עמידה בדרישות של הלקוח (SPEC) וכן עמידהבדרישות האיכות הכלליות של QA.
במידה ואין עמידה בדרישות האיכות יש לדווח על כך (BUG)

 

 

Regression

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

 

 

Sanity Test

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

 

 

Scenario

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

 

 

Step

מהלך בודד אותו יש לבדוק.
יש להשוות את התוצאה הצפויה (Expected Result)  לתוצאה בפועל (Actual Result)

 

 

Technical spec

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

 

 

Test

יחידה אחת מתוך ה ATP.
כולל בתוכו מספר Steps.
אוסף הצעדים (steps) יוצרים יחד בדיקה שלמה.

 

 

Version

גרסה

 

 

VDD - Version description document

מסמך המלווה את הגירסה ומתאר במה היא שונה מהגרסה הקודמת. אילו באגים תוקנו? אילו פיצ'רים חדשים נוספו?.

 

 

White box

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