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

להלן הנושאים, אותם נבין בחלק זה:

מה זה בדיקת ביצועים?

זהו החלק החשוב ביותר של בדיקות לא תפקודיות.

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

בדרך כלל, בדיקה זו מגדירה באיזו מהירות השרת מגיב לבקשת המשתמש.

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

זמן תגובה: זמן תגובה הוא הזמן שלוקח לשרת להגיב לבקשת הלקוח.

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

יַצִיבוּת: עבור גורם היציבות, אנו יכולים לומר כי, כאשר N-מספר משתמשים המשתמשים באפליקציה בו זמנית במשך זמן מסוים.

מתי אנו משתמשים במבחני ביצועים?

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

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

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

סוגי בדיקות ביצועים

להלן סוגי בדיקות הביצועים:

הפעל מחדש את mysql ubuntu

בדיקת עומס מבחן לחץ בדיקת מדרגיות בדיקת יציבות

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

בדיקת עומס

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

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

מבחן לחץ

בדיקת המאמץ היא בדיקה, הבודקת את התנהגות האפליקציה על ידי הפעלת עומס גדול מהעומס הרצוי.

לדוגמה: אם לקחנו את הדוגמה לעיל והגדלנו את העומס הרצוי 1000 ל-1100 משתמשים, והמטרה היא 4/שנייה. בזמן ביצוע בדיקת המאמץ בתרחיש זה, היא תעבור מכיוון שהעומס גדול (100 למעלה) מהעומס הרצוי בפועל.

בדיקת מדרגיות

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

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

בדיקת מדרגיות כלפי מעלה בדיקת מדרגיות כלפי מטה

בדיקת מדרגיות כלפי מעלה

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

בדיקת מדרגיות כלפי מטה

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

בדיקת יציבות

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

דוגמה לבדיקת ביצועים

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

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

תרחיש 1:כאשר יש לנו את 1000 המשתמשים כעומס הרצוי, וה-2.7/sec הוא זמן המטרה, התרחישים הללו יעברו תוך כדי ביצוע בדיקת העומס כי בבדיקת עומס, נתרכז ב-no. של משתמשים, ולפי הדרישה זה שווה ל-1000 משתמשים.תרחיש 2:בתרחיש הבא נגדיל את העומס הרצוי ב-100 משתמשים, וזמן היעד יעלה ל-3.5sek. תרחיש זה יעבור אם נבצע בדיקות מאמץ מכיוון שכאן, העומס בפועל גדול מ- (1100) מהעומס הרצוי (1000).תרחיש 3:בכך, אם נגדיל את העומס הרצוי פי שלושה
1200 → 3.5שניות: [זה לא קטן או שווה לעומס הרצוי ולכן זה יהיה לְהִכָּשֵׁל ]
1300 → 4שניות: [הוא לא קטן או שווה לעומס הרצוי. כְּלוֹמַר., לְהִכָּשֵׁל ]
1400 ← התרסק

הערה 1: בדיקת נפח וספיגה היא סוג של בדיקה אך לא בדיקת ביצועים.

בדיקת נפח

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

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

בדיקת השרייה

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

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

תהליך בדיקת ביצועים

לא ניתן לבצע את בדיקת הביצועים באופן ידני מכיוון:

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

תהליך בדיקת הביצועים יושלם בשלבים הבאים:

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

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

אין אות כניסה

זיהוי תרחישי ביצועים

ראשית, נזהה את תרחישי הביצועים על סמך הגורמים הבאים:

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

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

עסקת נתונים ענקית: אם יש לנו נתונים עצומים פירושו שמספר n של המשתמשים המשתמשים באפליקציה בו-זמנית.

לאחר שנזהה את תרחישי הביצועים, נעבור לשלב הבא.

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

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

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

java לקרוא csv

הגדר את סביבת הבדיקה והפצת העומס

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

בצע סקריפטים לבדיקה

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

תוֹצָאָה

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

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

תוצאת ניתוח

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

זהה את צוואר הבקבוק

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

הפעל מחדש את הבדיקה

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

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

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

בעיות הביצועים הן כדלקמן:

בעיית זמן תגובה בעיית מדרגיות צַוַאר הַבַּקבּוּק בעיית מהירות

בעיית זמן תגובה

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

בעיית מדרגיות

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

צַוַאר הַבַּקבּוּק

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

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

להלן צווארי הבקבוק הנפוצים ביותר בביצועים:

• ניצול זיכרון
• שימוש בדיסק
• ניצול CPU
• מגבלות מערכת הפעלה
• ניצול רשת

בעיות מהירות

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

כלים לבדיקת ביצועים

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

כלים מסחריים: LoadRunner[HP], WebLOAD, NeoLoad

כלי קוד פתוח: JMeter

LoadRunner

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

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

JMeter

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

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

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

WebLOAD

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

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

NeoLoad

Neotys מפתחת כלי בדיקה הנקרא NeoLoad. ה-NeoLoad משמש לבדיקת תרחישי בדיקת הביצועים. בעזרת NeoLoad נוכל למצוא את אזורי צוואר הבקבוק ברשת ואת תהליך פיתוח האפליקציה לנייד.

להפוך מחרוזת ל-int

כלי הבדיקה NeoLoad מהיר יותר בהשוואה לכלים מסורתיים.

מלבדם, ישנם כלים אחרים עומס חשמלי, כלי מתח ברשת, LoadUI Pro, StresStimulus, LoadView, LoadNinja ו-RedLine13, מה שעוזר לבדוק את ביצועי התוכנה או האפליקציה.