S.T.P  

 Software Test Plan 

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

• התקציב שמיועד עבור בדיקות

• כמה אנשים אנו נצטרך לבדיקות

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

• סוגים של תוכנה  שנצטרך לבדיקות

• כמה זמן יוקצה לכל  סבב של בדיקות

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

 

 

 

 

 

S.T.D

system test design

זהו מונח  שמייצג  את   בניית תסריט הבדיקה (TEST CASE)   שהם בעצם סידרת הבדיקות שאנחנו רוצים לבדוק במערכת

 כאשר בהרצתו  נשים לב  למצב המערכת  הצפוי אל מול זה  שבפועל  ואם יש  שוני  אז  נרשום את השוני בין המצבים  (כמובן שצילום מסך של  השוני  מהתוצאה הצפויה תורמת להבנת התקלה וממולצת)

 

 

 

 

S.T.R  

system test results

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

• כמה  בדיקות נעשו

• כמה  בדיקות עבור  וכמה נכשלו

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

• כמה  בדיקות עברו אל מול  אלו שנכשלו  באחוזים  

• גרף  שמציין את  כול הנתונים אללו ביחס לתאריך /לסבב בדיקות/חומרה

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

 

 

 

 

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

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

וזאת ללא  כל בדיקה של הקוד  שמאחורי  הפעולות

לדוגמא גלשנו לאתר אינטרנט והוא נפתח   (לא בודקים קוד HTML)

 

בדיקת קופסא  לבנה/קופסא שקופה

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

אכן בשימוש  ושנשמרו סטנדרטים של  כתיבת  קוד.  באתרים  לדוגמא  בדיקות  איכות HTML

 

 

 

אפיונים

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

מסמך זה  מובא למתכנתים וגם  לבודקים וממנו גוזרים  את  המקרי הבדיקה ואת תסריטי בדיקה 

 

מקרי הבדיקה test condition 

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

לדוגמא  לטסט קונדישן  " כרטיס קולנוע מעל גיל 70  עולה  10 שקלים "

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

 

 

תסריט הבדיקה TEST CASE

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

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

 

 

בדיקות אוטומטיות

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

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

 

בדיקות עומסים

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

 

 

 

בדיקות חיוביות 

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

 

בדיקה שלילית

בדיקה שלילית בודקת את המערכת במצבים שהמשתמש עושה משהו אסור במערכת ולכן  צפוי לקבל הודעת שגיאה  לדוגמא   בבדיקות ממשק משתמש  המשתמש  יכניס בסעיף החודשים חודש שמספרו 0 או חודש שמספרו גדול מ12 

 

בדיקות אימות confirmation testing

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

 

בדיקות רגרסיה   regression testing

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

 

בדיקות סטטיות

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

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

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

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

 

 

לינקים (קישורים)

קישור   חיצוני:

הפנייה לדף שנמצא מחוץ לאתר שבו אתה שוהה קרי לאתר אחר

קישור פנימי:

הפנייה לדף שנמצא בדף אחר בתוך האתר שבו אתה שוהה

 

 

 מאגר נתונים   -  database 

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

הקיצור השימושי שלו הוא DB  

 

 

 

תהליך אצווה -Batch Process

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

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

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

של הלקוחות.

 

 

מנהל המשימות-task manager

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

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

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

שהרי זה יפגע לנו במחשב.

 

session

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

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

 

 

 END TO  END

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