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

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

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

• مبانی تست اتوماسیون (۲۰٪)

  • مباحث پوشش داده شده: انواع اتوماسیون تست، الگوهای طراحی فریم‌ورک (Data-Driven, Keyword-Driven, Hybrid, POM)، چرخه‌های حیات اتوماسیون، استراتژی‌های تولید اسکریپت تست و اندازه‌گیری معیارهای پوشش کد تست.

• ابزارها و فریم‌ورک‌های تست (۲۵٪)

  • مباحث پوشش داده شده: مکانیسم‌های اصلی Selenium WebDriver، پیکربندی‌های تست موبایل با Appium، گردش کارهای توسعه رفتار-محور (BDD) با Cucumber، تست API با SoapUI، موتورهای بین-مرورگری مانند Zoho QEngine و مدیریت اجرای تست از طریق TestNG.

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

  • مباحث پوشش داده شده: سینتکس اصلی برنامه‌نویسی، اصول شی‌گرایی (OOP)، ساختارهای داده و پارادایم‌های مدیریت استثناها در Java، Python، JavaScript، C# و Ruby.

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

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

• مهارت‌های تحلیلی و حل مسئله (۱۰٪)

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

• ادغام و تحویل مداوم (۵٪)

  • مباحث پوشش داده شده: ادغام اسکریپت‌های تست در پایپ‌لاین‌های CI/CD، مدیریت ابزارهای ادغام مداوم، پیکربندی گیت‌های استقرار اتوماتیک و اجرای تست‌های موازی.

• تست اپلیکیشن‌های موبایل و دسکتاپ (۵٪)

  • مباحث پوشش داده شده: پیکربندی‌های پیشرفته اتوماسیون موبایل با Appium، تست اپلیکیشن‌های دسکتاپ ویندوز با WinAppDriver و اسکریپت‌نویسی در سطح سیستم با AutoIt.

• تست عملکرد و امنیت (۱۰٪)

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

توضیحات دوره

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

با ۵۵۰ سوال تمرینی کاربردی و مبتنی بر سناریو، این دوره به عنوان یک مخزن جامع مطالب آموزشی عمل می‌کند تا اطمینان حاصل شود که شما در اولین تلاش، مراحل فنی را پشت سر می‌گذارید. ارزیابی‌ها شامل مسئولیت‌های حیاتی مهندسی است و شما را مجبور می‌کند تا به صورت انتقادی درباره انتخاب فریم‌ورک، استراتژی‌های مکان‌یابی المان‌ها (Locators)، شکست‌های پایپ‌لاین و گلوگاه‌های عملکردی فکر کنید.

هر سوال در این بانک با یک توضیح بسیار دقیق در سطح متخصص طراحی شده است. شما فقط پاسخ درست را نخواهید دید؛ بلکه عمیقاً بررسی خواهید کرد که چرا انتخاب‌های مهندسی خاصی از نظر ساختاری برتر هستند و چرا رویکردهای جایگزین در محیط‌های عملیاتی (Production) شکست می‌خورند. این روش تضمین می‌کند که شما منطق حل مسئله لازم را برای بیان با اعتمادبه‌نفس تصمیمات فنی خود به مدیران استخدام و معماران فنی توسعه دهید.

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

سوال ۱: ابزارهای تست، فریم‌ورک‌ها و مدیریت استثناها

یک اسکریپت اتوماسیون تست با استفاده از Selenium WebDriver و Java در حین اجرا روی یک صفحه وب پویا و ناهمگام (Asynchronous)، خطای متناوب StaleElementReferenceException می‌دهد. المان هدف در ابتدا با موفقیت مکان‌یابی می‌شود، اما یک به‌روزرسانی AJAX در پس‌زمینه، محفظه DOM را درست قبل از وقوع تعامل رفرش می‌کند. کدام استراتژی محکم‌ترین روش برای رفع این خطا در معماری Page Object Model (POM) است؟

• گزینه‌ها:

  • الف) تعامل با المان را در یک بلوک try-catch استاندارد قرار دهید و یک Thread.sleep(5000) سخت‌افزاری در بلوک catch قبل از تلاش دوم برای کلیک پیاده‌سازی کنید.

  • ب) یک Explicit Wait با استفاده از ExpectedConditions.refreshed() ترکیبی با یک شرط در دسترس بودن المان مانند elementToBeClickable() پیاده‌سازی کنید تا اطمینان حاصل شود که درایور در هنگام تلاش مجدد، المان را از ساختار تازه DOM مکان‌یابی می‌کند.

  • ج) مقدار global implicit wait در نمونه WebDriver را در سطح ایجاد درایور به ۶۰ ثانیه افزایش دهید تا چیدمان صفحه زمان کافی برای تثبیت داشته باشد.

  • د) استراتژی مکان‌یاب WebDriver را کاملاً رها کرده و یک کلیک موس در سطح سیستم را از طریق اسکریپت خارجی AutoIt با استفاده از مختصات سخت‌افزاری صفحه اجرا کنید.

  • ه) پیکربندی مجموعه اتوماسیون را بازنویسی کنید تا منحصراً از طریق ماژول‌های تست عملکردی SoapUI اجرا شود تا حلقه‌های رندرینگ DOM مرورگر کاملاً دور زده شوند.

  • و) کل نشست (Session) درایور WebDriver را در بلوک catch مجدداً مقداردهی کنید تا حافظه کش و کوکی‌های مرورگر قبل از اجرای مجدد گام تست پاک شوند.

• پاسخ صحیح: ب

• توضیحات:

  • چرا گزینه ب درست است: متد ExpectedConditions.refreshed() دقیقاً برای مدیریت المان‌هایی طراحی شده است که از DOM جدا شده و سپس از طریق به‌روزرسانی‌های ناهمگام مجدداً متصل می‌شوند. با قرار دادن شرایط دیده‌شدن یا قابلیت کلیک در داخل آن، به WebDriver دستور می‌دهید که ارجاع کش‌شده قدیمی را نادیده گرفته، المان را با استفاده از تعریف مکان‌یاب اصلی مجدداً مکان‌یابی کند و تعامل را بدون ایجاد تاخیرهای مصنوعی اجرا کند.

  • چرا گزینه الف غلط است: دستورات sleep سخت‌افزاری باعث ایجاد زمان‌های بیکاری مصنوعی در حلقه‌های اجرا می‌شوند. این کار سرعت کلی اجرای مجموعه تست را به شدت کاهش می‌دهد، وضعیت Race Condition را بدون رفع آن می‌پوشاند و اگر به‌روزرسانی پس‌زمینه بیش از ۵ ثانیه طول بکشد، شکست می‌خورد.

  • چرا گزینه ج غلط است: Implicit waitها فقط تعیین می‌کنند که درایور چه مدت برای المانی که کاملاً در DOM غایب است جستجو کند. چون المان قبلاً وجود داشت و سپس stale شد، implicit wait باعث شروع حلقه مکان‌یابی مجدد نمی‌شود و هیچ تاثیری در رفع StaleElementReferenceException ندارد.

  • چرا گزینه د غلط است: کلیک بر اساس مختصات از طریق AutoIt بسیار شکننده است. اگر اندازه پنجره مرورگر تغییر کند، اپلیکیشن در یک کانتینر headless CI/CD اجرا شود یا تراز چیدمان حتی چند پیکسل جابجا شود، فوراً شکست می‌خورد.

  • چرا گزینه ه غلط است: SoapUI برای اعتبارسنجی API و وب‌سرویس‌ها طراحی شده است. این ابزار نمی‌تواند تعاملات پیچیده مرورگر یا رابط‌های کاربری را تحلیل یا رندر کند و برای اتوماسیون رگرسیون UI کاملاً نامناسب است.

  • چرا گزینه و غلط است: ایجاد مجدد کل نشست WebDriver برای شکست یک المان واحد، سربار عظیمی ایجاد می‌کند، وضعیت گام‌های باقی‌مانده در اسکریپت تست را کاملاً به هم می‌ریزد و عملکرد اجرای مجموعه تست را به شدت کاهش می‌دهد.

سوال ۲: استراتژی تست، برنامه‌ریزی و اتوماسیون پایپ‌لاین

شما مأمور به طراحی استراتژی اتوماسیون تست برای یک پلتفرم وب سازمانی هستید که از طریق یک پایپ‌لاین ادغام مداوم مستقر می‌شود. مجموعه تست رگرسیون شامل ۴۰۰ تست UI جامع Selenium است و اجرای متوالی آن‌ها تقریباً ۳ ساعت زمان می‌برد. تیم توسعه چندین بار در روز کد جدید ارسال می‌کند. چگونه باید معماری اتوماسیون را ساختاردهی کنید تا چرخه‌های بازخورد سریع را بدون کاهش پوشش کلی تست تضمین کنید؟

• گزینه‌ها:

  • الف) پایپ‌لاین CI/CD را طوری پیکربندی کنید که مجموعه کامل رگرسیون ۳ ساعته را مستقیماً در مرحله اصلی کامپایل کد برای هر کامیت توسعه‌دهنده اجرا کند.

  • ب) یک مجموعه تست Smoke سبک شامل مسیرهای حیاتی کسب‌وکار استخراج کنید که در کمتر از ۱۰ دقیقه کامل شود تا روی هر کامیت اجرا شود، در حالی که اجرای مجموعه کامل رگرسیون را به صورت موازی روی نودهای توزیع‌شده Selenium Grid به صورت شبانه یا در یک مسیر پایپ‌لاین همزمان مجزا زمان‌بندی کنید.

  • ج) اسکریپت‌های UI اتوماتیک را کاملاً از چرخه استقرار حذف کنید و برای تایید عملکرد اپلیکیشن صرفاً به معیارهای تحلیل استاتیک کد متکی شوید.

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

  • ه) Runner تست را طوری پیکربندی کنید که هر زمان خطای ابزار رخ داد، اجرای اسکریپت را به عنوان pass علامت بزند و برای شناسایی باگ‌های عملکردی کاملاً به تله‌متری پس از استقرار متکی شود.

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

• پاسخ صحیح: ب

• توضیحات:

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

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

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

  • چرا گزینه د غلط است: محدود کردن فرکانس استقرار تیم مهندسی مستقیماً با اصول اصلی Agile و DevOps که بر تحویل مکرر ارزش و کاهش اندازه دسته‌ها (Batch Size) تمرکز دارند، در تضاد است.

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

  • چرا گزینه و غلط است: WinAppDriver برای اپلیکیشن‌های دسکتاپ ویندوز بهینه شده است، نه پلتفرم‌های وب. اجرای یک مجموعه تست عظیم به صورت محلی روی یک ماشین واحد، مانع از مقیاس‌پذیری می‌شود، مزایای ادغام در پایپ‌لاین را از بین می‌برد و فاقد پوشش بین-مرورگری است.

سوال ۳: تست اتوماسیون موبایل و کنترل Context

در حین اجرای یک اسکریپت اتوماسیون موبایل Appium روی یک اپلیکیشن اندروید Hybrid، تست شما نیاز دارد با یک فرم ورودی که داخل یک کامپوننت web-view قرار دارد تعامل کند. بازرس View نیتیو نمی‌تواند Accessibility IDها یا Resource IDهای المان‌های داخل این فرم را استخراج کند. رویکرد فنی درست برای تعامل قابل اعتماد با این المان‌ها چیست؟

• گزینه‌ها:

  • الف) از مختصات پیکسل صفحه استفاده کنید تا تعاملات Tap نیتیو را دقیقاً روی مختصاتی که فرم ورودی روی صفحه دستگاه تست ظاهر می‌شود، تحریک کنید.

  • ب) به صورت برنامه‌نویسی شده هندل‌های context موجود را با استفاده از driver.getContextHandles() استعلام کنید، Context اجرای را از طریق driver.context(name) به context مربوط به web-view تغییر دهید و سپس از مکان‌یاب‌های استاندارد وب مانند CSS selectors یا XPaths استفاده کنید.

  • ج) تعاریف step در Cucumber را ادغام کنید تا هسته سیستم‌عامل موبایل مجبور شود المان‌های HTML تعبیه شده را به ویجت‌های UI نیتیو اندروید ترجمه کند.

  • د) یک ساختار حلقه Python یا Java ایجاد کنید که به طور مداوم صفحه اپلیکیشن نیتیو را رفرش کند تا زمانی که المان‌های وب به عنوان کامپوننت‌های view نیتیو شناسایی شوند.

  • ه) اجرای اپلیکیشن را در یک نمونه WinAppDriver قرار دهید تا کانتینر سیستم‌عامل موبایل داخلی را از محیط یک Runner دسکتاپ مدیریت کنید.

  • و) جریان اجرا را تغییر دهید تا به عنوان یک ارزیابی آسیب‌پذیری ایزوله در SoapUI اجرا شود تا چیدمان صفحه وب زیربنایی خارج از امولاتور موبایل تست شود.

• پاسخ صحیح: ب

• توضیحات:

  • چرا گزینه ب درست است: اپلیکیشن‌های Hybrid یک کانتینر نیتیو را در کنار یک context مرورگر وب تعبیه شده (web-view) اجرا می‌کنند. Appium نمی‌تواند المان‌های HTML داخلی را در حالی که در حالت پیش‌فرض NATIVE_APP است ببیند یا با آن‌ها تعامل کند. با شناسایی contextهای موجود و تغییر صریح تمرکز درایور به context مربوط به web-view، شما به Appium اجازه می‌دهید تا از موتورهای درایور داخلی Chromium/Safari خود برای مکان‌یابی المان‌ها با استفاده از مکان‌یاب‌های قدرتمند وب‌محور استفاده کند.

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

  • چرا گزینه ج غلط است: Cucumber یک فریم‌ورک توسعه رفتار-محور (BDD) است که برای نگاشت متن‌های کسب‌وکار خوانا برای انسان به کدهای تعریف گام (Step Definition) استفاده می‌شود. این ابزار هیچ قابلیتی برای تغییر یا دستکاری کامپایل اپلیکیشن موبایل یا مکانیسم‌های رندرینگ UI ندارد.

  • چرا گزینه د غلط است: یک مکانیسم رفرش حلقوی هرگز المان‌های HTML داخل یک web-view را به ویجت‌های view نیتیو موبایل تبدیل نمی‌کند، زیرا معماری رندرینگ آن‌ها اساساً متفاوت است و در زمان کامپایل اپلیکیشن تعریف شده است.

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

  • چرا گزینه و غلط است: انتقال اعتبارسنجی به یک تست امنیتی ایزوله در SoapUI کاملاً مسیر کاربر (User Journey) را دور می‌زند، اسکریپت عملکردی اپلیکیشن موبایل را بی‌فایده می‌کند و جریان کاربر Hybrid را کاملاً تست‌نشده باقی می‌گذارد.

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

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

• این یک بانک سوالات جامع و اورجینال است

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

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

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

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