API Testing چیست؟ راهنمای جامع تست API برای تسترهای نرم‌افزار

در دنیای نرم‌افزارهای امروزی، بخش زیادی از قابلیت‌های یک Application در پشت رابط کاربری و در لایه‌های Backend اجرا می‌شود. کاربران ممکن است فقط یک صفحه وب یا اپلیکیشن موبایل را ببینند، اما در پشت صحنه، سرویس‌های مختلف از طریق API با یکدیگر ارتباط برقرار می‌کنند. 🌐

به همین دلیل، تست کردن فقط رابط کاربری نمی‌تواند کیفیت یک نرم‌افزار را به‌طور کامل تضمین کند. Tester باید بتواند رفتار APIها، داده‌های ورودی و خروجی، خطاها، دسترسی‌ها و نحوه ارتباط سرویس‌های مختلف را نیز بررسی کند.

API Testing یکی از مهم‌ترین مهارت‌هایی است که یک Tester می‌تواند برای درک بهتر Backend و حرکت به سمت Test Automation یاد بگیرد. این نوع Testing هم برای Manual Testerها کاربرد دارد و هم یکی از پایه‌های مهم API Automation و تست سیستم‌های مدرن مانند Microservices محسوب می‌شود. 🚀

در این مقاله ابتدا با مفهوم API و نحوه کار آن آشنا می‌شویم، سپس مهم‌ترین روش‌ها و تکنیک‌های API Testing، ابزارهای مورد استفاده، سناریوهای تست، Authentication و Authorization، API Testing در Microservices و در نهایت مسیر ورود به API Automation را بررسی می‌کنیم.

API Testing چیست؟ 🧪

API Testing یکی از مهم‌ترین بخش‌های تست نرم‌افزار است که در آن رفتار و عملکرد Application Programming Interface (API) بررسی می‌شود.

در یک سیستم نرم‌افزاری، API نقش واسط بین بخش‌های مختلف سیستم را ایفا می‌کند. برای مثال، یک برنامه موبایل یا وب‌سایت ممکن است برای دریافت اطلاعات، ثبت سفارش، ورود کاربر یا پرداخت، با APIهای Backend ارتباط برقرار کند.

در API Testing به‌جای تمرکز صرف بر رابط کاربری (UI)، مستقیماً Requestهایی را به API ارسال می‌کنیم و Response دریافتی را از جنبه‌های مختلف بررسی می‌کنیم.

این بررسی می‌تواند شامل Status Code، ساختار Response، داده‌های برگشتی، Business Ruleها، مدیریت خطا، Authentication، Authorization، Performance و Security باشد.

API چه کاری انجام می‌دهد؟ 🔗

برای درک بهتر API Testing، ابتدا باید بدانیم API چه نقشی در یک سیستم نرم‌افزاری دارد.

فرض کنید کاربر در یک فروشگاه اینترنتی محصولی را به سبد خرید خود اضافه می‌کند. رابط کاربری اطلاعات موردنیاز را از کاربر دریافت کرده و آن را از طریق API به Backend ارسال می‌کند.

به‌صورت ساده می‌توان این جریان را چنین تصور کرد:

User
  ↓
Web / Mobile Application
  ↓
API
  ↓
Backend / Database
  ↓
Response
  ↓
Web / Mobile Application

API در این میان وظیفه دارد درخواست را دریافت کند، آن را پردازش کرده و نتیجه مناسب را برگرداند.

API Testing دقیقاً چه چیزی را بررسی می‌کند؟ 🔍

در API Testing سؤال اصلی فقط این نیست که آیا API پاسخ می‌دهد یا خیر.

Tester باید بررسی کند که آیا API رفتار مورد انتظار را در شرایط مختلف دارد یا خیر.

• آیا Request به‌درستی پردازش می‌شود؟
• آیا Status Code صحیح برگردانده می‌شود؟
• آیا Response Structure مطابق Contract است؟
• آیا داده‌های برگشتی صحیح هستند؟
• آیا Validation به‌درستی انجام می‌شود؟
• آیا خطاها به شکل مناسب مدیریت می‌شوند؟
• آیا کاربر فقط به منابع مجاز دسترسی دارد؟
• آیا API در شرایط غیرعادی نیز رفتار مناسبی دارد؟

بنابراین API Testing را می‌توان یک بررسی چندلایه دانست که از صحت عملکرد API شروع می‌شود و می‌تواند تا امنیت، کارایی، پایداری و قابلیت اطمینان آن ادامه پیدا کند.

یک مثال ساده از API Testing 🧩

فرض کنید API زیر برای دریافت اطلاعات یک کاربر استفاده می‌شود:

GET /api/users/125

یک Tester می‌تواند Request را ارسال کرده و موارد مختلفی را بررسی کند.

HTTP/1.1 200 OK
Content-Type: application/json

سپس Response Body نیز بررسی می‌شود:

{
  "id": 125,
  "name": "Ali",
  "email": "ali@example.com"
}

در اینجا فقط بررسی 200 OK کافی نیست. باید بررسی کنیم آیا اطلاعات کاربر صحیح است، ساختار JSON مطابق Contract است و آیا کاربر مجاز به مشاهده این اطلاعات بوده است یا خیر.

چرا API Testing اهمیت زیادی دارد؟ ⭐

بخش قابل‌توجهی از منطق واقعی یک نرم‌افزار در Backend و سرویس‌هایی قرار دارد که از طریق API با یکدیگر ارتباط برقرار می‌کنند.

بنابراین ممکن است رابط کاربری ظاهراً درست کار کند، اما در لایه API مشکلات مهمی وجود داشته باشد.

• محاسبات اشتباه
• Validation ناقص
• Business Ruleهای نادرست
• مشکلات Authentication و Authorization
• افشای اطلاعات حساس
• خطا در ارتباط بین سرویس‌ها
• مشکلات Performance

API Testing کمک می‌کند این مشکلات را در لایه‌ای نزدیک‌تر به منطق اصلی سیستم شناسایی کنیم.

تفاوت API Testing با UI Testing

در UI Testing معمولاً رفتار سیستم از طریق رابط کاربری بررسی می‌شود؛ اما در API Testing مستقیماً با لایه API ارتباط برقرار می‌کنیم.

API Testing	UI Testing
تمرکز بر API و Backend	تمرکز بر رابط کاربری
اجرای معمولاً سریع‌تر	معمولاً اجرای کندتر
مناسب برای تست Business Logic	مناسب برای بررسی رفتار End-to-End رابط کاربری
وابستگی کمتر به UI	وابستگی بیشتر به UI
مناسب برای Automation	Automation معمولاً پیچیده‌تر است

این به معنی جایگزین شدن API Testing با UI Testing نیست. هرکدام هدف متفاوتی دارند و در یک Test Strategy مناسب می‌توانند در کنار یکدیگر استفاده شوند.

API Tester چه چیزی را باید بررسی کند؟ 🎯

یک API Tester حرفه‌ای معمولاً فقط به یک نوع تست محدود نمی‌شود. بسته به نیاز پروژه، ممکن است موارد زیر را بررسی کند:

• Functional Testing: آیا API رفتار مورد انتظار را دارد؟
• Validation Testing: آیا ورودی‌های نامعتبر به‌درستی مدیریت می‌شوند؟
• Integration Testing: آیا API با سرویس‌های دیگر به‌درستی ارتباط برقرار می‌کند؟
• Security Testing: آیا API در برابر دسترسی غیرمجاز و سایر ریسک‌های امنیتی مقاوم است؟
• Performance Testing: آیا API تحت بار مورد انتظار عملکرد مناسبی دارد؟
• Reliability Testing: آیا API در شرایط خطا رفتار پایدار و قابل پیش‌بینی دارد؟

در ادامه مقاله، هرکدام از این مفاهیم را با جزئیات بیشتری بررسی خواهیم کرد و از مباحث پایه HTTP و REST به سمت تست‌های پیشرفته‌تر، Automation، Security، Performance و CI/CD حرکت می‌کنیم. 🚀

API Testing در کجای چرخه توسعه نرم‌افزار قرار می‌گیرد؟ 🔄

API Testing می‌تواند در مراحل مختلف چرخه توسعه نرم‌افزار انجام شود و محدود به مرحله‌ای خاص از پروژه نیست. هرچه تست‌ها زودتر در فرآیند توسعه وارد شوند، امکان شناسایی سریع‌تر Defectها و کاهش هزینه اصلاح آن‌ها بیشتر خواهد بود.

در یک فرآیند توسعه مدرن، API Testها می‌توانند از زمان طراحی Contract شروع شوند و تا مرحله Integration، Regression و Deployment ادامه پیدا کنند.

API Design
    ↓
Implementation
    ↓
API Testing
    ↓
Integration Testing
    ↓
Regression Testing
    ↓
CI/CD
    ↓
Release

به همین دلیل API Testing فقط فعالیتی برای پایان توسعه یک Feature نیست و می‌تواند در طول چرخه عمر آن Feature مورد استفاده قرار گیرد.

آیا API Testing فقط مخصوص REST API است؟ 🌐

خیر. اگرچه REST API یکی از رایج‌ترین انواع APIهایی است که در پروژه‌های وب و نرم‌افزاری با آن مواجه می‌شویم، اما API Testing محدود به REST نیست.

• REST API
• SOAP API
• GraphQL API
• gRPC
• WebSocket

روش ارسال Request، ساختار داده و نوع ارتباط در این فناوری‌ها متفاوت است، اما مفهوم اصلی Testing همچنان مشابه است: باید بررسی کنیم Interface موردنظر طبق Contract و Requirement رفتار می‌کند.

API Testing دستی یا Automation؟ 🤖

API Testing می‌تواند به‌صورت Manual یا Automated انجام شود و در یک پروژه حرفه‌ای معمولاً ترکیبی از هر دو مورد استفاده قرار می‌گیرد.

در Manual Testing، Tester می‌تواند با ابزارهایی مانند Postman یا ابزارهای مشابه، Requestها را به‌صورت دستی ارسال و Responseها را بررسی کند.

در Automation Testing، Testها با استفاده از زبان برنامه‌نویسی یا Frameworkهای مخصوص نوشته می‌شوند تا بتوان آن‌ها را به‌صورت تکرارشونده اجرا کرد.

Manual API Testing	Automated API Testing
مناسب برای Exploratory Testing	مناسب برای Regression Testing
انعطاف‌پذیری بالا	قابل تکرار و سریع
نیازمند اجرای دستی	قابل اجرا در CI/CD
مناسب برای بررسی اولیه API	مناسب برای Test Suiteهای بزرگ

نکته مهم این است که Automation جایگزین تفکر Tester نمی‌شود. حتی اگر تمام Testها Automated باشند، همچنان طراحی سناریو، انتخاب داده مناسب و تحلیل نتایج به دانش و تفکر انسانی نیاز دارد.

API Testing برای چه کسانی اهمیت دارد؟ 👨‍💻

API Testing فقط برای متخصصان Automation Testing نیست. افراد مختلفی در تیم توسعه نرم‌افزار می‌توانند از آن استفاده کنند.

• Manual Tester: برای بررسی رفتار Backend و Business Logic
• Automation Tester: برای ساخت و اجرای Automated API Tests
• QA Engineer: برای بررسی کیفیت سرویس‌ها و Integrationها
• Developer: برای بررسی و اعتبارسنجی APIهای توسعه‌یافته
• DevOps Engineer: برای اجرای Testها در Pipeline و بررسی سلامت سرویس‌ها

به همین دلیل یادگیری API Testing می‌تواند مهارت‌های یک Tester را از سطح تعامل با UI فراتر ببرد و درک عمیق‌تری از معماری و رفتار سیستم ایجاد کند.

برای یادگیری API Testing از کجا شروع کنیم؟ 🗺️

اگر با API Testing آشنایی ندارید، بهتر است یادگیری را به‌صورت مرحله‌ای پیش ببرید.

1. آشنایی با Client و Server
2. یادگیری مفاهیم HTTP
3. شناخت HTTP Methods و Status Codes
4. آشنایی با JSON و ساختار Request و Response
5. یادگیری REST API
6. کار با ابزارهایی مانند Postman
7. یادگیری Authentication و Authorization
8. طراحی Positive و Negative Testها
9. آشنایی با Database و Data Validation
10. یادگیری API Automation
11. آشنایی با CI/CD و Regression Testing
12. یادگیری مباحث Security و Performance

در بخش‌های بعدی مقاله، این مسیر را مرحله‌به‌مرحله طی می‌کنیم تا در نهایت به یک دید جامع و عملی نسبت به API Testing برسیم. 🚀

جمع‌بندی بخش اول 📝

API Testing به معنای بررسی رفتار API در برابر Requestهای مختلف و مقایسه Response واقعی با رفتار مورد انتظار است.

اما یک API Tester حرفه‌ای فقط Status Code را بررسی نمی‌کند؛ بلکه باید بتواند صحت داده، Business Logic، Validation، Security، Integration، Performance و Reliability را نیز در صورت نیاز ارزیابی کند.

در بخش بعدی، ابتدا با Client، Server، API و نحوه برقراری ارتباط میان آن‌ها آشنا می‌شویم تا پایه لازم برای درک HTTP و REST API را ایجاد کنیم. 🔗

۲. مفاهیم پایه API و ارتباط Client و Server 🌐

قبل از اینکه وارد جزئیات API Testing شویم، باید با مفاهیم پایه‌ای که در پشت ارتباط بین نرم‌افزارها قرار دارند آشنا شویم.

اگر بدانیم Client، Server، API، Request و Response چگونه با یکدیگر ارتباط برقرار می‌کنند، درک مراحل بعدی مانند HTTP Methods، Status Codes، Headers، Authentication و REST API بسیار ساده‌تر خواهد شد.

Client چیست؟ 💻

Client نرم‌افزاری است که برای دریافت یک سرویس یا اطلاعات، به یک Server درخواست ارسال می‌کند.

برای مثال، موارد زیر می‌توانند Client باشند:

• مرورگر وب
• اپلیکیشن موبایل
• اپلیکیشن دسکتاپ
• یک سرویس نرم‌افزاری دیگر
• ابزارهای تست API مانند Postman
• اسکریپت یا برنامه‌ای که به API متصل می‌شود

Client معمولاً آغازکننده ارتباط است و برای انجام یک عملیات، Request را به Server ارسال می‌کند.

Server چیست؟ 🖥️

Server سیستمی است که Requestهای Client را دریافت کرده و بر اساس منطق برنامه، آن‌ها را پردازش می‌کند.

Server ممکن است برای پردازش یک Request با اجزای مختلفی مانند Database، سرویس‌های دیگر یا سیستم‌های خارجی ارتباط برقرار کند.

Client
   ↓
Server
   ↓
Business Logic
   ↓
Database / Other Services
   ↓
Response

برای مثال، وقتی کاربر اطلاعات حساب خود را در یک اپلیکیشن مشاهده می‌کند، ممکن است Client اطلاعات موردنیاز را از Server درخواست کند و Server پس از دریافت اطلاعات از Database، Response مناسب را برگرداند.

API چه نقشی بین Client و Server دارد؟ 🔗

API یا Application Programming Interface مجموعه‌ای از قوانین و Interfaceهایی است که مشخص می‌کند نرم‌افزارها چگونه می‌توانند با یکدیگر ارتباط برقرار کنند.

در یک Web API، Client معمولاً یک Request ارسال می‌کند و Server پس از پردازش آن، Response برمی‌گرداند.

Client
   │
   │ Request
   ▼
  API
   │
   │ Processing
   ▼
Server
   │
   │ Response
   ▼
Client

بنابراین API را می‌توان به‌عنوان یک نقطه ارتباط استاندارد میان نرم‌افزارها در نظر گرفت؛ البته API صرفاً محدود به ارتباط Client و Server نیست و می‌تواند برای ارتباط میان سرویس‌ها و اجزای مختلف یک سیستم نیز استفاده شود.

Request چیست؟ 📤

Request پیامی است که Client برای درخواست انجام یک عملیات یا دریافت اطلاعات به Server ارسال می‌کند.

یک HTTP Request معمولاً شامل بخش‌هایی مانند موارد زیر است:

• HTTP Method
• URL
• Headers
• Query Parameters
• Path Parameters
• Request Body

برای مثال:

GET /api/users/125

در این مثال، Client درخواست دریافت اطلاعات کاربری با شناسه 125 را ارسال می‌کند.

Response چیست؟ 📥

Response پاسخی است که Server در نتیجه پردازش Request به Client برمی‌گرداند.

Response نیز می‌تواند شامل اطلاعات مختلفی باشد، از جمله:

• Status Code
• Headers
• Response Body

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 125,
  "name": "Ali"
}

در این مثال، Status Code برابر 200 نشان می‌دهد که Request با موفقیت پردازش شده و Response Body نیز اطلاعات کاربر را در قالب JSON برمی‌گرداند.

چرخه ساده یک API Request 🔄

می‌توان فرآیند یک Request ساده را به شکل زیر خلاصه کرد:

1. Client Request را ایجاد می‌کند
2. Request به API ارسال می‌شود
3. Server Request را دریافت می‌کند
4. Authentication و Validation در صورت نیاز انجام می‌شود
5. Business Logic اجرا می‌شود
6. Server با Database یا سرویس‌های دیگر ارتباط برقرار می‌کند
7. Response ایجاد می‌شود
8. Response به Client برگردانده می‌شود
9. Client Response را پردازش می‌کند

برای یک API Tester، تقریباً تمام مراحل این چرخه می‌توانند محل ایجاد خطا یا موضوعی برای تست باشند. 🎯

Endpoint چیست؟ 🎯

در API Testing مرتباً با واژه Endpoint مواجه می‌شویم. Endpoint را می‌توان یک نقطه مشخص برای دسترسی به یک قابلیت یا Resource در API در نظر گرفت.

برای مثال:

https://example.com/api/users/125

در این مثال، مسیر /api/users/125 بخشی از آدرس API است که برای دسترسی به اطلاعات یک User استفاده می‌شود.

البته Endpoint فقط به URL محدود نمی‌شود و در APIهای HTTP معمولاً ترکیب HTTP Method + URL رفتار مشخصی را تعریف می‌کند.

GET    /api/users
POST   /api/users
GET    /api/users/125
PUT    /api/users/125
DELETE /api/users/125

بنابراین یک مسیر یکسان می‌تواند با HTTP Methodهای مختلف، عملیات متفاوتی انجام دهد.

Resource چیست؟ 📦

در بسیاری از REST APIها، داده‌ها به‌صورت Resource مدل می‌شوند.

برای مثال ممکن است یک سیستم Resourceهایی مانند این داشته باشد:

• Users
• Products
• Orders
• Payments
• Comments

برای هر Resource نیز Endpointهای مختلفی برای ایجاد، دریافت، تغییر یا حذف اطلاعات وجود دارد.

URL و URI چه تفاوتی دارند؟ 🔎

در مباحث API ممکن است اصطلاحات URL و URI را ببینید. این دو مفهوم کاملاً یکسان نیستند، هرچند در مکالمات روزمره توسعه API گاهی به‌جای یکدیگر استفاده می‌شوند.

URI یک شناسه برای یک Resource است، در حالی که URL علاوه بر شناسایی Resource، نحوه دسترسی به آن را نیز مشخص می‌کند.

برای API Tester، در بسیاری از سناریوهای عملی تمرکز اصلی روی Endpoint، URL، Method و سایر اجزای HTTP Request خواهد بود.

HTTP چیست؟ 🌐

HTTP یا Hypertext Transfer Protocol یکی از پروتکل‌های اصلی برای انتقال پیام میان Client و Server در وب است.

بسیاری از APIهایی که در پروژه‌های وب با آن‌ها کار می‌کنیم، از HTTP یا نسخه امن آن یعنی HTTPS استفاده می‌کنند.

HTTP مشخص می‌کند Request و Response چگونه ساختاربندی و منتقل شوند و مفاهیمی مانند Method، Header، Status Code و Body را در اختیار ما قرار می‌دهد.

HTTPS چیست؟ 🔒

HTTPS نسخه امن HTTP است که از TLS برای محافظت از ارتباط میان Client و Server استفاده می‌کند.

به‌صورت ساده:

HTTP
Client ──────────────── Server

HTTPS
Client ════════════════ Server
          🔒 TLS

در API Testing، به‌خصوص هنگام کار با اطلاعات حساس مانند Credentials، Tokenها و اطلاعات شخصی، استفاده صحیح از HTTPS اهمیت زیادی دارد.

HTTP Method چیست؟ ⚙️

HTTP Method مشخص می‌کند Client چه نوع عملیاتی را از Server درخواست کرده است.

رایج‌ترین Methodهایی که در API Testing با آن‌ها مواجه می‌شویم عبارت‌اند از:

Method	کاربرد رایج
GET	دریافت اطلاعات
POST	ایجاد Resource یا اجرای یک عملیات
PUT	جایگزینی یا به‌روزرسانی کامل Resource
PATCH	به‌روزرسانی بخشی از Resource
DELETE	حذف Resource

در بخش‌های بعدی هرکدام از این Methodها را از دید API Tester با جزئیات بیشتری بررسی خواهیم کرد.

یک مثال کامل از ارتباط Client و API 🧩

فرض کنید کاربر در یک فروشگاه آنلاین وارد صفحه محصولات می‌شود و برنامه می‌خواهد اطلاعات محصول شماره 125 را دریافت کند.

GET /api/products/125
Accept: application/json

Server پس از پردازش Request ممکن است Response زیر را برگرداند:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 125,
  "name": "Laptop",
  "price": 1500
}

در این سناریو، API Tester می‌تواند موارد مختلفی را بررسی کند: آیا Method صحیح است؟ آیا Product شماره 125 واقعاً وجود دارد؟ آیا Status Code درست است؟ آیا ساختار JSON صحیح است؟ آیا قیمت محصول درست است؟ و آیا کاربر مجاز به مشاهده این اطلاعات است؟

این دقیقاً همان نقطه‌ای است که مفاهیم پایه Client، Server، API، Request و Response به فرآیند واقعی API Testing متصل می‌شوند. 🚀

۳. HTTP در API Testing 🌐

برای اینکه بتوانیم API را به‌درستی تست کنیم، باید با HTTP و اجزای اصلی آن آشنا باشیم. بسیاری از Testهایی که در API Testing انجام می‌دهیم، مستقیماً به رفتار HTTP مربوط هستند.

در این بخش با ساختار Request و Response، HTTP Methodها، Headerها، Status Codeها و سایر مفاهیم مهم HTTP آشنا می‌شویم.

ساختار HTTP Request 📤

یک HTTP Request معمولاً از چند بخش اصلی تشکیل می‌شود:

• HTTP Method
• URL
• Headers
• Query Parameters
• Path Parameters
• Request Body

برای مثال:

POST /api/users?source=mobile HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer <token>

{
  "name": "Ali",
  "email": "ali@example.com"
}

در این مثال، Request شامل Method برابر POST، مسیر API، Query Parameter، Headerهای مختلف و یک JSON Body است.

HTTP Methodها ⚙️

HTTP Method مشخص می‌کند Client چه عملیاتی را از Server درخواست کرده است. شناخت درست Methodها برای طراحی Test Caseهای API ضروری است.

GET — دریافت اطلاعات 📥

از GET معمولاً برای دریافت اطلاعات استفاده می‌شود.

GET /api/products

در تست GET باید مواردی مانند Response، Status Code، داده‌های برگشتی، Filtering، Sorting، Pagination و رفتار در برابر Parameterهای نامعتبر را بررسی کنیم.

POST — ایجاد یا اجرای عملیات 📤

POST معمولاً برای ایجاد یک Resource یا ارسال داده برای اجرای یک عملیات استفاده می‌شود.

POST /api/users

در این حالت Tester باید علاوه بر موفقیت عملیات، Validation، Duplicate Data، Required Fields، Business Rules و رفتار API در برابر داده‌های نامعتبر را نیز بررسی کند.

PUT — به‌روزرسانی کامل 🔄

PUT معمولاً برای جایگزینی یا به‌روزرسانی کامل یک Resource استفاده می‌شود.

PUT /api/users/125

یکی از نکات مهم در تست PUT این است که مشخص کنیم در صورت حذف یک Field از Request، آیا مقدار قبلی آن باید حذف شود، تغییر نکند یا Request باید رد شود. پاسخ این سؤال به Contract و طراحی API بستگی دارد.

PATCH — به‌روزرسانی جزئی ✏️

PATCH معمولاً برای تغییر بخشی از یک Resource استفاده می‌شود.

PATCH /api/users/125

{
  "email": "new@example.com"
}

در این مثال فقط Email تغییر می‌کند و سایر اطلاعات User نباید بدون دلیل تغییر کنند. بنابراین بررسی Data Integrity در تست PATCH اهمیت زیادی دارد.

DELETE — حذف Resource 🗑️

DELETE معمولاً برای حذف یک Resource استفاده می‌شود.

DELETE /api/users/125

Tester باید علاوه بر بررسی Response، مطمئن شود Resource واقعاً طبق رفتار مورد انتظار حذف شده و درخواست‌های بعدی نیز نتیجه صحیحی دارند.

مقایسه HTTP Methodها 📊

Method	کاربرد رایج	نمونه
GET	دریافت اطلاعات	GET /users
POST	ایجاد یا اجرای عملیات	POST /users
PUT	جایگزینی یا به‌روزرسانی کامل	PUT /users/125
PATCH	به‌روزرسانی بخشی	PATCH /users/125
DELETE	حذف Resource	DELETE /users/125

Idempotency در HTTP چیست؟ 🔁

یکی از مفاهیمی که API Tester باید با آن آشنا باشد Idempotency است.

به‌طور ساده، یک عملیات Idempotent عملیاتی است که اگر چند بار با همان شرایط اجرا شود، اثر نهایی آن مطابق تعریف HTTP و Contract API نباید با اجرای یک‌باره آن عملیات تغییر کند.

در HTTP، Methodهایی مانند GET، PUT و DELETE به‌طور کلی Idempotent در نظر گرفته می‌شوند؛ اما POST به‌طور کلی Idempotent نیست. با این حال، یک API می‌تواند با طراحی مناسب، برای برخی عملیات POST نیز مکانیزم Idempotency داشته باشد.

این مفهوم در سناریوهایی مانند Payment اهمیت ویژه‌ای دارد؛ زیرا ارسال دوباره یک Request نباید باعث ایجاد یک عملیات مالی تکراری شود.

HTTP Method فقط یک کلمه نیست 🎯

در API Testing نباید فقط بررسی کنیم که Method صحیح نوشته شده است. باید رفتار API را نیز با معنای آن Method مقایسه کنیم.

برای مثال اگر یک Endpoint با GET فراخوانی شود اما باعث تغییر غیرمنتظره در Data شود، این رفتار می‌تواند نشانه یک مشکل طراحی یا پیاده‌سازی باشد.

HTTP Headers چیستند؟ 🧩

HTTP Header اطلاعاتی درباره Request یا Response را منتقل می‌کند و به Client و Server کمک می‌کند نحوه پردازش پیام را مشخص کنند.

برای مثال، یک Request ممکن است Headerهای زیر را داشته باشد:

Content-Type: application/json
Accept: application/json
Authorization: Bearer <token>

هر Header می‌تواند نقش متفاوتی داشته باشد و Tester باید بداند در هر API چه Headerهایی ضروری، اختیاری یا ممنوع هستند.

Content-Type 📦

Content-Type مشخص می‌کند داده موجود در Request یا Response با چه Media Typeای ارسال شده است.

Content-Type: application/json

اگر API انتظار JSON داشته باشد اما Client داده را با Content-Type نامناسب ارسال کند، ممکن است Server نتواند Request را به‌درستی پردازش کند.

Accept 📥

Accept مشخص می‌کند Client چه نوع Media Typeهایی را برای Response ترجیح می‌دهد.

Accept: application/json

در API Testing می‌توان بررسی کرد که API در برابر Acceptهای مختلف چه رفتاری دارد و آیا Response مطابق Contract برگردانده می‌شود یا خیر.

Authorization 🔐

Header مربوط به Authorization معمولاً برای ارسال اطلاعات احراز هویت استفاده می‌شود.

Authorization: Bearer <token>

این Header در تست‌های Authentication و Authorization اهمیت زیادی دارد و باید سناریوهایی مانند Token معتبر، Token نامعتبر، Token منقضی‌شده و نبود Token بررسی شوند.

Query Parameter چیست؟ 🔎

Query Parameter معمولاً برای ارسال پارامترهایی استفاده می‌شود که روی نتیجه یک Request تأثیر می‌گذارند.

GET /api/products?category=mobile&page=2

در این مثال، category و page Query Parameter هستند.

API Tester باید موارد مختلفی را بررسی کند:

• Parameter معتبر
• Parameter نامعتبر
• Parameter خالی
• Parameter تکراری
• مقدار خارج از محدوده
• ترکیب چند Parameter
• نبود Parameterهای ضروری

Path Parameter چیست؟ 🛣️

Path Parameter بخشی از مسیر URL است که معمولاً برای شناسایی یک Resource مشخص استفاده می‌شود.

GET /api/users/125

در این مثال 125 یک Path Parameter است که شناسه User را مشخص می‌کند.

در تست Path Parameter باید مواردی مانند ID معتبر، ID ناموجود، مقدار نامعتبر، مقدار خالی و فرمت نادرست بررسی شود.

Query Parameter و Path Parameter چه تفاوتی دارند؟ 📊

Path Parameter	Query Parameter
بخشی از مسیر URL است	بعد از علامت ? قرار می‌گیرد
معمولاً برای شناسایی Resource استفاده می‌شود	معمولاً برای فیلتر، جست‌وجو، مرتب‌سازی و Pagination استفاده می‌شود
/users/125	/users?page=2

Request Body چیست؟ 📦

Request Body بخشی از Request است که داده موردنیاز برای انجام یک عملیات را در خود نگه می‌دارد. Body بیشتر در Methodهایی مانند POST، PUT و PATCH دیده می‌شود.

POST /api/users
Content-Type: application/json

{
  "name": "Ali",
  "email": "ali@example.com"
}

در API Testing، Request Body یکی از مهم‌ترین بخش‌ها برای Validation و Negative Testing است.

• Field اجباری حذف شود
• Data Type تغییر کند
• مقدار Null ارسال شود
• رشته خالی ارسال شود
• مقدار بیش از Maximum Length ارسال شود
• فرمت نامعتبر ارسال شود
• Field اضافی ارسال شود

Response Body چیست؟ 📥

Response Body داده‌ای است که Server در پاسخ به Request برمی‌گرداند.

{
  "id": 125,
  "name": "Ali",
  "email": "ali@example.com"
}

Tester باید علاوه بر بررسی وجود Response، محتوای آن را نیز Validate کند. صرفاً دریافت یک Response با Status Code موفق، تضمین نمی‌کند که داده‌ها صحیح هستند.

Status Code چیست؟ 🚦

HTTP Status Code عددی سه‌رقمی است که نتیجه پردازش Request را به Client اعلام می‌کند.

Status Codeها در پنج گروه اصلی قرار می‌گیرند:

• 1xx: اطلاعاتی
• 2xx: موفقیت
• 3xx: Redirect
• 4xx: خطای Client
• 5xx: خطای Server

در API Testing، انتخاب و بررسی Status Code صحیح یکی از مهم‌ترین Assertionها محسوب می‌شود؛ اما همان‌طور که در ادامه خواهیم دید، بررسی Status Code به‌تنهایی کافی نیست.

Status Codeهای مهم در API Testing 🚦

در API Testing لازم نیست تمام Status Codeهای HTTP را حفظ کنیم؛ اما باید کدهای رایج و کاربرد آن‌ها را بشناسیم و مهم‌تر از آن، بررسی کنیم که API در هر سناریو Status Code مناسب را برمی‌گرداند.

200 OK ✅

نشان‌دهنده موفقیت Request است و معمولاً در Responseهای موفق مانند دریافت اطلاعات استفاده می‌شود.

201 Created 🎉

معمولاً زمانی استفاده می‌شود که یک Resource جدید با موفقیت ایجاد شده باشد.

POST /api/users

HTTP/1.1 201 Created

204 No Content 📭

Request با موفقیت پردازش شده اما Response Body محتوایی ندارد. این Status Code در برخی عملیات مانند DELETE یا Update استفاده می‌شود.

400 Bad Request ⚠️

معمولاً زمانی استفاده می‌شود که Request از نظر ساختار یا داده‌های ارسال‌شده معتبر نباشد. نحوه استفاده دقیق از این کد به Contract و طراحی API بستگی دارد.

401 Unauthorized 🔐

معمولاً نشان‌دهنده این است که Request فاقد اطلاعات Authentication معتبر است یا اعتبارنامه ارائه‌شده معتبر نیست.

403 Forbidden 🚫

در این حالت Server درخواست را درک کرده اما اجازه انجام عملیات موردنظر را به Client نمی‌دهد؛ برای مثال کاربر Authentication شده اما Permission لازم را ندارد.

404 Not Found 🔍

معمولاً زمانی برگردانده می‌شود که Resource یا Endpoint موردنظر پیدا نشود.

409 Conflict ⚔️

زمانی استفاده می‌شود که Request با وضعیت فعلی Resource یا سیستم Conflict داشته باشد؛ برای مثال ایجاد Resourceای که با یک Resource موجود تعارض دارد.

422 Unprocessable Content 🧩

در برخی APIها برای زمانی استفاده می‌شود که Request از نظر Syntax قابل پردازش است اما داده‌ها از نظر Semantic یا Validation معتبر نیستند.

429 Too Many Requests ⏱️

معمولاً نشان می‌دهد Client در یک بازه زمانی بیش از حد مجاز Request ارسال کرده است. این Status Code در تست Rate Limiting اهمیت زیادی دارد.

500 Internal Server Error 💥

یک خطای عمومی در سمت Server را نشان می‌دهد. در Testing باید بررسی کنیم آیا خطاهای قابل پیش‌بینی به اشتباه به 500 تبدیل می‌شوند یا خیر.

502 Bad Gateway 🌐

معمولاً زمانی رخ می‌دهد که یک Gateway یا Proxy از سرویس upstream پاسخ نامعتبر دریافت کند.

503 Service Unavailable 🔧

معمولاً نشان‌دهنده در دسترس نبودن موقت سرویس است؛ برای مثال به دلیل Maintenance یا Overload.

مقایسه Status Codeهای رایج 📊

Status Code	دسته	کاربرد رایج
200	2xx	Request موفق
201	2xx	ایجاد موفق Resource
204	2xx	موفقیت بدون Response Body
400	4xx	Request نامعتبر
401	4xx	Authentication نامعتبر یا وجود ندارد
403	4xx	عدم دسترسی
404	4xx	Resource یا Endpoint پیدا نشد
409	4xx	Conflict
422	4xx	Validation یا Semantic Error
429	4xx	تعداد بیش از حد Request
500	5xx	خطای داخلی Server
502	5xx	خطای Gateway
503	5xx	سرویس موقتاً در دسترس نیست

آیا Status Code صحیح به معنی API سالم است؟ 🤔

خیر. یکی از اشتباهات رایج در API Testing این است که Tester فقط Status Code را بررسی کند.

HTTP/1.1 200 OK

{
  "userId": 125,
  "name": "Wrong User"
}

ممکن است Status Code برابر 200 باشد، اما اطلاعات اشتباه برگردانده شده باشد. بنابراین یک Test مناسب باید علاوه بر Status Code، Response Body، Data، Headers و Business Rules مرتبط را نیز بررسی کند.

Status Code را بر اساس Requirement تست کنید 🎯

نباید صرفاً بر اساس عادت بگوییم یک Endpoint «باید» همیشه 200 برگرداند. Status Code مورد انتظار باید بر اساس API Contract، استاندارد مورد استفاده و رفتار تعریف‌شده سیستم تعیین شود.

برای مثال، اگر یک API برای ایجاد Resource جدید طراحی شده باشد، ممکن است Response موفق آن 201 Created باشد، نه 200 OK.

بنابراین سؤال اصلی Tester این است:

«آیا API در این سناریو، Status Code مورد انتظار و تعریف‌شده در Contract را برمی‌گرداند؟»

جمع‌بندی بخش HTTP 📝

درک HTTP یکی از پایه‌های اصلی API Testing است. Tester باید بتواند Request و Response را بخواند، Method مناسب را تشخیص دهد، Headerها و Parameterها را تحلیل کند و Status Code مناسب را از رفتار واقعی API تشخیص دهد.

در بخش بعدی، به سراغ REST API می‌رویم و بررسی می‌کنیم REST چیست، چه اصولی دارد و یک API Tester هنگام تست REST API باید به چه نکاتی توجه کند. 🚀

۴. REST API چیست و چگونه تست می‌شود؟ 🌐

REST API یکی از رایج‌ترین روش‌ها برای طراحی Web API است. به همین دلیل، آشنایی با مفاهیم REST برای هر API Tester اهمیت زیادی دارد.

REST مخفف Representational State Transfer است و در اصل یک سبک معماری برای طراحی سیستم‌های توزیع‌شده، به‌خصوص سرویس‌های وب، محسوب می‌شود.

نکته مهم این است که REST یک Protocol مانند HTTP نیست. HTTP می‌تواند به‌عنوان یکی از پروتکل‌های مورد استفاده برای پیاده‌سازی RESTful API به کار رود.

RESTful API یعنی چه؟ 🧩

به APIای که اصول و محدودیت‌های معماری REST را به‌خوبی رعایت کند، معمولاً RESTful API گفته می‌شود.

در یک RESTful API، معمولاً داده‌ها به شکل Resource مدل می‌شوند و Client با استفاده از HTTP Methodها روی این Resourceها عملیات انجام می‌دهد.

GET    /users
GET    /users/125
POST   /users
PUT    /users/125
PATCH  /users/125
DELETE /users/125

در این مثال، users یک Resource است و HTTP Method مشخص می‌کند چه عملیاتی روی آن انجام شود.

Resource در REST API 📦

یکی از مهم‌ترین مفاهیم REST، نگاه کردن به داده‌ها به‌عنوان Resource است.

برای مثال در یک فروشگاه اینترنتی ممکن است Resourceهای زیر وجود داشته باشند:

• /users
• /products
• /orders
• /payments
• /reviews

به‌جای اینکه برای هر عملیات یک URL با نام فعل ایجاد کنیم، در طراحی RESTful معمولاً Resource را در URL قرار داده و نوع عملیات را با HTTP Method مشخص می‌کنیم.

GET /products/125

در اینجا URL مشخص می‌کند روی کدام Resource کار می‌کنیم و Method مشخص می‌کند چه عملیاتی انجام می‌دهیم.

اصول اصلی REST 🏗️

معماری REST بر مجموعه‌ای از محدودیت‌ها یا Architectural Constraints استوار است. مهم‌ترین آن‌ها عبارت‌اند از:

• Client-Server
• Stateless
• Cacheable
• Uniform Interface
• Layered System
• Code on Demand؛ به‌عنوان یک Constraint اختیاری

Client-Server Architecture 🖥️

در معماری Client-Server، مسئولیت‌های Client و Server از یکدیگر جدا می‌شوند.

Client مسئول Interface و تعامل با کاربر است، در حالی که Server مسئول پردازش داده‌ها و Business Logic است.

Client
  ↓
API
  ↓
Server
  ↓
Database

این جداسازی باعث می‌شود توسعه و تغییر Client و Server تا حد زیادی مستقل از یکدیگر انجام شود؛ البته این استقلال به نحوه طراحی و Contract بین آن‌ها نیز وابسته است.

Stateless چیست؟ 🧠

یکی از مهم‌ترین ویژگی‌های REST، Stateless بودن ارتباط است.

در یک API Stateless، هر Request باید اطلاعات لازم برای پردازش خود را در اختیار Server قرار دهد و Server نباید برای تکمیل Request به Session State ذخیره‌شده از Requestهای قبلی همان Client وابسته باشد.

برای مثال، اگر API برای Authentication از Token استفاده کند، Client معمولاً Token لازم را در Request ارسال می‌کند.

GET /api/profile
Authorization: Bearer <token>

در API Testing، Stateless بودن می‌تواند با ارسال Requestهای مستقل و بررسی اینکه هر Request اطلاعات لازم را همراه خود دارد، مورد ارزیابی قرار گیرد.

Cacheable چیست؟ ⚡

در REST، Responseها باید مشخص کنند که آیا قابلیت Cache شدن دارند یا خیر.

Cache می‌تواند با کاهش Requestهای غیرضروری به Server، Performance سیستم را بهبود دهد؛ اما در مقابل، Cache نادرست می‌تواند باعث نمایش داده‌های قدیمی یا حتی ایجاد مشکلات امنیتی شود.

بنابراین API Tester در سناریوهای مرتبط با Cache باید بررسی کند که Headerها و رفتار Cache مطابق Requirement و سیاست تعریف‌شده سیستم هستند.

Uniform Interface چیست؟ 🔗

Uniform Interface یکی از مهم‌ترین محدودیت‌های معماری REST است و هدف آن ایجاد یک روش استاندارد و یکنواخت برای تعامل Client با Resourceهاست.

این مفهوم شامل چند اصل مهم است؛ از جمله شناسایی Resourceها، دستکاری Resourceها از طریق Representation، پیام‌های Self-descriptive و استفاده از Hypermedia در صورت نیاز به سطح کامل‌تر REST.

شناسایی Resource با URI 🎯

هر Resource باید یک شناسه مشخص داشته باشد.

GET /api/products/125

در این مثال، URI مشخص می‌کند که Request مربوط به Product با شناسه 125 است.

Representation چیست؟ 📄

Client لزوماً خود Resource را دریافت نمی‌کند، بلکه یک Representation از وضعیت آن را دریافت یا ارسال می‌کند.

{
  "id": 125,
  "name": "Laptop",
  "price": 1500
}

در اینجا JSON یک Representation از اطلاعات Product است.

Self-descriptive Messages 🧩

پیام‌ها باید اطلاعات کافی برای درک و پردازش خود را داشته باشند. Headerهایی مانند Content-Type در این زمینه نقش مهمی دارند.

Content-Type: application/json

این Header به گیرنده اعلام می‌کند محتوای پیام از نوع JSON است و باید مطابق آن پردازش شود.

Hypermedia و HATEOAS 🔗

در سطح کامل‌تر REST، یک Representation می‌تواند لینک‌هایی برای دسترسی به Actionها یا Resourceهای مرتبط نیز داشته باشد. این مفهوم با HATEOAS یا Hypermedia as the Engine of Application State شناخته می‌شود.

{
  "id": 125,
  "name": "Laptop",
  "_links": {
    "self": {
      "href": "/api/products/125"
    }
  }
}

بسیاری از APIهایی که در پروژه‌های واقعی با آن‌ها کار می‌کنیم، از تمام جنبه‌های HATEOAS استفاده نمی‌کنند؛ بنابراین Tester باید Contract واقعی API را مبنای تست قرار دهد، نه صرفاً این فرض که هر REST API الزاماً باید HATEOAS کامل داشته باشد.

Layered System چیست؟ 🏗️

در یک Layered System، Client لزوماً نمی‌داند مستقیماً با کدام Server یا Component ارتباط برقرار کرده است.

Client
   ↓
API Gateway / Proxy
   ↓
Service
   ↓
Database / Other Services

ممکن است بین Client و سرویس اصلی، اجزایی مانند API Gateway، Load Balancer، Proxy یا Authentication Service قرار داشته باشند.

این موضوع برای API Tester اهمیت دارد؛ زیرا گاهی یک خطا از خود API نیست و ممکن است در Gateway، Network یا یکی از سرویس‌های میانی رخ داده باشد.

Code on Demand چیست؟ 💻

Code on Demand تنها Constraint اختیاری REST است. در این مدل، Server می‌تواند Code اجرایی را برای Client ارسال کند تا Client آن را اجرا کند.

این ویژگی در مقایسه با سایر Constraints کمتر در طراحی APIهای رایج امروزی دیده می‌شود و برای API Tester معمولاً اهمیت کمتری دارد؛ مگر اینکه سیستم موردنظر از آن استفاده کند.

REST API از دید یک Tester چه اهمیتی دارد؟ 🎯

شناخت REST فقط برای Developerها نیست. Tester باید بتواند تشخیص دهد API چگونه Resourceها را مدل کرده، چه Methodهایی برای آن‌ها تعریف شده و Contract مورد انتظار چگونه است.

• آیا Endpointها ساختار منطقی دارند؟
• آیا HTTP Method مناسب استفاده شده است؟
• آیا Resource به‌درستی شناسایی می‌شود؟
• آیا Response مطابق Representation مورد انتظار است؟
• آیا API رفتار Stateless مورد انتظار را دارد؟
• آیا Status Codeها مطابق Contract هستند؟
• آیا Headerها و Media Typeها صحیح هستند؟
• آیا دسترسی به Resourceها به‌درستی کنترل می‌شود؟

REST API یک استاندارد واحد نیست ⚠️

یکی از نکات مهم برای Tester این است که REST را با یک Specification ثابت و واحد اشتباه نگیرد. APIهای مختلف ممکن است از HTTP و مفاهیم REST استفاده کنند، اما در جزئیات طراحی مانند Naming، Status Codeها، Error Responseها، Pagination یا ساختار JSON با یکدیگر متفاوت باشند.

بنابراین هنگام تست یک REST API، API Contract، Documentation و Requirementهای همان پروژه مرجع اصلی Tester هستند.

جمع‌بندی REST API 📝

REST یک سبک معماری است که با مجموعه‌ای از Constraints، نحوه تعامل Client و Server با Resourceها را مشخص می‌کند. در API Testing، شناخت این اصول به Tester کمک می‌کند تا فراتر از ارسال ساده Request، طراحی و رفتار API را نیز ارزیابی کند.

در بخش بعدی، وارد یکی از مهم‌ترین موضوعات عملی API Testing یعنی JSON و ساختار داده‌های Request و Response می‌شویم. 📦

۵. JSON و ساختار داده در API Testing 📦

در بسیاری از APIهای امروزی، داده‌های Request و Response با فرمت JSON منتقل می‌شوند. به همین دلیل، شناخت JSON یکی از مهارت‌های پایه برای هر API Tester محسوب می‌شود.

Tester لازم نیست برای کار با JSON یک Developer حرفه‌ای باشد، اما باید بتواند ساختار آن را بخواند، داده‌ها را بررسی کند و خطاهای رایج را تشخیص دهد.

JSON چیست؟ 🧩

JSON مخفف JavaScript Object Notation است و یک فرمت متنی سبک برای نمایش و تبادل داده‌های ساختاریافته محسوب می‌شود.

یک JSON ساده می‌تواند به شکل زیر باشد:

{
  "id": 125,
  "name": "Ali",
  "email": "ali@example.com"
}

در این مثال، یک Object شامل سه Property به نام‌های id، name و email داریم.

JSON Object چیست؟ 🗂️

JSON Object با استفاده از آکولاد {} مشخص می‌شود و شامل مجموعه‌ای از Key-Valueهاست.

{
  "name": "Ali",
  "age": 30,
  "active": true
}

در این مثال، name، age و active Key هستند و مقادیر مقابل آن‌ها Value محسوب می‌شوند.

JSON Array چیست؟ 📚

برای نمایش مجموعه‌ای از مقادیر یا Objectها از Array استفاده می‌شود که با براکت [] مشخص می‌شود.

{
  "users": [
    {
      "id": 1,
      "name": "Ali"
    },
    {
      "id": 2,
      "name": "Sara"
    }
  ]
}

در API Testing باید بتوانیم تعداد عناصر Array، ترتیب آن‌ها در صورت اهمیت، مقادیر هر عنصر و ساختار Objectهای داخل آن را بررسی کنیم.

Data Typeهای رایج در JSON 🔢

JSON از چند نوع داده اصلی پشتیبانی می‌کند:

• String
• Number
• Boolean
• Object
• Array
• null

برای مثال:

{
  "name": "Ali",
  "age": 30,
  "active": true,
  "address": {
    "city": "Tehran"
  },
  "roles": ["tester", "qa"],
  "phone": null
}

شناخت Data Typeها در Validation اهمیت زیادی دارد؛ زیرا ممکن است مقدار از نظر ظاهری درست باشد اما Type اشتباهی داشته باشد.

String و Number چه تفاوتی دارند؟ 🔍

برای مثال این دو مقدار از نظر JSON یکسان نیستند:

{
  "age": 30
}

{
  "age": "30"
}

در حالت اول، مقدار age یک Number است؛ اما در حالت دوم یک String است. اگر API Contract انتظار Number داشته باشد، حالت دوم باید در Validation به‌عنوان داده نامعتبر بررسی شود.

Boolean چیست؟ ✔️

Boolean فقط می‌تواند یکی از دو مقدار true یا false باشد.

{
  "active": true,
  "verified": false
}

مقادیر زیر Boolean نیستند:

{
  "active": "true",
  "verified": 1
}

اگر Contract یک Field را Boolean تعریف کرده باشد، Tester باید Type آن را نیز بررسی کند.

Null با Empty String متفاوت است ⚠️

یکی از نکات مهم در API Testing تفاوت بین null و String خالی است.

{
  "phone": null
}

{
  "phone": ""
}

در حالت اول مقدار Field برابر null است، در حالی که در حالت دوم یک String با طول صفر داریم. رفتار API در برابر این دو مقدار باید بر اساس Requirement و Contract بررسی شود.

Nested JSON چیست؟ 🪆

یک JSON می‌تواند شامل Object یا Arrayهای تو در تو باشد.

{
  "id": 125,
  "profile": {
    "name": "Ali",
    "contact": {
      "email": "ali@example.com",
      "phone": "09120000000"
    }
  }
}

در چنین Responseهایی، Tester باید علاوه بر Structure کلی، مقدار Fieldهای تو در تو را نیز بررسی کند.

JSON Schema چیست؟ 🧩

JSON Schema روشی برای تعریف ساختار، Type، محدودیت‌ها و قواعد اعتبارسنجی داده‌های JSON است. در API Testing می‌توان از آن برای بررسی اینکه Response یا Request با ساختار مورد انتظار مطابقت دارد یا خیر استفاده کرد.

برای مثال، ممکن است Contract مشخص کند که یک User باید دارای id از نوع Integer و email از نوع String باشد.

{
  "type": "object",
  "required": ["id", "email"],
  "properties": {
    "id": {
      "type": "integer"
    },
    "email": {
      "type": "string"
    }
  }
}

در این حالت، Tester می‌تواند بررسی کند که Response واقعاً با Schema تعریف‌شده مطابقت دارد یا خیر.

Validation در JSON 🔍

در API Testing، Validation فقط به بررسی مقدار یک Field محدود نمی‌شود. می‌توان جنبه‌های مختلفی از داده را بررسی کرد:

• وجود یا عدم وجود Field
• Data Type
• مقدار Field
• محدوده عددی
• حداقل و حداکثر طول String
• فرمت داده
• ساختار Object
• تعداد عناصر Array
• ساختار عناصر Array

Required و Optional Fields 📋

هر Field در API الزاماً اجباری نیست. بعضی Fieldها باید همیشه ارسال یا در Response وجود داشته باشند و بعضی دیگر Optional هستند.

{
  "name": "Ali",
  "email": "ali@example.com",
  "phone": "09120000000"
}

فرض کنید name و email Required باشند و phone Optional باشد. در این صورت حذف phone نباید الزاماً باعث خطا شود؛ اما حذف email ممکن است باید با Error Response مواجه شود.

این موضوع یکی از سناریوهای مهم Negative Testing است.

Field اضافی در Request ➕

یکی دیگر از سناریوهای مهم این است که Client یک Field اضافی ارسال کند.

{
  "name": "Ali",
  "email": "ali@example.com",
  "unknownField": "test"
}

رفتار مورد انتظار به طراحی API بستگی دارد. ممکن است API Field اضافی را نادیده بگیرد، آن را رد کند یا در برخی شرایط باعث خطای Validation شود. Tester باید این رفتار را بر اساس Contract بررسی کند و نباید صرفاً یک رفتار را به‌عنوان قانون عمومی در نظر بگیرد.

Order و Structure داده‌ها 📐

در JSON Objectها، ترتیب Propertyها معمولاً نباید مبنای Validation قرار گیرد؛ زیرا Object یک مجموعه نامرتب از Name/Value Pairهاست.

{
  "id": 125,
  "name": "Ali"
}

{
  "name": "Ali",
  "id": 125
}

این دو Object از نظر Propertyها یکسان هستند، حتی اگر ترتیب آن‌ها متفاوت باشد.

اما در Arrayها ترتیب عناصر می‌تواند اهمیت داشته باشد؛ برای مثال اگر API Contract مشخص کرده باشد که محصولات بر اساس قیمت مرتب شوند.

JSON و Negative Testing ❌

یکی از ارزشمندترین کاربردهای JSON در API Testing، طراحی سناریوهای منفی است. Tester باید عمداً داده‌های نامعتبر ارسال کند و بررسی کند API آیا رفتار مورد انتظار را نشان می‌دهد یا خیر.

{
  "name": 123,
  "email": "invalid-email",
  "age": -10
}

در این مثال ممکن است چند مشکل هم‌زمان وجود داشته باشد: Type اشتباه برای name، فرمت نامعتبر برای email و مقدار نامعتبر برای age.

هدف Tester فقط این نیست که API خطا بدهد؛ باید بررسی کند نوع خطا، Status Code، Error Message و رفتار API نیز مطابق Contract و Requirement باشند.

Response Validation در عمل 🎯

فرض کنید API زیر را فراخوانی کرده‌ایم:

GET /api/users/125

و Response زیر را دریافت کرده‌ایم:

{
  "id": 125,
  "name": "Ali",
  "email": "ali@example.com",
  "active": true
}

Tester می‌تواند چند Assertion مختلف تعریف کند:

• Status Code برابر مقدار مورد انتظار باشد.
• Fieldهای Required وجود داشته باشند.
• id از Type مورد انتظار برخوردار باشد.
• email فرمت معتبر داشته باشد.
• active مقدار Boolean داشته باشد.
• مقدار id با Resource درخواست‌شده مطابقت داشته باشد.

این رویکرد باعث می‌شود تست API از یک بررسی ساده «Response دریافت شد یا نه» به یک Validation واقعی تبدیل شود. ✅

JSON در API Testing فقط داده نیست 📌

برای یک API Tester، JSON فقط فرمتی برای خواندن Response نیست. Structure و Data Typeهای آن می‌توانند بخشی از API Contract باشند و باید مانند سایر بخش‌های API مورد تست قرار گیرند.

در ادامه، به سراغ یکی از مهم‌ترین موضوعات API Testing یعنی Authentication و Authorization می‌رویم؛ جایی که بررسی امنیت و سطح دسترسی API اهمیت ویژه‌ای پیدا می‌کند. 🔐

۶. Authentication و Authorization در API Testing 🔐

بسیاری از APIها اطلاعات یا قابلیت‌هایی را در اختیار Client قرار می‌دهند که همه کاربران نباید به آن‌ها دسترسی داشته باشند. به همین دلیل، Authentication و Authorization از مهم‌ترین موضوعات در API Testing هستند.

این دو مفهوم به یکدیگر مرتبط‌اند، اما یکسان نیستند. درک تفاوت آن‌ها برای طراحی Test Caseهای دقیق و کشف مشکلات امنیتی API ضروری است.

Authentication چیست؟ 👤

Authentication یا احراز هویت فرآیندی است که در آن سیستم بررسی می‌کند «چه کسی هستید؟»

برای مثال، کاربر ممکن است با Username و Password وارد سیستم شود و Server پس از بررسی اطلاعات، یک Token صادر کند.

POST /api/login

{
  "username": "ali",
  "password": "********"
}

در صورت موفقیت، API ممکن است چیزی شبیه این Response برگرداند:

{
  "accessToken": "eyJhbGciOi..."
}

Client می‌تواند از این Token برای Requestهای بعدی استفاده کند.

Authorization چیست؟ 🛡️

Authorization یا کنترل دسترسی مشخص می‌کند کاربری که احراز هویت شده، «اجازه انجام چه کاری را دارد؟»

برای مثال، ممکن است دو کاربر هر دو Authentication شده باشند، اما فقط یکی از آن‌ها Permission حذف User را داشته باشد.

Authentication
«چه کسی هستی؟»
        ↓
Authorization
«چه اجازه‌ای داری؟»

تفاوت Authentication و Authorization 📊

Authentication	Authorization
تشخیص هویت کاربر	تعیین سطح دسترسی کاربر
Who are you?	What are you allowed to do?
معمولاً قبل از Authorization انجام می‌شود	پس از مشخص شدن هویت بررسی می‌شود
مثال: Login	مثال: Permission برای حذف User

Authentication در API چگونه انجام می‌شود؟ 🔑

روش‌های مختلفی برای Authentication در APIها وجود دارد. انتخاب روش به طراحی سیستم، سطح امنیت موردنیاز و معماری آن بستگی دارد.

• API Key
• Basic Authentication
• Bearer Token
• JWT
• OAuth 2.0

در API Testing، Tester باید روش Authentication مورد استفاده در پروژه را بشناسد و سناریوهای موفق و ناموفق آن را تست کند.

API Key چیست؟ 🔑

API Key یک مقدار credential است که API می‌تواند برای شناسایی یا کنترل دسترسی Client از آن استفاده کند.

GET /api/products
X-API-Key: <api-key>

محل ارسال API Key به طراحی API بستگی دارد و ممکن است در Header یا روش دیگری تعریف شده باشد.

Tester باید سناریوهایی مانند API Key معتبر، نامعتبر، منقضی‌شده یا حذف‌شده را بررسی کند؛ البته اینکه یک API Key قابلیت Expiration داشته باشد به طراحی سیستم بستگی دارد.

Basic Authentication چیست؟ 👤

در Basic Authentication معمولاً Username و Password در Credential مربوط به HTTP Authentication استفاده می‌شوند.

Authorization: Basic <base64-credentials>

Base64 رمزنگاری نیست؛ بنابراین استفاده از Basic Authentication بدون یک ارتباط امن مانند HTTPS می‌تواند Credentialها را در معرض خطر قرار دهد.

Bearer Token چیست؟ 🎟️

در بسیاری از APIها پس از Authentication، یک Access Token صادر می‌شود و Client آن را در Requestهای بعدی ارسال می‌کند.

Authorization: Bearer <access-token>

در تست Bearer Token باید فقط موفقیت Token معتبر را بررسی نکنیم؛ سناریوهای Token نامعتبر، حذف‌شده، منقضی‌شده و Token متعلق به کاربر دیگر نیز اهمیت دارند.

JWT چیست؟ 🧩

JWT یا JSON Web Token یکی از قالب‌های رایج برای انتقال Claimها میان سیستم‌هاست و می‌تواند در پیاده‌سازی Authentication و Authorization مورد استفاده قرار گیرد.

JWT معمولاً از سه بخش تشکیل می‌شود:

Header.Payload.Signature

• Header: اطلاعات مربوط به نوع Token و Algorithm
• Payload: شامل Claimها
• Signature: برای بررسی صحت و یکپارچگی Token

نکته مهم این است که Payload یک JWT معمولاً فقط Base64URL-encoded است و به‌خودی‌خود رمزنگاری‌شده نیست. بنابراین نباید اطلاعات محرمانه را صرفاً به این دلیل که داخل JWT قرار گرفته‌اند، امن فرض کرد.

سناریوهای مهم Authentication در API Testing 🧪

تست Authentication فقط به بررسی Login موفق محدود نمی‌شود. یک API Tester باید سناریوهای مختلفی را بررسی کند تا مشخص شود سیستم در شرایط نامعتبر نیز به‌درستی از منابع محافظت می‌کند.

• ارسال Credential معتبر
• ارسال Username یا Password اشتباه
• ارسال Request بدون Credential
• ارسال Token نامعتبر
• ارسال Token منقضی‌شده، در صورت وجود Expiration
• ارسال Token با Signature نامعتبر
• استفاده از Token کاربر دیگر
• ارسال Credential با فرمت نادرست

در هر سناریو باید علاوه بر Status Code، Response Body و پیام خطا نیز بررسی شود تا اطلاعات حساس به‌صورت ناخواسته در اختیار Client قرار نگیرد.

تست Authorization با نقش‌های مختلف 👥

فرض کنید یک سیستم دارای سه Role زیر باشد:

• Admin
• Editor
• Viewer

ممکن است هر سه کاربر بتوانند اطلاعات یک محصول را مشاهده کنند، اما فقط Admin اجازه حذف آن را داشته باشد.

DELETE /api/products/125

در این حالت Tester باید حداقل رفتار API را برای Roleهای مختلف بررسی کند:

Role	مشاهده	ویرایش	حذف
Admin	✅	✅	✅
Editor	✅	✅	❌
Viewer	✅	❌	❌

جدول بالا فقط یک مثال است و Permission واقعی هر سیستم باید از Requirement و Authorization Model همان پروژه مشخص شود.

Broken Access Control چیست؟ 🚨

یکی از مشکلات مهم امنیتی API، Broken Access Control است؛ یعنی کاربر بتواند به Resource یا عملیاتی دسترسی پیدا کند که طبق سطح دسترسی او نباید امکان دسترسی به آن را داشته باشد.

برای مثال، فرض کنید User شماره 100 فقط باید بتواند اطلاعات حساب خودش را مشاهده کند.

GET /api/users/100

اگر همان User بتواند فقط با تغییر ID به اطلاعات User دیگری دسترسی پیدا کند، می‌تواند نشانه یک مشکل Access Control باشد.

GET /api/users/101

این نوع سناریو باید در چارچوب مجاز و محیط‌های تستی مورد بررسی قرار گیرد و یکی از موارد مهم در API Security Testing است.

Authentication ≠ Authorization ⚠️

گاهی API به‌درستی بررسی می‌کند که User وارد سیستم شده است، اما بررسی نمی‌کند که آیا همان User اجازه دسترسی به Resource موردنظر را دارد یا خیر.

بنابراین این دو سناریو باید جداگانه تست شوند:

Authentication Test
آیا User معتبر است؟

Authorization Test
آیا User معتبر اجازه این عملیات را دارد؟

تست دسترسی بدون Authentication 🔒

برای Endpointهایی که نیاز به Authentication دارند، یکی از Test Caseهای پایه ارسال Request بدون Token یا Credential است.

GET /api/profile

اگر Endpoint واقعاً Protected باشد، Request نباید اطلاعات محافظت‌شده را در اختیار Client بدون Authentication قرار دهد.

تست Token نامعتبر ❌

Tester باید Tokenهای نامعتبر را نیز بررسی کند.

Authorization: Bearer invalid-token

API نباید صرفاً به وجود Header مربوط به Authorization اعتماد کند؛ بلکه باید اعتبار Credential را بررسی کند.

تست Token منقضی‌شده ⏳

اگر سیستم برای Tokenها زمان اعتبار تعریف کرده باشد، Tester باید بررسی کند که پس از Expiration، Token دیگر امکان دسترسی به Resourceهای محافظت‌شده را نداشته باشد.

همچنین باید بررسی شود که API در این شرایط رفتار مشخص و قابل پیش‌بینی داشته باشد و اطلاعات حساس را در Error Response افشا نکند.

تست Authorization با تغییر شناسه Resource 🔎

یکی از سناریوهای مهم این است که Tester با یک Credential معتبر، شناسه Resource را تغییر دهد و بررسی کند آیا دسترسی به Resource متعلق به کاربر دیگر به‌درستی محدود شده است یا خیر.

GET /api/orders/1001
GET /api/orders/1002

اگر کاربر فقط باید به Orderهای خودش دسترسی داشته باشد، دریافت اطلاعات Order کاربر دیگر می‌تواند نشانه ضعف در Access Control باشد.

API Tester باید چه چیزی را بررسی کند؟ 🎯

• آیا Endpoint بدون Authentication قابل دسترسی است؟
• آیا Token نامعتبر رد می‌شود؟
• آیا Token منقضی‌شده رد می‌شود؟
• آیا Role و Permission به‌درستی بررسی می‌شوند؟
• آیا کاربر فقط به Resourceهای مجاز دسترسی دارد؟
• آیا Error Response اطلاعات حساس افشا نمی‌کند؟
• آیا رفتار API با API Contract و Security Requirements مطابقت دارد؟

در بخش بعدی، سراغ API Testing Tools می‌رویم و بررسی می‌کنیم ابزارهایی مانند Postman، Swagger و ابزارهای Automation چگونه در فرآیند تست API به Tester کمک می‌کنند. 🛠️

۷. ابزارهای مورد استفاده در API Testing 🛠️

API Testing را می‌توان حتی با ابزارهای ساده مانند cURL انجام داد، اما در پروژه‌های واقعی معمولاً از ابزارهایی استفاده می‌شود که ارسال Request، بررسی Response، مدیریت Environment، اجرای تست و گزارش‌گیری را ساده‌تر کنند.

نکته مهم برای Tester این است که ابزار هدف نیست؛ ابزار باید در خدمت Test Strategy و نیاز پروژه باشد. ممکن است یک پروژه با Postman به‌خوبی پوشش داده شود و پروژه‌ای دیگر به Automation Framework یا ابزارهای تخصصی‌تر نیاز داشته باشد.

Postman چیست؟ 📮

Postman یکی از شناخته‌شده‌ترین ابزارها برای کار با API است و به Tester اجازه می‌دهد Requestهای مختلف را ایجاد، ارسال و Response آن‌ها را بررسی کند.

با Postman می‌توان بخش‌های مختلف یک API Request را کنترل کرد:

• HTTP Method
• URL
• Query Parameters
• Headers
• Authentication
• Request Body
• Cookies

همچنین می‌توان روی Response، Assertion تعریف کرد و مجموعه‌ای از Requestها را در قالب Collection مدیریت و اجرا کرد.

Postman برای API Tester چه کاربردهایی دارد؟ 🎯

• ارسال Requestهای دستی
• بررسی Response
• نوشتن Test Script
• مدیریت Environmentها
• استفاده از Variableها
• اجرای Collectionها
• تکرار Test Scenarioها
• اجرای تست‌های API در فرآیند Automation

Environment و Variable در Postman 🌍

در پروژه‌های واقعی معمولاً URL یا Credential مربوط به محیط‌های مختلف یکسان نیست. برای مثال ممکن است محیط‌های Development، Staging و Production وجود داشته باشند.

Development:
https://dev.example.com

Staging:
https://staging.example.com

Production:
https://api.example.com

به‌جای تغییر دستی URL در تمام Requestها، می‌توان مقدار Base URL را به‌صورت Variable مدیریت کرد.

{{baseUrl}}/api/users

این کار باعث می‌شود Collectionها قابل استفاده مجدد و نگهداری آن‌ها ساده‌تر شود.

Postman Collection چیست؟ 📚

Collection مجموعه‌ای از Requestهاست که می‌توان آن‌ها را بر اساس سرویس یا Feature سازمان‌دهی کرد.

Users
├── Login
├── Get User
├── Create User
├── Update User
└── Delete User

Products
├── Get Products
├── Get Product
├── Create Product
└── Update Product

این ساختار به Tester کمک می‌کند Testهای API را مرتب و قابل مدیریت نگه دارد و در صورت نیاز مجموعه‌ای از آن‌ها را به‌صورت گروهی اجرا کند.

Swagger و OpenAPI چیستند؟ 📘

OpenAPI Specification یک استاندارد برای توصیف API است و Swagger نام مجموعه‌ای از ابزارهای مرتبط با API documentation و OpenAPI است.

یکی از رایج‌ترین ابزارهایی که Tester با آن مواجه می‌شود Swagger UI است که می‌تواند Documentation تعاملی API را نمایش دهد.

GET    /users
POST   /users
GET    /users/{id}
PUT    /users/{id}
DELETE /users/{id}

در Swagger UI معمولاً می‌توان Endpointها، Parameterها، Request Body، Responseها، Status Codeها و روش Authentication را مشاهده و در بسیاری از پروژه‌ها Request را مستقیماً اجرا کرد.

Swagger فقط ابزار اجرای Request نیست 🔍

یکی از کاربردهای مهم Documentation مبتنی بر OpenAPI برای Tester، مقایسه رفتار واقعی API با Contract تعریف‌شده است.

برای مثال، اگر Documentation اعلام کند Response باید دارای Fieldهای مشخصی باشد اما API در عمل Field دیگری برگرداند، می‌تواند نشانه اختلاف بین Implementation و Contract باشد.

cURL چیست؟ 💻

cURL یک ابزار Command-Line برای انتقال داده از طریق URLها و پروتکل‌های مختلف است و می‌تواند برای ارسال HTTP Request نیز استفاده شود.

curl -X GET "https://api.example.com/users/125"

برای ارسال Header نیز می‌توان از گزینه -H استفاده کرد:

curl -X GET "https://api.example.com/users/125" \
  -H "Accept: application/json"

cURL برای Testerهایی که با Command Line و CI/CD کار می‌کنند بسیار کاربردی است؛ زیرا می‌توان Requestهای API را بدون وابستگی به رابط گرافیکی اجرا کرد.

Postman یا cURL؟ 🤔

Postman	cURL
رابط گرافیکی	Command Line
مناسب برای کار تعاملی	مناسب برای اجرای سریع و Scriptها
مدیریت Collection و Environment	قابل استفاده در Script و CI/CD
شروع کار ساده‌تر	نیازمند آشنایی بیشتر با Command Line

این دو ابزار رقیب مطلق یکدیگر نیستند و حتی می‌توانند در یک فرآیند Testing در کنار هم استفاده شوند.

در بخش بعدی، به سراغ API Test Automation می‌رویم و بررسی می‌کنیم چه زمانی تست دستی کافی نیست و چرا Automation برای Regression Testing اهمیت پیدا می‌کند. 🤖

API Test Automation چیست؟ 🤖

API Test Automation یعنی اجرای خودکار Testهای API با استفاده از Code یا ابزارهای Automation، به‌گونه‌ای که Tester بتواند Testها را بدون انجام دستی تمام مراحل، بارها و به‌صورت قابل تکرار اجرا کند.

هدف Automation فقط افزایش سرعت نیست. مهم‌تر از آن، ایجاد تست‌های قابل تکرار، قابل نگهداری و قابل اجرا در فرآیندهای CI/CD است.

چه زمانی API Testing را Automate کنیم؟ 🎯

همه Testها الزاماً ارزش Automation ندارند. معمولاً Testهایی که زیاد تکرار می‌شوند، نتیجه قابل پیش‌بینی دارند و در Regression Testing مورد استفاده قرار می‌گیرند، گزینه‌های مناسبی برای Automation هستند.

• Regression Testها
• Smoke Testهای API
• Testهای تکرارشونده
• Validationهای مهم Business Logic
• Contract Testها
• Testهای قابل اجرا در CI/CD
• Testهای Data-driven

یک مثال ساده از API Test Automation 🧪

فرض کنید Endpoint زیر باید اطلاعات User شماره 125 را برگرداند:

GET /api/users/125

در تست دستی ممکن است Tester هر بار Request را ارسال و Status Code و Response را بررسی کند.

اما در Automation می‌توان همین بررسی‌ها را به Test قابل اجرا تبدیل کرد:

GET /api/users/125

Assert:
Status Code == 200
Response.id == 125
Response.name is not empty
Response.email is valid

حالا این Test می‌تواند بارها بدون اجرای دستی مراحل تکرار شود.

API Testing با Python 🐍

Python یکی از زبان‌هایی است که می‌توان از آن برای Automation API Testing استفاده کرد. کتابخانه‌هایی مانند requests برای ارسال HTTP Request و Frameworkهایی مانند pytest برای ساخت و اجرای Testها کاربرد دارند.

import requests

def test_get_user():
    response = requests.get(
        "https://api.example.com/users/125"
    )

    assert response.status_code == 200
    assert response.json()["id"] == 125

این مثال ساده است، اما ایده اصلی API Automation را نشان می‌دهد: ارسال Request و بررسی نتیجه با Assertion.

API Testing با Playwright 🎭

Playwright فقط برای UI Testing نیست. این Framework امکان ارسال API Request و بررسی Response را نیز فراهم می‌کند.

const response = await request.get('/api/users/125');

expect(response.status()).toBe(200);

const body = await response.json();

expect(body.id).toBe(125);

این قابلیت به Tester اجازه می‌دهد API Testها را در کنار UI Testها و در یک Test Automation Framework مدیریت کند.

API Testing با Java و Rest Assured ☕

در اکوسیستم Java، کتابخانه Rest Assured یکی از ابزارهای شناخته‌شده برای تست APIهای REST است.

given()
    .when()
        .get("/api/users/125")
    .then()
        .statusCode(200);

Rest Assured امکان بررسی Status Code، Header، Response Body، JSON و Assertionهای مختلف را فراهم می‌کند.

Data-driven API Testing 📊

در بسیاری از پروژه‌ها لازم است یک Test با مجموعه‌ای از داده‌های مختلف اجرا شود. به این روش Data-driven Testing گفته می‌شود.

Test Data

username        expected
--------------------------------
valid_user      200
unknown_user    404
empty_user      400
invalid_user    400

به‌جای ایجاد Test جداگانه برای هر داده، می‌توان یک Test طراحی کرد که Dataهای مختلف را دریافت و اجرا کند.

API Testing در CI/CD 🔄

یکی از مهم‌ترین مزیت‌های Automation این است که API Testها می‌توانند در Pipelineهای CI/CD اجرا شوند.

Developer
   ↓
Commit
   ↓
Build
   ↓
API Tests 🧪
   ↓
Result
   ↓
Deploy 🚀

برای مثال، پس از هر تغییر در Code می‌توان مجموعه‌ای از API Testها را اجرا کرد. اگر Testهای حیاتی Fail شوند، Pipeline می‌تواند از ادامه فرآیند جلوگیری کند؛ البته سیاست دقیق Pipeline به پروژه بستگی دارد.

تفاوت API Testing دستی و Automation 📊

Manual API Testing	API Test Automation
اجرای دستی Request	اجرای خودکار
مناسب Exploration	مناسب Regression
تکرار زمان‌بر	تکرار سریع
مناسب بررسی‌های یک‌باره	مناسب Testهای پایدار و تکرارشونده
وابستگی بیشتر به Tester	قابل اجرا در CI/CD

Automation جایگزین Tester نیست 🧠

یکی از برداشت‌های اشتباه این است که با Automation دیگر نیازی به تست دستی وجود ندارد. در واقع Automation و Manual Testing اهداف متفاوتی دارند.

Automation برای اجرای سریع و قابل تکرار Testهای مشخص بسیار ارزشمند است، اما فعالیت‌هایی مانند Exploratory Testing، تحلیل رفتار غیرمنتظره، بررسی Usability و کشف سناریوهای جدید همچنان به تفکر و تحلیل Tester وابسته هستند.

بهترین رویکرد معمولاً ترکیبی از Manual Testing و Automation است؛ یعنی Tester تصمیم می‌گیرد چه چیزی را تست کند و Automation اجرای Testهای مناسب را سریع‌تر و پایدارتر می‌کند. 🚀

API Testing در CI/CD 🔄

یکی از مهم‌ترین مزیت‌های API Test Automation این است که Testها می‌توانند به بخشی از CI/CD Pipeline تبدیل شوند. در این حالت، تست API فقط زمانی اجرا نمی‌شود که Tester به‌صورت دستی آن را اجرا کند؛ بلکه می‌تواند در مراحل مختلف فرآیند توسعه نرم‌افزار به‌صورت خودکار اجرا شود.

Code Change
    ↓
Build
    ↓
API Tests 🧪
    ↓
Result
    ↓
Deploy 🚀

برای مثال، پس از Commit شدن تغییرات، Pipeline می‌تواند مجموعه‌ای از API Testهای مهم را اجرا کند. اگر تست‌های حیاتی Fail شوند، تیم می‌تواند قبل از انتشار نسخه جدید مشکل را بررسی کند.

Smoke Test در API چیست؟ 🔥

API Smoke Test مجموعه‌ای از تست‌های سریع و حیاتی است که برای بررسی سلامت اولیه سرویس اجرا می‌شود.

برای مثال، ممکن است بعد از Deploy نسخه جدید این موارد بررسی شوند:

• آیا API در دسترس است؟
• آیا Authentication کار می‌کند؟
• آیا Endpointهای اصلی پاسخ می‌دهند؟
• آیا Status Codeهای حیاتی صحیح هستند؟
• آیا Response ساختار مورد انتظار را دارد؟

هدف Smoke Test این نیست که تمام رفتار API را پوشش دهد؛ بلکه می‌خواهد خیلی سریع مشخص کند آیا سیستم برای ادامه Testing در وضعیت قابل قبولی قرار دارد یا خیر.

Regression Testing در API 🔁

هر تغییر در Backend ممکن است روی Endpointهای موجود تأثیر بگذارد. Regression Testing کمک می‌کند بررسی کنیم قابلیت‌هایی که قبلاً کار می‌کردند، پس از تغییر همچنان رفتار مورد انتظار را دارند.

برای مثال، فرض کنید Developer منطق مربوط به User را تغییر داده است. ممکن است این تغییر علاوه بر Endpoint جدید، روی Login، Profile یا Permissionهای قبلی نیز اثر بگذارد.

Change
  ↓
Run Regression API Tests
  ↓
Pass / Fail

API Test Automation برای Regression Testing بسیار ارزشمند است؛ زیرا مجموعه بزرگی از تست‌ها را می‌توان سریع و به‌صورت تکرارشونده اجرا کرد.

Contract Testing چیست؟ 📜

Contract Testing

فرض کنید یک Consumer انتظار دارد API چنین Responseای برگرداند:

{
  "id": 125,
  "name": "Ali",
  "email": "ali@example.com"
}

اگر Provider بدون هماهنگی، Field موردنیاز را حذف کند یا Type آن را تغییر دهد، ممکن است Consumer دچار مشکل شود؛ حتی اگر Endpoint همچنان Status Code 200 برگرداند.

Contract Testing در Microservices 🧩

Contract Testing در معماری‌های مبتنی بر Microservices اهمیت بیشتری پیدا می‌کند؛ زیرا تعداد ارتباطات بین سرویس‌ها زیاد است و تغییر یک Service می‌تواند روی Consumerهای آن تأثیر بگذارد.

Order Service
      ↓
Payment Service
      ↓
Notification Service

اگر Contract بین این سرویس‌ها به‌درستی کنترل نشود، ممکن است یک تغییر کوچک در Response باعث شکست سرویس دیگری شود.

API Test Pyramid 🔺

مانند UI Testing، در API Testing نیز بهتر است تمام تست‌ها در یک سطح قرار نگیرند. تست‌های سریع و پایدار API می‌توانند بخش مهمی از Test Suite را تشکیل دهند، در حالی که تعداد تست‌های End-to-End پرهزینه‌تر باید کنترل‌شده باشد.

        E2E Tests
       /         \
      /           \
   API / Integration
  /                 \
Unit Tests ───────────

هدف این رویکرد ایجاد تعادل بین سرعت، پوشش و هزینه نگهداری Test Suite است.

چرا API Test Automation ارزشمند است؟ 💡

• اجرای سریع تعداد زیادی Test
• کاهش خطای انسانی در تست‌های تکراری
• امکان اجرای مداوم Regression Testها
• امکان اجرای Testها در CI/CD
• دریافت سریع Feedback بعد از تغییرات
• امکان اجرای Data-driven Testها
• قابلیت ترکیب با سایر تست‌های Automation

اما همه چیز را Automate نکنیم ⚠️

Automation هزینه توسعه و نگهداری دارد. اگر Testی دائماً تغییر کند، ارزش تجاری کمی داشته باشد یا نیازمند قضاوت انسانی و Exploration باشد، ممکن است Automation آن انتخاب مناسبی نباشد.

Tester حرفه‌ای قبل از Automate کردن یک Test باید از خود بپرسد: «آیا ارزش اجرای مکرر این Test از هزینه ساخت و نگهداری Automation آن بیشتر است؟»

مسیر یادگیری API Testing برای Tester 🚀

برای یادگیری API Testing بهتر است مسیر را مرحله‌به‌مرحله طی کنید:

1. مفاهیم HTTP را یاد بگیرید.
2. Request و Response را به‌خوبی درک کنید.
3. JSON و Data Validation را تمرین کنید.
4. REST و API Contract را بشناسید.
5. Authentication و Authorization را تست کنید.
6. با Postman کار کنید.
7. Test Script و Assertion بنویسید.
8. API Test Automation را با یک زبان یا Framework یاد بگیرید.
9. Testها را وارد CI/CD کنید.

در ادامه مقاله، سراغ مهم‌ترین تکنیک‌ها و سناریوهای API Testing می‌رویم؛ یعنی جایی که Tester باید از مفاهیم تئوری عبور کند و برای پیدا کردن Bug، سناریوهای واقعی و هدفمند طراحی کند. 🧪

۸. تکنیک‌ها و سناریوهای مهم در API Testing 🧪

دانستن HTTP، REST، JSON و ابزارهای API به‌تنهایی یک Tester را به API Tester حرفه‌ای تبدیل نمی‌کند. بخش مهم مهارت API Testing این است که بتوانیم بر اساس Requirement و رفتار مورد انتظار سیستم، سناریوهای مناسب برای پیدا کردن Bug طراحی کنیم.

در این بخش، مهم‌ترین دسته‌های Test Scenario را بررسی می‌کنیم؛ از Validation داده‌ها و Boundary Testing گرفته تا Error Handling، Security و رفتار API در شرایط غیرمنتظره.

۸.۱. Positive Testing ✅

در Positive Testing، API با داده‌ها و شرایط معتبر فراخوانی می‌شود تا بررسی کنیم سیستم در شرایط عادی رفتار مورد انتظار را دارد یا خیر.

برای مثال، اگر Endpoint زیر برای دریافت اطلاعات User استفاده شود:

GET /api/users/125

سناریوی Positive می‌تواند شامل بررسی موارد زیر باشد:

• User با ID معتبر وجود داشته باشد.
• Credential معتبر ارسال شود.
• Request دارای ساختار صحیح باشد.
• Status Code مورد انتظار دریافت شود.
• Response دارای Fieldهای مورد انتظار باشد.
• مقادیر Response با داده واقعی User مطابقت داشته باشند.

۸.۲. Negative Testing ❌

در Negative Testing عمداً شرایط نامعتبر ایجاد می‌کنیم تا ببینیم API چگونه با خطاها و ورودی‌های غیرمجاز برخورد می‌کند.

برای مثال:

GET /api/users/invalid-id

• ارسال ID نامعتبر
• ارسال Fieldهای Required به‌صورت ناقص
• ارسال Data Type اشتباه
• ارسال Token نامعتبر
• حذف Authentication
• ارسال مقدار خارج از محدوده
• ارسال JSON نامعتبر

در Negative Testing نباید فقط بررسی کنیم که API خطا می‌دهد. باید بررسی کنیم آیا خطا به شکل صحیح و قابل پیش‌بینی مدیریت شده است یا خیر.

۸.۳. Boundary Value Testing 📏

اگر یک Field دارای محدودیت باشد، مقادیر مرزی اهمیت زیادی دارند.

فرض کنید Requirement می‌گوید مقدار age باید بین 18 تا 60 باشد.

مقدار	انتظار
17	❌ Invalid
18	✅ Valid
19	✅ Valid
59	✅ Valid
60	✅ Valid
61	❌ Invalid

مقادیر درست در اطراف Boundary می‌توانند Bugهایی را آشکار کنند که با Test کردن یک مقدار معمولی ممکن است دیده نشوند.

۸.۴. Equivalence Partitioning 🧩

در Equivalence Partitioning داده‌ها را به گروه‌هایی تقسیم می‌کنیم که انتظار داریم رفتار مشابهی داشته باشند.

برای مثال اگر مقدار سن باید بین 18 تا 60 باشد، می‌توان داده‌ها را به سه گروه تقسیم کرد:

• کمتر از 18 → Invalid
• 18 تا 60 → Valid
• بیشتر از 60 → Invalid

سپس به‌جای تست تعداد بسیار زیادی مقدار، می‌توان نماینده‌ای از هر Partition انتخاب کرد.

۸.۵. Input Validation 🔍

API باید ورودی‌ها را مطابق Requirement و Contract اعتبارسنجی کند. Tester باید بررسی کند که داده‌های نامعتبر به‌درستی شناسایی و مدیریت می‌شوند.

{
  "email": "not-an-email",
  "age": "twenty",
  "quantity": -5
}

در چنین سناریویی می‌توان Type، Format، Range و سایر Constraintهای مربوط به Fieldها را بررسی کرد.

۸.۶. Required Field Testing 📋

اگر API انتظار دارد Field خاصی همیشه در Request وجود داشته باشد، حذف آن Field یک سناریوی مهم تست است.

{
  "name": "Ali"
}

فرض کنید email نیز Required باشد. Tester باید بررسی کند API در صورت حذف آن چه رفتاری دارد و آیا Error Response مطابق Contract برمی‌گرداند یا خیر.

۸.۷. Data Type Testing 🔢

ارسال Type اشتباه یکی از سناریوهای ساده اما مهم API Testing است.

{
  "age": "30"
}

اگر Contract مشخص کرده باشد که age باید Number باشد، Tester باید بررسی کند API در برابر String چه رفتاری نشان می‌دهد.

۸.۸. Format Validation ✉️

بعضی Fieldها علاوه بر Type، Format مشخصی نیز دارند. Email، Date، URL و بعضی شناسه‌ها نمونه‌هایی از این Fieldها هستند.

{
  "email": "invalid",
  "birthDate": "not-a-date"
}

Tester باید بررسی کند که API داده‌هایی با Format نامعتبر را مطابق Requirement رد یا مدیریت می‌کند.

در بخش بعدی، سناریوهای مهم دیگری مانند Error Handling، Status Code، Pagination، Sorting، Filtering و Idempotency را بررسی می‌کنیم. 🚀

۸.۹. Status Code Testing 📊

یکی از مهم‌ترین بخش‌های API Testing بررسی HTTP Status Code است. Status Code فقط نشان نمی‌دهد Request موفق بوده یا شکست خورده؛ بلکه باید با رفتار واقعی Endpoint و Contract API نیز مطابقت داشته باشد.

برای مثال، اگر یک Resource با موفقیت دریافت شود، معمولاً انتظار دریافت 200 OK داریم. اما برای Resourceای که وجود ندارد، ممکن است API از 404 Not Found استفاده کند.

Status Code	مفهوم کلی	نمونه سناریو
200	OK	Request با موفقیت پردازش شده
201	Created	Resource جدید ایجاد شده
204	No Content	عملیات موفق بدون Response Body
400	Bad Request	Request نامعتبر
401	Unauthorized	Authentication معتبر نیست یا وجود ندارد
403	Forbidden	دسترسی مجاز نیست
404	Not Found	Resource پیدا نشد
409	Conflict	تعارض با وضعیت فعلی Resource
422	Unprocessable Content	داده از نظر Syntax قابل پردازش است اما Validation یا Semantic Rule را نقض می‌کند
500	Internal Server Error	خطای غیرمنتظره در Server

این جدول یک راهنمای کلی است و Status Code صحیح باید بر اساس API Contract و طراحی واقعی سیستم تعیین شود.

۸.۱۰. Error Handling Testing ❌

یک API خوب فقط در شرایط موفق عملکرد مناسبی ندارد؛ بلکه باید بتواند خطاها را نیز به‌صورت قابل پیش‌بینی مدیریت کند.

برای مثال اگر کاربر ID نامعتبری ارسال کند، Tester باید بررسی کند:

• Status Code مناسب باشد.
• Error Response ساختار مشخصی داشته باشد.
• پیام خطا برای Client قابل فهم باشد.
• اطلاعات حساس یا جزئیات داخلی Server افشا نشود.
• Response با API Contract مطابقت داشته باشد.

{
  "error": {
    "code": "USER_NOT_FOUND",
    "message": "User not found"
  }
}

ساختار Error Response به طراحی API بستگی دارد، اما Consistency در Error Handling برای Clientها و Test Automation اهمیت زیادی دارد.

۸.۱۱. Pagination Testing 📄

وقتی یک Endpoint تعداد زیادی Resource برمی‌گرداند، معمولاً داده‌ها به چند صفحه تقسیم می‌شوند. این قابلیت را Pagination می‌نامیم.

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

Tester باید فقط بررسی نکند که Response دریافت می‌شود؛ بلکه رفتار Pagination را نیز بررسی کند.

• صفحه اول داده صحیح را برگرداند.
• تعداد عناصر هر صفحه صحیح باشد.
• صفحه بعدی داده‌های مورد انتظار را برگرداند.
• صفحه آخر به‌درستی مدیریت شود.
• Page خارج از محدوده رفتار مشخصی داشته باشد.
• مقدار Limit نامعتبر یا غیرمجاز به‌درستی مدیریت شود.
• داده‌ای بین صفحات به‌صورت ناخواسته تکرار یا حذف نشود.

۸.۱۲. Sorting Testing ↕️

اگر API امکان مرتب‌سازی داده‌ها را فراهم کند، باید ترتیب Response با پارامترهای ارسال‌شده مطابقت داشته باشد.

GET /api/products?sort=price&order=asc

در این مثال Tester باید بررسی کند محصولات واقعاً بر اساس Price از کم به زیاد مرتب شده باشند.

همچنین باید حالت‌های مختلف مانند Ascending، Descending، Field نامعتبر و ترکیب Sorting با Filtering و Pagination بررسی شوند؛ البته پارامترهای واقعی به Contract API بستگی دارند.

۸.۱۳. Filtering Testing 🔎

Filtering به Client اجازه می‌دهد فقط بخشی از داده‌ها را دریافت کند.

GET /api/products?category=book

سناریوهای مهم شامل Filter معتبر، Filter بدون نتیجه، Filter با مقدار نامعتبر و ترکیب چند Filter هستند.

همچنین باید بررسی شود که Response واقعاً با شرط Filter مطابقت دارد و داده‌ای خارج از شرط موردنظر برگردانده نمی‌شود.

۸.۱۴. Idempotency Testing 🔁

Idempotency به این مفهوم مربوط است که اجرای چندباره یک عملیات با همان ورودی، از نظر اثر نهایی روی Resource چه رفتاری ایجاد می‌کند.

برای مثال، در APIهایی که برای عملیات خاص از مکانیزم Idempotency Key استفاده می‌کنند، ارسال مجدد یک Request ممکن است نباید باعث ایجاد چندباره یک عملیات شود.

POST /api/payments
Idempotency-Key: abc-123

Tester باید بر اساس Contract بررسی کند که ارسال مجدد Request با همان Key چه نتیجه‌ای دارد و آیا سیستم از ایجاد عملیات تکراری جلوگیری می‌کند یا خیر.

۸.۱۵. Duplicate Request Testing 🔄

در سیستم‌هایی که عملیات مالی، سفارش، ثبت‌نام یا ایجاد Resource انجام می‌دهند، ارسال ناخواسته یک Request تکراری می‌تواند پیامد مهمی داشته باشد.

Tester باید سناریوهایی مانند Double Click، Retry، Timeout و ارسال مجدد همان Request را در نظر بگیرد و بررسی کند آیا سیستم طبق طراحی از ایجاد عملیات تکراری جلوگیری می‌کند یا خیر.

۸.۱۶. Timeout و رفتار API در شرایط کندی ⏱️

همیشه Server بلافاصله Response نمی‌دهد. ممکن است Database، سرویس خارجی یا یکی از Microserviceها کند شده باشد.

در چنین شرایطی Tester باید رفتار Timeout و Retry را بررسی کند؛ به‌خصوص در APIهایی که عملیات آن‌ها Side Effect دارد.

هدف این تست فقط بررسی زمان Response نیست؛ بلکه باید مشخص شود در صورت Timeout، سیستم وارد وضعیت ناسازگار نمی‌شود و Retry باعث اجرای ناخواسته عملیات نمی‌شود.

در بخش بعدی، به سراغ Performance Testing، Rate Limiting و سناریوهای امنیتی API می‌رویم. 🚀

۸.۱۷. Rate Limiting Testing 🚦

Rate Limiting مکانیزمی است که تعداد Requestهای مجاز یک Client، User یا API Key را در یک بازه زمانی محدود می‌کند.

برای مثال، ممکن است API اجازه دهد یک Client در یک بازه مشخص تعداد محدودی Request ارسال کند.

GET /api/products

Request 1 → 200
Request 2 → 200
...
Request N → 429 Too Many Requests

در تست Rate Limiting باید بررسی کنیم پس از عبور از Limit، API رفتار مورد انتظار را نشان می‌دهد و Requestهای بیش از حد مجاز را مدیریت می‌کند.

Retry و Rate Limiting 🔄

گاهی Client در مواجهه با خطاهایی مانند 429 یا خطاهای موقت، Request را دوباره ارسال می‌کند. اگر Retry Policy به‌درستی طراحی نشده باشد، ممکن است فشار بیشتری به API وارد شود.

در صورت وجود Retry Mechanism، Tester باید رفتار آن را نیز بررسی کند؛ برای مثال تعداد Retryها، فاصله بین Retryها و اینکه چه خطاهایی باید یا نباید باعث Retry شوند.

۸.۱۸. API Performance Testing ⚡

Performance Testing در API Testing برای بررسی رفتار API تحت بارها و شرایط مختلف انجام می‌شود. هدف فقط پیدا کردن سریع‌ترین Response نیست؛ بلکه باید بررسی کنیم API در شرایط واقعی و مورد انتظار سیستم چگونه رفتار می‌کند.

• Response Time
• Throughput
• Concurrent Users یا Requests
• Error Rate
• Resource Utilization
• رفتار سیستم در افزایش Load

برای مثال، API ممکن است در حالت عادی Response بسیار سریعی داشته باشد، اما با افزایش تعداد Requestها، Response Time آن به‌شدت افزایش پیدا کند.

Load Testing برای API 📈

در Load Testing API را تحت Load مورد انتظار قرار می‌دهیم تا ببینیم سیستم در شرایط معمول کاری چگونه عمل می‌کند.

برای مثال:

100 Requests/second
500 Requests/second
1000 Requests/second

Tester می‌تواند Response Time، Error Rate و Throughput را در هر سطح از Load مقایسه کند.

Stress Testing برای API 💥

در Stress Testing Load را فراتر از شرایط عادی افزایش می‌دهیم تا مشخص شود نقطه شکست سیستم کجاست و API هنگام نزدیک شدن یا عبور از ظرفیت مورد انتظار چگونه رفتار می‌کند.

یک API خوب فقط در شرایط عادی مهم نیست؛ نحوه رفتار آن هنگام Overload نیز اهمیت دارد.

۸.۱۹. API Security Testing 🔐

API Security Testing برای بررسی نقاط ضعف امنیتی API انجام می‌شود. Tester باید بررسی کند آیا Authentication، Authorization، Input Validation و مدیریت اطلاعات حساس به‌درستی پیاده‌سازی شده‌اند یا خیر.

• Authentication Bypass
• Broken Access Control
• دسترسی به Resource کاربر دیگر
• Input Validation
• افشای اطلاعات حساس
• مدیریت نادرست Token
• Rate Limiting
• مدیریت نامناسب Errorها

۸.۲۰. Sensitive Data Exposure 🔒

API ممکن است اطلاعاتی را در Response برگرداند که Client واقعاً به آن‌ها نیاز ندارد یا نباید آن‌ها را مشاهده کند.

{
  "id": 125,
  "name": "Ali",
  "email": "ali@example.com",
  "passwordHash": "...",
  "internalId": "..."
}

Tester باید بررسی کند Response فقط شامل اطلاعات موردنیاز و مجاز باشد و داده‌های حساس مانند Credentialها، Secretها یا اطلاعات داخلی سیستم به‌صورت ناخواسته در اختیار Client قرار نگیرند.

۸.۲۱. Mass Assignment Testing 🧩

در برخی APIها Client می‌تواند چندین Field را برای ایجاد یا Update یک Resource ارسال کند. اگر Server بدون کنترل مناسب این Fieldها را بپذیرد، ممکن است کاربر بتواند Propertyهایی را تغییر دهد که نباید تحت کنترل او باشند.

{
  "name": "Ali",
  "role": "admin"
}

اگر کاربر عادی فقط اجازه تغییر name را داشته باشد، باید بررسی شود که ارسال Fieldهایی مانند role باعث ارتقای غیرمجاز سطح دسترسی نشود.

۸.۲۲. Injection Testing 💉

هر جایی که API ورودی کاربر را دریافت و در پردازش‌های دیگر استفاده می‌کند، Input Validation اهمیت پیدا می‌کند. Testerهای امنیتی ممکن است سناریوهای Injection را در محیط مجاز تست بررسی کنند.

نوع Injection به Technology و نحوه پردازش Input بستگی دارد و می‌تواند شامل مواردی مانند SQL Injection یا سایر Injectionهای مرتبط با Componentهای سیستم باشد.

هدف Tester در اینجا بررسی این است که داده ورودی به‌درستی Validate و به شکل امن پردازش شود و ورودی کاربر نتواند رفتار ناخواسته‌ای در سیستم ایجاد کند.

۸.۲۳. API Versioning Testing 🔢

APIها ممکن است در طول زمان تغییر کنند و نسخه‌های مختلفی داشته باشند.

/api/v1/users
/api/v2/users

در چنین شرایطی Tester باید بررسی کند Version جدید مطابق Contract خود رفتار می‌کند و تغییرات آن باعث شکستن رفتار مورد انتظار Consumerهای نسخه قبلی نمی‌شود؛ البته سیاست سازگاری بین نسخه‌ها به طراحی پروژه بستگی دارد.

۸.۲۴. Backward Compatibility Testing 🔄

اگر نسخه جدید API منتشر شود، ممکن است هنوز Clientهای قدیمی از نسخه قبلی استفاده کنند. بنابراین در صورت وجود Requirement برای Backward Compatibility، Tester باید بررسی کند تغییرات جدید باعث شکستن Consumerهای موجود نشده باشند.

تغییراتی مانند حذف Field، تغییر Data Type یا تغییر رفتار Status Code می‌توانند برای Consumerهای قبلی مشکل ایجاد کنند.

API Testing یعنی بررسی رفتار، نه فقط Response 🎯

همان‌طور که دیدیم، یک API Tester حرفه‌ای فقط به این سؤال پاسخ نمی‌دهد که «آیا Response دریافت شد؟» بلکه بررسی می‌کند API در شرایط مختلف، از ورودی معتبر و نامعتبر گرفته تا Load، Authentication، Authorization و خطاهای غیرمنتظره، مطابق Requirement و Contract رفتار می‌کند.

در بخش بعدی، به سراغ چرخه کامل API Testing می‌رویم و مرحله‌به‌مرحله بررسی می‌کنیم که یک Tester از زمان دریافت Requirement تا طراحی، اجرای، گزارش‌دهی و Automation تست‌های API چه مسیری را طی می‌کند. 🚀

۹. چرخه کامل API Testing از Requirement تا گزارش Bug 🔄

API Testing فقط به ارسال چند Request در Postman و بررسی Response محدود نمی‌شود. یک فرآیند حرفه‌ای از زمانی آغاز می‌شود که Tester Requirement و Contract مربوط به API را دریافت می‌کند و تا تحلیل نتایج، ثبت Bug و اجرای Regression ادامه پیدا می‌کند.

شناخت این چرخه به Tester کمک می‌کند تست API را به‌صورت سیستماتیک انجام دهد و از تست‌های پراکنده و بدون هدف جلوگیری کند.

۹.۱. بررسی Requirement 📋

اولین قدم، درک رفتار مورد انتظار API است. قبل از ارسال Request باید بدانیم Endpoint برای چه کاری طراحی شده و چه قوانینی باید رعایت شوند.

مواردی که Tester باید بررسی کند شامل این موارد است:

• هدف Endpoint چیست؟
• چه HTTP Methodی استفاده می‌شود؟
• چه Parameterهایی وجود دارد؟
• کدام Fieldها Required هستند؟
• چه Data Typeهایی مورد انتظار هستند؟
• چه Status Codeهایی باید برگردند؟
• چه Roleهایی مجاز به استفاده از Endpoint هستند؟
• رفتار API در شرایط Error چیست؟

۹.۲. بررسی API Documentation 📘

پس از Requirement، Tester باید Documentation مربوط به API را بررسی کند. این Documentation ممکن است با OpenAPI/Swagger یا مستندات داخلی پروژه ارائه شده باشد.

هدف این مرحله این است که Tester دقیقاً بداند API چه Contractی دارد و چه چیزی باید تست شود.

۹.۳. طراحی Test Scenario 🧠

بعد از شناخت Requirement، باید Test Scenarioهای مناسب طراحی شوند. در این مرحله نباید فقط Happy Path را در نظر گرفت.

• Positive Scenario
• Negative Scenario
• Boundary Value
• Equivalence Partitioning
• Authentication
• Authorization
• Error Handling
• Data Validation
• Performance
• Security

۹.۴. آماده‌سازی Test Data 🗂️

کیفیت API Test تا حد زیادی به کیفیت Test Data وابسته است. Tester باید داده‌های مناسب برای سناریوهای مختلف آماده کند.

نوع داده	مثال
Valid	User معتبر
Invalid	Email نامعتبر
Boundary	حداقل و حداکثر مقدار
Empty	رشته خالی
Null	مقدار null
Duplicate	داده تکراری
Unauthorized	User بدون Permission

همچنین باید مشخص شود Test Data مربوط به کدام Environment است و آیا اجرای Test ممکن است روی داده‌های واقعی یا سایر Testها تأثیر بگذارد یا خیر.

۹.۵. اجرای Request 🔌

در این مرحله Tester Request را با ابزار مناسب ارسال می‌کند. برای تست‌های دستی می‌توان از ابزارهایی مانند Postman، Swagger UI یا cURL استفاده کرد.

POST /api/users

Content-Type: application/json

{
  "name": "Ali",
  "email": "ali@example.com"
}

۹.۶. بررسی Response 🔍

بعد از دریافت Response باید آن را با Expected Result مقایسه کنیم. این مقایسه باید چند لایه داشته باشد و فقط به Status Code محدود نشود.

• Status Code
• Response Headers
• Response Body
• Data Typeها
• مقادیر Fieldها
• Business Rules
• Response Time
• Security Requirements

۹.۷. Assertion چیست؟ ✅

Assertion یک شرط قابل بررسی است که مشخص می‌کند نتیجه Test با Expected Result مطابقت دارد یا خیر.

Expected:
Status Code = 200
User ID = 125

Actual:
Status Code = 200
User ID = 125

Result: PASS ✅

در Automation، Assertionها باعث می‌شوند Test بتواند نتیجه را به‌صورت خودکار ارزیابی کند.

۹.۸. ثبت نتیجه Test 📝

نتیجه اجرای Test باید قابل پیگیری باشد. بسته به فرآیند تیم، نتیجه ممکن است در Test Management Tool، Test Case، Automation Report یا ابزار مدیریت پروژه ثبت شود.

برای Testهای مهم بهتر است مشخص باشد چه چیزی تست شده، با چه داده‌ای اجرا شده و نتیجه چه بوده است.

۹.۹. گزارش Bug 🐞

اگر Actual Result با Expected Result مطابقت نداشته باشد، Tester باید بررسی کند آیا واقعاً یک Defect وجود دارد یا مشکل از Test Data، Environment، Documentation یا Configuration است.

در صورت تأیید Defect، باید Bug Report دقیق و قابل بازتولید ثبت شود.

یک API Bug Report خوب چه اطلاعاتی دارد؟ 🐞

• عنوان واضح
• Environment
• Endpoint
• HTTP Method
• Request Headers
• Request Body یا Parameters
• مراحل بازتولید
• Expected Result
• Actual Result
• Status Code
• Response Body
• Severity و Priority در صورت استفاده در فرآیند تیم
• Log یا Screenshot در صورت نیاز

POST /api/users

Expected:
400 Bad Request

Actual:
500 Internal Server Error

Request:
{
  "name": "Ali"
}

Result:
API returns 500 when required email is missing.

این اطلاعات به Developer کمک می‌کند مشکل را سریع‌تر بازتولید و تحلیل کند.

۹.۱۰. Retest و Regression 🔁

پس از Fix شدن Bug، Tester ابتدا باید همان سناریوی قبلی را دوباره اجرا کند تا مشخص شود Defect واقعاً برطرف شده است. این مرحله Retesting است.

پس از آن، در صورت نیاز باید تست‌های مرتبط و Regression Testها نیز اجرا شوند تا مشخص شود Fix جدید مشکل دیگری ایجاد نکرده است.

Requirement
   ↓
Test Design
   ↓
Test Data
   ↓
Request
   ↓
Validation
   ↓
PASS / FAIL
   ↓
Bug Report 🐞
   ↓
Fix
   ↓
Retest
   ↓
Regression 🔄

این چرخه نشان می‌دهد API Testing یک فعالیت یک‌باره نیست؛ بلکه بخشی از چرخه مداوم کیفیت نرم‌افزار است.

۹.۱۱. API Testing در محیط‌های مختلف 🌍

API معمولاً در چند Environment مختلف اجرا می‌شود؛ برای مثال Development، Testing، Staging و در نهایت Production.

Tester باید بداند Testها در کدام Environment اجرا می‌شوند و چه تفاوت‌هایی میان این محیط‌ها وجود دارد.

Environment	کاربرد معمول
Development	توسعه و بررسی اولیه
Testing	اجرای Testهای تیم QA
Staging	شبیه‌سازی نزدیک‌تر به Production
Production	محیط واقعی کاربران

اجرای Test روی Environment اشتباه می‌تواند باعث نتیجه‌گیری نادرست یا حتی آسیب به داده‌های واقعی شود. بنابراین قبل از اجرای Test باید Environment و Test Data به‌دقت مشخص شده باشند.

۹.۱۲. مدیریت Environment و Configuration ⚙️

URL، Credential، API Key و سایر Configurationها ممکن است بین Environmentهای مختلف متفاوت باشند. بهتر است این اطلاعات از Test Logic جدا نگه داشته شوند.

BASE_URL=https://staging.example.com
API_VERSION=v1

در Automation می‌توان Configuration مناسب هر Environment را در اختیار Test Suite قرار داد تا یک مجموعه Test بدون تغییر در منطق اصلی، در محیط‌های مختلف اجرا شود.

۹.۱۳. Secretها را داخل Test Code قرار ندهید 🔐

یکی از نکات مهم در API Automation، مدیریت Credentialها و Secretهاست. اطلاعاتی مانند Password، API Key، Access Token و Secret Key نباید به‌صورت Hard-code در Repository قرار بگیرند.

// نامناسب ❌
const token = "real-secret-token";

بهتر است Secretها از روش‌های مناسب Configuration یا Secret Management دریافت شوند.

// ایده کلی
const token = process.env.API_TOKEN;

این موضوع به‌خصوص زمانی اهمیت دارد که Test Automation وارد Git و CI/CD Pipeline می‌شود.

۹.۱۴. API Test Data Management 🗂️

در پروژه‌های بزرگ، مدیریت Test Data می‌تواند به یکی از چالش‌های اصلی API Testing تبدیل شود. Testها نباید بدون توجه به وابستگی داده‌ها به یکدیگر اجرا شوند.

برای مثال، ممکن است ابتدا یک User ایجاد شود و سپس ID ایجادشده برای Testهای بعدی مورد استفاده قرار گیرد.

Create User
     ↓
Get User ID
     ↓
Update User
     ↓
Get User
     ↓
Delete User

اگر Testها به داده‌های ثابت وابسته باشند، تغییر Environment یا حذف داده می‌تواند باعث Fail شدن Test شود. بنابراین در Automation باید تا حد امکان Test Data قابل کنترل و مستقل طراحی شود.

۹.۱۵. Chaining بین API Requestها 🔗

گاهی نتیجه یک API Request ورودی Request بعدی است. این مفهوم در API Testing با نام‌هایی مانند Request Chaining شناخته می‌شود.

Login
  ↓
Access Token
  ↓
Create Order
  ↓
Order ID
  ↓
Get Order
  ↓
Cancel Order

در این حالت Tester باید علاوه بر هر Request، انتقال صحیح داده بین مراحل را نیز بررسی کند.

۹.۱۶. Dependency بین Testها ⚠️

وابستگی زیاد Testها به یکدیگر می‌تواند نگهداری Automation Suite را دشوار کند. اگر Test شماره ۲ فقط در صورت موفقیت Test شماره ۱ قابل اجرا باشد، شکست Test اول ممکن است باعث شکست زنجیره‌ای Testهای بعدی شود.

تا حد امکان بهتر است Testها مستقل باشند یا Dependency آن‌ها به‌صورت آگاهانه و کنترل‌شده مدیریت شود.

۹.۱۷. API Mocking و Virtualization 🎭

گاهی API موردنیاز برای Testing هنوز آماده نیست یا وابستگی به یک سرویس خارجی باعث می‌شود اجرای Test دشوار شود. در چنین شرایطی می‌توان از Mock یا Virtual Service استفاده کرد.

برای مثال، فرض کنید Order Service به Payment Service وابسته است، اما Payment Service هنوز آماده نیست.

Order Service
      ↓
   Payment API
      ↓
   [Mock Service]

Mock می‌تواند Responseهای مشخصی برگرداند تا Tester بتواند رفتار Order Service را در شرایط مختلف بررسی کند.

Mock برای سناریوهای Error نیز مفید است 🚨

یکی از مزیت‌های مهم Mock این است که Tester می‌تواند شرایطی را ایجاد کند که در محیط واقعی به‌سختی قابل تکرار هستند.

• 500 Internal Server Error
• Timeout
• Slow Response
• Connection Failure
• Invalid Response
• External Service Unavailable

به این ترتیب می‌توان بررسی کرد سیستم در مواجهه با Failure سرویس‌های وابسته چه رفتاری دارد.

۹.۱۸. API Testing در Microservices 🧩

در معماری Microservices، APIها معمولاً نقش مهمی در ارتباط بین Serviceها دارند. به همین دلیل API Testing باید علاوه بر یک Endpoint، تعامل میان سرویس‌ها را نیز در نظر بگیرد.

User Service
     ↓
Order Service
     ↓
Payment Service
     ↓
Notification Service

در چنین معماری‌ای، Failure یک Service می‌تواند روی چند Service دیگر تأثیر بگذارد. بنابراین تست Error Handling، Timeout، Retry، Contract و Dependencyها اهمیت بیشتری پیدا می‌کند.

در بخش بعدی، به سراغ API Testing در معماری Microservices و تفاوت آن با تست یک Monolithic API می‌رویم و نقش Tester را در این معماری دقیق‌تر بررسی می‌کنیم. 🧩

۹.۱۹. API Testing در معماری Microservices 🧩

در معماری Microservices، سیستم به مجموعه‌ای از Serviceهای کوچک‌تر تقسیم می‌شود که هرکدام مسئولیت مشخصی دارند و معمولاً از طریق API با یکدیگر ارتباط برقرار می‌کنند.

این معماری فرصت‌های جدیدی برای تست ایجاد می‌کند، اما در مقابل پیچیدگی API Testing را نیز افزایش می‌دهد؛ زیرا Tester دیگر فقط با یک API و یک Backend سروکار ندارد.

Client
  ↓
API Gateway
  ↓
┌───────────────┐
│ User Service  │
├───────────────┤
│ Order Service │
├───────────────┤
│ Payment       │
├───────────────┤
│ Notification  │
└───────────────┘

۹.۲۰. چه چیزهایی در Microservices باید تست شوند؟ 🔍

در یک سیستم Microservices، فقط تست کردن Response یک Endpoint کافی نیست. Tester باید رفتار Service و ارتباط آن با سایر اجزای سیستم را نیز بررسی کند.

• API Contract
• ارتباط بین Serviceها
• Authentication و Authorization
• Error Handling
• Timeout
• Retry
• Data Consistency
• Message و Eventها در صورت وجود
• Backward Compatibility
• رفتار سیستم هنگام Down شدن Dependency

۹.۲۱. Consumer و Provider در Contract Testing 🤝

در Contract Testing معمولاً دو طرف ارتباط اهمیت دارند: Consumer که از API استفاده می‌کند و Provider که API را ارائه می‌دهد.

Consumer
    │
    │  Request
    ▼
Provider
    │
    │  Response
    ▼
Consumer

اگر Provider ساختار Response را تغییر دهد، ممکن است Consumer دیگر نتواند با آن کار کند. Contract Testing کمک می‌کند این نوع ناسازگاری‌ها زودتر شناسایی شوند.

۹.۲۲. API Gateway Testing 🚪

در بسیاری از معماری‌های Microservices، Client مستقیماً با همه Serviceها ارتباط ندارد و درخواست‌ها ابتدا از طریق API Gateway عبور می‌کنند.

Client
   ↓
API Gateway
   ↓
Service A
Service B
Service C

در این حالت Tester باید علاوه بر Serviceهای داخلی، رفتار Gateway را نیز بررسی کند.

• Routing صحیح Request
• Authentication
• Authorization
• Rate Limiting
• Header Transformation
• Error Handling
• Timeout و رفتار Dependencyها

۹.۲۳. Distributed Failure Testing 💥

در سیستم‌های توزیع‌شده، Failure یک Service لزوماً به معنی از کار افتادن کل سیستم نیست. ممکن است سیستم برای برخی عملیات همچنان قابل استفاده باشد.

برای مثال، اگر Notification Service از دسترس خارج شود، ممکن است ثبت سفارش همچنان باید موفق باشد؛ فقط ارسال Notification با مشکل مواجه شود.

Create Order
     ↓
Order Service ────────→ Success ✅
     │
     ↓
Notification Service ─→ Failure ❌

Tester باید بررسی کند سیستم در چنین شرایطی مطابق طراحی خود رفتار می‌کند و Failure یک Dependency باعث ایجاد رفتارهای ناخواسته یا از دست رفتن داده نمی‌شود.

۹.۲۴. Event-driven API Testing 📡

در بعضی Microservices Architectureها ارتباط Serviceها فقط از طریق Request/Response نیست و از Message یا Event نیز استفاده می‌شود.

Order Created
     ↓
OrderCreated Event
     ↓
┌───────────────┐
│ Payment       │
│ Notification  │
│ Analytics     │
└───────────────┘

در این شرایط Tester باید علاوه بر API، انتشار Event، محتوای Message، Consumerها و رفتار سیستم در صورت پردازش مجدد یا شکست مصرف Message را نیز در نظر بگیرد.

۹.۲۵. Eventual Consistency 🔄

در سیستم‌های توزیع‌شده ممکن است تغییر ایجادشده در یک Service بلافاصله در تمام Serviceهای دیگر قابل مشاهده نباشد. این وضعیت می‌تواند بخشی از طراحی سیستم و مفهوم Eventual Consistency باشد.

بنابراین Tester نباید بدون شناخت Requirement، هر تأخیر کوتاهی در مشاهده داده را Bug تلقی کند. ابتدا باید مشخص شود سیستم چه سطحی از Consistency را انتظار دارد.

۹.۲۶. API Testing در مقایسه با UI Testing 🆚

API Testing و UI Testing جایگزین یکدیگر نیستند؛ هرکدام سطح متفاوتی از سیستم را بررسی می‌کنند.

API Testing	UI Testing
تمرکز روی Backend و API Contract	تمرکز روی رابط کاربری و رفتار End-to-End
معمولاً سریع‌تر	معمولاً کندتر
کمتر وابسته به UI	وابسته به UI
مناسب Validation منطق Backend	مناسب بررسی جریان واقعی کاربر
پایدارتر در برابر تغییرات UI	حساس‌تر به تغییرات UI

به همین دلیل، استفاده از API Testها در کنار UI Testها می‌تواند پوشش مناسبی ایجاد کند و بسیاری از Validationها را در لایه‌ای سریع‌تر انجام دهد.

۹.۲۷. آیا API Testing برای یک Manual Tester ضروری است؟ 🤔

برای Tester امروزی، آشنایی با API Testing یک مهارت بسیار ارزشمند است؛ حتی اگر هنوز وارد Automation نشده باشد.

دلیل آن این است که بخش بزرگی از منطق نرم‌افزار در Backend اجرا می‌شود و UI فقط یکی از راه‌های تعامل با آن است. Tester با شناخت API می‌تواند بدون وابستگی کامل به UI، رفتار Backend را مستقیماً بررسی کند.

• درک بهتر معماری نرم‌افزار
• توانایی بررسی Backend
• کشف Bugهای خارج از UI
• Debugging مؤثرتر
• آمادگی بهتر برای Automation
• درک بهتر Microservices
• تعامل بهتر با Developerها

در واقع API Testing می‌تواند یکی از مهم‌ترین پل‌ها بین Manual Testing و Test Automation باشد. 🚀

در بخش بعدی، به جمع‌بندی مهارت‌هایی می‌رسیم که یک API Tester باید یاد بگیرد و یک مسیر عملی برای تبدیل شدن به Tester مسلط به API Testing ارائه می‌کنیم. 🎯

۱۰. مهارت‌های موردنیاز یک API Tester حرفه‌ای 🎯

API Testing فقط یادگیری یک ابزار مانند Postman نیست. یک API Tester حرفه‌ای باید ترکیبی از دانش Testing، HTTP، API، Backend، Automation و Security داشته باشد.

لازم نیست همه این مهارت‌ها را از روز اول در سطح پیشرفته بدانید. مهم این است که مسیر یادگیری را درست بچینید و مرحله‌به‌مرحله پیش بروید.

۱۰.۱. دانش HTTP 🌐

اولین پایه برای API Testing، شناخت HTTP است. Tester باید بتواند Request و Response را تحلیل کند و مفهوم اجزای مختلف آن‌ها را بفهمد.

• HTTP Methods
• Status Codes
• Headers
• Cookies
• Query Parameters
• Path Parameters
• Request Body
• Response Body
• Authentication

بدون این دانش، کار با ابزارهای API بیشتر به اجرای دستورات آماده شبیه می‌شود تا Testing واقعی.

۱۰.۲. شناخت REST و API Design 🧩

Tester باید اصول کلی REST و نحوه طراحی API را بشناسد. برای مثال، تفاوت Resource، Endpoint، Method و Representation را درک کند.

همچنین آشنایی با مفاهیمی مانند Statelessness، Resource Naming، HTTP Semantics و API Versioning به تحلیل بهتر API کمک می‌کند.

۱۰.۳. JSON و Data Validation 🔢

بخش زیادی از APIهای امروزی از JSON استفاده می‌کنند. بنابراین Tester باید بتواند JSON را بخواند، ساختار آن را تحلیل کند و مقدار Fieldها و Data Typeهای آن را بررسی کند.

{
  "id": 125,
  "name": "Ali",
  "active": true,
  "roles": ["user", "customer"]
}

در این مثال Tester باید بتواند تشخیص دهد که id یک Number، name یک String، active یک Boolean و roles یک Array است.

۱۰.۴. SQL و Database Testing 🗄️

API در بسیاری از سیستم‌ها مستقیماً یا غیرمستقیم با Database ارتباط دارد. به همین دلیل آشنایی با SQL می‌تواند قدرت Tester را به‌طور قابل‌توجهی افزایش دهد.

برای مثال، اگر API یک User جدید ایجاد کند، Tester می‌تواند در محیط مجاز بررسی کند آیا داده مربوط به آن واقعاً در Database ثبت شده است یا خیر.

SELECT id, name, email
FROM users
WHERE id = 125;

البته Database Validation باید مطابق معماری و سطح دسترسی پروژه انجام شود و نباید به‌عنوان جایگزین Validation خود API در نظر گرفته شود.

۱۰.۵. Authentication و Authorization 🔐

Tester باید تفاوت Authentication و Authorization را به‌خوبی بداند.

• Authentication: آیا کاربر یا Client واقعاً همان موجودیتی است که ادعا می‌کند؟
• Authorization: آیا این User اجازه انجام این عملیات را دارد؟

در API Testing باید هر دو مفهوم در سناریوهای مختلف بررسی شوند؛ از User بدون Login گرفته تا User دارای Permission محدود.

۱۰.۶. کار با ابزارهای API 🛠️

یک API Tester باید حداقل با یک ابزار مناسب API Testing به‌خوبی کار کند. Postman یکی از ابزارهای رایج برای ارسال Request، ساخت Collection، تعریف Environment و اجرای Testهاست.

در کنار آن، آشنایی با ابزارهایی مانند Swagger UI و cURL نیز می‌تواند مفید باشد.

۱۰.۷. API Automation 🤖

بعد از تسلط بر Manual API Testing، مرحله بعدی می‌تواند ورود به Automation باشد. Tester باید بتواند Testهای قابل تکرار را به Code تبدیل کند.

بر اساس Technology Stack پروژه می‌توان از ابزارها و Frameworkهای مختلف استفاده کرد؛ برای مثال:

• Python + pytest + requests
• Java + Rest Assured
• JavaScript/TypeScript + Playwright
• ابزارهای Automation موجود در API Testing Platformها

انتخاب ابزار باید بر اساس نیاز پروژه، زبان تیم و زیرساخت Automation انجام شود، نه صرفاً محبوبیت یک ابزار.

۱۰.۸. Git و Version Control 🌿

وقتی API Testها به Code تبدیل می‌شوند، آشنایی با Git تقریباً ضروری می‌شود. Tester باید بتواند Test Code را دریافت، تغییر، Commit و با Branchهای تیم کار کند.

همچنین باید مفاهیم پایه‌ای مانند Branch، Pull Request، Merge و Conflict Resolution را بشناسد.

۱۰.۹. CI/CD 🔄

API Automation زمانی ارزش بیشتری پیدا می‌کند که بتواند به‌صورت خودکار در CI/CD Pipeline اجرا شود.

Tester بهتر است با مفاهیمی مانند Build، Pipeline، Test Stage، Environment Variable و Test Report آشنا باشد.

Commit
  ↓
Build
  ↓
API Test Suite 🧪
  ↓
Report
  ↓
Deploy 🚀

۱۰.۱۰. تفکر تحلیلی و طراحی Test 🧠

مهم‌ترین مهارت API Tester در نهایت یک ابزار یا زبان برنامه‌نویسی نیست؛ بلکه توانایی فکر کردن مانند Tester است.

Tester باید بتواند از Requirement سؤال استخراج کند، Boundaryها را پیدا کند، رفتارهای غیرعادی را تصور کند، Dependencyها را شناسایی کند و سناریوهایی طراحی کند که احتمال کشف Defect در آن‌ها بالا باشد.

ابزار می‌تواند Request را ارسال کند؛ اما این Tester است که تصمیم می‌گیرد چه چیزی باید تست شود و چرا. 🎯

۱۰.۱۱. مسیر پیشنهادی یادگیری API Testing 🛣️

اگر بخواهید API Testing را از پایه یاد بگیرید، بهتر است مستقیماً سراغ Automation نروید. ابتدا مفاهیم پایه را یاد بگیرید و سپس به‌تدریج آن‌ها را به Automation متصل کنید.

HTTP و Web Basics
        ↓
API و REST
        ↓
JSON و Data Validation
        ↓
Postman / Swagger
        ↓
Test Scenario Design
        ↓
Authentication / Authorization
        ↓
Advanced API Testing
        ↓
API Automation
        ↓
Git
        ↓
CI/CD

مرحله اول: HTTP و Web Basics 🌐

در ابتدا باید بدانید Browser یا Client چگونه با Server ارتباط برقرار می‌کند و Request و Response چگونه ساخته می‌شوند.

• HTTP Request و Response
• Methods
• Status Codes
• Headers
• Cookies
• URL
• Query Parameters
• Path Parameters

مرحله دوم: REST API 🧩

بعد از HTTP باید با ساختار API و اصول REST آشنا شوید. در این مرحله باید بتوانید یک Endpoint را بخوانید و اجزای آن را تشخیص دهید.

GET /api/users/125

در این مثال باید بدانید GET چیست، Resource چیست و مقدار 125 چه نقشی در Request دارد.

مرحله سوم: JSON و Data Validation 🔢

در مرحله بعد باید بتوانید Request و Responseهای JSON را بخوانید و Validationهای مختلف روی آن‌ها انجام دهید.

• Data Type
• Required Fields
• Nullable Fields
• Nested Objects
• Arrays
• Format
• Boundary Values

مرحله چهارم: Postman و Swagger 🛠️

حالا زمان آن است که مفاهیم را با ابزارهای واقعی تمرین کنید. در Postman می‌توانید Request بسازید، Header و Body اضافه کنید، Authentication را تنظیم کنید و Response را بررسی کنید.

Swagger UI نیز می‌تواند برای مشاهده و اجرای Endpointهای مستندشده بسیار مفید باشد.

مرحله پنجم: Test Design 🧠

در این مرحله باید از «ارسال Request» به «طراحی Test» برسید.

• Positive Testing
• Negative Testing
• Boundary Value Analysis
• Equivalence Partitioning
• Error Handling
• Authentication
• Authorization
• Data Validation

هدف این است که برای هر Endpoint بتوانید مجموعه‌ای منطقی از سناریوهای تست طراحی کنید.

مرحله ششم: Advanced API Testing 🚀

بعد از تسلط بر اصول پایه، می‌توانید سراغ موضوعات پیشرفته‌تر بروید.

• Pagination
• Filtering
• Sorting
• Rate Limiting
• Timeout
• Retry
• Idempotency
• API Versioning
• Contract Testing
• Mocking
• Performance Testing
• Security Testing

مرحله هفتم: API Automation 🤖

پس از اینکه در Manual API Testing مهارت کافی پیدا کردید، می‌توانید Testهای تکرارشونده را Automation کنید.

در این مرحله باید مفاهیمی مانند Test Case، Assertion، Setup، Teardown، Test Data، Parameterization و Reporting را در قالب Code یاد بگیرید.

Send Request
     ↓
Receive Response
     ↓
Validate Status Code
     ↓
Validate Response Body
     ↓
PASS / FAIL

مرحله هشتم: Git و CI/CD 🔄

در پروژه‌های واقعی، Test Automation معمولاً بخشی از Repository و Pipeline تیم است. بنابراین یادگیری Git و مفاهیم پایه CI/CD باعث می‌شود Testهای شما از محیط شخصی فراتر بروند و وارد فرآیند واقعی توسعه نرم‌افزار شوند.

۱۰.۱۲. API Testing برای Tester چه مزیتی دارد؟ ⭐

یادگیری API Testing فقط یک مهارت جدید به رزومه Tester اضافه نمی‌کند؛ بلکه درک او از خود نرم‌افزار را نیز عمیق‌تر می‌کند.

• درک بهتر Backend
• تحلیل بهتر Requirement
• توانایی Debugging بهتر
• کشف Bugهای خارج از UI
• آمادگی برای Automation
• درک بهتر معماری Microservices
• تعامل مؤثرتر با Developer
• امکان اجرای Testهای سریع‌تر و پایدارتر

۱۰.۱۳. آیا یادگیری Programming برای API Testing ضروری است؟ 💻

برای شروع Manual API Testing، لازم نیست برنامه‌نویس حرفه‌ای باشید. می‌توانید بسیاری از Testها را با ابزارهایی مانند Postman انجام دهید.

اما اگر هدف شما ورود جدی به API Automation باشد، یادگیری Programming بسیار ارزشمند و در بسیاری از پروژه‌ها ضروری است.

مفاهیمی مانند Variable، Function، Condition، Loop، Data Structure، Exception Handling و Object-Oriented Programming به شما کمک می‌کنند Testهای قابل نگهداری و قابل توسعه بنویسید.

۱۰.۱۴. Python یا JavaScript برای API Automation؟ 🐍

انتخاب زبان به پروژه و مسیر شغلی شما بستگی دارد. Python به دلیل Syntax نسبتاً ساده و اکوسیستم مناسب Testing گزینه خوبی برای شروع است. JavaScript/TypeScript نیز به‌خصوص در تیم‌هایی که از اکوسیستم JavaScript استفاده می‌کنند انتخاب بسیار مناسبی است.

مهم‌تر از انتخاب زبان، یادگیری اصول Automation و نوشتن Testهای خوانا، پایدار و قابل نگهداری است.

۱۰.۱۵. API Testing و آینده شغلی QA 🚀

با افزایش استفاده از Backendهای مستقل، Microservices، Mobile Applications و Frontendهای مدرن، APIها به بخش مهمی از معماری نرم‌افزار تبدیل شده‌اند. بنابراین توانایی تست API می‌تواند مهارت ارزشمندی برای مسیر شغلی QA و Test Automation باشد.

با این حال، API Testing را نباید یک مهارت جدا از Software Testing دید. بهترین نتیجه زمانی ایجاد می‌شود که Tester بتواند دانش Test Design، API، Automation، SQL، Git و CI/CD را در کنار یکدیگر استفاده کند.

در بخش بعدی، جمع‌بندی نهایی مقاله را انجام می‌دهیم و مهم‌ترین نکاتی را که باید از API Testing به خاطر بسپارید مرور خواهیم کرد. 🎯

۱۱. جمع‌بندی؛ API Testing را از کجا شروع کنیم؟ 🚀

API Testing یکی از مهم‌ترین بخش‌های تست نرم‌افزار مدرن است؛ زیرا بخش قابل‌توجهی از منطق برنامه در Backend و APIها اجرا می‌شود و بسیاری از Applicationها برای ارتباط میان Frontend، Backend، Mobile App و Serviceهای مختلف به API وابسته هستند.

در این مقاله دیدیم که API Testing فقط ارسال یک Request و بررسی Status Code نیست. یک Tester حرفه‌ای باید بتواند Requirement و API Contract را تحلیل کند، سناریوهای مثبت و منفی طراحی کند، Request و Response را بررسی کند و رفتار API را در شرایط مختلف اعتبارسنجی کند.

مهم‌ترین مواردی که در API Testing باید بررسی کنیم 🔍

• HTTP Method و Endpoint
• Request Parameters و Headers
• Request Body و Data Validation
• HTTP Status Code
• Response Body و Response Headers
• Authentication و Authorization
• Error Handling
• Pagination، Filtering و Sorting
• Rate Limiting و Retry
• Timeout و رفتار Dependencyها
• Performance
• Security
• API Versioning و Backward Compatibility
• Contract Testing
• رفتار API در معماری Microservices

API Tester فقط Request ارسال نمی‌کند 🧠

یکی از مهم‌ترین نکاتی که باید به خاطر داشته باشیم این است که ابزارهایی مانند Postman فقط وسیله‌ای برای اجرای Test هستند. ارزش واقعی API Testing در تفکر تستری و توانایی پیدا کردن سناریوهایی است که ممکن است باعث شکست سیستم شوند.

یک Tester خوب فقط نمی‌پرسد «آیا این Request جواب داد؟»؛ بلکه سؤال‌های بیشتری مطرح می‌کند:

• اگر داده اشتباه باشد چه اتفاقی می‌افتد؟
• اگر Field موردنیاز ارسال نشود چه می‌شود؟
• اگر User مجوز لازم را نداشته باشد چه اتفاقی می‌افتد؟
• اگر Request چند بار ارسال شود چه می‌شود؟
• اگر سرویس وابسته Down باشد چه اتفاقی می‌افتد؟
• اگر تعداد Requestها افزایش پیدا کند چه می‌شود؟
• آیا Response اطلاعاتی بیشتر از نیاز Client دارد؟
• آیا تغییر API باعث شکستن Consumerهای قبلی می‌شود؟

همین نوع سؤال‌هاست که API Testing را از اجرای ساده Requestها به یک فعالیت واقعی Quality Assurance تبدیل می‌کند. 🎯

از Manual API Testing شروع کنید 🛠️

اگر تازه وارد API Testing شده‌اید، لازم نیست از همان ابتدا سراغ Frameworkهای پیچیده Automation بروید. ابتدا HTTP، REST، JSON و مفاهیم پایه API را یاد بگیرید و با ابزارهایی مانند Postman تمرین کنید.

بعد از آن، Test Design و سناریوهای Negative را جدی بگیرید و سپس به سراغ Authentication، Database، Performance، Security و Contract Testing بروید.

در مرحله بعد می‌توانید Testهای تکرارشونده را با یک زبان برنامه‌نویسی مانند Python یا JavaScript/TypeScript Automation کنید و در نهایت Test Suite خود را وارد Git و CI/CD Pipeline کنید.

HTTP
  ↓
REST API
  ↓
Postman
  ↓
Test Design
  ↓
Advanced API Testing
  ↓
Automation 🤖
  ↓
Git
  ↓
CI/CD
  ↓
Professional API Testing 🚀

API Testing در مسیر حرفه‌ای QA ⭐

یادگیری API Testing می‌تواند نقطه اتصال مهمی بین Manual Testing و Test Automation باشد. Tester با ورود به دنیای API، از سطح بررسی صرفاً رابط کاربری عبور می‌کند و دید عمیق‌تری نسبت به Backend، Database، معماری نرم‌افزار و ارتباط بین Serviceها به دست می‌آورد.

در دنیای امروز که Microservices، Cloud، Mobile Applications و Frontendهای مدرن بخش مهمی از سیستم‌های نرم‌افزاری را تشکیل می‌دهند، شناخت API می‌تواند یکی از مهارت‌های ارزشمند برای یک QA Engineer باشد.

بنابراین اگر در مسیر یادگیری تست نرم‌افزار هستید، API Testing را فقط به‌عنوان یک ابزار یا تکنیک جانبی نبینید؛ آن را به‌عنوان بخشی از دانش فنی خود در Software Testing یاد بگیرید. 🚀

حرف آخر 💡

API در بسیاری از نرم‌افزارهای مدرن ستون ارتباطی بین بخش‌های مختلف سیستم است. هرچه Tester درک عمیق‌تری از این لایه داشته باشد، توانایی او برای کشف Defect، تحلیل مشکلات و طراحی Testهای مؤثر نیز بیشتر خواهد شد.

پس اگر می‌خواهید API Testing را شروع کنید، از ساده‌ترین نقطه آغاز کنید: HTTP را یاد بگیرید، API را بفهمید، با Postman تمرین کنید، سناریوهای مختلف طراحی کنید و بعد قدم‌به‌قدم وارد Automation شوید. 🎯

این مسیر شاید در ابتدا طولانی به نظر برسد، اما هر مرحله پایه‌ای برای مرحله بعد است و در نهایت شما را از اجرای ساده Requestها به سمت یک رویکرد حرفه‌ای در API Testing و Test Automation هدایت می‌کند. 🚀

۱۲. سوالات متداول درباره API Testing ❓