בדיקות API לבודקי תוכנה וממשקים

פורסם ע"יdinraפורסם בUncategorizedתגים: , , , , , , , , ,

בדיקות API – המדריך המלא: איך בודקים ממשקי API, אילו תרחישים חשוב לבדוק ואיך מתחילים?

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

API Testing REST API Postman Automation
מהן בדיקות API בקצרה?

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

תוכן עניינים – כל הנושאים במדריך

1. מה זה API ואיך הוא עובד?

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

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

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

איך נראית תקשורת באמצעות API?
1. המשתמש / אפליקציה
מבקש להציג מידע או לבצע פעולה
↓ HTTP Request
2. API Endpoint
מקבל את הבקשה ומעביר אותה לעיבוד
↓
3. שרת / Database / שירות עסקי
מבצע את הפעולה ומחזיר תוצאה
↓ HTTP Response
4. האפליקציה מקבלת תשובה
מציגה את המידע או הודעת שגיאה

תהליך התקשורת כולל בדרך כלל שני מרכיבים מרכזיים:

  • Request – בקשה: המידע שנשלח מהלקוח לשרת, כולל כתובת, שיטת HTTP, כותרות ונתונים.
  • Response – תגובה: התשובה שמחזיר השרת, כולל קוד סטטוס, כותרות וגוף התגובה.

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

2. למה חשוב לבצע בדיקות API?

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

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

בדיקת API יכולה לחשוף בעיות כאלה באופן ישיר.

אמינות נתונים

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

זיהוי תקלות מוקדם

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

אבטחת מידע

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

אינטגרציה בין מערכות

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

היתרונות המרכזיים של בדיקות API

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

3. סוגי ממשקי API וטכנולוגיות נפוצות

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

REST API

REST הוא סגנון ארכיטקטוני נפוץ מאוד לפיתוח ממשקי API. הוא מבוסס בדרך כלל על פרוטוקול HTTP, ומשתמש בשיטות כמו GET, POST, PUT, PATCH ו-DELETE.

בממשקי REST, המשאבים מזוהים באמצעות כתובות URL. לדוגמה:

הכתובת מתייחסת למשתמש שמזהה הרשומה שלו הוא 123.

SOAP API

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

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

GraphQL

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

בבדיקות GraphQL חשוב לבדוק את תקינות השאילתות, את שדות התגובה, את הרשאות הגישה לשדות ואת אופן הטיפול בשגיאות.

WebSocket API

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

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

סוג API מאפיין מרכזי שימוש נפוץ
RESTתקשורת מבוססת HTTP ומשאביםאתרים ואפליקציות
SOAPהודעות XML מובנותמערכות ארגוניות
GraphQLשאילתות גמישותמערכות עם מבני מידע מורכבים
WebSocketתקשורת דו-כיוונית מתמשכתצ'אט ועדכונים בזמן אמת

4. HTTP Methods – סוגי הבקשות בבדיקות API

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

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

מה חשוב לבדוק בכל שיטה?

GET: האם הנתונים שחזרו נכונים? האם ניתן לשלוף רשומה קיימת? מה קורה כאשר מזהה אינו קיים? האם הפרמטרים לסינון ולמיון עובדים כראוי?

POST: האם נוצרת רשומה חדשה? האם מתקבל מזהה ייחודי? האם הנתונים נשמרים בפועל? האם בקשה כפולה עלולה ליצור רשומות כפולות?

PUT: האם העדכון המלא מתבצע כראוי? האם שדות שלא נשלחו מטופלים בהתאם לחוזה הממשק? האם ניתן לעדכן רשומה שאינה קיימת?

PATCH: האם רק השדות המבוקשים משתנים? האם יתר השדות נשארים ללא שינוי?

DELETE: האם הרשומה נמחקת או עוברת למצב מחוק בהתאם לדרישות? האם ניתן למחוק אותה שוב? האם משתמש לא מורשה יכול לבצע מחיקה?

נקודה חשובה לבודקים:

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

5. קודי HTTP – מה צריך לבדוק בתשובת השרת?

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

קבוצת 2xx – הצלחה

  • 200 OK: הבקשה הצליחה.
  • 201 Created: משאב חדש נוצר בהצלחה.
  • 202 Accepted: הבקשה התקבלה לעיבוד, אך העיבוד עדיין לא בהכרח הושלם.
  • 204 No Content: הבקשה הצליחה ללא גוף תגובה.

קבוצת 3xx – הפניה

  • 301 Moved Permanently: המשאב הועבר באופן קבוע.
  • 302 Found: הפניה זמנית.
  • 304 Not Modified: ניתן להשתמש בגרסה השמורה במטמון בהתאם לתנאי הבקשה.

קבוצת 4xx – שגיאת בקשה או לקוח

  • 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: נשלחו יותר מדי בקשות בפרק זמן מסוים.

קבוצת 5xx – שגיאת שרת

  • 500 Internal Server Error: שגיאה פנימית בשרת.
  • 502 Bad Gateway: שרת ביניים קיבל תשובה לא תקינה משרת אחר.
  • 503 Service Unavailable: השירות אינו זמין כרגע.
  • 504 Gateway Timeout: שרת ביניים לא קיבל תשובה בזמן.

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

6. סוגי בדיקות API

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

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

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

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

Positive Testing – בדיקות חיוביות

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

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

Negative Testing – בדיקות שליליות

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

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

Boundary Testing – בדיקות גבולות

בדיקות שמתמקדות בערכים בקצוות הטווחים המותרים.

אם מערכת מאפשרת להזמין בין מוצר אחד ל-100 מוצרים, יש לבדוק את הערכים 0, 1, 2, 99, 100 ו-101 בהתאם לדרישות.

Schema Validation – בדיקת מבנה התגובה

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

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

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

Contract Testing – בדיקות חוזה

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

Regression Testing – בדיקות נסיגה

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

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

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

Performance Testing – בדיקות ביצועים

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

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

7. איך מבצעים בדיקות API שלב אחר שלב?

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

שלב 1 – הבנת הדרישות העסקיות

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

שלב 2 – לימוד תיעוד ה-API

בודקים את רשימת ה-Endpoints, שיטות HTTP, פרמטרים, כותרות, סוגי נתונים, הרשאות וקודי תגובה אפשריים.

שלב 3 – הכנת סביבת הבדיקות

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

שלב 4 – בניית תרחישי בדיקה

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

שלב 5 – ביצוע הבדיקות

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

שלב 6 – תיעוד תקלות

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

שלב 7 – בדיקות חוזרות ו-Regression

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

8. דוגמאות מעשיות לתרחישי בדיקות API

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

דוגמה 1 – שליפת משתמש באמצעות GET

GET /api/users/123 Host: api.example.com Accept: application/json Authorization: Bearer YOUR_TOKEN

דוגמה לתגובה תקינה:

{ "id": 123, "name": "David Cohen", "email": "david@example.com", "active": true }

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

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

דוגמה 2 – יצירת משתמש באמצעות POST

נשלחת בקשה ליצירת משתמש חדש:

POST /api/users Content-Type: application/json { "name": "David Cohen", "email": "david@example.com", "role": "customer" }

תרחישי הבדיקה האפשריים:

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

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

דוגמה 3 – עדכון משתמש באמצעות PATCH

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

PATCH /api/users/123 Content-Type: application/json { "email": "newemail@example.com" }

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

דוגמה 4 – בדיקת מחיקת משתמש

DELETE /api/users/123

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

דוגמה 5 – בדיקת Pagination

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

GET /api/products?page=2&limit=10

תרחישי בדיקה:

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

דוגמה 6 – בדיקת סינון ומיון

GET /api/products?category=electronics&sort=price

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

9. בדיקות API באמצעות Postman

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

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

איך מבצעים בדיקת API ב-Postman?

  1. פותחים בקשה חדשה.
  2. בוחרים את שיטת HTTP המתאימה, למשל GET או POST.
  3. מזינים את כתובת ה-Endpoint.
  4. מגדירים Headers בהתאם לדרישות.
  5. מוסיפים Authorization אם נדרש.
  6. בבקשות הכוללות נתונים, מגדירים Body בפורמט המתאים.
  7. שולחים את הבקשה באמצעות Send.
  8. בודקים את קוד התגובה, גוף התגובה, הכותרות וזמן התגובה.
  9. מוסיפים Assertions כדי לאמת את התוצאה באופן אוטומטי.

דוגמה לבדיקות אוטומטיות ב-Postman

אפשר לכתוב בדיקות JavaScript באזור Tests או Scripts של הבקשה:

pm.test("Status code is 200", function () { pm.response.to.have.status(200); }); pm.test("Response contains user ID", function () { const data = pm.response.json(); pm.expect(data.id).to.eql(123); }); pm.test("Response contains email", function () { const data = pm.response.json(); pm.expect(data).to.have.property("email"); }); pm.test("Response time is acceptable", function () { pm.expect(pm.response.responseTime).to.be.below(2000); });

בדוגמה זו מתבצעות ארבע בדיקות:

  • בדיקת קוד HTTP.
  • בדיקת מזהה המשתמש.
  • בדיקת קיום שדה email.
  • בדיקת זמן תגובה מתחת לשתי שניות.

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

עבודה עם Collections ו-Environments

Postman מאפשר לארגן בקשות בקבוצות הנקראות Collections. ניתן להגדיר Environment Variables כגון כתובת שרת, מזהה משתמש ו-Access Token, וכך להריץ את אותן בדיקות מול סביבות שונות.

לדוגמה:

{{baseUrl}}/api/users/{{userId}}

כך ניתן להחליף בין סביבת QA, סביבת Staging וסביבת Production בלי לשנות את כל כתובות הבקשות באופן ידני.

10. אוטומציה לבדיקות API

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

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

כלים נפוצים לאוטומציה של בדיקות API

כלי שימוש מרכזי למי מתאים?
Postmanבדיקות ידניות ואוטומטיותמתחילים ומנוסים
Playwrightבדיקות API ו-UIבודקי אוטומציה
REST Assuredבדיקות REST באמצעות Javaמפתחי ובודקי Java
Newmanהרצת Collections של Postman משורת הפקודהאוטומציה ו-CI/CD
Karateבדיקות API באמצעות DSL ייעודיצוותי QA ופיתוח
pytest + requestsבדיקות API באמצעות Pythonבודקי Python

מה כדאי להפוך לאוטומטי?

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

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

11. בדיקות API באמצעות Playwright

Playwright מוכר בעיקר ככלי לאוטומציה של בדיקות ממשק משתמש, אך הוא כולל גם יכולות לביצוע בדיקות API באמצעות APIRequestContext.

באמצעות Playwright ניתן לשלוח בקשות HTTP, לבדוק את התגובות, לבצע Assertions, לעבוד עם נתונים ולשלב בדיקות API בתוך תהליכי בדיקה רחבים יותר.

דוגמה לבדיקת API ב-Playwright

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

import { test, expect } from '@playwright/test'; test('Get user API', async ({ request }) => { const response = await request.get( 'https://api.example.com/users/123' ); expect(response.status()).toBe(200); const data = await response.json(); expect(data.id).toBe(123); expect(data).toHaveProperty('email'); });

מה מתבצע בקוד?

  • נשלחת בקשת GET לכתובת ה-API.
  • נבדק שקוד התגובה הוא 200.
  • מתבצעת קריאה של גוף התגובה בפורמט JSON.
  • נבדק שמזהה המשתמש הוא 123.
  • נבדק שקיים שדה email.

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

import { test, expect } from '@playwright/test'; test('Create user API', async ({ request }) => { const response = await request.post( 'https://api.example.com/users', { data: { name: 'David Cohen', email: 'david@example.com' } } ); expect(response.status()).toBe(201); const data = await response.json(); expect(data.name).toBe('David Cohen'); expect(data.email).toBe('david@example.com'); expect(data.id).toBeTruthy(); });

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

בדיקת API כחלק מתהליך E2E

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

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

להעמקה בנושא, מומלץ לקרוא את המדריך בדיקות API עם Playwright – מדריך מעשי לאוטומציה.

12. בדיקות אבטחה והרשאות API

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

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

Authentication – אימות משתמשים

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

יש לבדוק:

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

Authorization – הרשאות גישה

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

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

בדיקות IDOR ו-BOLA

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

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

GET /api/orders/1001

בודקים האם שינוי המזהה ל-1002 מאפשר גישה להזמנה שאינה שייכת לאותו משתמש.

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

בדיקות אבטחה נוספות

  • חשיפת סיסמאות, Tokens או מידע אישי בתגובות.
  • בדיקת הרשאות לפי תפקיד המשתמש.
  • בדיקת הגבלת קצב בקשות (Rate Limiting).
  • בדיקת קלטים חריגים ונתונים לא צפויים.
  • בדיקת מנגנוני אימות והרשאות מול שירותים חיצוניים.
  • בדיקת CORS כאשר הממשק נצרך מדפדפנים.
  • בדיקת טיפול בשגיאות ללא חשיפת Stack Traces או פרטים פנימיים.
  • בדיקת הגנה מפני שימוש לא מורשה במשאבים.

מסגרת מקצועית מוכרת בתחום היא OWASP API Security Top 10, שמציגה סיכוני אבטחה מרכזיים בממשקי API.

13. בדיקות ביצועים ועומסים לממשקי API

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

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

אילו מדדים חשוב לבדוק?

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

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

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

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

במהלך הבדיקה נמדוד:

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

כלים לבדיקות עומסים של API

כלים כמו JMeter ו-k6 מאפשרים לשלוח מספר רב של בקשות API ולבחון את התנהגות המערכת תחת עומס.

לקריאה נוספת:

14. תיעוד API ו-OpenAPI – למה זה חשוב לבודק?

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

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

מהו OpenAPI?

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

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

קישור: OpenAPI Initiative.

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

  • רשימת כל ה-Endpoints.
  • שיטת HTTP לכל Endpoint.
  • שדות חובה ושדות רשות.
  • סוגי נתונים ומגבלות.
  • מבנה Request ו-Response.
  • קודי שגיאה אפשריים.
  • מנגנוני Authentication ו-Authorization.
  • כללי Pagination, Sorting ו-Filtering.
  • תלות בין שירותים וממשקים.

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

15. טעויות נפוצות בבדיקות API

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

טעות מה הבעיה? מה כדאי לעשות?
בדיקת Status בלבדהתגובה יכולה להיות שגויה למרות קוד תקיןלבדוק גם את גוף התגובה
בדיקת נתונים תקינים בלבדתקלות רבות מתגלות רק בקלט חריגלהוסיף Negative Testing
התעלמות מהרשאותגישה לא מורשית למידעלבדוק משתמשים ותפקידים שונים
בדיקת Endpoint בודדתקלות באינטגרציה לא מתגלותלבדוק תהליכים מקצה לקצה
התעלמות מ-Response Timeממשק יכול להיות תקין אך איטילהגדיר דרישות ביצועים
נתוני בדיקה לא מבוקריםתוצאות לא עקביות בין הרצותלנהל נתוני בדיקה ולנקות אותם
היעדר בדיקות חוזרותתיקון עלול ליצור תקלות חדשותלבנות Regression Suite

16. צ'קליסט מלא לבדיקות API

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

צ'קליסט בדיקות API מקצועי

בדיקות פונקציונליות

  • בדיקת GET לשליפת נתונים.
  • בדיקת POST ליצירת נתונים.
  • בדיקת PUT ו-PATCH לעדכון.
  • בדיקת DELETE למחיקה.
  • בדיקת תוצאות מול הדרישות העסקיות.

בדיקות נתונים

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

בדיקות HTTP

  • בדיקת Status Codes.
  • בדיקת Headers.
  • בדיקת Content-Type.
  • בדיקת מבנה Response.
  • בדיקת טיפול בשגיאות.

בדיקות אבטחה

  • בדיקת משתמש ללא הרשאה.
  • בדיקת Token לא תקין.
  • בדיקת Token שפג תוקפו.
  • בדיקת גישה לנתוני משתמש אחר.
  • בדיקת חשיפת מידע רגיש.

בדיקות אינטגרציה וביצועים

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

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

  • בדיקת Assertions.
  • בדיקת Schema.
  • בדיקת נתונים דינמיים.
  • בדיקת הרצה חוזרת.
  • שילוב בדיקות בתהליך CI/CD.

17. איך מתחילים לעבוד בתחום בדיקות API?

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

שלב ראשון – הבנת יסודות HTTP

לומדים מהן בקשות ותגובות, מה ההבדל בין GET ל-POST, מה משמעות קודי HTTP וכיצד מועברים נתונים בין לקוח לשרת.

שלב שני – עבודה עם JSON

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

שלב שלישי – תרגול ב-Postman

מתחילים עם בקשות GET ו-POST, ממשיכים לעדכון ומחיקה, לומדים לעבוד עם Headers, Tokens ו-Environment Variables.

שלב רביעי – כתיבת תרחישי בדיקה

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

שלב חמישי – לימוד אוטומציה

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

שלב שישי – בניית תיק עבודות

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

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

18. שאלות ותשובות נפוצות בנושא בדיקות API

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

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

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

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

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

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

איזה כלי הכי מתאים לבדיקות API?

Postman הוא נקודת התחלה נוחה לבדיקות ידניות ואוטומטיות. Playwright מתאים לבדיקות API בקוד ולשילוב עם בדיקות UI, REST Assured מתאים לסביבות Java, ו-Karate מציע דרך נוספת לכתיבת בדיקות API.

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

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

מה זה Endpoint?

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

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

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

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

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

האם בדיקות API מחליפות בדיקות UI?

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

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

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

מה כדאי ללמוד אחרי Postman?

מומלץ ללמוד כתיבת בדיקות אוטומטיות באמצעות JavaScript או Python, להכיר Playwright או REST Assured, ולהעמיק בנושאי Authentication, Contract Testing, אינטגרציה ו-CI/CD.

סיכום: בדיקות API הן מיומנות מרכזית בעולם ה-QA

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

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

הדרך הנכונה להתחיל היא ללמוד את יסודות HTTP ו-JSON, להתנסות בבדיקות ידניות באמצעות Postman, ובהמשך להרחיב את הידע לאוטומציה באמצעות Playwright, Python או כלים נוספים.

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

ממשיכים ללמוד ולהעמיק בתחום ה-QA

ב-TESQA תמצאו מדריכים מעשיים לבדיקות תוכנה ידניות ואוטומטיות, בדיקות API, Playwright, בדיקות ביצועים, עומסים וכלים מקצועיים לעולם ה-QA.

לכל מדריכי TESQA

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

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

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

להשאיר תגובה