معرفی و تعریف
«تست کارایی نرمافزار» (Software Performance Testing) مهارتی است که به طراحی، اجرا و تحلیل آزمون‌هایی می‌پردازد که رفتار سامانه را زیر بار مشخص می‌سنجند. هدف این تست تنها ثبت زمان پاسخ نیست، بلکه باید مشخص شود سامانه در چه سناریویی، با چه تعداد کاربر یا درخواست هم‌زمان و با چه نرخ خطایی کار میکند.
متخصص این حوزه سناریوهای استفاده واقعی را به الگوهای بار تبدیل میکند و شاخص‌هایی مانند زمان پاسخ، نرخ خطا، توان عملیاتی و مصرف منابع را اندازه می‌گیرد. سپس علت افت عملکرد را بررسی میکند. خروجی این کار باید به تیم توسعه و زیرساخت کمک کند تا میان مشکلات کد، پایگاه داده، شبکه، تنظیمات سرور و ظرفیت ناکافی تمایز قائل شوند.
این مهارت را مهندسان تست نرمافزار، توسعه‌دهندگان بک‌اند، مهندسان دواپس و تیم‌های مسئول سامانه‌های پرترافیک به کار می‌برند. تست کارایی با بهینه‌سازی عملکرد وب یا اجرای صرف یک ابزار تفاوت دارد. اعتبار نتایج آن به واقع‌بینانه بودن سناریو، کنترل شرایط آزمایش و تفسیر درست داده‌ها وابسته است.
برآورد ۱۴۰ ساعت برای فردی در نظر گرفته شده است که پیش‌نیازهای ثبت شده را دارد و به طور منظم در محیط آزمایشی تمرین میکند. افراد باتجربه در تست API و پایش سامانه ممکن است با حدود ۸۰ تا ۱۲۰ ساعت تمرین به سطح کاربردی برسند. در مقابل، افرادی که تجربه کمتری دارند، به حدود ۱۶۰ تا ۲۲۰ ساعت مطالعه و تمرین نیاز دارند.
این مهارت را با نام‌های دیگری نیز می‌شناسند:
- تست عملکرد نرمافزار
- آزمون کارایی نرمافزار
- تست پرفورمنس
- Performance Testing
اهمیت و کاربردها
چرا این مهارت مهم است؟
کندی یا خطای سامانه اغلب زمانی آشکار میشود که کاربران هم‌زمان وارد سامانه می‌شوند، کمپین، ترافیک ایجاد میکند یا فرایندهای زمان‌بر مانند پرداخت و گزارش‌گیری تحت فشار قرار می‌گیرند. تست کارایی پیش از انتشار، ریسک چنین رخدادهایی را کاهش می‌دهد و شواهد قابل بررسی را برای تصمیم‌گیری درباره ظرفیت سامانه و اولویت رفع گلوگاه‌ها فراهم میکند.
اگر در بازار کار ایران به دنبال موقعیت شغلی مرتبط هستید، علاوه بر عنوان مهندس تست نرمافزار، عنوان‌های «QA Automation»، توسعه‌دهنده بک‌اند و مهندس دواپس را نیز بررسی کنید. در متن آگهی‌ها به کلیدواژه‌هایی مانند Performance Testing و Load Testing و JMeter و API، مانیتورینگ، Observability و تحلیل گلوگاه توجه کنید. میزان مسئولیت در این مهارت به اندازه تیم و نوع سامانه بستگی دارد و ممکن است میان تیم‌های توسعه، تست و زیرساخت تقسیم شود.
ارزش حرفه‌ای این مهارت در توانایی توضیح نتایج است و تنها گفتن اینکه «سامانه کند است» گزارش مفیدی به شمار نمی‌رود. گزارش قابل استفاده باید سناریو، حجم بار، محیط اجرا، شاخص‌های مشاهده شده، نقطه افت عملکرد و فرضیه‌های فنی برای بررسی‌های بعدی را مشخص کند.
کاربردها
-
آزمون بار API پیش از انتشار
ارسال درخواست هم‌زمان به مسیرهای مهم مانند ورود، جست‌وجو یا ثبت سفارش و سنجش زمان پاسخ، نرخ خطا و توان عملیاتی.
-
ارزیابی سامانه‌های پرداخت و تراکنش
شبیه‌سازی جریان‌های حساس مانند ایجاد پرداخت، تایید تراکنش و دریافت وضعیت، با داده آزمایشی و بدون ایجاد تراکنش واقعی.
-
بررسی ظرفیت در رویدادهای پرترافیک
برآورد رفتار سامانه هنگام ثبت نام، فروش محدود، انتشار نتیجه یا کمپین تبلیغاتی که ورود هم‌زمان کاربران را افزایش می‌دهد.
-
شناسایی گلوگاه پایگاه داده و سرویس‌ها
مقایسه شاخص‌های آزمون با داده‌های پایش برای تشخیص تاخیر در کوئری‌ها، اتصال‌های سرویس یا مصرف منابع سرور.
-
کنترل رگرسیون کارایی
اجرای سناریوهای ثابت در نسخه‌های مختلف برای تشخیص افت محسوس عملکرد پس از تغییر کد، تنظیمات یا وابستگی‌ها.
ابزارهای مرتبط
پیش‌نیازها
شروع این مهارت با دانستن پیش‌نیازهای زیر هموارتر میشود.
- مهارت تست نرمافزار Software Testing
- مهارت تست API API Testing
- مهارت شبکه و ارتباطات سرویس‌ها Networking and Service Communication
- آشنایی پایه با HTTP، کدهای وضعیت و ساختار درخواست و پاسخ
- توانایی خواندن لاگ‌های سرویس و خطاهای رایج
- دسترسی به یک محیط آزمایشی امن و قابل‌بازنشانی
مسیر یادگیری تست کارایی نرمافزار
-
۲۰ ساعت
شاخص‌های کارایی و گونه‌های آزمون را تشخیص دهید.
مفاهیم زمان پاسخ، درصدک‌ها، توان عملیاتی، نرخ خطا، هم‌زمانی و زمان فکر کردن کاربر را یاد بگیرید. تفاوت تست بار، تست فشار، تست استقامت و تست جهش ناگهانی بار را با مثال‌های روشن توضیح دهید و برای هرکدام هدفی قابل‌سنجش تعیین کنید.
-
۲۵ ساعت
رفتار واقعی کاربر را به سناریوی بار تبدیل کنید.
جریان مهمی مانند ورود، مشاهده محصول و ثبت سفارش را انتخاب کنید. مسیرهای API، نسبت استفاده از هر مسیر، داده‌های ورودی، تعداد کاربران هم‌زمان و شیب افزایش بار را مشخص کنید. سناریو را بر پایه فرض‌های ثبت شده بسازید، نه حداکثرسازی تصادفی تعداد درخواست‌ها.
-
۳۰ ساعت
ابزار اجرا را متناسب با سناریو انتخاب کنید.
Apache JMeter برای ساخت سناریوهای HTTP و پروتکل‌های پشتیبانی شده، رابط گرافیکی مناسبی دارد و به شروع کار کمک میکند. با این حال، تنها گزینه موجود نیست. برای سناریوهایی که نگهداری نسخه‌ای اسکریپت‌ها، اجرای ساده در CI یا تولید بار بسیار زیاد اهمیت دارد، ابزارهای اسکریپتی می‌توانند مناسب‌تر باشند. ابزار را بر اساس پروتکل هدف، نیاز به رابط گرافیکی، توانایی تیم در اسکریپت‌نویسی، شیوه اجرای خودکار و حجم بار انتخاب کنید.
در JMeter، گروه کاربر، درخواست HTTP، داده‌های ورودی، اعتبارسنجی پاسخ و گزارش‌گیرها را پیکربندی کنید. متغیرسازی داده‌ها، مدیریت نشست و ترتیب درست درخواست‌ها را تمرین کنید. برای اجرای تکرارپذیر، می‌توانید پیکربندی ابزار و محیط آزمایشی را با Docker ثابت نگه دارید.
-
۳۰ ساعت
نتایج آزمون و داده‌های پایش را تحلیل کنید.
نتایج زمان پاسخ و خطا را در کنار شاخص‌های CPU، حافظه، اتصال‌ها و لاگ سرویس بررسی کنید. Prometheus می‌تواند شاخص‌های سامانه را هنگام آزمون جمع‌آوری کند و Grafana برای مقایسه روند بار، زمان پاسخ و مصرف منابع در بازه زمانی به کار می‌رود. InfluxDB نیز در برخی پیکربندی‌ها برای ذخیره داده‌های زمان‌محور نتیجه آزمون و بررسی روندها استفاده میشود.
میان همبستگی و علت تمایز بگذارید. افزایش زمان پاسخ به‌تنهایی ثابت نمی‌کند که مشکل از پایگاه داده است. فرضیه‌ها را با اجرای کنترل‌شده آزمون کنید.
-
۲۰ ساعت
گلوگاه‌ها و محدودیت‌های آزمون را گزارش کنید.
گزارشی بنویسید که محیط، نسخه سامانه، سناریو، داده آزمایشی، الگوی بار، شاخص‌های اصلی و محدودیت‌های آزمون را بیان کند. یافته‌ها را بر اساس شدت و شواهد اولویت‌بندی کنید و برای هر مورد، اقدام پیشنهادی قابل‌پیگیری ارائه دهید.
-
۱۵ ساعت
آزمون کارایی را در فرایند تحویل نرمافزار قرار دهید.
سناریوی کوتاهی برای رگرسیون کارایی انتخاب کنید و معیار هشدار آن را تعریف کنید. اجرای آزمون را با فرایند یکپارچه‌سازی و تحویل مستمر هماهنگ کنید، اما فقط در محیطی که بار تولید شده و داده‌های آن برای سامانه خطر ایجاد نمی‌کند.
زمان تقریبی یادگیری
برآورد مجموع زمان آموزش، مطالعه و تمرین تا رسیدن به سطح کاربردی؛ بسته به پیش‌زمینه شما می‌تواند کمتر یا بیشتر باشد.
پروژه‌های تمرینی
برای آشنایی بهتر با این مهارت، توجه به موارد زیر می‌تواند مفید باشد.
-
آزمون بار API فروشگاه آزمایشی
توضیح پروژه: برای ورود، فهرست محصولات و ثبت سبد خرید سناریو بسازید. نسبت درخواست‌ها، داده آزمایشی، تعداد کاربران و معیارهای موفقیت را مستند کنید و نتیجه را در گزارش کوتاهی ارائه دهید.
-
مقایسه دو نسخه از یک API
توضیح پروژه: یک API ساده را در دو نسخه یا با دو تنظیم متفاوت اجرا کنید. سناریوی ثابت را روی هر دو اجرا کنید و تفاوت زمان پاسخ، نرخ خطا و مصرف منابع را بدون نتیجه‌گیری شتاب‌زده تحلیل کنید.
-
شناسایی گلوگاه در سرویس دارای پایگاه داده
توضیح پروژه: سرویسی با مسیر جست‌وجو یا گزارش‌گیری انتخاب کنید. هنگام افزایش تدریجی بار، شاخص‌های برنامه و پایگاه داده را ثبت کنید و فرضیه خود درباره گلوگاه را با تغییر کنترل شده بررسی کنید.
پرسش‌های رایج درباره تست کارایی نرمافزار
اگر درباره این مهارت پرسشی دارید، ممکن است پاسخ آن را در میان موارد زیر پیدا کنید.
تست کارایی نرمافزار با تست بار چه تفاوتی دارد؟
تست کارایی مفهوم جامعتری برای سنجش رفتار سامانه است، در حالی که تست بار زیرمجموعهای از آن محسوب میشود و عملکرد زیر تقاضای مشخص را بررسی میکند.
آیا برای یادگیری تست کارایی باید برنامه‌نویس باشم؟
الزام مطلق نیست، اما آشنایی با HTTP و API، ساختار داده درخواست و پاسخ و خواندن لاگ‌ها ضروری است. برای سناریوهای پیچیده، اسکریپت‌نویسی و درک کد مزیت مهمی محسوب میشود.
آیا Apache JMeter برای تست کارایی کافی است؟
JMeter ابزار پرکاربردی برای ساخت و اجرای سناریوهای بار است، اما به‌تنهایی کیفیت آزمون را تضمین نمی‌کند. انتخاب ابزار به پروتکل، نیاز به رابط گرافیکی یا اسکریپت‌نویسی، اجرای CI و حجم بار وابسته است. طراحی سناریوی معتبر، داده مناسب، محیط کنترل شده و تحلیل شاخص‌های سامانه بخش‌های اصلی کار هستند.
تست کارایی را روی سامانه عملیاتی اجرا کنیم؟
خیر، اجرای تست کارایی روی محیط واقعی به دلیل ایجاد فشار سنگین و خطر اختلال برای کاربران ممنوع است. اجرای آزمون روی محیط عملیاتی بدون هماهنگی و کنترل می‌تواند اختلال، هزینه یا داده‌های گمراه‌کننده ایجاد کند.
زمان پاسخ مناسب برای سامانه چقدر است؟
پاسخ ثابتی وجود ندارد و زمان مناسب به نوع کسبوکار و انتظارات کاربران بستگی دارد، اما به طور معمول بازههای زیر ثانیه مطلوب هستند.
چگونه نمونهکار تست کارایی بسازم؟
سناریوی قابلتکراری برای API آزمایشی بسازید و همراه آن هدف آزمون، الگوی بار، فایل پیکربندی، نتایج، نمودارهای منتخب و تحلیل محدودیتها را منتشر کنید. صرف فایل ابزار، بدون توضیح سناریو و نتیجه، نمونهکار کافی نیست.
