Stress Test در توسعه موبایل: چیست، اهداف و چگونه انجام می‌شود

Stress Test چیست؟

Stress Test (تست استرس) فرآیند ارزیابی توانایی سیستم برای کار در شرایطی فراتر از پارامترهای محاسبه شده است. برای یک برنامه موبایل، این می‌تواند به معنای 10000 اعلان push همزمان در مقابل هنجار 1000 باشد، برای بک‌اند — 50000 RPS در مقابل 5000 مورد انتظار. تفاوت اصلی Stress Test با Load Test در این است که هدف تأیید عملکرد نیست، بلکه مطالعه رفتار سیستم فراتر از ظرفیت طراحی شده آن است. Netflix Engineering (2024) Stress Test را به عنوان «بررسی این فرضیه که سیستم به طور قابل پیش‌بینی خراب می‌شود» تعریف می‌کند.

تست استرس شامل دو مرحله اجباری است: بارگذاری تا شکست و مشاهده بازیابی. بازیابی (recovery) توانایی سیستم برای بازگشت به کار عادی پس از رفع اضافه بار است. سیستمی که بدون راه‌اندازی مجدد بازیابی نمی‌شود، حتی اگر بار کوتاه مدت را تحمل کند، شکننده محسوب می‌شود. بر اساس AWS Well-Architected Framework (2024)، زمان بازیابی پس از Stress Test نباید از 5 دقیقه تجاوز کند.

برای کلاینت‌های موبایل، Stress Test شامل بررسی عملکرد در شرایط خاتمه اجباری فرآیندها، قطع شبکه و اتمام حافظه RAM است. Android Low Memory Killer ممکن است در کمبود RAM فرآیند پس‌زمینه را خاتمه دهد — تست استرس باید بررسی کند که برنامه به درستی وضعیت را پس از چنین خاتمه‌ای بازیابی می‌کند. Apple UIKit (2024) توصیه می‌کند سناریوهای memory warning را در هر صفحه از برنامه آزمایش کنید.

اهداف تست استرس

تعیین نقطه شکست

اولین هدف Stress Test — تعیین نقطه شکست (breaking point). این لحظه‌ای است که یکی از شاخص‌های کلیدی عملکرد از آستانه بحرانی عبور می‌کند: زمان پاسخ p95 از 10 ثانیه فراتر می‌رود، درصد خطاهای HTTP 5XX از 5% فراتر می‌رود یا توان عملیاتی به زیر 50% baseline می‌رسد. ثبت نقطه شکست به تیم اجازه می‌دهد از قبل حد مقیاس‌پذیری سیستم را بداند. Capacity planning دقیقاً بر داده‌های Stress Test متکی است، نه Load Test، زیرا Load Test شرایط مرزی را بررسی نمی‌کند.

بررسی مکانیسم‌های بازیابی

هدف دوم — بررسی مکانیسم‌های بازیابی. پس از کاهش بار به سطح عادی، سیستم باید به شاخص‌های استاندارد بازگردد. اگر اتصالات پایگاه داده آزاد نشوند یا کش invalid نشود، Stress Test این مشکل را آشکار می‌کند. Circuit breaker (Hystrix, Resilience4j) باید در هنگام اضافه بار فعال شود و پس از تثبیت، اتصال را به طور خودکار بازیابی کند. Health check endpointها به نظارت بر وضعیت هر سرویس در طول آزمایش کمک می‌کنند.

اعتبارسنجی auto-scaling

هدف سوم — اعتبارسنجی auto-scaling. اگر زیرساخت از Kubernetes یا AWS Auto Scaling استفاده می‌کند، Stress Test بررسی می‌کند که podها یا نمونه‌های جدید به اندازه کافی سریع ایجاد می‌شوند. بر اساس Google Kubernetes Engine (2024)، زمان استقرار یک pod جدید نباید از 30 ثانیه از لحظه فعال شدن معیار HPA (Horizontal Pod Autoscaler) تجاوز کند. HPA باید بر اساس CPU، حافظه و معیارهای سفارشی مقیاس‌دهی کند. Cluster Autoscaler گره‌های جدیدی اضافه می‌کند اگر گره‌های فعلی podها را جای ندهند.

روش‌شناسی Stress Test

افزایش تدریجی بار (Ramp-up Stress Test) — رایج‌ترین سناریو. بار اولیه در سطح 50% بار مورد انتظار تنظیم می‌شود، سپس هر 2 دقیقه 10% افزایش می‌یابد تا زمانی که سیستم از کار بیفتد. این سناریو امکان یافتن مرز دقیق پایداری را فراهم می‌کند. Grafana Cloud k6 (2025) برای به دست آوردن نمودار صاف زمان پاسخ، افزایش گام بیش از 10% را توصیه نمی‌کند.

جهش ناگهانی بار (Spike Stress Test) — بار در عرض 10-30 ثانیه از 10% به 500% افزایش می‌یابد. این سناریو موقعیت‌هایی مانند انتشار ویروسی محتوا یا حمله DDoS را مدل‌سازی می‌کند. Spike Stress Test نه چندان عملکرد بلکه سرزندگی سیستم را بررسی می‌کند: توانایی سقوط نکردن کامل و بازگشت به کار پس از تثبیت. API Gateway باید rate limiting را برای محافظت از بک‌اند در برابر جهش‌های ناگهانی پیکربندی کند.

نگهداری طولانی مدت اضافه بار (Sustained Stress Test) — سیستم به مدت 30-60 دقیقه در حالت اضافه بار نگه داشته می‌شود. این سناریو نشت منابعی را آشکار می‌کند که در آزمایش‌های کوتاه مدت ظاهر نمی‌شوند. نشت حافظه در برنامه‌های Java/Kotlin در طول 20-40 دقیقه کار فشرده جمع می‌شود و تنها Sustained Stress Test آن را کشف می‌کند.

تحلیل نقطه شکست و بازیابی

نقطه شکست بر اساس سه معیار تعیین می‌شود: زمان پاسخ، درصد خطا و توان عملیاتی. معمولاً ابتدا آستانه زمان پاسخ عبور می‌کند — درخواست‌ها طولانی‌تر از حد تعیین شده اجرا می‌شوند. سپس درصد خطا افزایش می‌یابد: سرور فرصت پردازش درخواست‌ها را ندارد و 503 برمی‌گرداند. در آخر Throughput کاهش می‌یابد — سیستم حتی با حداقل بار هم کنار نمی‌آید. معیار نقطه شکست در پروفایل بار برای برنامه‌ریزی ظرفیت ثبت می‌شود.

تحلیل بازیابی شامل سه فاز است: واکنش فوری (30 ثانیه اول پس از رفع بار)، تثبیت (1-5 دقیقه) و بازیابی کامل (5-30 دقیقه). در فاز واکنش فوری، زمان پاسخ باید به زیر baseline برسد — سیستم از صف‌ها آزاد می‌شود. اگر این اتفاق نیفتد، مشکل در بار نیست، بلکه در وضعیت انباشته شده است. Graceful degradation — توانایی سیستم برای حفظ عملکرد جزئی در هنگام اضافه بار — شاخص کلیدی بلوغ معماری است.

Chaos Engineering Stress Test را با وارد کردن عمدی خرابی‌ها تکمیل می‌کند: قطع سرور پایگاه داده، تأخیر شبکه، توقف میکروسرویس. Chaos Monkey از Netflix (2024) به طور تصادفی فرآیندها را در محیط تولید خاتمه می‌دهد و resilience سیستم را بررسی می‌کند. برای برنامه‌های موبایل، Chaos Engineering به معنای آزمایش سناریوهای زیر است: عدم وجود شبکه، در دسترس نبودن API، پاسخ خالی سرور.

ابزارهای Stress Test

k6 با ramping-arrival-rate

k6 از Stress Test از طریق ماژول `execution` با پیکربندی ramping-arrival-rate پشتیبانی می‌کند. این حالت تعداد درخواست‌ها در ثانیه را بدون توجه به زمان اجرای هر درخواست افزایش می‌دهد. در مقایسه با Load Test، Stress Test در k6 نیاز به تنظیم thresholds تهاجمی‌تر و غیرفعال کردن gracefull-stop برای شبیه‌سازی خرابی ناگهانی دارد. Grafana Cloud به طور خودکار نقطه شکست را بر اساس شکست در نمودار زمان پاسخ تشخیص می‌دهد. k6-operator برای Kubernetes امکان اجرای Stress Test توزیع شده از کلاستر را فراهم می‌کند.

JMeter با Ultimate Thread Group

JMeter امکان پیکربندی Stress Test را از طریق Ultimate Thread Group — افزونه‌ای که پروفایل بار را به صورت جدول تعیین می‌کند: تعداد线程‌ها، زمان گرم‌آوری، زمان نگهداری، زمان کاهش — فراهم می‌کند. Ultimate Thread Group برای سناریوهای پیچیده چندفازی مناسب است. JMeter Backend Listener معیارها را برای ساخت نمودارهای نقطه شکست به InfluxDB ارسال می‌کند. برای Stress Test در JMeter توصیه می‌شود timeoutهای اتصال را غیرفعال کنید تا رفتار در هنگام اضافه بار دقیق‌تر اندازه‌گیری شود.

Gremlin برای Chaos Engineering

Gremlin — پلتفرم Chaos Engineering برای Stress Test زیرساخت. Gremlin امکان قطع شبکه، بارگذاری CPU، پر کردن دیسک و خاتمه فرآیندها در سطح podهای منفرد Kubernetes را فراهم می‌کند. تیم‌های SRE از Gremlin همراه با k6 برای Stress Test جامع استفاده می‌کنند: k6 بار ایجاد می‌کند، Gremlin خرابی‌ها را وارد می‌کند. Game Day — جلسات منظم Stress Test با استفاده از Gremlin که در «chaos report» برای تحلیل پایداری سیستم مستند می‌شوند.

مثال Stress Test در k6

اسکریپت ارائه شده در k6 یک Stress Test با افزایش تدریجی بار تا شکست را نشان می‌دهد. Ramping-arrival-rate تعداد درخواست‌ها در ثانیه را بدون توجه به زمان اجرا افزایش می‌دهد. Thresholds برای تشخیص تهاجمی تخریب تنظیم شده‌اند: p95 حداکثر 2000 ms، error rate حداکثر 5%. هنگام عبور از آستانه‌ها، k6 آزمایش را با کد خطا پایان می‌دهد که امکان ادغام Stress Test در pipeline CI/CD را فراهم می‌کند.

import http from 'k6/http'
import check from 'k6'

export const options = {
    scenarios: {
        stress: {
            executor: 'ramping-arrival-rate',
            startRate: 50,
            timeUnit: '1s',
            stages: [
                { duration: '2m', target: 200 },
                { duration: '5m', target: 500 },
                { duration: '2m', target: 1000 },
            ],
            preAllocatedVUs: 50,
            maxVUs: 200,
        },
    },
    thresholds: {
        http_req_duration: ['p(95)<2000'],
        http_req_failed: ['rate<0.05'],
    },
}

export default function() {
    const res = http.get('https://api.example.com/health')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
}

بهترین روش‌های تست استرس

Stress Test را در staging شروع کنید — تست استرس در محیط تولید نیاز به نظارت پیشرفته و برنامه بازگشت دارد. Google SRE (2024) انجام Stress Test در محیط 100% ایزوله که از نظر معماری و توان تولید را تکرار می‌کند، توصیه می‌کند. پس از آزمایش موفق در staging می‌توان تحت نظارت SRE به تولید منتقل شد. Feature flag برای غیرفعال کردن عملکرد در هنگام اضافه بار — عنصر اجباری.

Stress Test را در CI/CD خودکار کنید برای تحلیل رگرسیون نقطه شکست. اگر نسخه جدید برنامه نقطه شکستی 20% پایین‌تر از نسخه قبلی داشته باشد، این یک رگرسیون است که باید قبل از انتشار اصلاح شود. Baseline breaking point در معیارها ذخیره می‌شود و به طور خودکار با نتیجه هر Stress Test مقایسه می‌شود. هشدار هنگام کاهش 10% نقطه شکست فعال می‌شود.

هر Stress Test را مستند کنید: پروفایل بار، نقطه شکست، رفتار بازیابی و لیست مشکلات کشف شده. Netflix Engineering (2024) «Game Day» — جلسات منظم Stress Test که نتایج آنها در «chaos report» مستند می‌شود — برگزار می‌کند. گزارش تست استرس باید شامل نمودار «RPS — زمان پاسخ» با مشخص شدن نقطه شکست باشد.