בדיקות REST API עם Postman – הסבר

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

Unit Tests ו-Integration Tests הם דבר נהדר שיהיה, אך הם אינם מספיקים כדי לבדוק כל היבט של האפליקציה. יתרה מזאת, הם באחריותו של מפתח, לא של בודק QA.

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

מהו API ולמה אנחנו צריכים אותו?

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

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

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

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

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

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

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

ה-API משתמש בפרוטוקולים הידועים ביותר, כגון SOAP, REST ואחרים. SOAP (Simple Object Access Protocol) מבוסס על XML ומונחה פונקציות. REST (Representational State Transfer) מבוסס על HTML. הוא מארגן את הנתונים שלו ב-XML, YAML ו-JSON ומונחה נתונים. הוא תומך גם בפורמטים OpenAPI, Swagger ו-RAML. בקשות ה-REST HTTP הנפוצות ביותר הן POST, GET, PUT ו-DELETE.

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

בדיקת REST API עם Postman

API Testing משמש לאימות APIs שכן הוא בודק את הפונקציונליות, האמינות, הביצועים והאבטחה. API Testing מבוצע באמצעות ה-URL, אשר קורא ל-endpoint של ה-API. קריאות אלו נקראות Requests. לאחר שליחת Request, עלינו לצפות לקבל Response. לאחר מכן התגובה מושווית לתוצאות הצפויות.

בקשה מגיעה במגוון סוגים – GET, POST, PUT, PATCH, DELETE, COPY, HEAD, OPTIONS, LINK, UNLINK, PURGE, LOCK, UNLOCK, PROPFIND ו-VIEW. הנפוצים ביותר הם GET, POST, PUT, DELETE.

בקשת GET משמשת לקבלת הנתונים מה-URL המשותף (endpoint). לא מבוצעים שינויים ב-endpoint.

בקשת POST משמשת לשליחת הנתונים לנקודת הקצה.

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

בקשת DELETE משמשת למחיקת נתונים בנקודת הקצה.

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

קיימים כלים רבים המשמשים לבדיקות API – Katalon Studio, Postman, Apigee, JMeter, Rest-assured, Assertible, Soap UI, Karate DSL, Rest Console, API Fortress, Pyresttest, Hoppscotch, Taurus, Citrus Framework ו-Airborne, מבין היתר. לא נסביר כל אחד ואחד מהם, אולם לשם הדוגמה נתמקד ב-Postman.

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

בעזרת ה-Requests שנוצרו, תוכלו להשתמש ב-Parameters, Authorization, Headers, Body, Pre-request Script ו-Tests. אין צורך בכולם בכל Request, מכיוון שחלק מה-Requests אינם דורשים שכולם יהיו מלאים בנתונים.

ההתמקדות שלנו תהיה בתחום הבדיקות.

כנקודת התחלה, אנו משתמשים ב-Swagger כנקודת ציון של נקודות קצה זמינות ויוצרים Requests ב-Postman. לאחר הגדרת Request, אנו לוחצים על כפתור ה-"Send". עלינו לקבל את התגובה תוך זמן קצר. תגובה צריכה להכיל "Status: 200 OK" או קוד סטטוס דומה שמתחיל ב-"2". באזור ה-Body של התגובה, ברוב המקרים, צריכים להיות נתונים שהתקבלו מהשרת. נתונים אלה נבדקים באזור ה-Tests ב-Postman.

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

בדיקה בסיסית – בדיקת הסטטוס של תגובה היא:

pm.test("סטטוס תגובה", function () {
 pm.response.to.have.status(200);
 });

קיימות גם בדיקות הבודקות את אזור ה-Body:

pm.test("התגובה צריכה להכיל", function () {

pm.response.to.have.jsonBody(“[response_data0:]”);

pm.response.to.have.jsonBody(“[response_data1:]”);

pm.response.to.have.jsonBody(“[response_data2:]”);

});

בבדיקות אלו, ניתן להשתמש במשתנים כדי לאחסן את הנתונים שנאספו ולהשתמש בהם בבדיקה אחרת כקלט דינמי. משתנים או פרמטרים נשמרים בפורמט הבא: {{variable}}.

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

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

צינור CI/CD

לאחר הכנתם, ניתן להשתמש בבדיקות API גם בהמשך. אחת האפשרויות היא להשתמש בהן בצינור ה-CI/CD שלכם. מהו צינור CI/CD?

CI הוא ראשי תיבות של Continuous Integration (אינטגרציה רציפה). צינור CI/CD הוא סדרה של שלבים אוטומטיים לאספקת גרסת התוכנה העדכנית ביותר. לעיתים יש צורך לבצע שלבים מסוימים באופן ידני וזה גם אפשרי. הכוח האמיתי של צינור CI/CD הוא האוטומציה שלו. פרטים נוספים על צינור CI/CD ניתן למצוא בחומרי DevOps.

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

לאחר שנוודא שהכול פועל כשורה, נוכל לייצא את הנתונים מ-Postman – אמורים להיות לנו קבצי Collections.json ו-Environment.json.

כדי להריץ את Postman Collection.json ו-Environment.json, עלינו להתקין את Newman. Newman מעניק לנו את היכולת להשתמש בבדיקות Postman API בצינור ה-CI/CD.

כדי להתחיל, התקינו nodejs. לאחר מכן, בשורת הפקודה, הריצו "npm install -g newman”.

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

לאחר מכן, הריצו זאת עם Newman.

ניתן לעשות זאת עם ה-״newman run [collection name] -e [collection environment]” שבו “-e" מייצג את פרמטר הסביבה.

מלבד Newman, אנו יכולים להשתמש גם בכלים ל-CI/CD כמו TeamCity, Jenkins וכו'.

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

לכל הפרטים על אופן ההגדרה, אנא חפש מדריכים ייעודיים של Newman או Jenkins.

קודי תגובה נפוצים של שרת

קודי תגובת שרת עבור REST API נעים בין 100 ל-500. קיימים בהם "תת-קודים" כהסבר מפורט יותר, אך לא נעמיק עד כדי כך במאמר זה. לדוגמה, בסדרת 400, כולם מכירים את הקוד "404 – Not Found".

להלן סקירה כללית של הקודים:

1** – תגובות זמניות כמו "Continue", "Switching Protocols" ו-"Processing"

2** – תגובות חיוביות משרת כגון "OK", "Created", "Accepted" וכו'.

3** – הפניות מסוג Responses כמו "Multiple Choices", "Use Proxy", "Temporary Redirect" וכו'.

4** – סדרת Responses זו היא משהו שברוב המקרים החיוביים לא תרצו לראות, שכן חלקם הם "Bad Request", "Not Found", "Forbidden", "Unauthorised" וכו'.

5** – סדרה זו קשורה ספציפית לשגיאות בצד השרת – מהסוג שגם אתם לא רוצים לראות. חלק מהן הן ״Internal Server Error״, ״Not Implemented״, ״Bad Gateway״, ״Service Unavailable״, ״Network Authentication Required״ וכו׳.

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

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

מסקנה

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

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

פשוט אך יעיל.