تست API چیست؟ انواع، چک‌لیست و مثال API Testing

ممکن است صفحه ثبت سفارش کاملاً سالم به نظر برسد، اما API در پشت آن سفارش را دوبار ثبت کند، تخفیف را اشتباه محاسبه کند یا با عوض‌کردن یک شناسه، سفارش کاربر دیگری را نشان دهد. تست رابط کاربری به‌تنهایی چنین ریسک‌هایی را زود و دقیق آشکار نمی‌کند. تست API مستقیماً سراغ قرارداد، منطق کسب‌وکار، داده، دسترسی و رفتار سرویس می‌رود؛ همان جایی که بسیاری از خطاهای پرهزینه شکل می‌گیرند.

در این راهنما، API Testing را از پایه تا اجرا یاد می‌گیرید: چه چیزی را در Request و Response بررسی کنیم، چه تست‌کیس‌هایی بنویسیم، کدام کدهای HTTP مهم‌اند، تست قرارداد و امنیت چه تفاوتی دارند و چگونه یک مجموعه تست قابل‌اعتماد را وارد CI/CD کنیم. مثال محوری مقاله، API ثبت سفارش یک فروشگاه ایرانی است تا نکته‌ها فقط نظری نباشند.

تست API چیست؟

تست API فرایندی است که در آن بدون وابستگی به ظاهر برنامه، به Endpointها درخواست می‌فرستیم و رفتار قابل مشاهده سیستم را با انتظارهای تعریف‌شده مقایسه می‌کنیم. این انتظار می‌تواند کد وضعیت، محتوای پاسخ، Schema، تغییر پایگاه داده، پیام منتشرشده در صف، ثبت رویداد حسابرسی یا حتی «رخ ندادن» یک اثر جانبی باشد.

برای نمونه، در تست POST /orders صرفاً دیدن 201 Created کافی نیست. باید مطمئن شویم قیمت نهایی درست محاسبه شده، موجودی فقط یک‌بار کم شده، کاربر به سبد خرید دیگری دسترسی ندارد، شناسه سفارش قابل رهگیری است و تکرار ناخواسته درخواست باعث دو سفارش یا دو برداشت وجه نمی‌شود.

تست API معمولاً بخشی از تست یکپارچه‌سازی است، اما بسته به مرز و وابستگی‌ها می‌تواند در سطح Component، Contract، System یا End-to-End نیز اجرا شود.

API چیست و چه چیزهایی را می‌توان تست کرد؟

API یک قرارداد ارتباطی میان دو مصرف‌کننده نرم‌افزاری است. این ارتباط همیشه REST روی HTTP نیست؛ SOAP، GraphQL، gRPC، WebSocket، Webhook و APIهای رویدادمحور نیز وجود دارند. اصول مشترک‌اند، ولی روش فراخوانی و Assertionها با نوع رابط تغییر می‌کنند. برای نمونه، در REST روی Method و Status Code تمرکز می‌کنیم؛ در GraphQL ممکن است پاسخ HTTP موفق باشد اما آرایه errors خطای عملیاتی را نشان دهد؛ و در gRPC باید Status و پیام Protobuf را بسنجیم. برای جزئیات این پروتکل، راهنمای تست gRPC را ببینید.

در یک API مبتنی بر HTTP معمولاً این اجزا هدف تست هستند:

• مسیر و پارامترها: Path Parameter، Query Parameter، فیلتر، مرتب‌سازی و Pagination؛
• متد: مانند GET، POST، PUT، PATCH و DELETE؛
• هدرها: Authorization، Content-Type، Accept، Cache-Control، Correlation ID و Idempotency Key؛
• بدنه درخواست: ساختار، نوع داده، فیلدهای الزامی و قواعد کسب‌وکار؛
• پاسخ: Status، هدر، بدنه، Schema و پیام خطا؛
• وضعیت و اثر جانبی: تغییر داده، ارسال پیام، ایمیل، رزرو موجودی یا فراخوانی سرویس دیگر.

چرا تست API اهمیت دارد؟

بازخورد سریع‌تر و دقیق‌تر

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

کشف خطا پیش از تکمیل رابط کاربری

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

پوشش ریسک‌هایی که در UI دیده نمی‌شوند

مجوز سطح شیء، هدرهای کش، داده‌های اضافی پاسخ، Rate Limit، سازگاری نسخه‌ها و رفتار هم‌زمانی معمولاً از UI به‌خوبی قابل مشاهده نیستند. تست در مرز API کنترل مستقیم‌تری روی این متغیرها می‌دهد.

پایه مناسب برای اتوماسیون

APIها ورودی و خروجی ساختاریافته دارند و برای اجرای تکرارشونده مناسب‌اند. با این حال، هر تستی ارزش خودکارسازی ندارد؛ انتخاب باید بر اساس تکرار، ریسک، ثبات و هزینه نگهداری انجام شود. راهنمای اتوماسیون تست معیارهای این تصمیم را توضیح می‌دهد.

تفاوت تست API با تست UI و Unit Test

این لایه‌ها جایگزین هم نیستند. یک استراتژی سالم تعداد زیادی تست سریع در لایه‌های پایین، تست‌های هدفمند API و تعداد محدودتری تست End-to-End برای جریان‌های حیاتی دارد.

آناتومی Request و Response در تست API

درخواست را کامل تعریف کنید

یک Test Case قابل تکرار باید Base URL و نسخه API، Endpoint، Method، هدر، پارامتر، Body، پیش‌شرط، هویت کاربر و داده اولیه را مشخص کند. عبارت مبهم «ارسال درخواست معتبر» برای بازتولید خطا کافی نیست.

POST /v1/orders
Authorization: Bearer <customer-token>
Content-Type: application/json
Idempotency-Key: test-order-1001

{
  "cartId": "cart-874",
  "addressId": "addr-22",
  "paymentMethod": "online"
}

پاسخ فقط Status Code نیست

در پاسخ، حداقل این پنج بُعد را بسنجید:

1. معنا: آیا Status Code با نتیجه عملیات سازگار است؟
2. قرارداد: آیا فیلدها، نوع داده و فیلدهای الزامی مطابق Schema هستند؟
3. کسب‌وکار: آیا مبلغ، تخفیف، مالیات، هزینه ارسال و وضعیت سفارش درست است؟
4. اثر جانبی: آیا موجودی، رکورد پرداخت یا پیام صف دقیقاً به اندازه مورد انتظار تغییر کرده است؟
5. ویژگی غیرکارکردی: آیا زمان پاسخ، امنیت، ظرفیت و قابلیت مشاهده در محدوده پذیرفته‌شده‌اند؟

{
  "orderId": "ord-4821",
  "status": "PENDING_PAYMENT",
  "payableAmount": 1285000,
  "currency": "IRR",
  "traceId": "4b9c..."
}

در مثال بالا باید واحد پول و قرارداد آن روشن باشد؛ اشتباه گرفتن ریال و تومان می‌تواند تستی با Status موفق اما نتیجه مالی نادرست بسازد.

متدهای HTTP و مفهوم Safe و Idempotent

بر اساس RFC 9110، متدهای GET، HEAD، OPTIONS و TRACE از نظر معنایی Safe هستند؛ یعنی هدف تعریف‌شده آن‌ها تغییر وضعیت سرور نیست. PUT، DELETE و متدهای Safe، Idempotent تعریف می‌شوند: چند درخواست یکسان باید همان اثر مورد نظر یک درخواست را داشته باشد. این تعریف به معنای یکسان‌بودن تمام Responseها یا Logها نیست.

• GET: بازیابی منبع؛ نباید با بازکردن URL موجودی یا وضعیت سفارش را تغییر دهد.
• POST: معمولاً ایجاد یا اجرای فرمان؛ ذاتاً Idempotent نیست، مگر API سازوکاری مثل Idempotency Key تعریف کند.
• PUT: ایجاد یا جایگزینی وضعیت منبع در URI مشخص؛ اثر مورد نظر آن Idempotent است.
• PATCH: تغییر جزئی؛ Idempotent بودن آن به قرارداد و نوع عملیات وابسته است.
• DELETE: اثر مورد نظر Idempotent است، هرچند درخواست دوم ممکن است ۴۰۴ بدهد.

برای پرداخت، رزرو بلیت و ثبت سفارش، تست تکرار Request حیاتی است. Timeout کلاینت ممکن است پس از انجام عملیات رخ دهد و کاربر همان درخواست را دوباره بفرستد. انتظار را صریح کنید: آیا همان نتیجه قبلی برمی‌گردد، ۴۰۹ می‌گیریم یا رکورد جدید ساخته می‌شود؟

کدهای وضعیت HTTP را چگونه تست کنیم؟

کد وضعیت باید معنای نتیجه را منتقل کند، اما قواعد دقیق هر API در قرارداد آن ثبت می‌شود. این نگاشت نقطه شروع خوبی است:

• 200 OK: عملیات موفق همراه محتوا؛
• 201 Created: منبع جدید ایجاد شده؛ بهتر است شناسه یا Location قابل بررسی باشد؛
• 204 No Content: عملیات موفق بدون بدنه پاسخ؛
• 400 Bad Request: Request از نظر ساختار یا معنا قابل پردازش نیست؛
• 401 Unauthorized: اعتبار احراز هویت موجود نیست یا پذیرفته نشده است؛
• 403 Forbidden: هویت شناخته شده اما عملیات مجاز نیست؛
• 404 Not Found: منبع هدف پیدا نشده یا طبق سیاست افشا نمی‌شود؛
• 409 Conflict: درخواست با وضعیت فعلی منبع تعارض دارد؛
• 422 Unprocessable Content: محتوا فهمیده شده اما اجرای دستورهای آن ممکن نیست؛
• 429 Too Many Requests: محدودیت نرخ اعمال شده است؛
• 5xx: سرور نتوانسته درخواست ظاهراً معتبر را انجام دهد.

خطای رایج این است که برای هر پاسخ 2xx تست را Pass کنیم. ممکن است API با ۲۰۰ بدنه‌ای شامل وضعیت شکست برگرداند یا با ۲۰۴ به‌اشتباه Body تولید کند. Status، قرارداد و نتیجه کسب‌وکار را با هم Assert کنید.

انواع تست API

۱. تست عملکردی و منطق کسب‌وکار

بررسی می‌کند Endpoint برای ورودی معتبر، نتیجه درست بسازد. در سفارش، جمع اقلام، محدودیت تعداد، کد تخفیف، هزینه ارسال و وضعیت گردش کار مهم‌اند. سناریوی Happy Path لازم است اما بیشترین خطاها اغلب در مرزها و ترکیب قواعد رخ می‌دهند.

۲. تست منفی و اعتبارسنجی ورودی

فیلد حذف‌شده، مقدار Null، نوع داده اشتباه، عدد منفی، رشته بسیار بلند، تاریخ نامعتبر، مقدار خارج از Enum، JSON ناقص و پارامتر ناشناخته را بررسی کنید. پاسخ خطا باید پایدار، قابل فهم و بدون Stack Trace یا اطلاعات حساس باشد.

۳. تست قرارداد و Schema

قرارداد مشخص می‌کند مصرف‌کننده چه ورودی و خروجی‌ای را می‌تواند انتظار داشته باشد. OpenAPI یک توصیف استاندارد و مستقل از زبان برای HTTP APIها ارائه می‌کند؛ نسخه منتشرشده OpenAPI Specification را مرجع قرار دهید. برای داده JSON نیز JSON Schema می‌تواند نوع، ساختار و محدودیت‌ها را توصیف و اعتبارسنجی کند.

افزودن فیلد اختیاری معمولاً سازگارتر از حذف فیلد یا تغییر نوع آن است، اما سازگاری واقعی به رفتار مصرف‌کننده وابسته است. در معماری میکروسرویس، Consumer-Driven Contract در برابر E2E کمک می‌کند شکست قرارداد پیش از استقرار کشف شود.

۴. تست احراز هویت و مجوز دسترسی

Authentication می‌پرسد «چه کسی هستی؟» و Authorization می‌پرسد «به چه چیزی اجازه داری؟». فقط توکن نامعتبر را تست نکنید. با توکن معتبر کاربر A شناسه سفارش کاربر B را امتحان کنید، نقش‌ها را جابه‌جا کنید و دسترسی در سطح Object، Property و Function را بسنجید.

در فهرست OWASP API Security Top 10 2023، Broken Object Level Authorization در رتبه نخست آمده است. یک تست ساده تغییر /orders/481 به /orders/482 می‌تواند نشت جدی داده را آشکار کند. برای دامنه کامل‌تر، مقاله مبانی تست امنیت را بخوانید.

۵. تست کارایی، ظرفیت و پایداری

Latency یک درخواست دستی معیار Performance نیست. ابتدا SLO یا معیار پذیرش را تعیین کنید، سپس Load، حجم داده، نرخ درخواست، الگوی افزایش بار، درصد خطا و صدک‌هایی مانند p95 و p99 را اندازه بگیرید. تست Soak نشتی منابع و افت تدریجی را بهتر از اجرای کوتاه آشکار می‌کند. این حوزه بخشی از تست غیرکارکردی است.

۶. تست هم‌زمانی، Retry و Idempotency

دو درخواست هم‌زمان برای آخرین موجودی، مصرف دوباره کد تخفیف یا Retry پس از Timeout را اجرا کنید. انتظار باید درباره قفل، نسخه رکورد، Conflict و یکتایی تراکنش روشن باشد. این سناریوها با اجرای ترتیبی معمولاً دیده نمی‌شوند.

۷. تست نسخه‌بندی و سازگاری عقب‌رو

مصرف‌کننده قدیمی را در برابر نسخه جدید Provider اجرا کنید. حذف فیلد، تغییر نام، تغییر نوع، سخت‌ترشدن Validation و تغییر معنای مقدارها می‌تواند Breaking Change باشد. صرفاً معتبر بودن Schema جدید، سازگاری با کلاینت‌های موجود را تضمین نمی‌کند.

۸. تست قابلیت مشاهده و مدیریت خطا

در شکست‌ها بررسی کنید Correlation ID یا Trace ID وجود دارد، Log حساسیت‌زدایی شده، Metrics قابل تفکیک‌اند و Timeoutها به خطای قابل اقدام تبدیل می‌شوند. تستی که فقط «۵۰۰ آمد» را ثبت کند، برای عیب‌یابی تولید ارزش کمی دارد.

طراحی Test Case برای API سفارش؛ مثال گام‌به‌گام

فرض کنید Endpoint ثبت سفارش چنین قراردادی دارد: مشتری احراز هویت‌شده، یک سبد فعال و یک نشانی متعلق به خودش را ارسال می‌کند. API قیمت را در سرور محاسبه می‌کند، موجودی را رزرو و سفارش را در وضعیت انتظار پرداخت می‌سازد.

سناریوی مثبت

• پیش‌شرط: سبد دارای دو کالا با موجودی کافی و نشانی فعال؛
• Request: توکن مشتری، شناسه سبد و نشانی معتبر، Idempotency Key یکتا؛
• Expected: کد ۲۰۱، Schema معتبر، مبلغ محاسبه‌شده توسط سرور و وضعیت PENDING_PAYMENT؛
• اثر جانبی: یک سفارش، یک رزرو موجودی و یک رویداد قابل رهگیری؛
• پاک‌سازی: لغو سفارش یا بازگرداندن داده Fixture.

سناریوهای منفی و مرزی

• سبد خالی، منقضی یا متعلق به کاربر دیگر؛
• نشانی حذف‌شده یا متعلق به حساب دیگر؛
• قیمت دست‌کاری‌شده در Body؛ سرور نباید مبلغ کلاینت را منبع حقیقت بداند؛
• موجودی صفر یا کاهش موجودی میان مشاهده سبد و ثبت سفارش؛
• توکن منقضی، Scope ناکافی یا نقش نامجاز؛
• ارسال دوباره همان Idempotency Key با Body یکسان و سپس Body متفاوت؛
• قطع یا Timeout سرویس پرداخت و Retry امن؛
• دو درخواست هم‌زمان برای آخرین واحد کالا.

برای درگاه‌های بانکی، Callback، امضا، Sandbox و مغایرت وضعیت‌ها ریسک‌های ویژه‌ای دارند؛ راهنمای تست درگاه پرداخت و Sandbox این سناریوها را عمیق‌تر بررسی می‌کند.

قالب پیشنهادی تست‌کیس API

ابزارهای تست API؛ کدام را انتخاب کنیم؟

ابزار «بهترین» به زبان تیم، نوع API، هدف تست و محیط اجرا وابسته است. دسته‌بندی زیر برای انتخاب عملی‌تر از فهرست محبوبیت است:

• بررسی دستی و اکتشافی: curl، Postman و ابزارهای مشابه برای ساخت سریع Request و مشاهده Response؛
• تست خودکار کدنویسی‌شده: REST Assured برای Java، کتابخانه‌های HTTP در Python/JavaScript و Framework تست زبان تیم؛
• Contract Testing: ابزارهای اعتبارسنجی OpenAPI/JSON Schema و ابزارهایی مانند Pact؛
• Performance: k6، JMeter یا ابزار سازمانی متناسب با پروتکل و بار؛
• Security: Proxy و Scannerهایی مانند OWASP ZAP در کنار تست دستی مجوز و منطق کسب‌وکار؛
• پروتکل‌های خاص: ابزارهای ویژه GraphQL، gRPC، SOAP یا پیام‌رسان.

برای شروع بدون کدنویسی و ساخت Collection، راهنمای تست API با Postman مسیر مستقیمی ارائه می‌کند. وقتی تست‌ها زیاد و حیاتی شدند، آن‌ها را مانند کد نسخه‌بندی، Review و در CI اجرا کنید.

فرایند عملی تست API از نیازمندی تا CI

1. مرز را مشخص کنید: سرویس واقعی، Mock یا Stub؟ کدام وابستگی‌ها در دامنه‌اند؟
2. قرارداد و ریسک را بخوانید: OpenAPI، مثال‌ها، قواعد کسب‌وکار، مدل دسترسی و SLOها؛
3. ماتریس سناریو بسازید: مثبت، منفی، مرزی، نقش‌ها، وضعیت‌های منبع، Retry و هم‌زمانی؛
4. داده و محیط را آماده کنید: Fixture قابل تکرار، حساب‌ها، Secret امن، Cleanup و Seed؛
5. تست اکتشافی انجام دهید: ابهام قرارداد و رفتارهای غیرمنتظره را پیش از خودکارسازی پیدا کنید؛
6. Assertion چندلایه بنویسید: Response، State، Side Effect و Observability؛
7. مجموعه را لایه‌بندی کنید: Smoke سریع برای هر Commit، Regression در Merge و تست سنگین در زمان/محیط کنترل‌شده؛
8. شکست را قابل تشخیص کنید: گزارش شامل داده مورد انتظار، نتیجه واقعی و Trace ID باشد؛
9. نگهداری کنید: تغییر قرارداد، Flaky Test، زمان اجرا و تست‌های کم‌ارزش را دوره‌ای بازبینی کنید.

مدیریت محیط، داده و محدودیت‌های تیم‌های ایرانی

کیفیت تست API به محیط وابسته است. Environment مشترک و داده تصادفی می‌تواند شکست کاذب بسازد. برای هر تست داده یکتا تولید کنید، Cleanup روشن داشته باشید و وابستگی خارجی را آگاهانه واقعی، Sandbox، Stub یا Virtualized انتخاب کنید.

در ایران، محدودیت دسترسی به سرویس‌های خارجی، تحریم IP، ناپایداری شبکه، تفاوت منطقه زمانی و تقویم، پیامک و درگاه بانکی باید در طراحی لحاظ شود. این موارد را با «Retry بی‌نهایت» پنهان نکنید؛ Timeout، Backoff، Circuit Breaker و پیام خطای کاربر باید قرارداد و تست پذیرش مشخص داشته باشند.

Secretها را داخل Collection یا Repository قرار ندهید. متغیر محیطی، Secret Manager یا Credential محدود و قابل ابطال استفاده کنید. Log و گزارش تست نیز نباید توکن، شماره کارت، کد ملی، تلفن یا داده شخصی واقعی را منتشر کند.

اشتباهات رایج در API Testing

• بررسی فقط ۲۰۰: منطق، Schema و State نادیده می‌ماند.
• تست فقط Happy Path: خطاهای مرزی، مجوز و هم‌زمانی کشف نمی‌شوند.
• اعتماد کامل به مستندات: قرارداد باید با رفتار واقعی و نیازمندی کسب‌وکار مقایسه شود.
• وابستگی تست‌ها به ترتیب اجرا: شکست یک تست، چندین شکست زنجیره‌ای تولید می‌کند.
• داده مشترک و Cleanup ناقص: اجرای موازی و تکرارشونده ناپایدار می‌شود.
• Assertion روی کل Response پویا: شناسه، زمان و ترتیب نامرتبط تست را شکننده می‌کنند؛ فقط قرارداد و رفتار مهم را Assert کنید.
• مخلوط‌کردن تست Functional و Load: هدف، داده و محیط این دو متفاوت است.
• نادیده‌گرفتن مجوز سطح شیء: توکن معتبر الزاماً مجوز دسترسی به هر شناسه را نمی‌دهد.
• ثبت Secret در گزارش: ابزار تست نباید خودش منشأ نشت امنیتی شود.

چک‌لیست تست API

• Endpoint، Method، نسخه و Content-Type درست‌اند.
• پارامترهای اجباری، اختیاری، Null، نوع اشتباه و حدود طول/عدد تست شده‌اند.
• Status Code و ساختار استاندارد خطا با قرارداد هماهنگ است.
• Schema، فیلدهای الزامی، نوع داده و سازگاری عقب‌رو بررسی شده‌اند.
• محاسبات و قواعد کسب‌وکار مستقل از مقدارهای ارسالی کلاینت Assert شده‌اند.
• Authentication، Role، Scope، مالکیت Object و دسترسی Property پوشش دارند.
• State و Side Effect مانند موجودی، پیام و تراکنش کنترل شده‌اند.
• Retry، Idempotency، Timeout و درخواست هم‌زمان سناریو دارند.
• Pagination، Sort، Filter، Empty Result و حجم زیاد داده تست شده‌اند.
• Latency، نرخ خطا، ظرفیت و بازیابی با معیار پذیرش مشخص سنجیده می‌شوند.
• Trace ID، Log و Metrics برای تشخیص شکست قابل استفاده‌اند.
• داده تست مستقل، قابل تکرار، قابل پاک‌سازی و فاقد اطلاعات واقعی حساس است.
• Smoke Test در CI سریع است و تست‌های سنگین زمان‌بندی جدا دارند.
• گزارش شکست Request/Response حساسیت‌زدایی‌شده و Expected/Actual روشن دارد.

جمع‌بندی

تست API زمانی ارزشمند است که رفتار سرویس را از چند زاویه بسنجد: قرارداد، منطق، دسترسی، وضعیت، اثر جانبی و ویژگی‌های غیرکارکردی. از یک Endpoint حیاتی شروع کنید، سناریوهای مثبت و منفی را با داده کنترل‌شده اجرا کنید، سپس Retry، هم‌زمانی، امنیت و سازگاری را اضافه کنید. مجموعه‌ای کوچک اما قابل اعتماد و قابل تشخیص، از صدها تستی که فقط کد ۲۰۰ را چک می‌کنند مفیدتر است.

قدم بعدی پیشنهادی: برای API واقعی خود یک جدول شامل Endpoint، ریسک اصلی، نقش‌های مجاز، حالت‌های منفی و اثرهای جانبی بسازید. سپس پنج سناریوی پرریسک را در ابزار انتخابی اجرا و تنها تست‌های تکرارشونده را وارد CI کنید.

سوالات متداول درباره تست API

تست API چیست؟

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

برای تست API فقط Postman کافی است؟

Postman برای یادگیری، تست اکتشافی و Collection مناسب است، اما کفایت آن به مقیاس و هدف بستگی دارد. در پروژه جدی ممکن است به تست کدنویسی‌شده، Contract Testing، Performance Tool، Security Testing و اجرای CI نیز نیاز باشد.

تفاوت تست API و تست Integration چیست؟

تست API بر رابط قابل مشاهده تمرکز دارد؛ تست Integration بر تعامل میان اجزا. بسیاری از تست‌های API یکپارچه‌سازی هستند، اما API را می‌توان با وابستگی Mockشده در سطح Component نیز آزمود و Integration بدون HTTP هم ممکن است.

چه چیزهایی را در پاسخ API باید بررسی کنیم؟

Status Code، Headers، Body، Schema و پیام خطا نقطه شروع‌اند. علاوه بر آن‌ها، منطق کسب‌وکار، تغییر State، Side Effect، مجوز دسترسی، زمان پاسخ و قابلیت رهگیری را متناسب با ریسک بررسی کنید.

از کدام تست‌کیس API شروع کنیم؟

از مسیر حیاتی کسب‌وکار و پرریسک‌ترین شکست شروع کنید؛ مثلاً ثبت سفارش، ورود یا پرداخت. یک سناریوی مثبت، چند ورودی نامعتبر، نقش غیرمجاز، منبع متعلق به کاربر دیگر و تکرار Request را پوشش دهید؛ سپس پوشش را بر اساس ریسک توسعه دهید.

منابع فنی این راهنما

• RFC 9110 — HTTP Semantics
• OpenAPI Specification — Latest Published Version
• JSON Schema Specification
• OWASP API Security Top 10 — 2023