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

1. מהן בדיקות ביצועים (Performance Testing)?

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

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

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

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

2. מהן בדיקות עומסים (Load Testing)?

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

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

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

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

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

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

3. בדיקות עומסים מול בדיקות ביצועים – ההבדלים המרכזיים

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

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

4. אילו סוגי בדיקות קיימים בתחום הביצועים?

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

א. Load Testing – בדיקות עומסים

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

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

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

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

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

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

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

ד. Endurance Testing / Soak Testing – בדיקות סיבולת

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

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

ה. Scalability Testing – בדיקות מדרגיות

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

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

ו. Volume Testing – בדיקות נפח נתונים

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

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

5. אילו מדדים חשוב למדוד?

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

Response Time – זמן תגובה

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

Throughput – תפוקה

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

Concurrent Users – משתמשים במקביל

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

Percentiles – אחוזונים

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

• Median / P50: מחצית מהבקשות הסתיימו בזמן זה או מהר יותר.
• P90: 90% מהבקשות הסתיימו בזמן זה או מהר יותר.
• P95: 95% מהבקשות הסתיימו בזמן זה או מהר יותר.
• P99: 99% מהבקשות הסתיימו בזמן זה או מהר יותר.

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

Error Rate – שיעור שגיאות

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

CPU Utilization – ניצול מעבד

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

Memory Usage – שימוש בזיכרון

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

Database Performance – ביצועי מסד הנתונים

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

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

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

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

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

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

7. איך מתכננים בדיקת עומסים מקצועית?

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

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

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

שלב 2: הגדרת יעדי ביצועים

יש להגדיר מראש מדדי הצלחה ברורים. לדוגמה:

• 95% מהבקשות יסתיימו בתוך שתי שניות.
• שיעור השגיאות לא יעלה על 1%.
• המערכת תתמוך ב-1,000 משתמשים פעילים במקביל.
• תהליך רכישה יושלם ללא כשלים עסקיים.

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

שלב 3: בניית תרחישי שימוש

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

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

שלב 4: הכנת סביבת הבדיקה

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

שלב 5: הרצת הבדיקה ואיסוף נתונים

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

שלב 6: ניתוח התוצאות והפקת מסקנות

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

שלב 7: תיקון והרצה חוזרת

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

8. כלים נפוצים לבדיקות עומסים וביצועים

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

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

9. טעויות נפוצות בבדיקות ביצועים ועומסים

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

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

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

הסתמכות על זמן תגובה ממוצע

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

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

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

בדיקה בסביבה שאינה מייצגת את הייצור

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

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

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

בדיקה ללא קריטריוני הצלחה מוגדרים

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

10. מה התפקיד של בודק QA בבדיקות עומסים?

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

במסגרת העבודה, בודק QA יכול להיות אחראי על:

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

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

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

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

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

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

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

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

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

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

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

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

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

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