בדיקות REST API – מדריך לאנשי ה QA

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

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

במדריך זה נלמד מהן בדיקות REST API, כיצד פרוטוקול HTTP עובד, אילו שיטות בדיקה חשוב להכיר, איך לבנות Test Cases איכותיים, כיצד לבדוק תגובות JSON, אילו כלי עבודה מתאימים לאנשי QA ואיך לזהות תקלות שעלולות להישאר נסתרות בבדיקות רגילות.

תוכן עניינים

• מה זה REST API?
• איך REST API עובד?
• שיטות HTTP שחשוב להכיר
• קודי תגובה HTTP
• סוגי בדיקות REST API
• איך כותבים Test Cases לבדיקות REST API?
• בדיקות JSON ואימות נתונים
• בדיקות Authentication ו-Authorization
• בדיקות שליליות ותרחישי קצה
• כלים לבדיקות REST API
• אוטומציה בבדיקות REST API
• בדיקות ביצועים ועומסים
• תקלות נפוצות ואיך לזהות אותן
• תהליך עבודה מומלץ לאיש QA
• צ'קליסט לבדיקות REST API
• איך ללמוד בדיקות REST API ולהתקדם בתחום?

1. מה זה REST API?

REST הוא ראשי תיבות של Representational State Transfer. מדובר בסגנון ארכיטקטוני המגדיר עקרונות לתקשורת בין מערכות באמצעות HTTP. API הוא ראשי תיבות של Application Programming Interface, כלומר ממשק המאפשר לתוכנות שונות לתקשר ולהעביר ביניהן מידע.

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

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

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

להרחבה בנושא היסודות, מומלץ לקרוא גם את המדריך מה זה API ואיך בודקים API – המדריך המלא לבודקי תוכנה.

2. איך REST API עובד?

תהליך תקשורת REST API מורכב בדרך כלל מארבעה שלבים:

1. Client: מערכת הלקוח שולחת בקשה לשרת. לדוגמה, אפליקציה או כלי בדיקות כמו Postman.
2. HTTP Request: הבקשה כוללת כתובת URL, שיטת HTTP, Headers ולעיתים גם פרמטרים ו-Body.
3. Server Processing: השרת מקבל את הבקשה, בודק הרשאות, מבצע לוגיקה עסקית ומתקשר עם מסד הנתונים במידת הצורך.
4. HTTP Response: השרת מחזיר קוד סטטוס, Headers ולעיתים תוכן בפורמט JSON.

דוגמה מעשית לבקשת REST API

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

כתובת הבקשה:

GET https://api.example.com/customers/105

תגובה אפשרית מהשרת:

{
  "id": 105,
  "firstName": "David",
  "lastName": "Cohen",
  "email": "david@example.com",
  "active": true
}

מה איש QA צריך לבדוק במקרה הזה?

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

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

3. שיטות HTTP שחשוב להכיר בבדיקות REST API

אחד הדברים הראשונים שאיש QA צריך להכיר הוא HTTP Methods. כל שיטה מייצגת פעולה אחרת על משאב במערכת.

Method	מטרה	דוגמה	מה בודקים?
GET	שליפת מידע	קבלת פרטי לקוח	נכונות הנתונים וההרשאות
POST	יצירת משאב חדש	פתיחת לקוח	יצירה, ולידציות ומניעת כפילויות
PUT	החלפת משאב	עדכון פרטי לקוח מלאים	החלפת הנתונים לפי החוזה
PATCH	עדכון חלקי	שינוי כתובת דוא"ל	עדכון השדה הנדרש בלבד
DELETE	מחיקת משאב	מחיקת לקוח	מחיקה, הרשאות והתנהגות חוזרת

GET – בדיקת שליפת נתונים

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

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

• שליפת רשומה קיימת.
• שליפת רשומה שאינה קיימת.
• שליפת רשומות לפי פרמטר חיפוש.
• בדיקת Pagination באמצעות page ו-limit.
• בדיקת מיון לפי תאריך או שם.
• בדיקת משתמש ללא הרשאות.

POST – בדיקת יצירת נתונים

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

תרחישים חשובים:

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

PUT לעומת PATCH

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

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

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

4. קודי תגובה HTTP – מה איש QA חייב להכיר?

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

קוד	משמעות	מתי מצפים לו?
200	OK	בקשה הצליחה
201	Created	נוצר משאב חדש
202	Accepted	הבקשה התקבלה לעיבוד עתידי
204	No Content	הפעולה הצליחה ללא גוף תגובה
400	Bad Request	בקשה לא תקינה
401	Unauthorized	אין אימות משתמש תקין
403	Forbidden	אין הרשאה לפעולה
404	Not Found	המשאב אינו קיים או אינו חשוף למשתמש
405	Method Not Allowed	שיטת HTTP אינה נתמכת בנתיב
409	Conflict	התנגשות עם מצב קיים
415	Unsupported Media Type	פורמט התוכן אינו נתמך
422	Unprocessable Content	הבקשה תקינה תחבירית אך הנתונים אינם תקינים מבחינה סמנטית
429	Too Many Requests	חריגה ממגבלת בקשות
500	Internal Server Error	שגיאה פנימית בשרת
502	Bad Gateway	שרת ביניים קיבל תגובה לא תקינה
503	Service Unavailable	השירות אינו זמין זמנית
504	Gateway Timeout	חריגה מזמן ההמתנה של שרת ביניים

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

5. סוגי בדיקות REST API

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

בדיקות פונקציונליות (Functional Testing)

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

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

בדיקות אינטגרציה (Integration Testing)

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

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

בדיקות חוזה (Contract Testing)

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

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

בדיקות אבטחה (Security Testing)

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

בדיקות רגרסיה (Regression Testing)

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

בדיקות תאימות (Compatibility Testing)

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

6. איך כותבים Test Cases לבדיקות REST API?

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

במדריך איך כותבים Test Case לבדיקת API – מדריך מעשי עם דוגמאות ניתן להעמיק בשיטת העבודה ובבניית מקרי בדיקה.

מבנה מומלץ ל-Test Case

רכיב	תיאור
Test Case ID	מזהה ייחודי לבדיקה
Test Title	תיאור קצר של הבדיקה
Preconditions	תנאים מקדימים
HTTP Method	GET / POST / PUT / PATCH / DELETE
Endpoint	כתובת ה-API
Test Data	נתוני הבדיקה
Steps	שלבי הביצוע
Expected Result	התוצאה הצפויה
Actual Result	התוצאה שהתקבלה
Status	Pass / Fail / Blocked

דוגמה: בדיקת יצירת לקוח באמצעות POST

נניח שקיים API המאפשר יצירת לקוח חדש.

Endpoint:

POST /api/customers

Request Body:

{
  "firstName": "David",
  "lastName": "Cohen",
  "email": "david@example.com",
  "phone": "0501234567"
}

תוצאה צפויה:

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

טבלת Test Cases לדוגמה

ID	תרחיש	נתוני בדיקה	תוצאה צפויה
API-001	יצירת לקוח תקין	כל השדות תקינים	201 Created
API-002	חסר שם פרטי	firstName חסר	שגיאת ולידציה
API-003	דוא"ל לא תקין	abc@	שגיאת ולידציה
API-004	משתמש ללא Token	ללא Authorization	401
API-005	שליחת JSON שגוי	תחביר JSON לא תקין	400
API-006	יצירת לקוח עם דוא"ל כפול	דוא"ל קיים	שגיאה בהתאם לאפיון
API-007	שליפת לקוח קיים	מזהה תקין	200 עם נתונים נכונים
API-008	שליפת לקוח לא קיים	מזהה לא קיים	404 או תגובה מוגדרת אחרת

7. בדיקות JSON ואימות נתונים

JSON הוא פורמט נפוץ להעברת נתונים ב-REST API. איש QA צריך להכיר את המבנה שלו ולדעת לבדוק לא רק את הערכים אלא גם את סוגי הנתונים, השדות, המבנה והקשרים ביניהם.

מה חשוב לבדוק בתגובת JSON?

• שדות חובה: האם כל השדות שהוגדרו בחוזה קיימים?
• Data Types: האם מספר מוחזר כמספר, Boolean כערך Boolean ומחרוזת כמחרוזת?
• Null Values: האם ערכים ריקים מטופלים בהתאם לדרישות?
• Nested Objects: האם אובייקטים מקוננים בנויים בצורה נכונה?
• Arrays: האם רשימות הנתונים מכילות את הפריטים הצפויים?
• Data Integrity: האם הנתונים תואמים למקור הנתונים?
• Unexpected Fields: האם נוספו שדות שלא אמורים להיחשף?

דוגמה לבדיקת JSON

{
  "orderId": 12345,
  "status": "approved",
  "total": 250.50,
  "paid": true,
  "customer": {
    "id": 105,
    "name": "David Cohen"
  },
  "items": [
    {
      "productId": 10,
      "quantity": 2
    }
  ]
}

בבדיקה זו יש לוודא ש-orderId הוא מספר, שהסטטוס הוא approved, שסכום העסקה תואם לחישוב העסקי, ש-paid הוא Boolean ושמערך items כולל את המוצרים והכמויות הנכונים.

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

בדיקת Schema

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

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

8. בדיקות Authentication ו-Authorization

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

חשוב להבחין בין שני מושגים:

• Authentication: אימות זהות המשתמש – מי אתה?
• Authorization: בדיקת הרשאות – מה מותר לך לבצע?

בדיקות Authentication

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

בדיקות Authorization

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

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

בדיקה חשובה במיוחד היא IDOR – Insecure Direct Object Reference. מדובר במצב שבו משתמש יכול לגשת למשאב של משתמש אחר באמצעות שינוי מזהה המשאב בבקשה.

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

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

9. בדיקות שליליות ותרחישי קצה

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

Boundary Value Analysis

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

• 17 – ערך מתחת למינימום.
• 18 – הערך המינימלי המותר.
• 19 – ערך מעל המינימום.
• 119 – ערך מתחת למקסימום.
• 120 – הערך המקסימלי המותר.
• 121 – ערך מעל המקסימום.

Equivalence Partitioning

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

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

תרחישי קצה נוספים

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

10. כלים לבדיקות REST API

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

Postman

Postman הוא אחד הכלים הנפוצים ביותר לבדיקות API. הוא מאפשר לשלוח בקשות HTTP, להגדיר Headers, להעביר פרמטרים, לשלוח JSON, לשמור Collections ולכתוב בדיקות JavaScript.

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

למדריך מעשי מומלץ לקרוא את בדיקות API עם Postman – מדריך למתחילים.

Swagger / OpenAPI

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

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

cURL

cURL הוא כלי שורת פקודה לשליחת בקשות HTTP. הוא שימושי כאשר רוצים להריץ בדיקות מתוך Terminal, לשחזר תקלות או לשלב בקשות בסקריפטים.

curl -X GET "https://api.example.com/customers/105" \
-H "Accept: application/json"

Playwright

Playwright מאפשר לבצע גם בדיקות API באמצעות APIRequestContext. כך ניתן לכתוב בדיקות אוטומטיות ב-JavaScript או TypeScript, לשלב אותן בתהליך בדיקות רחב ולהשתמש באותו כלי גם לבדיקות UI.

JMeter ו-k6

Apache JMeter ו-k6 מתאימים לבדיקות ביצועים ועומסים של ממשקי API. הם מאפשרים לדמות משתמשים ובקשות רבות ולבדוק זמני תגובה, קצב בקשות ושיעורי שגיאות.

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

11. אוטומציה בבדיקות REST API

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

אפשר לבצע אוטומציה באמצעות Postman, Playwright, pytest, REST Assured וכלים נוספים.

דוגמה לאוטומציה עם Playwright

הדוגמה הבאה ממחישה בדיקת GET בסיסית באמצעות JavaScript:

import { test, expect } from '@playwright/test';

test('Get customer details', async ({ request }) => {
  const response = await request.get(
    'https://api.example.com/customers/105'
  );

  expect(response.status()).toBe(200);

  const body = await response.json();

  expect(body.id).toBe(105);
  expect(body.firstName).toBe('David');
  expect(body.active).toBe(true);
});

מה הבדיקה עושה?

1. שולחת בקשת GET לכתובת API.
2. בודקת שהתקבל קוד תגובה 200.
3. ממירה את התגובה לאובייקט JSON.
4. בודקת את מזהה הלקוח.
5. בודקת את השם הפרטי.
6. בודקת שהלקוח מוגדר כפעיל.

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

מתי כדאי לבצע אוטומציה?

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

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

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

12. בדיקות ביצועים ועומסים ל-REST API

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

בבדיקות ביצועים בוחנים בין היתר:

• Response Time: כמה זמן לוקח לשרת להחזיר תגובה.
• Throughput: כמה בקשות המערכת מסוגלת לעבד בפרק זמן נתון.
• Error Rate: אחוז הבקשות שנכשלו.
• Concurrent Users: מספר המשתמשים או התהליכים הפעילים במקביל.
• Resource Utilization: צריכת CPU, זיכרון ומשאבי מערכת.
• Latency Percentiles: זמני תגובה באחוזונים כגון P90, P95 ו-P99.

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

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

להעמקה בנושא:

• Load Testing לעומת Stress Testing – ההבדלים והיישום
• כלי בדיקות עומסים – מה כדאי לבחור?
• אילו מדדים בודקים בבדיקות עומסים?

13. תקלות נפוצות בבדיקות REST API ואיך לזהות אותן

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

1. החזרת נתונים שגויים

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

2. שדות חסרים בתגובה

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

3. בעיות הרשאות

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

4. טיפול לא נכון בבקשות כפולות

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

5. בעיות בתאריכים ובאזורי זמן

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

6. בעיות Pagination

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

7. בעיות במקביליות

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

8. חשיפת מידע רגיש

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

14. תהליך עבודה מומלץ לאיש QA בבדיקות REST API

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

1. לימוד האפיון: הבנת המטרה העסקית, ה-EndPoints, הפרמטרים, סוגי הנתונים והתגובות האפשריות.
2. היכרות עם המערכת: הבנת תהליכים עסקיים, קשרים בין שירותים ומבנה הנתונים.
3. בדיקת התיעוד: מעבר על Swagger או OpenAPI והבנת החוזה.
4. הכנת סביבת בדיקות: הגדרת כתובות שרת, משתמשים, הרשאות ונתוני בדיקה.
5. כתיבת Test Cases: בניית תרחישים חיוביים, שליליים, גבולות ואבטחה.
6. בדיקות Smoke: בדיקה ראשונית שהשירות זמין ופעולות מרכזיות פועלות.
7. בדיקות פונקציונליות: בדיקת הפעולות והנתונים.
8. בדיקות אינטגרציה: בדיקת תקשורת בין מערכות.
9. בדיקות שליליות: בדיקת קלט שגוי, הרשאות, ערכים חסרים ותרחישי קצה.
10. בדיקות רגרסיה: הרצת הבדיקות לאחר שינויים.
11. דיווח באגים: תיעוד הבקשה, התגובה, נתוני הבדיקה והתוצאה הצפויה.
12. סיכום בדיקות: הצגת כיסוי הבדיקות, תקלות פתוחות ורמת הסיכון.

15. צ'קליסט לבדיקות REST API

לפני סיום בדיקות של ממשק API, מומלץ לעבור על הרשימה הבאה:

16. איך ללמוד בדיקות REST API ולהתקדם בתחום ה-QA?

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

מומלץ להתקדם בשלבים:

1. ללמוד את יסודות HTTP, בקשות ותגובות.
2. להבין את ההבדלים בין GET, POST, PUT, PATCH ו-DELETE.
3. ללמוד לקרוא ולכתוב JSON.
4. להכיר קודי תגובה HTTP.
5. להתנסות בבדיקות עם Postman.
6. ללמוד Authentication ו-Authorization.
7. לתרגל כתיבת Test Cases ותרחישים שליליים.
8. להכיר Swagger ו-OpenAPI.
9. להתחיל ללמוד JavaScript או Python לצורך אוטומציה.
10. לבנות פרויקט בדיקות API עצמאי ולהציג אותו בתיק עבודות.

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

17. שאלות נפוצות על בדיקות REST API

מה ההבדל בין בדיקות REST API לבדיקות UI?

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

האם צריך לדעת תכנות כדי לבצע בדיקות REST API?

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

האם Postman מספיק לבדיקות REST API?

Postman מתאים למגוון רחב של בדיקות ידניות ואוטומטיות. בפרויקטים מורכבים ניתן לשלב אותו עם Playwright, pytest, REST Assured וכלי CI/CD.

מה צריך לבדוק מלבד קוד HTTP?

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

מה ההבדל בין REST API ל-SOAP?

REST הוא סגנון ארכיטקטוני המשתמש לרוב ב-HTTP ובפורמטים כמו JSON. SOAP הוא פרוטוקול להעברת הודעות המשתמש בדרך כלל במבנה XML ומגדיר סטנדרטים נוספים לתקשורת בין מערכות.

האם REST API חייב להחזיר JSON?

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

מה זה Idempotency בבדיקות API?

Idempotency היא תכונה של פעולה שבה ביצוע אותה בקשה מספר פעמים מוביל לאותה תוצאה סופית מבחינת מצב המערכת, כמו בבקשת GET ובדרך כלל גם PUT ו-DELETE. ב-POST לא מובטחת תכונה זו, אלא אם הוגדר מנגנון מתאים כמו Idempotency Key.

מהו API Endpoint?

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

מה ההבדל בין 401 ל-403?

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

סיכום: בדיקות REST API הן מיומנות חיונית לכל איש QA

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

איש QA מקצועי צריך להכיר את שיטות HTTP, להבין קודי תגובה, לבדוק מבני JSON, לכתוב Test Cases איכותיים, לבצע בדיקות הרשאות, לזהות תרחישי קצה ולהכיר כלים כמו Postman, Swagger ו-Playwright.

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

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

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

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