تست عملکرد چیست؟ تفاوت Load، Stress و Scalability

ممکن است API پرداخت در تست دستی با کد ۲۰۰ پاسخ دهد، اما در فروش ویژه p99 آن به ۱۲ ثانیه برسد؛ کاربر دوباره روی پرداخت بزند، درخواست Retry شود و سفارش تکراری بسازد. از نظر Functional مسیر ظاهراً سالم است، ولی از نظر سرعت، ظرفیت و پایداری آماده بار واقعی نیست. تست عملکرد این فاصله را پیش از بحران آشکار می‌کند.

در این راهنما، Performance Testing را از تعریف تا اجرا یاد می‌گیرید: تفاوت Load، Stress، Spike، Soak و Scalability؛ ساخت Workload Model؛ انتخاب p95 و p99؛ تعیین Threshold؛ تشخیص گلوگاه و یک مثال عملی برای فروشگاه ایرانی. تمرکز این مقاله مبانی اجرایی است؛ طراحی پیشرفته برنامه و انواع بیشتر در مقاله تخصصی جداگانه آمده است.

تست عملکرد یا Performance Testing چیست؟

تست عملکرد ارزیابی می‌کند سیستم در برابر یک Workload مشخص، با چه سرعت، ظرفیت، پایداری و مصرف منبعی کار می‌کند. این تست زیرمجموعه تست غیرکارکردی است، اما در طول اجرا باید درستی نتیجه نیز کنترل شود؛ پاسخ سریع اما اشتباه، عملکرد قابل قبول نیست.

هدف می‌تواند پاسخ به یکی از این پرسش‌ها باشد:

• آیا سامانه بار عادی و اوج پیش‌بینی‌شده را با SLO مورد نظر تحمل می‌کند؟
• در چه نقطه‌ای Latency، Error یا Saturation از حد قابل قبول عبور می‌کند؟
• پس از یک Spike یا کمبود منبع، سیستم چگونه و در چه زمانی بازیابی می‌شود؟
• با دو برابرشدن منابع، ظرفیت چقدر افزایش می‌یابد و هزینه هر تراکنش چگونه تغییر می‌کند؟
• یک تغییر کد یا زیرساخت نسبت به Baseline چه Regressionی ساخته است؟

تفاوت تست Performance با Functional و Frontend Performance

یک Load Test پروتکل HTTP لزوماً JavaScript سنگین، رندر مرورگر یا تجربه شبکه موبایل را اندازه نمی‌گیرد. در وب، Core Web Vitals فعلی شامل LCP، INP و CLS است و باید با داده آزمایشگاهی و Field Data بررسی شود. نتیجه Backend و Frontend را مرتبط اما جدا گزارش کنید.

انواع تست عملکرد

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

تفاوت Load Test و Stress Test

Load Test

بار هدف از داده یا پیش‌بینی کسب‌وکار می‌آید: مثلاً Peak واقعی، رشد کمپین و حاشیه اطمینان توافق‌شده. تست در محدوده‌ای اجرا می‌شود که محصول باید Service Level Objective را رعایت کند. شکست یعنی Requirement عملکرد برآورده نشده است.

Stress Test

بار یا محدودیت منبع عمداً فراتر از شرایط معمول می‌رود تا Saturation، رفتار تخریب، کنترل Backpressure و Recovery دیده شود. هدف «کرش دادن بی‌برنامه» نیست؛ Stop Condition، پنجره اجرا، مالک زیرساخت و روش بازگردانی باید پیشاپیش مشخص باشند.

نکته ایمنی: Stress یا Spike روی Production بدون مجوز صریح، محدودیت بار، مانیتورینگ و برنامه توقف انجام ندهید. چنین تستی می‌تواند به کاربران، داده و سرویس‌های ثالث آسیب بزند.

Workload Model چیست و چرا از تعداد VU مهم‌تر است؟

Workload Model توصیف می‌کند چه مقدار کار، با چه ترکیبی، چه توزیع داده‌ای و در چه زمان‌بندی‌ای وارد سیستم می‌شود. «۵۰۰۰ کاربر هم‌زمان» به‌تنهایی مبهم است: این افراد در هر ثانیه چند تراکنش می‌سازند؟ فقط صفحه می‌خوانند یا پرداخت می‌کنند؟ Think Time و Session Duration چقدر است؟

مدل خوب این اجزا را دارد:

• Business Transactions: جست‌وجو، مشاهده محصول، افزودن سبد، Login و Checkout؛
• Mix: سهم هر تراکنش از ترافیک؛
• Arrival/Throughput: درخواست یا Iteration در واحد زمان؛
• Concurrency: کارهای هم‌زمان در حال اجرا؛
• Think/Pacing: مکث طبیعی و فاصله تکرار سفر؛
• Data Distribution: کالای محبوب و Long Tail، حساب تازه و قدیمی، Cache Hit/Miss؛
• Temporal Pattern: Warm-up، Ramp-up، Steady State، Spike و Cool-down؛
• Dependencies: درگاه، پیامک، Search، Queue و Rate Limit سرویس ثالث.

مدل بار Open و Closed

Closed Workload Model

در مدل Closed، Virtual User پس از پایان Iteration قبلی کار بعدی را آغاز می‌کند. اگر سیستم کند شود، همان VU دیرتر تکرار می‌کند و نرخ ورود کار پایین می‌آید. این مدل برای جمعیت ثابتِ کاربران تعاملی می‌تواند مناسب باشد.

Open Workload Model

در مدل Open، Arrival Rate مستقل از زمان پاسخ هدف تنظیم می‌شود؛ مثلاً هر ثانیه ۱۰۰ سفارش جدید وارد شود. برای جریان‌هایی که تقاضا با کندشدن سرور متوقف نمی‌شود، این مدل واقع‌بینانه‌تر است.

مستندات رسمی k6 درباره مدل Open و Closed توضیح می‌دهد که در مدل Closed، کندشدن سیستم می‌تواند Arrival Rate را ناخواسته کاهش دهد؛ پدیده‌ای مرتبط با Coordinated Omission. مدل را بر اساس رفتار تقاضا انتخاب کنید، نه صرفاً قابلیت پیش‌فرض ابزار.

چگونه نیازمندی عملکرد قابل تست بنویسیم؟

عبارت «سامانه باید سریع باشد» Testable نیست. یک NFR عملکردی باید سناریو، بار، Dataset، محیط، پنجره اندازه‌گیری، Percentile، Error و شرط پایداری را مشخص کند.

نمونه آموزشی: در محیط Performance با پیکربندی مستند و داده معادل ۵ میلیون کالا، هنگام ۲۰۰ درخواست جست‌وجو و ۲۰ درخواست Checkout در ثانیه به مدت ۳۰ دقیقه پس از Warm-up، p95 زمان جست‌وجو کمتر از ۸۰۰ میلی‌ثانیه، p99 کمتر از ۱۵۰۰ میلی‌ثانیه و نرخ خطای فنی کمتر از ۰٫۵٪ باشد؛ هیچ سفارش یا برداشت تکراری رخ ندهد و Queue پس از پایان بار ظرف پنج دقیقه به Baseline بازگردد.

عددهای بالا نمونه‌اند، نه استاندارد جهانی. Threshold واقعی باید از SLO، داده کاربران، ریسک و هزینه ظرفیت محصول شما بیاید. معیار عملکرد را از همان مرحله تحلیل نیازمندی روشن کنید.

متریک‌های کلیدی در Performance Testing

چهار سیگنال معرفی‌شده در Google SRE: Monitoring Distributed Systems چارچوب مفیدی هستند: Latency، Traffic، Errors و Saturation. در تست عملکرد، Correctness و Cost را نیز کنار آن‌ها بگذارید.

Latency و Percentile

• p50: میانه تجربه؛ نیمی سریع‌تر و نیمی کندترند.
• p95: تجربه ۵٪ کندتر را نمایان می‌کند.
• p99: Tail بحرانی را بهتر نشان می‌دهد، ولی به حجم نمونه و نویز حساس‌تر است.
• Max: برای تشخیص رخداد بد مفید است، اما به‌تنهایی Threshold پایدار نیست.

Average می‌تواند چند درخواست بسیار کند را پنهان کند. Latency پاسخ‌های موفق و ناموفق را جدا ببینید؛ خطای ۵۰۰ ممکن است سریع برگردد و میانگین را ظاهراً بهتر کند.

Traffic و Throughput

RPS، TPS، پیام بر ثانیه یا حجم داده معیار تقاضاست. Request با Transaction یکی نیست: یک Checkout ممکن است چند درخواست و چند پیام بسازد. واحد را دقیق نام‌گذاری کنید و نرخ موفق را از کل تلاش‌ها جدا کنید.

Error Rate و Correctness

فقط HTTP 5xx را خطا ندانید. Timeout، ۴۲۹، پاسخ ناقص، Business Error غیرمنتظره، سفارش تکراری و پیام گم‌شده مهم‌اند. اسکریپت Load باید Response و اثر کسب‌وکار را Assert کند؛ وگرنه سامانه‌ای که سریع خطا می‌دهد Pass می‌شود.

Saturation و منابع

CPU، Memory، GC، Disk I/O، Network، Thread Pool، Connection Pool، Queue Depth، Lock Wait و Database Connections را متناسب با معماری اندازه بگیرید. درصد CPU پایین تضمین سلامت نیست؛ ممکن است گلوگاه Connection Pool یا سرویس پایین‌دست باشد.

Client، Server و Dependency Timing

زمان از دید Load Generator، زمان ثبت‌شده در سرویس، Spanهای Trace و زمان وابستگی را کنار هم بگذارید. تفاوت آن‌ها می‌تواند شبکه، TLS، Queue یا Serialization را آشکار کند. یک نمودار بدون هم‌ترازی ساعت‌ها و Trace ID عیب‌یابی را دشوار می‌کند.

فرایند گام‌به‌گام تست عملکرد

1. هدف و ریسک را تعیین کنید: Release Gate، Capacity، Regression، کمپین یا Recovery؟
2. SLO و Threshold را بنویسید: چه متریکی، در چه Scope و چه بازه‌ای Pass/Fail می‌شود؟
3. Workload را از داده بسازید: Analytics، Log، Forecast و Business Event؛ داده شخصی را ناشناس کنید.
4. محیط و Dataset را مستند کنید: نسخه، منابع، Autoscaling، Cache، DB، Feature Flag و سرویس ثالث.
5. اسکریپت را Functional Validate کنید: Correlation، Token، داده پویا، Check و Cleanup درست باشند.
6. Load Generator را Baseline کنید: CPU، شبکه و محدودیت Port خود Generator نباید گلوگاه شود.
7. Smoke و Baseline اجرا کنید: با بار کم، درستی و Telemetry را کنترل کنید.
8. Ramp و Steady State اجرا کنید: بار را کنترل‌شده افزایش دهید و زمان کافی برای مشاهده رفتار پایدار بدهید.
9. Telemetry را هم‌زمان جمع کنید: Metric، Log، Trace، Deployment Event و Queryهای کند.
10. نتیجه و Bottleneck را تحلیل کنید: هم‌بستگی زمانی بسازید و با آزمایش کنترل‌شده فرضیه را تأیید کنید.
11. اصلاح و Retest کنید: همان Workload و محیط را تا حد ممکن تکرار کنید.

مثال Test Plan فروشگاه ایرانی

هدف

بررسی آمادگی Checkout برای کمپین با نرخ سفارش دو برابر Peak مشاهده‌شده، بدون تکرار سفارش و با بازیابی کنترل‌شده درگاه.

ترکیب تراکنش نمونه

این درصدها فقط مثال‌اند و باید با داده واقعی جایگزین شوند. برای Endpointها، Authentication و Assertionهای درست از راهنمای تست API استفاده کنید.

مراحل اجرا

• ۵ دقیقه Smoke با بار کم و کنترل صحت مالی؛
• Warm-up تا پایدارشدن Cache و JIT طبق معماری؛
• Ramp تدریجی تا بار هدف؛
• ۳۰ دقیقه Steady State برای ارزیابی SLO؛
• Spike کنترل‌شده برای کمپین؛
• Cool-down و سنجش تخلیه Queue و Recovery؛
• Soak جداگانه برای نشتی منابع و Jobهای زمان‌بندی‌شده؛
• Stress فقط در محیط و پنجره مجاز با Stop Condition.

شرایط توقف ایمن

مثلاً اگر Error بحرانی مالی، رشد کنترل‌نشده Queue، مصرف نزدیک سقف پایدار، اثر بر کاربر واقعی یا ناتوانی Generator در حفظ نرخ رخ دهد، تست متوقف می‌شود. Stop Condition را با SRE و مالک محصول پیش از اجرا توافق کنید.

محیط و داده Performance Test

محیط لازم نیست همیشه کپی کامل Production باشد، اما تفاوت‌ها باید شناخته و اثرشان تحلیل شود. اگر ظرفیت محیط نصف Production است، فرض خطی‌بودن مقیاس را بدون شواهد نپذیرید. Database Size، Index، Network، CDN، Cache، Autoscaling و محدودیت سرویس ثالث می‌توانند نتیجه را عوض کنند.

چک‌لیست راه‌اندازی محیط تست را با این موارد تکمیل کنید:

• نسخه App، Schema و Infrastructure as Code؛
• Resource Limit و Replica Count؛
• حجم و توزیع Dataset، نه فقط تعداد رکورد؛
• Cache سرد/گرم و سیاست Eviction؛
• Autoscaling Min/Max و زمان واکنش؛
• Telemetry Sampling و هزینه Observability؛
• Stub/Sandbox/واقعی بودن Payment، SMS و Search؛
• Clock Sync و منطقه زمانی Generatorها؛
• ظرفیت شبکه و مکان جغرافیایی تولید بار.

ابزارهای تست عملکرد

انتخاب ابزار بر اساس پروتکل، مدل بار، مهارت تیم، توزیع جغرافیایی، محدودیت دسترسی و نیاز Telemetry انجام می‌شود:

• JMeter: اکوسیستم گسترده و پشتیبانی چند پروتکل؛ برای شروع و معماری اجرای توزیع‌شده، راهنمای Apache JMeter را ببینید.
• k6: سناریوهای کدنویسی‌شده با JavaScript و مدل‌های Arrival Rate؛
• Gatling: سناریوهای کدنویسی‌شده و گزارش Performance؛
• Locust: تعریف رفتار کاربر با Python؛
• ابزارهای APM/Observability: برای Metric، Trace، Log و Profiling؛ مولد بار نیستند اما برای تشخیص لازم‌اند.

مقاله مقایسه k6 و Gatling در کنار JMeter مسیر انتخاب ابزار را عمیق‌تر می‌کند. قبل از انتخاب، امکان اجرای Local/On-premise را نیز بسنجید؛ وابستگی کامل به Cloud خارجی ممکن است برای تیم ایرانی ریسک دسترسی و پرداخت داشته باشد.

Threshold و Pass/Fail

Threshold باید از هدف محصول بیاید و داخل اجرای خودکار قابل ارزیابی باشد. مستندات Thresholdهای k6 نمونه‌هایی مانند شرط روی Percentile، Count و Rate ارائه می‌کند.

نمونه مفهومی:
checkout p(95) < 800ms
checkout p(99) < 1500ms
technical_error_rate < 0.5%
duplicate_order_count = 0
queue_recovery_time < 5m

Threshold کلی برای همه Endpointها ننویسید. Health Check، جست‌وجو و گزارش سنگین اهمیت و Budget متفاوت دارند. نتایج Warm-up و Ramp را نیز بی‌دلیل با Steady State مخلوط نکنید.

تحلیل گلوگاه؛ از هم‌بستگی تا علت

اگر هم‌زمان با افزایش p99، Connection Pool پر شده است، یک فرضیه داریم؛ هنوز علت اثبات نشده. ظرفیت Pool را کنترل‌شده تغییر دهید یا Trace نمونه را بررسی کنید و تست را تکرار کنید. افزایش بی‌هدف همه منابع ممکن است علامت را پنهان و هزینه را بالا ببرد.

روند تحلیل:

1. لحظه عبور از Threshold را روی Timeline پیدا کنید.
2. تراکنش و گروه خطا را جدا کنید.
3. Latency را به Client، Gateway، Service، DB و Dependency بشکنید.
4. Saturation، Queue و Retry را در همان پنجره بررسی کنید.
5. تغییر Deployment، Autoscaling و Job زمان‌بندی‌شده را روی نمودار قرار دهید.
6. فرضیه محدود بسازید و با یک تغییر کنترل‌شده Retest کنید.

گزارش اجرای Performance باید نسخه، Workload واقعیِ تولیدشده، اختلاف با Target، Thresholdهای Pass/Fail و محدودیت نتیجه را ثبت کند. راهنمای اجرای تست و ثبت شواهد برای ساخت Evidence قابل پیگیری مفید است.

خطاهای رایج در تست عملکرد

• تمرکز بر VU: بدون نرخ ورود، Think Time و Transaction Mix، عدد کاربر معنی کسب‌وکاری ندارد.
• گزارش Average: Tail Latency و کاربران کند پنهان می‌شوند.
• عدم بررسی Response: خطای سریع به‌عنوان موفقیت ثبت می‌شود.
• Generator ضعیف: منبع تولید بار زودتر از SUT اشباع می‌شود.
• Cache و Data غیرواقعی: همه درخواست‌ها یک کالا را می‌زنند یا Dataset بسیار کوچک است.
• نادیده‌گرفتن Warm-up: JIT، Connection و Cache با Steady State مخلوط می‌شوند.
• Closed Model برای Arrival ثابت: کندشدن سیستم خودبه‌خود بار تولیدی را کم می‌کند.
• Environment Drift: اجرای قبل و بعد روی نسخه یا پیکربندی متفاوت مقایسه می‌شود.
• نداشتن Telemetry: فقط نمودار کلاینت داریم و علت قابل تشخیص نیست.
• Stress بدون Guardrail: تست از دامنه مجاز عبور می‌کند یا به سرویس ثالث فشار می‌زند.
• مقایسه ناسالم: Percentileهای دو اجرا با حجم نمونه و Workload متفاوت کنار هم گذاشته می‌شوند.
• اعلام Capacity از یک Run: نویز، Autoscaling و وضعیت داده نادیده گرفته می‌شوند.

نکات ویژه برای تیم‌های ایرانی

• Latency داخلی، بین‌المللی و مسیر CDN را جدا اندازه بگیرید؛ مکان Generator نتیجه را تغییر می‌دهد.
• تحریم یا محدودیت پرداخت سرویس Cloud را پیش از وابستگی به Load Generator خارجی بسنجید.
• درگاه بانکی و پیامک را بدون هماهنگی زیر بار نگذارید؛ Sandbox یا Stub با رفتار Timeout/Retry بسازید.
• ریال/تومان، Callback پرداخت و سفارش تکراری را به‌عنوان Correctness زیر بار کنترل کنید.
• کمپین‌های تقویمی، فروش لحظه‌ای و شروع ثبت‌نام می‌توانند Spike بسازند؛ فقط Average روزانه را مدل نکنید.
• شبکه موبایل ناپایدار و Retry کلاینت ممکن است تقاضای Backend را چند برابر کند.
• Log و Trace نباید شماره کارت، تلفن، Token یا داده شخصی واقعی را وارد گزارش کنند.

چک‌لیست Performance Testing

• هدف تست و تصمیم مورد انتظار روشن است.
• SLO/Threshold برای Transactionهای حیاتی تعریف شده است.
• Workload از داده یا فرضیه مستند ساخته شده است.
• Open/Closed بودن مدل با رفتار تقاضا سازگار است.
• Transaction Mix، Arrival Rate، Concurrency و Think Time مشخص‌اند.
• Dataset از نظر حجم و توزیع نماینده است.
• محیط، نسخه، منابع، Cache و Autoscaling ثبت شده‌اند.
• اسکریپت با بار کم از نظر Functional و Correlation تأیید شده است.
• Load Generator ظرفیت و مانیتورینگ کافی دارد.
• p50، p95، p99، Traffic، Error، Correctness و Saturation ثبت می‌شوند.
• پاسخ موفق و ناموفق جدا تحلیل می‌شود.
• Warm-up، Ramp و Steady State در گزارش قابل تفکیک‌اند.
• Stop Condition و مجوز اجرای Stress روشن است.
• سرویس‌های ثالث از بار ناخواسته محافظت شده‌اند.
• یافته با Timeline، Trace و فرضیه علت مستند می‌شود.
• اصلاح با Workload قابل مقایسه Retest می‌شود.

جمع‌بندی

تست عملکرد مسابقه تولید بیشترین درخواست نیست؛ آزمایشی کنترل‌شده برای پاسخ به یک سؤال ظرفیت، سرعت، پایداری یا مقیاس است. ارزش نتیجه به واقع‌گرایی Workload، کیفیت Telemetry و صراحت Threshold وابسته است.

برای شروع، یک Transaction حیاتی انتخاب کنید، Peak واقعی و ترکیب رفتار را از داده استخراج کنید، با بار کم درستی Script را ثابت کنید و سپس Load Test کنترل‌شده با p95/p99، نرخ خطا، Correctness و Saturation اجرا کنید. پس از Baseline می‌توانید Spike، Soak، Stress و Scalability را با هدف‌های جدا اضافه کنید.

سوالات متداول درباره تست عملکرد

تست عملکرد چیست؟

ارزیابی سرعت، ظرفیت، پایداری و مصرف منابع سیستم زیر Workload تعریف‌شده است. نتیجه با Thresholdهایی مانند Percentile زمان پاسخ، Throughput، Error Rate، Correctness و Saturation سنجیده می‌شود.

تفاوت Load Test و Stress Test چیست؟

Load Test بررسی می‌کند سیستم در بار عادی و Peak مورد انتظار SLO را رعایت می‌کند یا نه. Stress Test آگاهانه از این محدوده عبور می‌کند تا اشباع، رفتار تخریب و بازیابی را با Guardrail مشخص بسنجد.

چرا p95 و p99 از Average مهم‌ترند؟

Average می‌تواند اقلیتی از پاسخ‌های بسیار کند را پنهان کند. p95 و p99 Tail تجربه را نشان می‌دهند. بااین‌حال Percentile باید همراه حجم نمونه، نرخ خطا و Scope تراکنش تفسیر شود.

چند کاربر مجازی برای تست لازم است؟

عدد ثابتی وجود ندارد. بار از نرخ تراکنش، Concurrency، Think Time، Session و Mix واقعی یا Forecast کسب‌وکار مشتق می‌شود. VU فقط یکی از ابزارهای تولید آن Workload است.

آیا تست عملکرد روی Production انجام می‌شود؟

برخی اندازه‌گیری‌های کنترل‌شده یا بازیابی ممکن است با مجوز در Production انجام شوند، اما Load/Stress بی‌اجازه خطرناک است. دامنه، سقف بار، پنجره، Kill Switch، مانیتورینگ و اثر بر کاربر و سرویس ثالث باید از قبل تصویب شود.

منابع فنی

• Google SRE — Monitoring Distributed Systems
• Grafana k6 — Open and Closed Workload Models
• Grafana k6 — Thresholds
• web.dev — Web Vitals