تست بار, تست عملکرد, تست نرم افزار

آموزش JMeter از صفر؛ ساخت اولین تست بار HTTP

انتشار در تاریخ توسط محمد عسکری

اگر فقط تعداد Threadها را بالا ببرید و دکمه Start را بزنید، ممکن است یک نمودار شلوغ داشته باشید؛ اما هنوز معلوم نیست کاربر واقعی، داده واقعی و معیار پذیرش را شبیه‌سازی کرده‌اید یا نه. یک تست بار مفید باید سناریوی روشن، کنترل صحت پاسخ و خروجی قابل تحلیل داشته باشد.

در این آموزش JMeter از صفر، یک سناریوی ساده جست‌وجوی محصول را می‌سازیم، با Assertion جلوی «پاسخ سریع اما اشتباه» را می‌گیریم، داده‌ها را از CSV می‌خوانیم، مقدار پویا را استخراج می‌کنیم و در پایان تست را از خط فرمان اجرا می‌کنیم. مثال‌ها برای سیستم آزمایشی یا سامانه‌ای است که مجوز تست آن را دارید؛ هرگز بار را بدون هماهنگی روی سرویس شخص ثالث یا محیط Production نفرستید.

در پایان این راهنما می‌توانید:

  • JMeter و اجزای اصلی Test Plan را توضیح دهید؛
  • اولین تست بار HTTP/API را در GUI بسازید و اعتبارسنجی کنید؛
  • داده آزمایشی، Session و Token را مدیریت کنید؛
  • تست را در CLI اجرا و گزارش HTML را تحلیل کنید؛
  • خطاهای رایج مانند نبود Assertion، استفاده از GUI زیر بار و اشتباه گرفتن Thread با RPS را تشخیص دهید.

JMeter چیست و چه چیزی را اندازه می‌گیرد؟

Apache JMeter یک ابزار متن‌باز مبتنی بر Java برای ایجاد بار در سطح پروتکل است. با آن می‌توان درخواست‌های HTTP/HTTPS، API، JDBC و چند پروتکل دیگر را اجرا کرد. برای شروع، بهتر است دامنه مسئله را محدود کنیم: این مقاله روی تست بار HTTP و API تمرکز دارد. برای شناخت انواع Load، Stress، Spike و Scalability ابتدا راهنمای تست عملکرد را ببینید.

JMeter مرورگر واقعی نیست

HTTP Sampler درخواست را در سطح پروتکل می‌فرستد؛ موتور رندر مرورگر، اجرای کامل JavaScript صفحه، Layout و Core Web Vitals را شبیه‌سازی نمی‌کند. بنابراین زمان پاسخ JMeter با «زمانی که صفحه برای کاربر قابل استفاده می‌شود» یکی نیست. برای سنجش تجربه مرورگر به ابزارهای مرورگرمحور نیاز دارید و برای یافتن گلوگاه سرور باید متریک‌های Application، دیتابیس، Cache، CPU، Memory و Network را هم‌زمان مشاهده کنید.

چه زمانی JMeter انتخاب مناسبی است؟

  • می‌خواهید ظرفیت یک Endpoint یا جریان API را زیر بار بسنجید؛
  • سناریو به Session، Cookie، Header یا Token پویا نیاز دارد؛
  • به اجرای تکرارپذیر در CLI و CI/CD نیاز دارید؛
  • تیم اکوسیستم Java و افزونه‌های JMeter را می‌شناسد.

اگر هنوز ابزار را انتخاب نکرده‌اید، مقایسه ابزارهای تست عملکرد و سپس راهنمای انتخاب فریم‌ورک اتوماسیون کمک می‌کند تصمیم را بر اساس سناریو و مهارت تیم بگیرید، نه محبوبیت ابزار.

پیش‌نیاز و نصب JMeter

JMeter روی Java اجرا می‌شود. مستندات رسمی فعلی سازگاری با Java ۸ یا بالاتر را ذکر می‌کند و توصیه می‌کند جدیدترین نسخه جزئیِ نسخه پشتیبانی‌شده را نصب کنید. برای ضبط HTTPS نیز JDK به‌دلیل وجود ابزار keytool انتخاب مناسب‌تری است. از آنجا که الزام نسخه ممکن است در انتشارهای بعدی تغییر کند، پیش از نصب، صفحه Getting Started همان نسخه JMeter را بررسی کنید.

گام ۱: بررسی Java

java -version

اگر فرمان شناخته نشد، JDK را از توزیع معتبر نصب و متغیرهای محیطی را مطابق سیستم‌عامل تنظیم کنید. خطای JAVA_HOME را با حدس زدن مسیر حل نکنید؛ مسیر واقعی نصب Java را ثبت کنید.

گام ۲: دانلود و اجرا

  1. آخرین نسخه Production را فقط از صفحه رسمی Apache JMeter دانلود کنید.
  2. فایل ZIP یا TGZ را در مسیری بدون فاصله‌های دردسرساز باز کنید.
  3. در Windows فایل bin/jmeter.bat و در macOS/Linux فایل bin/jmeter را اجرا کنید.
  4. GUI باید باز شود. این محیط را برای ساخت و Debug نگه دارید، نه تولید بار اصلی.

در ماشین تولیدکننده بار، ظرفیت CPU، حافظه، شبکه و تنظیمات سیستم‌عامل نیز بخشی از طراحی آزمایش است. اگر خود Load Generator اشباع شود، نتیجه درباره سامانه هدف قابل اعتماد نیست.

سناریوی نمونه: جست‌وجوی محصول در فروشگاه

فرض کنید تیم یک فروشگاه اینترنتی ایرانی می‌خواهد Endpoint جست‌وجو را پیش از کمپین فروش بررسی کند. آدرس‌های زیر نمونه‌اند و باید با محیط تست خودتان جایگزین شوند:

Base URL: https://api.example.test
Request:  GET /v1/products/search?q=گوشی
Expected: HTTP 200
Expected body: JSON with success=true
Example SLO: p95 < 800 ms and error rate < 1%

عددهای ۸۰۰ میلی‌ثانیه و یک درصد فقط نمونه آموزشی‌اند. معیار واقعی باید از SLO محصول، داده ترافیک و ریسک کسب‌وکار بیاید. برای طراحی محیط تکرارپذیر، مطلب آماده‌سازی محیط تست را نیز بخوانید.

قبل از ابزار، مدل بار را بنویسید

  • سناریو: کاربر عبارت جست‌وجو را ارسال می‌کند و فهرست نتیجه معتبر می‌گیرد.
  • بار اولیه: ۵ کاربر هم‌زمان، Ramp-up ده ثانیه و ۳ تکرار.
  • داده: چند عبارت و دسته‌بندی متفاوت، نه یک ورودی ثابت.
  • معیار صحت: Status مناسب و وجود مقدار منطقی در JSON.
  • معیار کارایی: Percentile، نرخ خطا و Throughput در بازه پایدار.
  • مشاهده‌پذیری: متریک‌های API، دیتابیس، Cache و زیرساخت با Timestamp مشترک.

درخت Test Plan را بشناسید

ساختار پیشنهادی اولین سناریو چنین است:

Test Plan
└── Thread Group: Product Search
    ├── HTTP Request Defaults
    ├── HTTP Header Manager
    ├── HTTP Cookie Manager
    ├── CSV Data Set Config
    ├── Uniform Random Timer
    └── HTTP Request: Search Products
        ├── Response Assertion
        └── JSON JMESPath Assertion
  • Thread Group: تعداد کاربران مجازی، Ramp-up و تکرارها را کنترل می‌کند.
  • Config Element: تنظیم مشترک مانند Host، Header، Cookie و داده CSV را نگه می‌دارد.
  • Sampler: عملیات واقعی، مثلاً درخواست HTTP را اجرا می‌کند.
  • Timer: مکث و Think Time را وارد می‌کند.
  • Assertion: صحت پاسخ را بررسی می‌کند.
  • Listener: نتیجه را نمایش می‌دهد؛ Listenerهای سنگین فقط هنگام Debug فعال باشند.

ساخت اولین تست بار HTTP در JMeter

گام ۱: افزودن Thread Group

روی Test Plan راست‌کلیک کنید و مسیر Add → Threads (Users) → Thread Group را بروید. برای اجرای اولیه این مقدارها را قرار دهید:

  • Number of Threads: 5
  • Ramp-up Period: 10 ثانیه
  • Loop Count: 3
  • Action after a Sampler error: برای Debug می‌تواند Start Next Thread Loop باشد؛ انتخاب نهایی را با نوع خطا هماهنگ کنید.

Ramp-up ده ثانیه یعنی JMeter پنج Thread را تدریجی شروع می‌کند؛ به معنای «۱۰ درخواست در ثانیه» نیست. در پایان نیز انتظار ۱۵ Iteration داریم، اما تعداد Requestها به ساختار سناریو و Controllerها بستگی دارد.

گام ۲: تعریف تنظیمات مشترک HTTP

زیر Thread Group، از مسیر Add → Config Element → HTTP Request Defaults این مقدارها را وارد کنید:

  • Protocol: https
  • Server Name or IP: api.example.test
  • Connect Timeout و Response Timeout: بر اساس رفتار واقعی سرویس؛ خالی گذاشتن عمدی باشد، نه فراموشی.

سپس یک HTTP Header Manager اضافه کنید:

Accept: application/json
Content-Type: application/json

این کار Host و Headerهای تکراری را از Samplerها بیرون می‌آورد و تغییر محیط را ساده‌تر می‌کند.

گام ۳: افزودن Cookie Manager

اگر سیستم Session مبتنی بر Cookie دارد، HTTP Cookie Manager را در سطح Thread Group اضافه کنید. هر Thread فضای Cookie مستقل دارد و مانند یک کاربر جدا Session خود را نگه می‌دارد. Cookie را بین همه کاربران Hard-code نکنید؛ مگر این رفتار دقیقاً بخشی از سناریو باشد.

گام ۴: ساخت HTTP Request

از مسیر Add → Sampler → HTTP Request یک Sampler بسازید:

  • Name: Search Products
  • Method: GET
  • Path: /v1/products/search
  • Parameters: نام q و مقدار ${keyword}

در این مرحله متغیر keyword هنوز تعریف نشده است؛ در گام CSV آن را مقداردهی می‌کنیم. اگر Endpoint را به‌صورت API بررسی می‌کنید، قواعد Contract، Status و داده را از راهنمای تست API بگیرید.

Assertion؛ تفاوت «پاسخ» با «پاسخ درست»

یکی از خطرناک‌ترین خطاها این است که فقط زمان پاسخ را ببینیم. سرور ممکن است خیلی سریع یک JSON خطا، صفحه Login یا نتیجه خالی اشتباه برگرداند. تستی که محتوای پاسخ را کنترل نمی‌کند، می‌تواند خرابی سریع را به‌عنوان موفقیت گزارش کند.

بررسی Status و محتوای JSON

  1. زیر HTTP Request یک Response Assertion اضافه کنید.
  2. Field to Test را روی Response Code بگذارید.
  3. Pattern را 200 و نوع تطبیق را Equals انتخاب کنید.
  4. یک JSON JMESPath Assertion اضافه کنید.
  5. Expression را مطابق Contract، مثلاً success و Expected Value را true قرار دهید.

اگر API ساختار دیگری دارد، Expression را از روی Contract واقعی بنویسید. Assertionهای ضروری را نگه دارید؛ تعداد زیاد یا Scriptهای سنگین می‌توانند به Load Generator هزینه تحمیل کنند.

پارامتری‌سازی با CSV Data Set Config

یک تست واقعی نباید همه کاربران را با یک کلمه جست‌وجو بفرستد؛ Cache می‌تواند نتیجه را غیرواقعی کند. فایلی به نام search-data.csv کنار فایل JMX بسازید:

keyword,category
گوشی,mobile
لپ تاپ,laptop
هدفون,audio
کفش,sport
کتاب,book

در Thread Group یک CSV Data Set Config اضافه و این گزینه‌ها را تنظیم کنید:

  • Filename: search-data.csv
  • File Encoding: UTF-8؛ برای داده فارسی حیاتی است.
  • Variable Names: خالی، تا سطر اول Header خوانده شود.
  • Delimiter: کاما
  • Recycle on EOF: بسته به سناریو؛ برای داده یکتا معمولاً False.
  • Stop thread on EOF: اگر داده نباید تکرار شود، True.

اکنون ${keyword} در HTTP Request از هر سطر خوانده می‌شود. در تست‌های حساب کاربری، داده شخصی یا رمز واقعی Production را در CSV نگه ندارید؛ حساب مصنوعی و Secret Management مناسب CI استفاده کنید.

Correlation؛ مدیریت Token و مقدارهای پویا

پارامتری‌سازی داده را از بیرون وارد می‌کند؛ Correlation مقداری را از پاسخ قبلی می‌گیرد و در درخواست بعدی مصرف می‌کند. نمونه رایج، access_token یا شناسه سفارش است.

استخراج Token از پاسخ Login

فرض کنید پاسخ Login چنین است:

{
  "access_token": "eyJ...",
  "expires_in": 3600
}
  1. زیر Sampler ورود، JSON JMESPath Extractor اضافه کنید.
  2. Names of created variables: access_token
  3. JMESPath expressions: access_token
  4. Default values: NOT_FOUND
  5. در Header Manager بنویسید: Authorization: Bearer ${access_token}
  6. برای اطمینان، Assertion بگذارید که Token مقدار NOT_FOUND نباشد.

Token ثابت ضبط‌شده معمولاً منقضی می‌شود و اجرای بعدی را خراب می‌کند. Correlation باید بخشی از سناریو باشد، نه وصله‌ای پس از شکست تست.

Think Time و Timer؛ کاربر ربات نیست

کاربر واقعی بین مشاهده نتیجه و اقدام بعدی مکث می‌کند. بدون Timer، هر Thread بلافاصله درخواست بعدی را می‌فرستد و الگویی می‌سازد که شاید با Production ارتباطی نداشته باشد.

یک مکث تصادفی ساده

زیر بخشی که باید مکث داشته باشد، Uniform Random Timer اضافه کنید. مثلاً Constant Delay برابر ۱۰۰۰ و Random Delay Maximum برابر ۲۰۰۰ میلی‌ثانیه، مکثی بین حدود یک تا سه ثانیه ایجاد می‌کند. اعداد را از Analytics یا Log واقعی استخراج کنید.

دامنه Timer مهم است: Timer روی Samplerهای هم‌سطح و فرزند خود اثر می‌گذارد. بعد از افزودن آن، ترتیب و زمان سناریو را با یک Thread بررسی کنید.

اعتبارسنجی در GUI، نه اجرای بار در GUI

قبل از هر Load Test، Thread Group را با یک کاربر و یک تکرار Validate کنید. موقتاً View Results Tree را برای Debug فعال کنید و این موارد را ببینید:

  • URL، Method، Header و Body همان چیزی است که انتظار دارید؛
  • متغیرهای CSV مقدار گرفته‌اند و متن فارسی خراب نشده است؛
  • Cookie یا Token از پاسخ قبلی عبور می‌کند؛
  • Assertion در پاسخ سالم Pass و در پاسخ دست‌کاری‌شده Fail می‌شود؛
  • Log JMeter خطای Connection، SSL یا Script ندارد.

پس از Debug، View Results Tree، View Results in Table و Listenerهای پرهزینه را Disable یا حذف کنید. طبق مستندات رسمی، GUI برای ساخت Script است و Load Test باید در CLI اجرا شود.

اجرای JMeter در خط فرمان و ساخت گزارش HTML

فایل را با نام checkout.jmx ذخیره کنید. پوشه خروجی گزارش باید وجود نداشته باشد یا خالی باشد. سپس از پوشه bin یا با PATH درست اجرا کنید:

jmeter -n -t checkout.jmx -l results.jtl -e -o report
  • -n: اجرای CLI
  • -t: مسیر Test Plan با پسوند JMX
  • -l: ذخیره Sampleها در JTL
  • -e: تولید Dashboard پس از پایان تست
  • -o: پوشه خروجی گزارش HTML

فایل JTL را همراه نسخه JMX، Commit برنامه، تنظیم بار، داده تست و زمان اجرا نگه دارید. بدون این Context، مقایسه دو Run ممکن است گمراه‌کننده باشد.

پارامترهای محیط را از CLI عبور دهید

برای جلوگیری از چند نسخه JMX، مقادیر متغیر را Property کنید:

jmeter -n -t checkout.jmx -l results.jtl -e -o report   -Jhost=staging.example.test   -Jthreads=20   -Jduration=300

در JMeter از ${__P(host,api.example.test)} و الگوی مشابه استفاده کنید. Secret را در Command Line آشکار نکنید؛ آرگومان‌ها ممکن است برای کاربران دیگر سیستم یا Logهای CI قابل مشاهده باشند.

گزارش JMeter را چگونه تحلیل کنیم؟

Percentile مهم‌تر از Average تنهاست

میانگین می‌تواند کندی بخشی از کاربران را پنهان کند. p95 برابر ۸۰۰ میلی‌ثانیه یعنی حدود ۹۵ درصد Sampleها حداکثر ۸۰۰ میلی‌ثانیه زمان برده‌اند و حدود پنج درصد کندتر بوده‌اند. p90، p95 و p99 را در کنار Median ببینید؛ هیچ Percentile به‌تنهایی کافی نیست.

سه شاخص پایه

  • Response Time: توزیع زمان پاسخ برای هر Transaction یا Endpoint؛
  • Throughput: تعداد عملیات تکمیل‌شده در واحد زمان؛
  • Error Rate: نسبت Sampleهای ناموفق، شامل شکست Assertion.

ابتدای Ramp-up و پایان Ramp-down را با بازه پایدار قاطی نکنید. نتیجه Client را با نمودارهای سرور روی خط زمان مشترک مقایسه کنید: افزایش p95 همراه با پرشدن Connection Pool یا Query کند، سرنخ بسیار بهتری از خود نمودار JMeter است.

نمونه تصمیم‌گیری

مشاهده برداشت اولیه بررسی بعدی
p95 بالا، CPU پایین انتظار I/O یا Dependency DB، Cache، DNS، سرویس ثالث و Connection Pool
Throughput ثابت، Thread بیشتر رسیدن به سقف ظرفیت Queue، Saturation و محدودیت Load Generator
Error زیاد با ۲۰۰ خطای منطقی یا داده Assertion، Contract و نمونه Response
زمان‌ها ناگهان بد می‌شوند Spike، GC یا Rate Limit Timeline سرور و Logهای همان دقیقه

این جدول تشخیص قطعی نیست؛ فرضیه می‌سازد. برای طراحی ظرفیت، Baseline، Load Profile و تحلیل گلوگاه، راهنمای عمیق برنامه‌ریزی تست عملکرد را بخوانید.

Thread با RPS برابر نیست

Thread Group معمولی تعداد کاربران شبیه‌سازی‌شده را کنترل می‌کند. هر Thread یک Iteration را اجرا می‌کند، منتظر پاسخ‌ها و Timerها می‌ماند و سپس ادامه می‌دهد. پس اگر سامانه کند شود، همان تعداد Thread الزاماً همان نرخ درخواست قبلی را تولید نمی‌کند.

اگر هدف شما دقیقاً الگوی Arrival Rate مانند ۵ درخواست در ثانیه است، مدل بار و ابزار زمان‌بندی را صریح انتخاب کنید. JMeter در مستندات فعلی Open Model Thread Group آزمایشی نیز دارد، اما نباید فقط برای رسیدن به یک عدد ظاهری از آن استفاده کرد. ابتدا مشخص کنید کسب‌وکار «کاربر هم‌زمان» می‌خواهد یا «ورود عملیات در واحد زمان».

خطاهای رایج JMeter و راه حل

خطای اتصال یا SSL

  • Host، Port، Proxy و DNS ماشین Load Generator را بررسی کنید؛
  • تفاوت Certificate محیط تست و Production را مستند کنید؛
  • Timeout را بی‌نهایت نگذارید و از روی رفتار مورد انتظار تنظیم کنید؛
  • خطای شبکه ایران یا مسیر بین‌المللی را با خطای Application یکی ندانید.

نتیجه عالی اما غیرواقعی

  • Assertion وجود ندارد و پاسخ خطا معتبر شمرده شده است؛
  • همه کاربران یک داده Cache‌شده را می‌خوانند؛
  • Think Time حذف شده و سناریو رفتار واقعی ندارد؛
  • فقط یک Endpoint آسان تست شده، نه جریان کسب‌وکار؛
  • Load Generator پیش از سامانه هدف اشباع شده است.

تست در مقیاس بالا ناپایدار است

  • GUI و Listenerهای سنگین هنوز فعال‌اند؛
  • Response Bodyهای غیرضروری در JTL ذخیره می‌شوند؛
  • Script یا Assertion پرهزینه روی هر Sample اجرا می‌شود؛
  • داده پویا در لحظه ساخته می‌شود، در حالی که CSV از قبل آماده کافی است؛
  • CPU، Heap یا شبکه مولد بار ظرفیت لازم را ندارد.

ملاحظات اجرای تست بار برای کاربران ایران

اگر محصول برای کاربران داخل ایران است، یک Run از دیتاسنتر خارجی تصویر کامل نمی‌دهد. مسیر شبکه، اپراتور، CDN، DNS، درگاه پرداخت و سرویس پیامک ممکن است رفتار متفاوتی داشته باشند.

  • بار را از موقعیت‌هایی اجرا کنید که فرضیه جغرافیایی مشخص دارند؛
  • وابستگی‌های پرداخت و پیامک را در محیط تست Mock یا Sandbox کنید؛
  • ریال/تومان، Unicode فارسی، اعداد فارسی و Encoding CSV را در داده‌ها بگنجانید؛
  • زمان سرورها و Load Generatorها را همگام کنید تا Correlation متریک ممکن باشد؛
  • محدودیت امنیتی، WAF و Rate Limit را پیشاپیش با تیم عملیات هماهنگ کنید.

هدف دور زدن محدودیت‌ها نیست؛ هدف جدا کردن ریسک شبکه، Dependency و ظرفیت برنامه با آزمایش کنترل‌شده است.

قرار دادن تست JMeter در CI/CD

یک تست بار کامل معمولاً برای هر Commit مناسب نیست. در Pipeline یک Smoke Performance کوچک، پایدار و محدود اجرا کنید؛ آزمون‌های ظرفیت طولانی‌تر را زمان‌بندی‌شده یا پیش از انتشار مهم انجام دهید.

  • JMX و داده غیرحساس را Version Control کنید؛
  • Host، Thread و Duration را Property کنید؛
  • Artifact گزارش و JTL را با Retention مشخص ذخیره کنید؛
  • Threshold را از Baseline و SLO بسازید؛
  • Flaky یا Noise محیط را پنهان نکنید؛ Run نامعتبر را از شکست محصول جدا گزارش کنید.

برای طراحی Gateها و مسیر Fast/Slow، مطلب تست مداوم در CI/CD را بخوانید. راهنمای پیشرفته JMeter نیز ادامه مناسب این آموزش برای مقیاس‌دهی و نکات حرفه‌ای‌تر است.

چک‌لیست اولین تست بار با JMeter

  • مجوز، Scope، پنجره اجرا و مخاطب Incident مشخص است.
  • سناریو، بار، داده و معیار پذیرش پیش از ساخت JMX نوشته شده است.
  • Host و Headerهای مشترک در Config Element قرار دارند.
  • Cookie، Token و شناسه‌های پویا Correlate شده‌اند.
  • داده فارسی با UTF-۸ و CSV متنوع وارد می‌شود.
  • Assertion هم Status و هم منطق پاسخ را بررسی می‌کند.
  • Think Time از رفتار واقعی آمده است.
  • تست با یک Thread در GUI اعتبارسنجی شده است.
  • Listenerهای سنگین خاموش و اجرای اصلی در CLI است.
  • JTL، گزارش HTML، نسخه کد و تنظیمات Run نگهداری می‌شوند.
  • متریک‌های Client و Server با زمان مشترک تحلیل می‌شوند.
  • نتیجه شامل محدودیت‌ها، فرضیه گلوگاه و اقدام بعدی است.

سوالات متداول آموزش JMeter

آیا JMeter برای تست رابط کاربری وب مناسب است؟

برای تولید بار HTTP مناسب است، اما مرورگر واقعی و تجربه رندر صفحه را شبیه‌سازی نمی‌کند. برای معیارهای UI و Core Web Vitals از ابزار مرورگرمحور در کنار تست پروتکل استفاده کنید.

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

GUI و Listenerهای تصویری CPU و حافظه مصرف می‌کنند و می‌توانند خود مولد بار را به گلوگاه تبدیل کنند. سناریو را در GUI بسازید و Debug کنید؛ اجرای اصلی را با CLI انجام دهید.

تعداد Thread در JMeter همان تعداد درخواست در ثانیه است؟

خیر. Thread نماینده کاربر شبیه‌سازی‌شده است و نرخ خروجی به زمان پاسخ، Timer، تعداد Sampler و ساختار Loop بستگی دارد. RPS هدف باید با مدل بار مناسب طراحی و در خروجی اندازه‌گیری شود.

چطور بفهمیم پاسخ سریع واقعاً صحیح است؟

در کنار Status Code، Assertion روی Contract یا محتوای منطقی پاسخ بگذارید؛ مثلاً وجود فیلد و مقدار مورد انتظار در JSON. سپس چند نمونه Fail را عمداً اجرا کنید تا خود Assertion را آزمایش کنید.

برای شروع چه تعداد کاربر مجازی مناسب است؟

عدد عمومی وجود ندارد. با یک کاربر صحت Script را تأیید کنید، سپس از Baseline کم‌ریسک و افزایش تدریجی استفاده کنید. بار هدف باید از ترافیک واقعی، ظرفیت مورد انتظار، SLO و محدودیت محیط بیاید.

جمع‌بندی

اولین تست JMeter موفق تستی نیست که بیشترین Thread را اجرا کند؛ تستی است که بتوان نتیجه‌اش را توضیح و تکرار کرد. از یک سناریوی کوچک شروع کنید، صحت پاسخ را با Assertion بسنجید، داده و Token را درست مدیریت کنید، GUI را فقط برای Debug به کار ببرید و اجرای اصلی را با CLI و گزارش قابل ردیابی انجام دهید. سپس با داده Production و مشاهده‌پذیری سرور، سناریو را به یک آزمایش ظرفیت واقعی تبدیل کنید.

منابع رسمی

محمد عسکری

محمد هستم، توسعه‌دهنده وب با بیش از ده سال تجربه در برنامه‌نویسی سمت سرور و کاربر. به یادگیری و اشتراک‌گذاری دانش علاقه‌مندم و اخیراً تمرکزم را روی حوزه تست نرم‌افزار گذاشته‌ام تا تجربیاتم را در این زمینه نیز به اشتراک بگذارم و به درک بهتر کیفیت نرم‌افزار کمک کنم.

دیدگاهتان را بنویسید