איך כותבים תרחיש לבדיקת עומסים? מדריך מעשי לבניית Load Testing Scenario

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

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

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

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

מהו תרחיש לבדיקת עומסים?

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

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

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

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

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

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

למה חשוב לכתוב תרחיש עומסים לפני שמתחילים לבדוק?

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

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

לא בהכרח.

תרחיש מסודר מאפשר:

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

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

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

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

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

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

נרצה להבין:

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

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

דוגמה לחלוקת פעולות במערכת הזמנות:

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

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

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

לכל תרחיש חייבת להיות מטרה ברורה.

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

לדוגמה:

1. לבדוק האם המערכת תומכת ב-500 משתמשים בו-זמנית.
2. לבדוק האם זמן התגובה של פעולות מרכזיות נשאר מתחת לשתי שניות.
3. לבדוק האם שיעור השגיאות נשאר נמוך מ-1%.
4. לבדוק האם המערכת מסוגלת להתמודד עם עלייה הדרגתית במספר המשתמשים.
5. לבדוק האם מסד הנתונים מצליח לעבד את כמות השאילתות הצפויה.
6. לבדוק האם שירותי צד שלישי מגיבים בצורה תקינה תחת עומס.

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

לדוגמה:

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

שלב שלישי: זיהוי תהליכי המשתמש המרכזיים

כעת צריך לפרק את פעילות המשתמשים לתהליכים ברורים.

כל תהליך צריך להיות מורכב מפעולות הגיוניות שמבוצעות ברצף.

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

תהליך רכישה:

1. כניסה לאתר.
2. התחברות לחשבון.
3. חיפוש מוצר.
4. צפייה בפרטי המוצר.
5. הוספת המוצר לעגלת הקניות.
6. מעבר לעגלת הקניות.
7. הזנת פרטי משלוח.
8. בחירת אמצעי תשלום.
9. אישור ההזמנה.

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

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

דוגמה לחלוקת תרחישים:

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

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

אחד הפרמטרים החשובים ביותר בתרחיש עומסים הוא מספר המשתמשים הווירטואליים (Virtual Users).

משתמש וירטואלי הוא תהליך שמדמה פעילות של משתמש אמיתי מול המערכת.

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

לדוגמה:

• 10,000 משתמשים רשומים.
• 2,000 משתמשים פעילים בשעות השיא.
• 500 משתמשים שמבצעים פעולות במקביל.

אלה נתונים שונים לחלוטין.

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

Ramp-up – עלייה הדרגתית בעומס

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

לדוגמה:

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

חשוב לזכור: Ramp-up מתאר את קצב העלייה בעומס, ולא את מספר הבקשות שהמערכת מקבלת בכל שנייה.

שלב חמישי: הגדרת Think Time בין פעולות

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

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

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

הזמן שבין פעולה לפעולה נקרא Think Time.

לדוגמה:

• משתמש נכנס לעמוד הבית.
• ממתין 3 שניות.
• מבצע חיפוש.
• ממתין 5 שניות.
• נכנס לעמוד מוצר.
• ממתין 8 שניות.
• מוסיף מוצר לעגלה.

זמני ההמתנה האלה חשובים כדי לדמות התנהגות אנושית.

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

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

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

שלב שישי: הגדרת נתוני בדיקה (Test Data)

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

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

לכן יש להכין מראש:

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

בנוסף, חשוב לבדוק האם הנתונים נשארים זמינים לאורך הבדיקה.

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

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

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

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

לפני הרצת הבדיקה צריך להחליט כיצד נמדוד הצלחה.

המדד הראשון שרוב הבודקים חושבים עליו הוא זמן תגובה (Response Time), אבל הוא בהחלט לא היחיד.

המדדים המרכזיים שכדאי להגדיר:

1. Response Time – זמן תגובה

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

2. Throughput – תפוקה

כמה בקשות המערכת מצליחה לעבד בפרק זמן נתון, למשל בקשות לשנייה (RPS).

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

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

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

איזה אחוז מהבקשות הסתיימו בשגיאה או בתוצאה שאינה תקינה.

5. Percentiles – אחוזונים

מדד שמאפשר להבין את התפלגות זמני התגובה.

לדוגמה:

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

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

6. משאבי מערכת

• CPU Utilization.
• Memory Usage.
• Disk I/O.
• Database Connections.
• Network Utilization.

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

שלב שמיני: כתיבת תרחיש הבדיקה בפועל

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

תרחיש מסודר צריך לכלול את הפרטים הבאים:

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

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

Scenario ID: LOAD-001

Scenario Name: בדיקת עומסים לתהליך רכישת מוצר.

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

הגדרות הבדיקה:

• משתמשים במקביל: 500.
• זמן Ramp-up: 10 דקות.
• זמן עומס יציב: 30 דקות.
• זמן Ramp-down: 5 דקות.
• סביבת בדיקה: סביבת Performance ייעודית.
• נתוני בדיקה: 500 חשבונות משתמשים ונתוני מוצרים זמינים.

רצף הפעולות:

תנאי הצלחה לדוגמה:

• P95 של פעולות הגלישה לא יעלה על 2 שניות.
• P95 של פעולת ההתחברות לא יעלה על 3 שניות.
• שיעור השגיאות לא יעלה על 1%.
• לא תתרחש קריסה של השירות.
• לא ייווצרו הזמנות כפולות.
• תהליכי הרכישה יסתיימו בתוצאה עסקית תקינה.

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

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

שלב תשיעי: בחירת כלי לביצוע בדיקות עומסים

לאחר כתיבת התרחיש יש לבחור כלי שיאפשר לממש אותו ולהריץ את הבדיקה.

קיימים מספר כלים נפוצים בתחום.

JMeter

Apache JMeter הוא אחד הכלים המוכרים לבדיקות עומסים.

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

<ins>יתרונות:</ins>

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

k6

Grafana k6 הוא כלי לבדיקות עומסים המבוסס על JavaScript.

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

דוגמה לתרחיש בסיסי ב-k6:

import http from 'k6/http';
import { sleep, check } from 'k6';
export const options = {
  vus: 100,
  duration: '5m',
};
export default function () {
  const response = http.get('https://example.com');
  check(response, {
    'status is 200': (r) => r.status === 200,
    'response time under 2s': (r) => r.timings.duration < 2000,
  });
  sleep(2);
}

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

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

Locust

Locust הוא כלי קוד פתוח לבדיקות עומסים שנכתב ב-Python.

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

הכלי מתאים במיוחד למי שמעדיף לבנות תרחישי בדיקה באמצעות Python.

השוואה בין הכלים

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

שלב עשירי: הרצת הבדיקה וניתוח התוצאות

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

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

רק לאחר מכן כדאי להגדיל את העומס.

במהלך הבדיקה יש לעקוב אחר:

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

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

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

אילו סוגי תרחישים כדאי לכתוב?

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

1. Load Test – בדיקת עומס רגילה

מטרתה לבדוק כיצד המערכת מתפקדת תחת עומס צפוי.

לדוגמה: 500 משתמשים במקביל במשך 30 דקות.

2. Stress Test – בדיקת מאמץ

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

לדוגמה: הגדלת מספר המשתמשים מ-500 ל-1,000, לאחר מכן ל-1,500 ולבסוף ל-2,000.

3. Spike Test – בדיקת קפיצת עומס

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

לדוגמה: מעבר מ-100 משתמשים ל-1,000 משתמשים בתוך זמן קצר.

4. Soak Test – בדיקת עומס ממושכת

מטרתה לבדוק האם המערכת מסוגלת להתמודד עם עומס לאורך זמן.

לדוגמה: 400 משתמשים במשך 8 שעות.

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

להרחבה בנושא ההבדלים בין סוגי הבדיקות, מומלץ לקרוא את המאמר <a href="https://tesqa.net/2026/11/02/load-testing-%d7%9c%d7%a2%d7%95%d7%9e%d7%aa-stress-testing/">Load Testing לעומת Stress Testing</a>.

טעויות נפוצות בכתיבת תרחישי בדיקות עומסים

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

1. שימוש במספר משתמשים שאינו מבוסס על נתונים

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

2. בדיקת פעולה אחת בלבד

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

3. התעלמות מזמני Think Time

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

4. שימוש באותם נתוני בדיקה

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

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

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

6. התעלמות משירותים חיצוניים

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

7. ביצוע הבדיקה ללא ניטור תשתיתי

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

8. הרצת עומס גבוה ללא בדיקה מקדימה

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

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

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

פרטי התרחיש

• Scenario ID:
• Scenario Name:
• System Under Test:
• Test Environment:
• Test Objective:
• Test Type:

הגדרות עומס

• Expected Concurrent Users:
• Maximum Concurrent Users:
• Ramp-up Time:
• Steady-state Duration:
• Ramp-down Time:
• Requests per Second (Target):

התנהגות משתמשים

• User Type:
• Business Flow:
• Action Sequence:
• Think Time:
• User Distribution:

נתוני בדיקה

• Test Accounts:
• Test Records:
• Dynamic Data:
• Data Cleanup:

מדדי ביצועים

• Response Time P50:
• Response Time P95:
• Response Time P99:
• Throughput:
• Error Rate:
• CPU Utilization:
• Memory Utilization:
• Database Performance:

תנאי הצלחה

• Expected Results:
• Maximum Allowed Response Time:
• Maximum Allowed Error Rate:
• Business Validation:
• System Stability:

תוצאות הבדיקה

• Actual Number of Users:
• Actual Throughput:
• Actual Response Time:
• Actual Error Rate:
• Identified Bottlenecks:
• Recommendations:

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

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

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

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

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

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

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

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

כמה משתמשים צריך להגדיר בתרחיש בדיקת עומסים?

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

האם צריך לכתוב תרחיש נפרד לכל פעולה?

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

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

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

כמה זמן צריכה להימשך בדיקת עומסים?

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

מה ההבדל בין תרחיש בדיקה לבדיקת עומסים לבין Test Case רגיל?

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

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

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

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

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

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

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

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

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

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

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

קורס לבדיקות תוכנה מדויק

לעבוד מהבית כבודק תוכנה עם FIVERR >> לחץ כאן