שאלות API ו־Postman בראיון QA: להבין את המערכת מעבר למסך

מפת המושגים שחייבים להבין

Methods נפוצים

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

Status codes שכדאי להכיר

200 להצלחה כללית, 201 ליצירת משאב, 204 להצלחה ללא body, 400 לבקשה לא תקינה, 401 כשאין authentication תקין, 403 כשהזהות ידועה אך הפעולה אסורה, 404 כשמשאב לא נמצא, 409 להתנגשות מצב, 422 לנתונים שלא עוברים validation לפי חוזים מסוימים, 429 להגבלת קצב ו־500 לשגיאה פנימית. תמיד בודקים את החוזה של המערכת, לא רק הגדרה כללית.

שאלות API נפוצות בראיון

איך חושבים על בדיקות חיוביות ושליליות?

ל־POST שיוצר משתמש אפשר לבנות קבוצות:

• בקשה תקינה עם כל שדות החובה.
• שדה חובה חסר, null או מחרוזת ריקה.
• אימייל בפורמט שגוי וערכי גבול לאורך.
• משתמש שכבר קיים ותרחיש מקביל של שתי בקשות.
• Content-Type שגוי או JSON פגום.
• token חסר, פג תוקף או בעל role לא מתאים.
• שדה נוסף שאינו מוגדר בחוזה.
• תווים בשפות שונות, Unicode וקלט שעלול להשפיע על אבטחה.

מה צריך לדעת לעשות ב־Postman

Collection ו־Environment

Collection מארגנת requests, scripts ותיעוד. Environment מחזיק ערכים שמשתנים בין סביבות, כגון baseUrl. אל תשמרו סיסמאות או tokens אמיתיים במאגר ציבורי. השתמשו ב־current value מקומי או במנגנון secrets מתאים.

בדיקה בסיסית לתגובה

pm.test('status is 201', () => {
  pm.response.to.have.status(201);
});

pm.test('created user has an id and email', () => {
  const body = pm.response.json();
  pm.expect(body.id).to.be.a('string').and.not.empty;
  pm.expect(body.email).to.eql(pm.variables.get('email'));
});

pm.test('response is JSON', () => {
  pm.expect(pm.response.headers.get('Content-Type')).to.include('application/json');
});

שמירת ערך לבקשה הבאה

const body = pm.response.json();
pm.collectionVariables.set('userId', body.id);

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

Pre-request script לנתון ייחודי

const suffix = Date.now();
pm.collectionVariables.set('email', 'qa+' + suffix + '@example.com');

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

הרצת Collection

אפשר להריץ collection דרך Collection Runner, Postman CLI או Newman, להזין קובץ נתונים ולשלב את הבדיקות ב־CI. ודאו שההרצה נכשלת באמת כאשר test נכשל ושאין תלות בסדר שאינה מתועדת.

תרגיל ראיון: API ליצירת הזמנה

נניח שהחוזה הוא:

POST /api/orders
Authorization: Bearer <token>
Content-Type: application/json

{
  "productId": "p-101",
  "quantity": 2,
  "coupon": "QA10"
}

בנו את התשובה בראיון בסדר הבא:

טעויות נפוצות בראיון API

• להציג רשימת status codes בלי לחבר אותם לתרחיש.
• לבדוק רק response ולהתעלם ממה שנשמר או הופעל מאחור.
• לבלבל בין authentication להרשאה.
• לשכוח תרחישים מקבילים, retry ופעולה כפולה.
• להדפיס token, סיסמה או מידע אישי ל־console ולדוח.
• ליצור collection שתלויה בנתון שנשאר מהרצה קודמת.
• לקרוא לכל 4xx "באג" בלי לבדוק את החוזה.
• להגיד ש־Postman הוא סוג הבדיקה. Postman הוא כלי, והבדיקה היא ההחלטה והאימות.

כדי לחבר API לפרויקט מלא, עברו למדריך פרויקט Playwright לתיק עבודות ולמדריך שאלות ראיון QA.

שאלות נפוצות

מקורות רשמיים

• Postman Docs: יצירת collection וכתיבת test
• Postman Docs: בדיקות אינטגרציה ו־environments