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

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

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

• مبانی تست پرفورمنس (۱۵٪): اصول اصلی تست لود در حجم‌های پایه، تست استرس تخریبی، محدودیت‌های مقیاس‌پذیری، تست استقامت (Endurance) طولانی‌مدت و تست Spike برای نوسانات سریع ترافیک.

• برنامه‌ریزی و طراحی تست (۱۸٪): ترسیم سناریوهای تست نماینده، مدل‌سازی رفتار واقعی کاربر، مدل‌سازی ریاضی Workload (قانون لیتل، منحنی‌های همزمانی)، مدیریت داده‌های تست مصنوعی و تعریف اهداف سطح سرویس (SLO) شفاف.

• ابزارهای تست پرفورمنس (۲۰٪): اسکریپت‌نویسی پیشرفته چندپروتکلی، پارامتریک‌سازی و Correlation در Apache JMeter، Micro Focus LoadRunner و Tricentis NeoLoad.

• اجرا و مانیتورینگ تست (۱۲٪): راه‌اندازی محیط تست مشابه محیط Production، تزریق لود توزیع‌شده، مکانیسم‌های مدیریت خطا، تحلیل ناهنجاری‌های داده‌ای و مانیتورینگ لحظه‌ای منابع زیرساختی (CPU، حافظه، Disk I/O، شبکه).

• تحلیل نتایج و بهینه‌سازی (۱۵٪): شناسایی سیستماتیک گلوگاه‌ها (Bottlenecks)، تیونینگ عملکرد معماری، بهینه‌سازی پیکربندی وب‌سرور/اپلیکیشن، برنامه‌ریزی ظرفیت زیرساخت و بنچ‌مارکینگ پایه.

• تست‌های ابری و توزیع‌شده (۱۰٪): راه‌اندازی گره‌های تولید لود جهانی از طریق ارائه‌دهندگان تست ابری، اجرای تست‌های توزیع‌شده در مقیاس بزرگ، تست الاستیسیته و تایید الگوریتم‌های Load Balancing تحت استرس شدید.

• اتوماسیون و یکپارچه‌سازی (۵٪): ادغام اعتبارسنجی عملکرد در خط لوله‌های CI/CD (DevOps)، پلتفرم‌های تست بدون اسکریپت، مقیاس‌بندی زیرساخت‌های کانتینری پویا (Docker, Kubernetes) و طراحی فریم‌ورک‌های تست خودکار.

• متریک‌ها و گزارش‌دهی (۵٪): ردیابی شاخص‌های کلیدی عملکرد (Latency, Throughput, Error Rates)، جمع‌آوری متریک‌ها، بصری‌سازی عمیق داده‌ها، ابزارهای گزارش‌دهی و ساختاردهی ارتباطات فنی با ذینفعان.

درباره دوره

قبولی در مصاحبه برای نقش‌های مهندس پرفورمنس، SDET یا Load Tester بسیار فراتر از دانستن نحوه زدن دکمه «اجرا» در یک ابزار تست است. تیم‌های مهندسی مدرن با چالش‌های معماری بسیار پیچیده‌ای روبرو هستند: میکروسرویس‌هایی که در اثر افزایش ناگهانی ترافیک شکست می‌خورند، نشت‌های حافظه (Memory Leaks) که از تست‌های واحد می‌گذرند اما سیستم را در تست‌های استقامت کرش می‌کنند، و Load Balancerهای اشتباه پیکربندی شده‌ای که باعث توزیع ناعادلانه ترافیک در کلاسترهای سرور می‌شوند. مصاحبه‌کنندگان فنی به دنبال کاندیداهایی هستند که بتوانند علت دقیق گلوگاه سیستم را pinpoint کنند، Thread Dumpها را تفسیر کنند و داده‌های تله‌متری هرج و مرج سرور را به استراتژی‌های بهینه‌سازی ساختاریافته تبدیل کنند.

من این فریم‌ورک جامع آزمون تمرینی شامل ۵۵۰ سوال بسیار فنی و سناریو-محور را توسعه دادم تا محیط سخت‌گیرانه مصاحبه‌های شرکت‌های بزرگ مدرن را شبیه‌سازی کنم. این دوره از تعاریف ساده و سطح بالای واژگان می‌گذرد. در عوض، شما را مستقیماً در حلقه‌های شبیه‌سازی دنیای واقعی قرار می‌دهم: ارزیابی اتمام Thread Pool، رفع باگ‌های Correlation در اسکریپت‌های JMeter یا LoadRunner، تحلیل لاگ‌های Garbage Collection و تعیین اعتبار ریاضی یک مدل Workload خاص. هر سوال با یک تحلیل فنی بسیار دقیق همراه است که توضیح می‌دهد چرا مسیر مهندسی صحیح لود را به‌طور بهینه مدیریت می‌کند و در عین حال، محدودیت‌های دقیق سیستمی که باعث شکست گزینه‌های جایگزین تحت استرس می‌شود را شرح می‌دهد. این ساختار به عنوان یک شبیه‌ساز باfidelity بالا طراحی شده تا رویکرد تفکر سیستمی شما را تقویت کند، نقاط کور فنی را از بین ببرد و دقت مکانیکی مورد نیاز برای عبور از مراحل مصاحبه مهندسی پرفورمنس را در اولین تلاش به شما بدهد.

نمونه سوالات تمرینی

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

سوال ۱: تشخیص ناهنجاری‌های عملکردی در تست استقامت (Endurance Testing)

در طول یک تست استقامت ۷۲ ساعته مداوم روی یک پلتفرم تجارت الکترونیک سازمانی تحت یک پروفایل لود ثابت و پایدار، تله‌متری مانیتورینگ نشان می‌دهد که زمان پاسخگویی اپلیکیشن به مرور زمان به‌صورت خطی کاهش می‌یابد، در حالی که میزان استفاده از CPU سرور روی ۳۵٪ ثابت می‌ماند. با این حال، فعالیت Paging File در سطح سیستم‌عامل به‌طور مداوم افزایش می‌یابد تا زمانی که کانتینر اپلیکیشن با خطای OutOfMemoryError (OOM) کرش می‌کند. علت ریشه‌ای این رفتار عملکردی چیست؟

• الف) یک الگوی کلاسیک CPU Throttling ناشی از Micro-stuttering در لایه مجازی‌سازی.

• ب) یک نشت شدید حافظه Heap یا Native که در آن منابع تخصیص یافته توسط محیط Runtime جمع‌آوری نمی‌شوند.

• ج) لود بالانسر دچار یک نقص مسیریابی چرخشی شده که تمام Thread Poolهای فعال را به یک گره واحد هدایت می‌کند.

• د) مشکل اتمام Connection Pool دیتابیس که در آن وضعیت Threadها به یک Deadlock غیرقابل حل تغییر می‌کند.

• ه) اشباع کارت شبکه (NIC) که باعث فروپاشی سیستماتیک اندازه پنجره‌های TCP می‌شود.

• و) اسکریپت تست در حفظ Pacing حالت پایدار شکست خورده و منجر به افزایش ناگهانی و ناخواسته ترافیک شده است.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• چرا درست است: کاهش خطی زمان پاسخگویی همراه با افزایش فعالیت Paging File و پروفایل ثابت CPU به‌شدت به اشباع حافظه اشاره دارد. وقتی یک اپلیکیشن در طول تست‌های استقامت طولانی‌مدت دچار نشت حافظه می‌شود، RAM فیزیکی سیستم‌عامل تمام شده و سیستم مجبور به استفاده از حافظه مجازی (Paging/Swapping روی دیسک) می‌شود. چون I/O دیسک بسیار کندتر از RAM سخت‌افزاری است، زمان پاسخگویی افزایش می‌یابد. این چرخه ادامه می‌یابد تا زمانی که محدودیت‌های فیزیکی تکمیل شده و منجر به خطای مرگبار OutOfMemoryError شود.

• چرا گزینه‌های دیگر غلط هستند:

• گزینه الف غلط است: CPU Throttling یا Micro-stuttering باعث ایجاد پیک‌های نامنظم و دندانه‌دار در نمودارهای CPU می‌شود، نه یک خط صاف ۳۵٪.

• گزینه ج غلط است: اگر لود بالانسر ترافیک را به یک گره هدایت می‌کرد، پروفایل CPU آن گره خاص در مراحل اولیه تست به شدت به سمت اشباع ۱۰۰٪ می‌رفت.

• گزینه د غلط است: اتمام Connection Pool معمولاً باعث تایم-اوت‌های ناگهانی و تخت برای تراکنش‌های ورودی می‌شود، نه یک افت تدریجی و نرم مرتبط با گسترش Page-file.

• گزینه ه غلط است: اشباع کارت شبکه باعث کاهش نرخ Throughput و پرتاب استثناهای Socket Time-out فوری در گره‌های تزریق لود می‌شود.

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

سوال ۲: ارزیابی پیشرفته Correlation و Regular Expression در اسکریپت‌نویسی ابزارها

یک تست‌کننده پرفورمنس در حال نوشتن یک گردش کار پیچیده تجاری در Apache JMeter است که با یک سیستم امنیتی تعامل دارد. اپلیکیشن یک توکن رمزنگاری‌شده پویا و یک‌بار مصرف به نام sys_auth_id تولید می‌کند که در بدنه پاسخ HTTP به این صورت قرار دارد: {"security":{"token":"A47B_99x","expiry":3600}}. این توکن در هر تراکنش تغییر می‌کند. کدام پیکربندی Regular Expression مقدار توکن را به‌طور تمیز و بدون شامل کردن ساختار JSON اطراف استخراج می‌کند؟

• الف) {"security":{"token":"(.+?)" با انتخاب تمپلیت $0

• ب) "token":"([^"]+)" با انتخاب تمپلیت $1

• ج) token":"(.*)" با انتخاب تمپلیت $0

• د) "token":"([A-Z0-9_]+)" با انتخاب تمپلیت $2

• ه) token":"(.*?) با انتخاب تمپلیت $1

• و) (?<=token":")([A-Z0-9_]+) با انتخاب تمپلیت $0

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• چرا درست است: عبارت منظم "token":"([^"]+)" شناسه کلید منحصربه‌فرد را هدف قرار می‌دهد. پیکربندی گروه کپچر ([^"]+) به موتور دستور می‌دهد که یک یا چند کاراکتر را که نشان‌دهنده کوتیشن دوگانه نیستند کپچر کند و به‌طور تمیز A47B_99x را جدا کند. جفت کردن این با فلگ تمپلیت $1 به JMeter می‌گوید که فقط محتویات اولین گروه کپچر منطقی را استخراج کند و مقدار تمیز را به درخواست‌های HTTP پویا بعدی پاس دهد.

• چرا گزینه‌های دیگر غلط هستند:

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

• گزینه ج غلط است: توالی Wild-card (.*) به‌صورت Greedy عمل می‌کند؛ یعنی از کوتیشن بسته عبور کرده و بقیه رشته JSON شامل المان‌های expiry را هم می‌بلعد.

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

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

• گزینه و غلط است: Lookbehind assertions به‌طور بومی و قابل اعتماد در اجزای استخراج‌کننده Regex استاندارد JMeter بدون دور زدن‌های پیچیده پیکربندی مدیریت نمی‌شوند.

سوال ۳: محاسبات مدل‌سازی Workload و تخصیص ریاضی همزمانی (Concurrency)

شما در حال طراحی یک تست پرفورمنس بر اساس تله‌متری لاگ‌های Production هستید. داده‌های تولید نشان می‌دهد که ۳,۶۰۰ کاربر تجاری در هر ساعت وارد شده و دقیقاً یک گردش کار Checkout را تکمیل می‌کنند. میانگین مدت زمان تراکنش End-to-End برای یک سفر کاربر دقیقاً ۴۵ ثانیه اندازه‌گیری شده است. بر اساس قانون لیتل (Little's Law)، حداقل مقدار همزمانی کاربر (User Concurrency) در حالت پایدار که در ابزار تزریق لود شما مورد نیاز است تا این نرخ Throughput هدف را بدون تاخیرهای Pacing به دست آورید، چقدر است؟

• الف) ۱۵ کاربر همزمان

• ب) ۴۵ کاربر همزمان

• ج) ۶۰ کاربر همزمان

• د) ۸۰ کاربر همزمان

• ه) ۱۲۰ کاربر همزمان

• و) ۳۰۰ کاربر همزمان

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• چرا درست است: قانون لیتل رابطه ریاضی بین همزمانی، نرخ ورود و مدت زمان را از طریق فرمول $L = \lambda \times W$ تعیین می‌کند. ابتدا نرخ ورود ($\lambda$) در هر ثانیه را محاسبه کنید: ۳,۶۰۰ تراکنش تقسیم بر ۳,۶۰۰ ثانیه در یک ساعت برابر است با دقیقاً ۱ تراکنش در ثانیه. سپس این نرخ ورود را در میانگین مدت زمان پردازش ($W$) که ۴۵ ثانیه است ضرب کنید. $L = 1 \text{ txn/sec} \times 45 \text{ seconds} = 45$. این بدان معناست که شما باید حداقل ۴۵ کاربر فعال همزمان در حالت پایدار داشته باشید تا آن حجم تولیدی را شبیه‌سازی کنید.

• چرا گزینه‌های دیگر غلط هستند:

• گزینه الف غلط است: ۱۵ کاربر همزمان تحت این محدودیت‌های زمانی تنها ۱,۲۰۰ گردش کار تکمیل شده در ساعت تولید می‌کنند.

• گزینه ج غلط است: ۶۰ کاربر همزمان از Throughput ریاضی هدف فراتر رفته و تقریباً ۴,۸۰۰ تراکنش ساعتی تولید می‌کند.

• گزینه د غلط است: ۸۰ کاربر همزمان پروفایل سیستم را از تراز با خطوط پایه لاگ‌های تولید خارج می‌کند.

• گزینه ه غلط است: ۱۲۰ کاربر همزمان نشان‌دهنده یک فاکتور تورمی است که حجم کاربران ردیابی شده در لاگ‌های تولید را به اشتباه نمایش می‌دهد.

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

آنچه انتظار داشته باشید

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

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

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

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

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

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

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