آموزش ۵۰۰+ سوال و جواب مصاحبه تست API سال ۲۰۲۶ - آخرین آپدیت

پوشش جامع حوزه‌های آزمون

این بانک سوالات تمرینی دقیقاً حول محور صلاحیت‌های فنی اصلی سازمان‌دهی شده است که در مصاحبه‌های مدرن تست API، ارزیابی‌های شرکتی و مراحل غربالگری فنی سنجیده می‌شوند:

• مبانی API (۲۰٪)

  • مباحث پوشش داده شده: تعاریف هسته معماری API، الگوهای معماری (REST, SOAP, RPC)، پروتکل‌های HTTP، کدهای وضعیت، هدرهای درخواست/پاسخ، Payloadها، متدها و محدودیت‌های ذاتی معماری‌های API.

• استراتژی و برنامه‌ریزی تست (۱۵٪)

  • مباحث پوشش داده شده: طراحی تست‌کیس‌های قدرتمند، اولویت‌بندی End-pointها بر اساس ریسک، مدیریت داده‌های تست پویا، Mocking و Stubbing وابستگی‌ها و تفسیر مشخصات OpenAPI/Swagger.

• تست امنیتی API (۱۰٪)

  • مباحث پوشش داده شده: جریان‌های احراز هویت و مجوزدهی (OAuth2, JWT, Basic Auth, API Keys)، اعتبارسنجی ورودی‌های مخرب، SQL Injection از طریق End-pointها، Broken Object-Level Authorization (BOLA) و پروتکل‌های رمزنگاری.

• تست عملکرد و بار (۱۵٪)

  • مباحث پوشش داده شده: تحلیل متریک‌های کلیدی تأخیر، تنظیم پیکربندی‌های تست بار، جداسازی گلوگاه‌های پایین‌دستی، اجرای تست‌های استرس و استقامت و اندازه‌گیری مرزهای مقیاس‌پذیری بک‌اند.

• ابزارها و فناوری‌های تست API (۱۰٪)

  • مباحث پوشش داده شده: ساخت فریم‌ورک‌های اتوماسیون مقیاس‌پذیر، استفاده از Collectionها و Environmentهای Postman، اسکریپت‌نویسی شرایط تست پیچیده در SoapUI، پیکربندی Thread Groupها در Apache JMeter و مدیریت خط لوله‌های اجرای خودکار.

• حل مسئله و تفکر انتقادی (۱۰٪)

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

• ارتباطات و همکاری (۱۰٪)

  • مباحث پوشش داده شده: مستندسازی دقیق گزارش‌های نقص (Defect Logs)، انتقال علت‌های فنی ریشه‌ای به تیم‌های مهندسی بک‌اند، تدوین گزارش‌های شفاف اجرای تست و همسو کردن پوشش تست با نیازمندی‌های محصول.

• مفاهیم پیشرفته تست API (۱۰٪)

  • مباحث پوشش داده شده: تست معماری‌های میکروسرویس، اعتبارسنجی قوانین Routing و Rate-limiting در API Gateway، مدیریت سازگاری عقب‌رو (Backwards Compatibility) از طریق استراتژی نسخه‌بندی API و تأیید انطباق قرارداد در محیط‌های کانتینری.

توضیحات دوره

موفقیت در مصاحبه‌های فنی برای نقش‌های QA، اتوماسیون یا تست‌های تخصصی بک‌اند، نیازمند درک عمیق از پروتکل‌های اپلیکیشن و الگوهای طراحی معماری است. پنل‌های مصاحبه معمولاً فراتر از تکنیک‌های تأیید ساده می‌روند تا بررسی کنند کاندیدا چگونه با خطاهای گذرا در شبکه، Race Conditionها، خطاهای اعتبارسنجی Edge-case، انقضای توکن‌ها و گلوگاه‌های سیستم‌های پایین‌دستی برخورد می‌کند. من این بانک سوالات جامع را برای ارائه دانش سناریو-محور مورد نیاز جهت عبور از این مراحل غربالگری فنی طراحی کرده‌ام.

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

به جای ارائه تئوری‌های سطحی، این دوره شما را به چالش می‌کشد تا عدم تطابق‌های ساختاری را دیباگ کنید، نقص‌های امنیتی در Payloadهای JWT را ارزیابی کنید، پیکربندی‌های عملکرد را تحت بار بهینه کنید و سازگاری عقب‌رو را در به‌روزرسانی‌های نسخه‌ها حفظ کنید. با عبور از این چالش‌های واقع‌گرایانه، شما دایره لغات فنی و رویکرد تحلیلی استراتژیکی را می‌سازید که برای پاسخگویی با اعتمادبه‌نفس و دقت به سوالات مصاحبه ضروری است.

پیش‌نمایش نمونه سوالات تمرینی

سوال ۱: امنیت پیشرفته API و احراز هویت

یک اپلیکیشن بک‌اند سازمانی از OAuth2 به همراه JSON Web Tokens (JWT) برای احراز هویت بدون وضعیت (stateless) استفاده می‌کند. در طول یک تست امنیتی فعال روی یک End-point به‌روزرسانی بحرانی (PUT /api/v2/users/{id})، یک اسکنر خودکار آسیب‌پذیری Broken Object-Level Authorization (BOLA) را گزارش می‌دهد. این End-point هدر Authorization را برای استخراج نقش کاربر تجزیه می‌کند، اما هرگونه تغییر ساختاری در پارامتر ID مسیر درخواست را می‌پذیرد، مشروط بر اینکه امضای توکن از نظر فنی معتبر باشد. قدرتمندترین استراتژی اصلاح برنامه‌نویسی برای تأیید در طراحی تست شما چیست؟

• الف) پیکربندی API Gateway برای حذف تمام درخواست‌های PUT که در آن‌ها پارامترهای Query دقیقاً با ویژگی‌های بدنه درخواست مطابقت ندارند.

  • دلیل نادرست بودن: این رویکرد شکست می‌خورد زیرا آسیب‌پذیری‌های BOLA در پارامترهای مسیر (Path) و هندلرهای مسیر اپلیکیشن وجود دارند، نه در پارامترهای Query. تکیه بر قوانین API Gateway برای تطبیق بدنه با کوئری، بدون رفع نقص کدنویسی در کنترلر بک‌اند، تنها بدهی پیکربندی شکننده ایجاد می‌کند.

• ب) دستور به تیم توسعه برای تغییر کامل از پیکربندی‌های JWT نامتقارن به توکن‌های Opaque ذخیره‌شده در سمت سرور با مقادیر Time-to-live پایین.

  • دلیل نادرست بودن: اگرچه توکن‌های Opaque نحوه ذخیره‌سازی داده‌های نشست را تغییر می‌دهند، اما ذاتاً نقص‌های منطقی مجوزدهی (Authorization) را حل نمی‌کنند. اگر هندلر منابع بک‌اند همچنان نتواند بررسی کند که آیا هویت نشست احراز شده مالک ID منبع هدف است یا خیر، نقص BOLA کاملاً فعال باقی می‌ماند.

• ج) پیاده‌سازی یک مرحله اعتبارسنجی کد در بک‌اند که صریحاً ادعای هویت کاربر (User Identity Claim) را مستقیماً از Payload توکن JWT تأیید شده استخراج کرده و آن را با رکورد مالک نمونه منبع خاص در دیتابیس، پیش از اجرای به‌روزرسانی، مطابقت دهد.

  • دلیل درست بودن: BOLA زمانی رخ می‌دهد که یک اپلیکیشن به ورودی غیرقابل اعتماد کاربر (ID در مسیر URL) برای مکان‌یابی یک منبع تکیه کند بدون اینکه تأیید کند کاربر وارد شده حقوق مالکیت آن منبع را دارد. اعتبارسنجی ادعای امن داخل توکن تأیید شده مستقیماً در برابر رکورد دیتابیس، تضمین می‌کند که دسترسی به داده‌ها کاملاً مجاز است.

• د) افزودن یک لایه Regex اعتبارسنجی ورودی روی پارامتر مسیر End-point برای اطمینان از اینکه فیلد User ID فقط رشته‌های استاندارد UUIDv4 را می‌پذیرد.

  • دلیل نادرست بودن: اعتبارسنجی نحوی (Syntactic) ورودی فقط تضمین می‌کند که فرمت شناسه معتبر است. این کار منطق دسترسی را تأیید نمی‌کند؛ یک مهاجم می‌تواند به راحتی یک UUID از نظر نحوی درست متعلق به کاربر دیگری را ارائه دهد تا از سیستم سوءاستفاده کند.

• ه) اعمال یک آستانه سخت‌گیرانه Rate-limiting (۵ درخواست در دقیقه) روی End-point به‌روزرسانی برای جلوگیری از حملات Brute-force Enumeration.

  • دلیل نادرست بودن: محدود کردن نرخ درخواست یک تمرین دفاعی در عمق (Defense-in-depth) است که حملات انبوه را کند می‌کند، اما نقص ساختاری بنیادین را برطرف نمی‌کند. یک مهاجم ماهر تنها به یک درخواست محاسبه شده نیاز دارد تا داده‌های خصوصی کاربر دیگری را از طریق یک ارجاع شیء غیرمجاز دستکاری کند.

• و) به‌روزرسانی شمای مستندات API در Swagger/OpenAPI برای علامت‌گذاری پارامتر User ID به عنوان یک فیلد فقط-خواندنی در تمام محیط‌ها.

  • دلیل نادرست بودن: تغییر پارامترهای مستندات فقط رفتار کلاینت را هدایت می‌کند و هیچ محافظتی در زمان اجرا (Runtime) فراهم نمی‌کند. End-point سرور همچنان در برابر درخواست‌های HTTP خام که به صورت دستی یا از طریق پروکسی‌هایی مانند Burp Suite ساخته شده‌اند، کاملاً در معرض خطر است.

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

در طول یک تست بار JMeter با همزمانی بالا روی یک پلتفرم میکروسرویس، End-point مربوط به GET /api/v1/products/search زمانی که تعداد Threadهای فعال از ۸۰۰ کاربر همزمان فراتر می‌رود، شروع به بازگرداندن خطاهای پراکنده HTTP 503 Service Unavailable می‌کند. متریک‌های زیرساخت داخلی نشان می‌دهد که بهره‌وری CPU در نمونه API Gateway در سطح مناسب ۲۲٪ است، اما Connection Pool داخلی میکروسرویس کاتالوگ محصولات در پایین‌دست کاملاً تخلیه شده است. کدام اقدام موثرترین پاسخ عیب‌یابی برای جداسازی و رفع این گلوگاه سیستمی است؟

• الف) گسترش لایه API Gateway با معرفی یک Elastic Network Load Balancer با الگوریتم مسیریابی Round-robin.

  • دلیل نادرست بودن: بهره‌وری پایین CPU در Gateway تأیید می‌کند که گلوگاه آنجا نیست. افزودن ظرفیت زیرساختی به نقطه‌ای که در حال حاضر کم‌بهره است، هیچ کمکی به رفع کمبود منابع در سرویس کاتالوگ پایین‌دستی نمی‌کند.

• ب) افزایش پیکربندی تعداد Threadها در طرح تست JMeter به ۱۵۰۰ کاربر برای اجبار سیستم به ارائه یک خطای Stack Trace قطعی.

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

• ج) تحلیل لاگ‌های اجرای سرویس پایین‌دستی، بررسی نبود ایندکس‌های دیتابیس روی فیلدهای جستجوی پرکاربرد و پیاده‌سازی الگوی Circuit Breaker در کنار بهینه‌سازی ویژگی‌های Connection Pooling.

  • دلیل درست بودن: تخلیه Connection Pool نشان می‌دهد که میکروسرویس پایین‌دستی اتصالات دیتابیس را برای مدت طولانی باز نگه داشته است که احتمالاً به دلیل کوئری‌های کند ناشی از نبود ایندکس است. معرفی Circuit Breaker از سرویس در بار بالا محافظت می‌کند، در حالی که تنظیم Pool و ایندکس‌گذاری، گلوگاه تأخیر زیربنایی را حل می‌کند.

• د) پیکربندی مجدد End-point هدف برای حذف خودکار تمام هدرهای Payload سنگین و اجبار به استفاده از فشرده‌سازی Gzip در تمام پاسخ‌ها.

  • دلیل نادرست بودن: فشرده‌سازی Gzip مصرف پهنای باند شبکه و زمان انتقال Payload را کاهش می‌دهد، اما مصرف Connection Pool بک‌اند یا عملکرد کند کوئری‌های دیتابیس را اصلاح نمی‌کند.

• ه) بازنویسی اسکریپت‌های تست اتوماسیون برای نادیده گرفتن تمام کدهای وضعیت سری ۵۰۰ جهت تثبیت گزارش‌های تراکنش پایه.

  • دلیل نادرست بودن: پوشاندن یا نادیده گرفتن خطاها در پیکربندی گزارش‌ها، هدف اعتبارسنجی عملکرد را از بین می‌برد. این کار شکست‌های شدید سیستمی را که بر کاربران واقعی در محیط تولید تأثیر می‌گذارد، پنهان می‌کند.

• و) انتقال فوری کل محیط تست از Apache JMeter به Collectionهای Postman برای تضمین پایداری اجرای چندنخی.

  • دلیل نادرست بودن: تغییر ابزار اجرای تست، خطای پیکربندی میکروسرویس بک‌اند را رفع نمی‌کند. علاوه بر این، Postman در درجه اول برای اتوماسیون عملکردی و رگرسیون طراحی شده است، نه برای تست‌های همزمانی انبوه چندنخی.

سوال ۳: طراحی پیشرفته API و Idempotency

یک پلتفرم ارکستراسیون پرداخت ناهمزمان، جذب پرداخت‌ها را از طریق End-point مربوط به POST /v1/charges پردازش می‌کند. برای جلوگیری از پرداخت دوبارگاناشی (Double-billing) به دلیل تلاش‌های مجدد شبکه (Network Retries)، معماری سیستم به یک مکانیزم Idempotency نیاز دارد. در طول یک بررسی یکپارچگی، متوجه می‌شوید که وقتی دو درخواست API یکسان با هدر Idempotency-Key دقیقاً مشابه در فاصله ۵۰ میلی‌ثانیه از یکدیگر می‌رسند، سیستم گاهی اوقات رکوردهای پرداخت تکراری در دیتابیس ایجاد می‌کند. این موضوع چه نقص بنیادینی را برجسته می‌کند و چگونه باید اعتبارسنجی شود؟

• الف) API فاقد سیاست‌های پیکربندی CORS مناسب است و به اسکریپت‌های Cross-site اجازه می‌دهد تا عناصر هدر را دستکاری کنند.

  • دلیل نادرست بودن: اشتراک منابع متقاطع (CORS) یک مکانیزم امنیتی در سطح مرورگر است که درخواست‌های وب متقاطع را محدود می‌کند. این مورد تأثیری بر منطق پردازش یا Race Conditionهای هندلرهای Idempotency در سمت سرور ندارد.

• ب) کد سمت سرور اعتبارسنجی Idempotency را با اجرای بررسی‌های غیراتمیک (read-then-write) بدون مکانیسم قفل توزیع‌شده (Distributed Lock) روی محدودیت کلید منحصر‌به‌فرد انجام می‌دهد.

  • دلیل درست بودن: وقتی درخواست‌های همزمان به طور همزمان می‌رسند، یک Race Condition رخ می‌دهد. اگر بک‌اند دیتابیس را برای بررسی کلید بخواند پیش از آنکه درخواست اول نوشتن آن را به پایان برساند، هر دو درخواست کلید را «استفاده نشده» می‌بینند و اقدام به درج رکوردهای تکراری می‌کنند. پیاده‌سازی یک قفل توزیع‌شده یا عملیات اتمیک "set-if-not-exists" این Race Condition را به طور کامل حل می‌کند.

• ج) اپلیکیشن کلاینت در هش کردن (Hash) صحیح بدنه Payload قبل از ارسال درخواست به سرور مبدأ شکست می‌خورد.

  • دلیل نادرست بودن: هش کردن Payload تکنیکی است که برای تأیید یکپارچگی داده‌ها یا ایجاد کلیدهای قطعی استفاده می‌شود، اما نحوه مدیریت عملیات دیتابیس تقریباً همزمان یا Race Conditionها توسط سرور را تغییر نمی‌دهد.

• د) API Gateway با مدت زمان Timeout نامناسب HTTP پیکربندی شده است و باعث می‌شود کلاینت زودتر قطع شود.

  • دلیل نادرست بودن: تایم‌اوت‌های Gateway باعث می‌شوند کلاینت‌ها اتصال را قطع کرده و دوباره تلاش کنند که می‌تواند ترافیک را افزایش دهد، اما مشکل اصلی اینجاست که سرور در یک بازه ۵۰ میلی‌ثانیه‌ای، کار را پذیرفته و تکرار کرده است.

• ه) لایه ایزولاسیون دیتابیس برای استفاده از تراکنش‌های Serializable پیکربندی شده است که مانع از اجرای نوشتن‌های همزمان می‌شود.

  • دلیل نادرست بودن: ایزولاسیون Serializable بالاترین سطح ایزولاسیون است و با سریال‌سازی دسترسی‌ها، فعالانه به جلوگیری از ناهنجاری‌ها کمک می‌کند، نه اینکه باعث تکرار خاموش داده‌ها بدون پرتاب یک استثنای همزمانی صریح شود.

• و) End-point باید مجدداً طراحی شود تا از متد استاندارد HTTP GET استفاده کند تا ویژگی‌های ذاتی Idempotency پروتکل را به ارث ببرد.

  • دلیل نادرست بودن: تغییر یک تراکنش ایجاد منبع که حالت سیستم را تغییر می‌دهد به متد GET، محدودیت‌های بنیادین معماری REST را نقض می‌کند. متدهای GET باید ایمن و فقط-خواندنی باقی بمانند و هرگز نباید برای شروع پرداخت‌های مالی یا تغییر حالت استفاده شوند.

• به آزمون‌های سوالات مصاحبه خوش آمدید تا شما را برای ارزیابی سوالات مصاحبه تست API آماده کنیم.

• شما می‌توانید هر تعداد بار که بخواهید در آزمون‌ها شرکت کنید

• این یک بانک سوالات اصلی و بسیار گسترده است

• در صورت داشتن سوال، از پشتیبانی مدرسان بهره‌مند می‌شوید

• هر سوال دارای یک توضیح دقیق است

• سازگار با موبایل از طریق اپلیکیشن Udemy

امیدوارم تا الان متقاعد شده باشید! و سوالات بسیار بیشتری در داخل دوره وجود دارد.