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

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

במדריך זה נלמד:

• מהו API
• מהו REST API
• כיצד משתמשים ב-Postman
• כיצד לקרוא JSON ו-XML
• כיצד לבצע Response Validation
• אילו בדיקות חשוב לבצע
• טעויות נפוצות
• טיפים לעבודה מקצועית

מהו API?

API (Application Programming Interface) הוא ממשק המאפשר לשתי מערכות תוכנה לתקשר זו עם זו.

לדוגמה:

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

המשתמש אינו רואה את התקשורת עצמה – היא מתבצעת באמצעות API.

למה בכלל לבדוק API?

בדיקות API מציעות מספר יתרונות משמעותיים:

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

מהו REST API?

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

כל בקשה מורכבת מ:

• URL
• HTTP Method
• Headers
• Body (במידת הצורך)

לדוגמה:

GET /users/15

HTTP Methods

GET

מחזיר מידע.

GET /users

POST

יוצר רשומה חדשה.

POST /users

PUT

מעדכן אובייקט קיים.

PUT /users/15

PATCH

מעדכן חלק מהשדות בלבד.

DELETE

מוחק אובייקט.

Status Codes

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

Postman

Postman הוא הכלי הפופולרי ביותר לבדיקות API.

באמצעותו ניתן:

• לשלוח בקשות
• לשמור Collections
• ליצור Environment
• לכתוב Tests
• לבצע Automation
• לנהל Authentication
• ליצור Mock Servers
• להריץ Collection Runner

יצירת בקשה ראשונה

לדוגמה:

GET
https://api.company.com/users

נלחץ Send.

נקבל Response.

Headers

דוגמה:

Authorization:
Bearer Token

Content-Type:
application/json

Authentication

סוגים נפוצים:

Basic Auth

Bearer Token

OAuth

API Key

JWT

Parameters

דוגמה:

/users?id=15

Path Parameters

/users/15

Request Body

בדוגמה של POST:

{
   "name":"David",
   "age":32,
   "city":"Tel Aviv"
}

JSON

זהו פורמט הנתונים הנפוץ ביותר כיום.

דוגמה:

{
   "id":15,
   "name":"David",
   "age":32,
   "active":true
}

סוגי נתונים ב-JSON

• String
• Number
• Boolean
• Null
• Object
• Array

JSON Object

{
  "employee":{
      "name":"Dan",
      "salary":12000
  }
}

JSON Array

{
   "employees":[
      {
         "id":1
      },
      {
         "id":2
      }
   ]
}

XML

למרות שרוב המערכות משתמשות כיום ב-JSON, עדיין קיימות מערכות רבות (במיוחד מערכות Legacy ו-SOAP) המשתמשות ב-XML.

דוגמה:

<employee>
   <name>David</name>
   <salary>12000</salary>
</employee>

JSON לעומת XML

Response Validation

זהו לב ליבן של בדיקות API.

אין להסתפק בכך שהתקבלה תשובה – יש לוודא שהתשובה נכונה.

יש לאמת:

• Status Code
• Headers
• Response Time
• Body
• Schema
• Business Logic
• Data Types
• Error Messages

בדיקת Status Code

לדוגמה:

Expected:
200

המערכת החזירה:

404

הבדיקה נכשלת.

בדיקת Response Time

לדוגמה:

Expected:
< 1000 ms

בדיקת Headers

לדוגמה:

Content-Type
application/json

בדיקת Body

{
   "status":"SUCCESS"
}

יש לוודא שהשדה אכן מחזיר SUCCESS כאשר הפעולה הצליחה.

בדיקות Business Logic

דוגמה:

נוצר משתמש חדש.

יש לוודא:

• המשתמש נשמר במסד הנתונים.
• ניתן להתחבר איתו.
• ניתן לשלוף אותו.
• המידע תואם למה שנשלח.

Positive Testing

בודקים קלט תקין.

Negative Testing

בודקים קלט שגוי.

לדוגמה:

• גיל שלילי
• אימייל לא תקין
• שדה חובה חסר
• מספר טלפון לא חוקי

Boundary Testing

לדוגמה:

אם מותר להזין גיל בין 18 ל-65:

נבדוק:

17

18

19

64

65

66

Error Handling

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

• Stack Trace
• SQL Queries
• Passwords
• Tokens

כתיבת Assertions ב-Postman

דוגמה:

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

בדיקת ערך מתוך JSON:

pm.test("User Name", function () {
    var json = pm.response.json();
    pm.expect(json.name).to.eql("David");
});

בדיקות Schema

יש לוודא שמבנה ה-JSON תואם למפרט.

לדוגמה:

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

טעויות נפוצות של בודקי API

• בדיקת Status Code בלבד.
• אי-בדיקת תוכן ה-Response.
• התעלמות מתרחישי שגיאה.
• שימוש בנתוני בדיקה קבועים.
• אי-בדיקת הרשאות.
• חוסר בדיקות גבול.
• התעלמות מזמני תגובה.

Best Practices

• השתמשו ב-Collections מסודרים.
• עבדו עם Environments.
• כתבו Assertions לכל בקשה.
• צרו נתוני בדיקה ייחודיים.
• בצעו בדיקות חיוביות ושליליות.
• שמרו על תיעוד ברור.
• שלבו את הבדיקות ב-CI/CD.
• השתמשו במשתנים (Variables) במקום ערכים קשיחים.
• בצעו בדיקות חוזרות לאחר כל שינוי ב-API.

סיכום

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

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

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

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

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