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

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

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

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

1. מה זה Test Case בבדיקות API?

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

בבדיקות API, ה-Test Case מגדיר כיצד לשלוח בקשה לשרת וכיצד לוודא שהתגובה שהתקבלה תואמת לדרישות המערכת.

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

GET /api/users/123

בודק התוכנה צריך להגדיר מראש:

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

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

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

2. מהם השדות שחייבים להופיע ב-Test Case של API?

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

שדה	הסבר
Test Case ID	מזהה ייחודי לתרחיש הבדיקה
Test Case Title	שם ברור המתאר מה נבדק
Module	המודול או השירות הנבדק
Description	תיאור מטרת הבדיקה
Preconditions	תנאים מקדימים לביצוע
HTTP Method	סוג הבקשה: GET, POST, PUT, PATCH או DELETE
Endpoint	כתובת ה-API הנבדקת
Headers	כותרות הבקשה
Request Body	הנתונים הנשלחים בבקשה, אם קיימים
Test Data	נתוני הבדיקה
Test Steps	שלבי ביצוע הבדיקה
Expected Result	התוצאה הצפויה
Actual Result	התוצאה שהתקבלה בפועל
Status	Passed, Failed או Blocked
Priority	רמת החשיבות של הבדיקה

חשוב להבין שלא בכל Test Case חייבים למלא את כל השדות. למשל, בבקשת GET פשוטה ייתכן שלא יהיה Request Body, ובדיקת DELETE עשויה לדרוש בדיקה נוספת של מצב הנתונים לאחר המחיקה.

טיפ מקצועי: אל תסתפקו בשם כללי כמו "בדיקת API". כתבו כותרת שמסבירה בדיוק מה נבדק, למשל: "Verify that GET request returns user details for an existing user".

3. איך כותבים Test Case לבדיקת API? שלב אחר שלב

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

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

שלב ראשון: הבנת דרישות ה-API

קראו את מסמך הדרישות או את תיעוד ה-API, למשל Swagger או OpenAPI.

בדקו:

• מהי מטרת ה-Endpoint?
• אילו HTTP Methods נתמכים?
• אילו פרמטרים נדרשים?
• אילו שדות חובה קיימים?
• אילו שדות הם אופציונליים?
• האם נדרשת הזדהות?
• אילו קודי HTTP מוגדרים?
• מהו מבנה התגובה הצפוי?

לדוגמה:

Endpoint: POST /api/users

מטרת הפעולה: יצירת משתמש חדש.

שדות חובה:

• name
• email
• password

שדות אופציונליים:

• phone
• address

התנהגות צפויה:

• יצירת משתמש עם נתונים תקינים תחזיר 201 Created.
• כתובת דוא"ל לא תקינה תחזיר 400 Bad Request.
• ניסיון ליצור משתמש עם כתובת דוא"ל שכבר קיימת יטופל בהתאם לחוזה ה-API, למשל באמצעות 409 Conflict.

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

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

בדיקות חיוביות (Positive Testing)

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

דוגמאות:

• יצירת משתמש חדש עם כל שדות החובה.
• שליפת משתמש קיים.
• עדכון פרטי משתמש עם נתונים תקינים.
• מחיקת משתמש קיים.
• שליחת בקשה עם Token תקף.

בדיקות שליליות (Negative Testing)

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

דוגמאות:

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

בדיקות גבולות (Boundary Testing)

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

דוגמאות:

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

שלב שלישי: כתיבת תנאים מקדימים

Preconditions הם התנאים שחייבים להתקיים לפני ביצוע הבדיקה.

לדוגמה:

• המשתמש קיים במערכת.
• סביבת הבדיקות זמינה.
• קיים Token תקף.
• למשתמש יש הרשאה מתאימה.
• בסיס הנתונים מכיל את הנתונים הנדרשים לבדיקה.

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

שלב רביעי: הגדרת פעולות הבדיקה

יש לתעד בדיוק מה הבודק צריך לבצע.

לדוגמה:

1. פתיחת Postman.
2. בחירת HTTP Method מסוג GET.
3. הזנת כתובת ה-Endpoint.
4. הוספת Authorization Token.
5. שליחת הבקשה.
6. בדיקת קוד התגובה.
7. בדיקת מבנה ה-JSON.
8. השוואת הנתונים לתוצאה הצפויה.

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

שלב חמישי: הגדרת Expected Result

זהו אחד החלקים החשובים ביותר בכתיבת Test Case.

התוצאה הצפויה צריכה להיות מדידה ולא כללית.

לא מומלץ לכתוב:
"המערכת מחזירה תשובה תקינה".

עדיף לכתוב:

• HTTP Status Code: 200.
• Content-Type: application/json.
• שדה id מכיל את הערך 123.
• שדה email מכיל את כתובת הדוא"ל הצפויה.
• שדה name מכיל את שם המשתמש הנכון.
• התגובה עומדת במבנה שהוגדר ב-API Contract.
• זמן התגובה עומד בדרישה שהוגדרה, אם קיימת דרישה כזו.

4. דוגמה מעשית: כתיבת Test Case עבור API ליצירת משתמש

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

פרטי ה-API:

פרמטר	ערך
HTTP Method	POST
Endpoint	/api/users
Content-Type	application/json
Authentication	Bearer Token
שדות חובה	name, email, password
תגובה צפויה	201 Created

דוגמת Request Body:

{ "name": "David Cohen", "email": "david@example.com", "password": "Pass12345!" }

Test Case 1 – יצירת משתמש עם נתונים תקינים

שדה	פירוט
Test Case ID	API_TC_001
Title	Create user with valid data
Preconditions	Token תקף, כתובת דוא"ל שאינה קיימת
Method	POST
Endpoint	/api/users
Test Data	שם, דוא"ל וסיסמה תקינים
Expected Status	201 Created
Expected Result	משתמש חדש נוצר ומוחזר מזהה משתמש ייחודי

שלבי הבדיקה:

1. שליחת בקשת POST לכתובת /api/users.
2. הוספת Authorization Token תקף.
3. הוספת Content-Type: application/json.
4. שליחת נתוני משתמש תקינים.
5. בדיקת קוד התגובה.
6. בדיקת מבנה התגובה.
7. בדיקה שהמשתמש החדש אכן נשמר במערכת.

תוצאה צפויה:

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

Test Case 2 – יצירת משתמש ללא כתובת דוא"ל

שדה	פירוט
Test Case ID	API_TC_002
Title	Create user without email
Preconditions	סביבת הבדיקות זמינה
Method	POST
Endpoint	/api/users
Test Data	name ו-password ללא email
Expected Status	400 Bad Request
Expected Result	המערכת דוחה את הבקשה ומחזירה שגיאת ולידציה

שלבי הבדיקה:

1. שליחת בקשת POST.
2. הוספת שם וסיסמה תקינים.
3. השמטת שדה email.
4. שליחת הבקשה.
5. בדיקת קוד התגובה.
6. בדיקת הודעת השגיאה.
7. בדיקה שלא נוצר משתמש חדש.

תוצאה צפויה:

• מתקבל HTTP 400, בהתאם לחוזה ה-API.
• מתקבלת הודעת שגיאה שמציינת שהשדה email נדרש.
• לא נוצר משתמש חדש.
• לא נחשף מידע רגיש בתגובה.

Test Case 3 – יצירת משתמש עם כתובת דוא"ל קיימת

שדה	פירוט
Test Case ID	API_TC_003
Title	Create user with existing email
Preconditions	קיים משתמש עם אותה כתובת דוא"ל
Method	POST
Endpoint	/api/users
Test Data	כתובת דוא"ל שכבר קיימת
Expected Status	409 Conflict
Expected Result	יצירת המשתמש נדחית

שלבי הבדיקה:

1. יצירת משתמש עם כתובת דוא"ל מסוימת.
2. שליחת בקשה נוספת עם אותה כתובת דוא"ל.
3. בדיקת קוד התגובה.
4. בדיקת הודעת השגיאה.
5. בדיקה שלא נוצר משתמש כפול.

תוצאה צפויה:

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

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

5. אילו בדיקות נוספות חשוב להכניס ל-Test Case של API?

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

בדיקות HTTP Status Codes

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

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

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

בדיקות JSON Response

כאשר API מחזיר JSON, יש לבדוק:

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

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

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

בבדיקה חשוב לוודא:

• id הוא מספר.
• name הוא מחרוזת.
• email הוא כתובת תקינה.
• active הוא ערך Boolean.
• לא מוחזר שדה password.

בדיקות Authentication ו-Authorization

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

כדאי להגדיר Test Cases עבור המצבים הבאים:

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

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

זוהי בדיקה חשובה במיוחד למניעת בעיות הרשאות מסוג Broken Object Level Authorization (BOLA).

בדיקות פרמטרים ונתוני קצה

יש לבדוק כיצד ה-API מגיב לנתונים חריגים:

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

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

בדיקות Pagination ו-Sorting

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

דוגמאות:

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

6. דוגמה ל-Test Case עבור GET, PUT ו-DELETE

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

בדיקת GET – שליפת משתמש

Test Case ID: API_TC_004

מטרה: לוודא שניתן לשלוף פרטי משתמש קיים.

• Method: GET
• Endpoint: /api/users/123
• Preconditions: משתמש 123 קיים ו-Token תקף.
• Expected Status: 200 OK.

תוצאה צפויה:

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

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

בדיקת PUT – עדכון משתמש

Test Case ID: API_TC_005

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

• Method: PUT
• Endpoint: /api/users/123
• Preconditions: משתמש 123 קיים ו-Token בעל הרשאה מתאימה.
• Request Body: פרטי משתמש מעודכנים.
• Expected Status: בהתאם לחוזה, למשל 200 או 204.

תוצאה צפויה:

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

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

בדיקת DELETE – מחיקת משתמש

Test Case ID: API_TC_006

מטרה: לוודא שניתן למחוק משתמש קיים.

• Method: DELETE
• Endpoint: /api/users/123
• Preconditions: משתמש 123 קיים ו-Token בעל הרשאה מתאימה.
• Expected Status: בהתאם לחוזה, למשל 204.

תוצאה צפויה:

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

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

7. איך משתמשים ב-Postman לביצוע Test Cases?

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

אחד הכלים הנפוצים ביותר לבדיקות API הוא Postman.

<PRIVATE_PERSON>

תהליך העבודה הבסיסי:

1. פתיחת Postman.
2. יצירת Collection עבור המערכת הנבדקת.
3. יצירת Request חדש.
4. בחירת HTTP Method.
5. הזנת כתובת ה-Endpoint.
6. הגדרת Headers.
7. הגדרת Authorization.
8. הזנת Request Body במקרה הצורך.
9. שליחת הבקשה.
10. השוואת התגובה ל-Expected Result.

דוגמה לבדיקת API באמצעות Postman

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

GET https://example.com/api/users/123

נגדיר את הבקשה:

• Method: GET
• Authorization: Bearer Token
• Header: Accept: application/json

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

• Status Code.
• Response Time.
• Response Body.
• Response Headers.
• התאמה לדרישות הבדיקה.

ניתן גם להוסיף בדיקות אוטומטיות באמצעות JavaScript בלשונית Scripts של Postman.

דוגמה:

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

בדיקת שדה מזהה:

pm.test("User ID is correct", function () { const response = pm.response.json(); pm.expect(response.id).to.eql(123); });

בדיקת סוג הנתון:

pm.test("User name is a string", function () { const response = pm.response.json(); pm.expect(response.name).to.be.a("string"); });

בדיקות אלה מאפשרות להפוך חלק מה-Test Cases לבדיקות אוטומטיות שניתן להריץ שוב ושוב כחלק מתהליך Regression Testing.

8. איך מתעדים את תוצאות הבדיקה?

לאחר ביצוע ה-Test Case יש להשוות בין התוצאה בפועל לבין התוצאה הצפויה.

לדוגמה:

שדה	ערך
Test Case ID	API_TC_001
Expected Result	HTTP 201 ומשתמש חדש נוצר
Actual Result	HTTP 201 ומשתמש חדש נוצר
Status	Passed

דוגמה לתרחיש שנכשל:

שדה	ערך
Test Case ID	API_TC_002
Expected Result	HTTP 400
Actual Result	HTTP 500
Status	Failed

במקרה של כישלון, חשוב לתעד:

• כתובת ה-Endpoint.
• סוג הבקשה.
• נתוני הבקשה.
• קוד התגובה.
• גוף התגובה.
• Headers רלוונטיים.
• צילום מסך או קובץ לוג, במידת הצורך.
• תאריך ושעת ביצוע.
• סביבת הבדיקות.
• מזהה גרסה או Build.

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

9. טעויות נפוצות בכתיבת Test Case לבדיקות API

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

אלה הטעויות שכדאי להימנע מהן:

1. בדיקת Status Code בלבד

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

2. כתיבת Expected Result כללי מדי

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

3. התעלמות מתרחישים שליליים

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

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

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

5. אי בדיקת השפעת הפעולה על המערכת

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

6. התעלמות מהרשאות ואבטחת מידע

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

7. כתיבת תרחישים כפולים

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

10. איך בודקים אם כיסוי ה-Test Cases מספיק טוב?

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

אפשר להשתמש בטבלת Traceability פשוטה:

דרישה	Test Case	כיסוי
יצירת משתמש	API_TC_001	חיובי
שדה דוא"ל חובה	API_TC_002	שלילי
מניעת משתמש כפול	API_TC_003	שלילי
שליפת משתמש	API_TC_004	חיובי
עדכון משתמש	API_TC_005	חיובי
מחיקת משתמש	API_TC_006	חיובי
הרשאות גישה	API_TC_007	אבטחה
נתונים לא תקינים	API_TC_008	ולידציה

מומלץ לבדוק גם:

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

11. מה ההבדל בין Test Case ידני לבדיקת API אוטומטית?

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

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

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

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

12. צ'קליסט מקצועי לפני אישור Test Case של API

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

• האם מטרת הבדיקה ברורה?
• האם ה-Endpoint נכון?
• האם נבחר HTTP Method מתאים?
• האם כל ה-Headers הנדרשים מוגדרים?
• האם הוגדרו תנאים מקדימים?
• האם נתוני הבדיקה מתאימים לתרחיש?
• האם הוגדר Expected Status Code?
• האם נבדק תוכן התגובה?
• האם נבדקו סוגי הנתונים?
• האם נבדקו שדות חובה?
• האם נבדקו תרחישים שליליים?
• האם נבדקו הרשאות?
• האם נבדקה השפעת הפעולה על הנתונים?
• האם ניתן לשחזר את הבדיקה?
• האם הבדיקה קשורה לדרישה מוגדרת?

סיכום: Test Case איכותי הוא הבסיס לבדיקות API מקצועיות

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

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

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

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

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

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

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

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