
הטקסט המלא של הדקות הראשונות בהרצאה «מבוא לקורס JMeter» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום לכולם, בשיעור הקרוב נעשה היכרות עם בדיקות עומסים ו-J-Meter כהכנה לעבודה שלנו וללימוד שלנו של כלי ה-J-Meter. אז בואו נתחיל. המצגת הקרובה, אנחנו נדבר על בדיקות עומסים ובדיקות ממשקים, פרפורמנס ו-API.
ה-J-Meter הוא בעצם כלי שמאפשר לנו לבצע בדיקות עומסים ובדיקות ממשקים על המערכות שאותן אנחנו בודקים. בדיקת עומסים בעצם התפקיד שלה או היעד שלה היא לוודא שהמערכת שלנו, האפליקציה שאנחנו בודקים, האתר שאנחנו בודקים, מתפקד בצורה תקינה ברמה הפונקציונלית, ברמת הביצועים,
בזמן אמיתי, בזמן שהרבה משתמשים, הרבה ממשקים ניגשים ומנסים לקבל ממנו את השירות. קודם כל, מה זה פרפורמנס, או מה זה כל הנושא הזה של עומסים?
בעצם כשאנחנו בודקים עומסים, בודקים ביצועים, אז אנחנו רוצים לראות שהמערכת שלנו עומדת ביעדי העולם האמיתי מבחינת הבדיקות.
אנחנו רוצים לוודא בסביבת הבדיקה, בעזרת משתמשים וירטואליים, שהמערכת באמת עושה את מה שהיא אמורה לעשות, ועושה את זה בזמן סביר. בדיקת עומסים בעזרת J-Meter מאפשרת לנתח את התוצאות, לתרגם אותן לדוחות, גרפים וטבלאות ומאפשרת בעזרת זה לאתר צוואר בקבוק או צמתים שהם עמוסים וצריכים להיות מטופלים או צריכים
להיות משופרים מבחינת המערכת, אם צריך לפתוח תקלות על הביצועים של המערכת. כשאנחנו עושים בדיקות ביצועים אנחנו בודקים גם את התוכנה, גם את החומרה זאת אומרת הרבה פעמים התוכנה תעשה את מה שהיא צריכה אבל החומרה לא תאפשר לה לענות למספר הגדול של הפניות של הבקשות של משתמשים באותו זמן ולכן היא לא תוכל לבצע את העבודה למרות שהתוכנה כתובה טוב.
יהיה נדרש לשפר את הקונפיגורציה של המערכת מבחינת החומרה מבחינת הhardware לדוגמה לשפר זיכרון להוסיף ליסנרים להוסיף במקום בדיסק וכדומה. מה זה בעצם פרפורמנס טסטינג?
זה בעצם בדיקה שמשלבת גם בדיקה פונקציונלית אבל גם בדיקה של תגובת המערכת או ביצוע שלה או כמה זמן לוקח לה לעשות את מה שהיא נדרשת לו. בואו נתאר מצב שיש לנו אתר אינטרנט שאמור לספק תוצאות של בחירות וברמה מסוימת באיזושהי שעה במהלך יום הבחירות הוא צריך לעמוד בעומס של עשרות משתמשים בו זמנית.
כשאנחנו בודקים את האתר ברגע מסוים כמשתמש בודד אנחנו נקבל תשובה די מהר, אבל החוכמה היא לעשות את הבדיקה של קבלת האינפורמציה מהאתר על תוצאות הבחירות בסימולציה של מספר פונים, מספר משתמשים גדול שמבקש את אותה אינפורמציה או אינפורמציה משרתי המידע באותו הזמן.
בעצם כל מערכת מודרנית בנויה היום בצורה כזאת היא שהיא מציגה בסביבת האינטרנט נתונים שבאים ממערכות פנימיות שלה, ממערכות דאטאבייס, ממערכות לוגיקה פנימיות.
אנחנו רוצים לראות שכל התהליך הזה מתבצע בזמן סביר. זאת אומרת שהצגת הנתונים, אם אנחנו מתייחסים לדוגמה שלנו, מתבצעת בזמן של לא יותר מ-X שניות ומאפשרת למבקר באתר לקבל את האינפורמציה שהוא ביקש.
אם אנחנו נראה שבעומס מסוים המבקר לא מקבל את האינפורמציה בזמן הנכון או מקבל הודעת שגיאה, לפיכך נבין שהטסט שלנו נכשל, טסט הביצועים שלנו נכשל.
נרצה גם לדעת איך המערכת שלנו מתפקדת בעומס של משתמשים לאורך זמן. זאת אומרת שוב תמיד אנחנו כשאנחנו בודקים אנחנו בדרך כלל נבדוק בסביבה סטרילית נבדוק משתמשי קצה יחידים ונראה את המערכת מתפקדת בתנאים די נקיים, גנים אבל כשאנחנו עושים את בדיקת העומסים אנחנו נדמה ביקור של הרבה משתמשים בו זמנית וגם לאורך זמן ונרצה לראות שהטיפול בזיכרון והטיפול של
המערכת במשתמשים והניקוי של העיקרון בשרת יתבצע בצורה תקינה לאורך זמן ועומד ביעדים שלו. מחזור חיים של בדיקות מסוג ביצועים, בדיקות ביצועים מתי אנחנו יכולים לבצע את בדיקות העומסים, בדיקות הביצועים?
בדיקות ביצועים בדרך כלל מתבצעים אחרי שווידאנו שהפונקציונליות מתבצעת בצורה תקינה. אם נתייחס שוב לאתר משרד הפנים או אתר כלשהו שאמור לספק תוצאות בחירות, נראה שהתוצאות מגיעות בצורה תקינה.
אחרי השלב הזה נוכל לבדוק האם באמת התוצאות מגיעות גם בצורה תקינה וגם בזמן סביר למשתמש הקצה, בסימולציה של עומס שהוא לכיוון העומס האמיתי הצפוי ביום הבחירות או העומס שהמערכת התחייבה אליו. בדיקות ביצועים ישוו את הביצועים של המערכת בפועל לביצועים שתוכננו מבחינת האפיון