Load Testing לעומת Stress Testing: מה ההבדל ומתי צריך לבצע כל בדיקה?

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

מה זה Load Testing?

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

לדוגמה, אתר מסחר אלקטרוני שמשרת בדרך כלל 300 משתמשים בו-זמנית עשוי להידרש להתמודד עם 1,500 משתמשים בתקופת מבצעים. באמצעות Load Testing ניתן לבדוק האם האתר ממשיך להציג מוצרים, להוסיף פריטים לעגלה, לבצע חיפושים ולהשלים רכישות במהירות ובאמינות.

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

מה בודקים במסגרת Load Testing?

• זמני תגובה (Response Time): כמה זמן חולף מרגע שליחת בקשה ועד לקבלת התשובה.
• תפוקת מערכת (Throughput): כמה בקשות או עסקאות המערכת מסוגלת לעבד בפרק זמן נתון.
• שיעור שגיאות (Error Rate): אחוז הבקשות שנכשלות תחת העומס המתוכנן.
• ניצול משאבים: שימוש במעבד (CPU), בזיכרון (RAM), בדיסקים ובמשאבי הרשת.
• יציבות: האם המערכת שומרת על ביצועים עקביים לאורך זמן.
• ביצוע תהליכים עסקיים: האם פעולות כמו התחברות, חיפוש, שמירת נתונים ותשלום מתבצעות בהצלחה.

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

מה זה Stress Testing?

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

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

נניח שמערכת פיננסית מתוכננת לשרת 2,000 משתמשים במקביל. בבדיקת Stress Testing ניתן להעלות את מספר המשתמשים ל-3,000, לאחר מכן ל-5,000 ובהמשך ל-8,000. בכל שלב בודקים כיצד המערכת מגיבה, אילו רכיבים הופכים לצוואר בקבוק ומהו מנגנון הכשל.

מה בודקים במסגרת Stress Testing?

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

Load Testing לעומת Stress Testing – טבלת השוואה

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

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

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

הארגון מעריך שבשעות הפעילות הרגילות יהיו באתר כ-500 משתמשים בו-זמנית, ובתקופות מבצעים המספר עשוי להגיע ל-2,000 משתמשים.

שלב ראשון – ביצוע Load Testing

בשלב זה נריץ תרחישים המדמים את הפעילות הצפויה של המשתמשים:

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

נניח שהארגון הגדיר שזמן התגובה ב-P95 לא יעלה על שתי שניות וששיעור השגיאות לא יעלה על 1% בתרחיש העומס המתוכנן. אם המערכת עומדת בדרישות, ניתן להסיק שהיא מסוגלת להתמודד עם תרחיש השימוש שהוגדר.

שלב שני – ביצוע Stress Testing

כעת נמשיך להעלות את העומס מעבר לתרחיש המתוכנן:

• 3,000 משתמשים במקביל.
• 4,000 משתמשים במקביל.
• 6,000 משתמשים במקביל.
• המשך העלאת העומס עד לזיהוי נקודת הכשל.

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

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

איך מתכננים בדיקת Load Testing ו-Stress Testing?

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

1. הגדרת מטרות ודרישות ביצועים

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

מומלץ להגדיר יעדי ביצועים מדידים (Performance Requirements) ולהתבסס על דרישות עסקיות, נתוני שימוש היסטוריים ויעדי SLA.

2. בניית תרחישי משתמשים מציאותיים

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

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

3. הכנת סביבת בדיקה מתאימה

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

4. הרצת הבדיקות ואיסוף נתונים

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

5. ניתוח התוצאות והפקת מסקנות

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

כלים נפוצים לביצוע Load Testing ו-Stress Testing

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

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

ההבדל בין Stress Testing לבין Spike Testing ו-Soak Testing

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

Spike Testing – בדיקות קפיצה בעומס

Spike Testing בוחנת כיצד המערכת מתמודדת עם שינוי חד ומהיר בעומס. לדוגמה, מעבר מ-500 משתמשים ל-5,000 משתמשים בתוך מספר שניות, ולאחר מכן ירידה חדה במספר המשתמשים.

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

Soak Testing – בדיקות עומס ממושכות

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

Stress Testing – בדיקות מאמץ

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

טעויות נפוצות בביצוע בדיקות עומסים ומאמץ

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

בדיקת מספר משתמשים ללא תרחיש עסקי

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

התמקדות בזמן תגובה ממוצע בלבד

זמן תגובה ממוצע עלול להסתיר בעיות חמורות שחווים חלק מהמשתמשים. יש למדוד גם P90, P95 ו-P99, בהתאם לדרישות המערכת.

התעלמות מבסיס הנתונים

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

ביצוע בדיקות ללא ניטור מקביל

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

הרצת Stress Testing בסביבת ייצור ללא בקרה

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

מתי כדאי לבצע Load Testing ומתי Stress Testing?

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

תפקיד בודק התוכנה בתהליך

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

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

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

למי שמעוניין להרחיב את הידע בתחום, מומלץ לקרוא גם את המדריך בנושא איך מבצעים Load Testing בפועל, וכן את המאמר בדיקות עומסים מול בדיקות ביצועים – מה ההבדל?.

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

Load Testing ו-Stress Testing הן שתי שיטות מרכזיות בעולם בדיקות הביצועים, אך הן בוחנות היבטים שונים של המערכת.

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

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