02_load ב-JMeter: מה חדש ואיך זה עובד
אחרי ש-01_smoke מאשר שהמערכת עולה, ה-endpoints הקריטיים זמינים, והזרימה הבסיסית באמת עובדת, אפשר לעבור לשלב הבא: 02_load. כאן כבר לא מסתפקים ב"בדיקת תקינות", אלא מתחילים לבדוק איך המערכת מתנהגת תחת עומס יציב, ממושך וריאליסטי יותר.
המאמר הזה לא חוזר על יסודות JMeter שכבר הוסברו במדריך הקודם, אלא מתמקד רק במה שחדש ב-02_load לעומת 01_smoke, ואיך לקרוא נכון את התסריט הזה.
מה חדש ב-02_load לעומת 01_smoke
- הרצה לפי זמן (Duration-based) ולא לפי מספר קטן של לופים.
- עומס ברירת מחדל גבוה יותר כדי לדמות עבודה של יותר משתמשים במקביל.
- Transaction Controller למדידת כל הזרימה העסקית כיחידה אחת.
- Think Time בין שלבים שונים, כדי לדמות שימוש אנושי ולא "ירי" רציף של בקשות.
- Assertions חזקים יותר שלא מסתפקים רק ב-HTTP 200.
- שימוש מעשי ב-token שמתקבל אחרי Login וממשיך עם שאר ה-flow.
- קובץ תוצאות נפרד עבור בדיקת העומס.
1. Duration-based Load: עומס לפי זמן
ב-01_smoke בדרך כלל עובדים עם מעט משתמשים ומעט איטרציות, כי המטרה היא לבדוק שהכול תקין. ב-02_load הרעיון כבר שונה: לא רק לבדוק שה-flow עובד, אלא לראות איך המערכת מחזיקה מעמד לאורך זמן תחת עומס רציף.
במקום לשאול "האם התסריט עבר פעם אחת?", מתחילים לשאול: איך המערכת מתנהגת במשך כמה דקות כשהיא מקבלת תנועה קבועה?
לכן כאן חשובים שלושה פרמטרים עיקריים:
- threads — כמה משתמשים וירטואליים ירוצו במקביל.
- ramp_up — תוך כמה זמן להעלות את כל המשתמשים.
- duration — כמה זמן בדיקת העומס תמשיך לרוץ.
בברירת המחדל של 02_load מוגדרים ערכים כמו threads=50, ramp_up=60, duration=300. המשמעות היא שהעומס לא רק עולה בהדרגה, אלא גם נשמר למשך זמן אמיתי יותר ולא נגמר מהר כמו Smoke.
2. מדידת כל ה-flow עם Transaction Controller
אחד הדברים החדשים באמת ב-02_load הוא Transaction Controller בשם Full Business Flow. הרעיון שלו פשוט אבל חשוב: לא למדוד רק כל בקשה בנפרד, אלא גם את כל הזרימה העסקית מקצה לקצה.
לדוגמה, אם ה-flow הוא:
health → login → profile → orders → stats
בלי Transaction Controller תקבלו זמני תגובה נפרדים לכל שלב. זה טוב, אבל זה לא עונה על שאלה עסקית חשובה: כמה זמן לוקח למשתמש להשלים את כל הפעולה?
עם Transaction Controller מתקבלת בנוסף שורה שמודדת את כל ה-flow כיחידה אחת. כך אפשר להבין גם את הביצועים של כל endpoint וגם את החוויה הכוללת של המשתמש.
3. Think Time: למה לא שולחים בקשות בלי הפסקה
ב-Load אמיתי לא תמיד נכון לדמות משתמש ששולח בקשה אחרי בקשה בלי לעצור. זו התנהגות מלאכותית מדי, שלפעמים יוצרת עומס אגרסיבי שלא באמת מייצג משתמשים אמיתיים.
לכן ב-02_load נוספו זמני המתנה קצרים בין שלבים שונים בזרימה. העיכובים האלה נקראים Think Time.
המטרה שלהם היא:
- לקרב את הבדיקה להתנהגות אמיתית יותר.
- למנוע תרחיש שבו כל משתמש יורה בקשות בצורה לא טבעית.
- ליצור עומס מדורג וסביר יותר על המערכת.
כלומר, עדיין יש עומס, אבל הוא נראה יותר כמו שימוש אמיתי ופחות כמו לולאה מכנית.
4. Assertions חזקים יותר: לא רק 200
ב-01_smoke מספיק לפעמים לבדוק שהתקבל HTTP 200. ב-02_load זה כבר לא מספיק, כי תגובה יכולה לחזור עם 200 ובכל זאת להיות שגויה, ריקה או חלקית.
לכן בתסריט הזה מוסיפים גם בדיקות תוכן. לדוגמה:
- ב-Health בודקים לא רק 200 אלא גם שהתוכן כולל UP.
- ב-Login בודקים לא רק שהבקשה הצליחה, אלא גם שהתגובה באמת מחזירה token.
כך התסריט בודק לא רק "האם השרת ענה", אלא גם "האם השרת ענה נכון".
5. שימוש ב-token בתוך הזרימה
במאמר הקודם כבר הוסבר איך מחלצים ערך מ-JSON. ב-02_load החילוץ הזה הופך לחלק מעשי מהזרימה העסקית: אחרי Login מחלצים את ה-token, ואז משתמשים בו בבקשות הבאות.
זה חשוב כי כך ה-flow כבר לא נראה כמו אוסף של בקשות מנותקות, אלא כמו תרחיש API אמיתי: המשתמש מתחבר, מקבל הרשאה, ורק אחר כך ממשיך לשאר הפעולות.
היתרון הוא לא רק ריאליזם, אלא גם אמינות: אם ה-login נשבר או שה-token לא חולץ נכון, גם השלבים הבאים ייכשלו, בדיוק כמו במערכת אמיתית.
6. הזרימה העסקית ב-02_load
התסריט שומר על אותו רעיון כללי של Flow עסקי, אבל מריץ אותו תחת עומס ממשי יותר. הזרימה נראית כך:
- health → login → profile → orders → stats
כלומר, לא מדובר רק באוסף endpoint-ים שנבדקים בנפרד, אלא בשרשרת פעולות שמדמה שימוש אמיתי במערכת.
סיכום
אם 01_smoke בודק שהמערכת "חיה ועובדת", אז 02_load בודק איך היא מתנהגת תחת שימוש רציף, מדוד וריאליסטי יותר.
זהו השלב שבו התסריט עובר מבדיקת תקינות בסיסית לבדיקת עומס התחלתית שכוללת משך הרצה אמיתי יותר, מדידה של flow שלם, Think Time, assertions חזקים יותר, שימוש מעשי ב-token ושמירת תוצאות נפרדת.
ללימוד עמוק יותר: אפשר להדביק את הפרומפט הבא ל-ChatGPT:
אתה מומחה JMeter ובדיקות ביצועים. קראתי את המאמר הזה: https://qablog.co.il/load-testing
תסביר:
1) מה זה Duration-based load ואיפה מגדירים duration בתסריט
2) מה נותן Transaction Controller ואיך לקרוא את המדידה של "Full Business Flow"
3) איך Think Time משפיע על עומס ולמה הוא חשוב
4) אילו Assertions נוספו מעבר ל-HTTP 200 ואיך זה מעלה אמינות
5) איך משתמשים ב-token בתוך ה-flow אחרי Login
6) למה נשמר קובץ תוצאות נפרד ואיך מנתחים אותו אחרי הרצה
תשאל אותי עד 5 שאלות קצרות כדי להתאים את ההנחיות אליי:
OS, איפה הפרויקט נמצא, כמה משתמשים אני רוצה לדמות, כמה זמן להריץ, והאם אני רוצה לעבוד דרך GUI או CLI.מקורות רשמיים