मॉड्यूल 16 · परफ़ॉर्मेंस टेस्टिंग

लोड टेस्टिंग

Mutqan Soft QA टीम द्वारा · · 18 मिनट · मध्यम

Load testing, performance testing का एक प्रकार है जो जाँचता है कि system उस load में कैसा व्यवहार करता है जिसे संभालने की उससे उम्मीद है। ISTQB इसे अनुमानित loads में testing बताता है, low से typical और peak usage तक, जो simulated users या processes की नियंत्रित संख्या से पैदा होते हैं। सवाल ठोस है: expected load पर क्या response times, error rate और resource use तय सीमा के अंदर रहते हैं?

उदाहरण: एक online store का पिछले साल का सबसे व्यस्त घंटा औसतन 100 requests प्रति सेकंड था, और business को 20% growth की उम्मीद है। Load test 120 requests प्रति सेकंड तक ramp-up करता है, उसे 30 मिनट स्थिर रखता है और जाँचता है, मसलन, कि search p95 300 ms के अंदर रहे और 0.5% से कम requests fail हों। Expected peak से आगे जाना stress testing है, जो अगला पाठ है।

यह क्यों ज़रूरी है

कई performance defects सिर्फ़ concurrent load और realistic data volumes में दिखते हैं: खत्म होता connection pool, एक lock जिसका सौ checkouts इंतज़ार करते हैं, ऐसी query जो दस rows पर तेज़ और दस लाख पर धीमी है। Functional tests एक बार में एक request भेजते हैं, आम तौर पर थोड़े से test data पर, और इनसे कभी नहीं टकराते। अगर ये पहली बार असली peak पर सामने आएँ, तो कीमत होती है खोई हुई sales, failed bookings या outage।

Tester के लिए load test "system तेज़ होना चाहिए" को evidence में बदलता है: एक तय load, measured results और पहले से सहमत criteria के मुकाबले verdict। यह release decision को सहारा देता है, performance regressions पकड़ता है और developers को अस्पष्ट शिकायत की बजाय दोहराया जा सकने वाला run देता है।

Expected load: वह संख्या जिस पर आप टेस्ट करते हैं

Expected load वह traffic है जिसे system को संभालना है, और इसे concurrent users और workload models वाले पाठ के workload model से बताया जाता है: कौन-से transactions, किस mix में, किस rate पर। Script लिखने से पहले इसे तय करें, और हर संख्या का स्रोत लिखें।

  • Production data: हाल के महीनों का सबसे व्यस्त घंटा, हर transaction के लिए, analytics, access logs या monitoring से; 24 घंटों में फैलाया गया दिन का total नहीं।
  • Forecasts: campaigns, seasonal peaks, salary day, registration windows। Measured peak को सहमत growth factor से गुणा करें।
  • Levels: कम से कम typical busy hour और expected peak टेस्ट करें; दोनों ऐसे loads हैं जिन्हें संभालने के लिए system design हुआ है।
  • अभी history नहीं: users की संख्या और वे कितनी बार action लेते हैं, इससे अनुमान लगाएँ, और plan में उसे assumption के रूप में लिखें।

आज़माएँ: परफ़ॉर्मेंस टेस्ट डेटा जनरेटर

Load profile: ramp-up, steady state, ramp-down

Load profile बताता है कि लगाया गया load समय के साथ कैसे बदलता है। इसके तीन stages में से सिर्फ़ एक measurement है। Store के लिए: 10 मिनट में 120 requests प्रति सेकंड तक ramp-up, 30 मिनट hold, 5 मिनट में ramp-down।

  • Ramp-up: load धीरे-धीरे बढ़ता है, जैसे असली traffic बढ़ता है, और इस बीच caches, connection pools और autoscaling warm up होते हैं। सीधे full load से शुरू करना ऐसा spike बनाता है जिसके बारे में किसी ने पूछा नहीं, और एक cold system को मापता है।
  • Steady state: target load स्थिर रखा जाता है। System steady तब है जब throughput लगाए गए load के बराबर हो और response times व resource use सपाट रहें; स्थिर load पर लगातार बढ़ते response times का मतलब है कि work queue में जमा हो रहा है, और यह एक finding है। इसे इतनी देर रखें कि हर transaction के बहुत सारे samples मिलें, आम तौर पर दसियों मिनट; कई घंटों के runs soak tests हैं।
  • Ramp-down: load वापस शून्य पर आता है, और response times, queues और resource use को baseline पर लौटना चाहिए। जो system बाद में भी धीमा रहे, वह recover नहीं हुआ।
Store का load test 10 मिनट में 120 requests प्रति सेकंड के expected peak तक ramp-up करता है, 30 मिनट उसे स्थिर रखता है और 5 मिनट में ramp-down करता है; pass criteria से सिर्फ़ steady state को judge किया जाता है।
  1. Expected peak पर load testOnline store, release 4.2, search, product page और checkout का production mix

    संदर्भ रेखा:expected peak: 120 requests प्रति सेकंड (पिछले साल 100 × 1.2 growth)

    1. 1ramp-up 0–10 min0 → 120 req/s; warm-up, judge नहीं होता
    2. 2steady state 10–40 min120 req/s पर hold; pass criteria से judge होता है
    3. 3ramp-down 40–45 min120 → 0 req/s; baseline पर वापसी जाँचें

Ramps सीधी रेखाओं में दिखाए गए हैं; कोई tool load को छोटे steps में भी बढ़ा सकता है।

आज़माएँ: Concurrent रिक्वेस्ट टेस्ट जनरेटर

Pass criteria: run से पहले सहमत

Pass criteria load test को उसका expected result देते हैं। ये non-functional requirements, service level objectives या acceptance criteria से आते हैं, ISO/IEC 25010 की performance efficiency characteristic (time behaviour, resource utilisation, capacity) को cover करते हैं, और पहले run से पहले product owner और developers के साथ सहमत होते हैं, numbers देखने के बाद नहीं।

  • हर transaction का response time, percentiles में: search p95 ≤ 300 ms, checkout p95 ≤ 800 ms।
  • Error rate: HTTP 5xx और unexpected 4xx responses, timeouts, connection errors और failed content checks, मसलन 0.5% से कम।
  • Achieved throughput: planned 120 requests प्रति सेकंड का कम से कम 95%। जो run target तक पहुँचा ही नहीं, वह उसके बारे में कुछ साबित नहीं करता।
  • Headroom बचाने वाले resource ceilings, जैसे database CPU 75% से कम।
  • Test की अपनी validity: load generator overload नहीं था (CPU 80% से कम) और responses का content जाँचा गया, सिर्फ़ status 200 नहीं।
  • Window: सिर्फ़ steady state को judge करें। Load tools अक्सर अपने built-in thresholds हर sample पर निकालते हैं, ramps समेत, इसलिए पहले steady-state window को filter करें।

Load test की planning और execution

एक छोटा plan लिखें और system व environment के owners के साथ review करें, फिर छोटे steps में चलाएँ, ताकि full run से पहले script, data और measurements पर भरोसा हो।

  • Plan: scope, transactions और mix, load levels, profile, pass criteria और abort criteria, जैसे "अगर errors दो मिनट तक 5% से ऊपर रहें तो रोकें"।
  • Environment और data: production जैसा size और configuration, run के दौरान shared नहीं, monitored; इतने अलग-अलग users और products कि caches और unique constraints realistic व्यवहार करें; payment या SMS providers stubbed या उनके sandbox में।
  • Permission: सिर्फ़ उन्हीं systems पर load डालें जो आपके हैं या जिन्हें टेस्ट करने की लिखित अनुमति है, अलग generator machines से, और शुरू करने से पहले operations को बताएँ।
  • Smoke run, फिर full run: कुछ मिनटों के लिए एक या दो virtual users साबित करते हैं कि script login करती है, data इस्तेमाल करती है और सही responses पाती है; फिर low-load baseline और dashboards देखते हुए पूरा profile।
  • Evaluate और repeat: steady state को judge करें, result reproducible है यह पक्का करने के लिए run दोहराएँ, और build, configuration, data और time window दर्ज करें।

आज़माएँ: लोड टेस्ट डेटा जनरेटर आज़माएँ: रिस्पॉन्स टाइम एनालाइज़र आज़माएँ: HTTP रिक्वेस्ट बेंचमार्क

Worked example: sale से पहले एक online store

Seasonal sale से पहले release 4.2 टेस्ट होता है। Expected peak: पिछले साल के 100 requests प्रति सेकंड × 1.2 growth = 120। Plan और run 1 के results नीचे के block में हैं; tester उन्हें इस क्रम में पढ़ता है:

  • पहले validity: 119.6 requests प्रति सेकंड achieved और generator 41% CPU पर, इसलिए timings पर भरोसा किया जा सकता है।
  • Criteria: search और errors pass; checkout fail, उसका p95 800 ms के मुकाबले 1,140 ms।
  • Trend: checkout p95 लगभग 600 ms से शुरू हुआ और स्थिर load पर हर मिनट बढ़ता गया, यानी checkout requests queue में जमा हो रही थीं।
  • Report और confirm: load level, window, metric, graphs और build के साथ defect report। Developers वजह checkout service के database connection pool तक ट्रेस करते हैं, जिसकी सीमा 20 connections है; fix के बाद वही profile और data फिर चलाए जाते हैं (confirmation testing) और run 1 से तुलना होती है।
Load test plan: online store, release 4.2, perf environment
Expected peak:  100 req/s (busiest hour last year) x 1.2 growth = 120 req/s
Mix:            search 70 %, product page 20 %, checkout 10 %
Profile:        ramp-up 0 -> 120 req/s in 10 min, steady state 30 min
                (minutes 10-40), ramp-down 5 min
Pass criteria:  search p95 <= 300 ms, checkout p95 <= 800 ms,
                error rate < 0.5 %, throughput >= 114 req/s
Validity:       load generator CPU < 80 %, response content checked

Run 1, steady state (min 10-40)   Target      Result      Verdict
  throughput                      >= 114      119.6       pass
  search p95                      <= 300 ms   210 ms      pass
  checkout p95                    <= 800 ms   1,140 ms    fail
  error rate                      < 0.5 %     0.2 %       pass
  load generator CPU (max)        < 80 %      41 %        valid

आम गलतियाँ

  • Production data और forecasts से निकालने की बजाय load का अंदाज़ा लगाना ("चलो 1,000 users आज़माते हैं")।
  • बिना ramp-up के full load से शुरू करना और start-up spike को system की performance बताकर report करना।
  • पूरे run को, ramps समेत, judge करना, या results देखने के बाद pass criteria तय करना।
  • हर HTTP 200 को success मानना, जिससे तेज़ error pages numbers को अच्छा दिखा देते हैं।
  • यह जाँचे बिना pass घोषित करना कि planned throughput पहुँचा और load generator bottleneck नहीं था।
  • Shared environment में सिर्फ़ एक बार चलाना, build, configuration और data दर्ज किए बिना।

QA का नज़रिया

Load tests performance risk वाली releases से पहले, sale, salary day या registration window जैसे जाने-पहचाने peaks से पहले, और architecture, infrastructure या अहम queries बदलने के बाद होते हैं; कई teams regressions पकड़ने के लिए pipeline में नियमित रूप से छोटा load test भी चलाती हैं। Expected load product owner और operations या analytics से आता है, environment और monitoring operations से, और criteria product owner और developers के साथ सहमत होते हैं।

जल्दी पूछें: अब तक का सबसे व्यस्त घंटा कौन-सा था, और आगे क्या उम्मीद है? कौन-से transactions सबसे अहम हैं? उस peak पर क्या स्वीकार्य है? किन third-party services पर traffic जाएगा, और किसे बताना है? हर criterion का verdict उसके evidence और steady-state window के साथ report करें; fail हुआ criterion load level, metric और graphs के साथ defect report बनता है।

अभ्यास

Booking API के load test की planning और judgement

आपका काम

एक clinic chain की booking API के दो मुख्य transactions हैं: खाली slots खोजना और booking बनाना। नीचे के material में पिछले तीन महीनों का सबसे व्यस्त घंटा और पहला full run है। Business को अगली तिमाही 25% ज़्यादा traffic की उम्मीद है। Requirement: expected peak पर slot search p95 ≤ 400 ms, booking p95 ≤ 1,000 ms और 1% से कम failed requests।

Load test plan करें, फिर तय करें कि पहला run pass हुआ या नहीं।

सामग्री
Busiest hour, last 3 months (production analytics)
  GET  /api/slots       36,000 requests
  POST /api/bookings     7,200 requests

First full run, steady state window (minutes 10-40)
  achieved throughput        11.2 req/s
  slot search p95            280 ms
  booking p95                720 ms
  error rate                 0.4 %
  load generator CPU (max)   97 %
चरण
  1. सबसे व्यस्त घंटे को requests प्रति सेकंड में expected peak में बदलें, हर transaction के लिए और कुल।
  2. हर stage की duration के साथ load profile बनाएँ।
  3. Pass criteria, validity checks और वह window लिखें जिस पर वे लागू होते हैं।
  4. Full run से पहले क्या तैयार करना है, उसकी सूची बनाएँ।
  5. पहले run को judge करें और तय करें कि आगे क्या करना है।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Expected peak: slot search 36,000 / 3,600 = 10 प्रति सेकंड और booking 7,200 / 3,600 = 2, यानी 12; 25% growth के साथ 12.5 और 2.5, यानी कुल 15 requests प्रति सेकंड।

Profile: पहले smoke run, फिर 10 मिनट में 15 requests प्रति सेकंड तक ramp-up, 30 मिनट hold (मिनट 10 से 40) और 5 मिनट में ramp-down।

Steady state पर criteria: slot search p95 ≤ 400 ms, booking p95 ≤ 1,000 ms, errors 1% से कम, बिना confirmation number वाली bookings को भी गिनते हुए। Validity: throughput कम से कम 14.25 requests प्रति सेकंड (95%) और load generator CPU 80% से कम।

तैयारी: हज़ारों test patients और खाली slots ताकि bookings न टकराएँ, runs के बीच reset, SMS provider stubbed, monitoring चालू, operations को सूचना।

Verdict: inconclusive, pass नहीं। Response times और errors criteria के अंदर हैं, लेकिन run 15 में से सिर्फ़ 11.2 requests प्रति सेकंड तक पहुँचा और generator 97% CPU पर चला, यानी generator ही bottleneck था और उसकी देरी ने timings बिगाड़े हो सकते हैं। Generator capacity बढ़ाएँ और run दोहराएँ।

अक्सर पूछे जाने वाले सवाल

Load testing और stress testing में क्या फ़र्क है?

Load testing expected load को, expected peak तक, लगाता है और pass criteria जाँचता है। Stress testing जानबूझकर उस peak से आगे जाता है, यह जानने के लिए कि system कहाँ और कैसे टूटता है और क्या recover करता है। कुछ sources यह रेखा कहीं और खींचते हैं: Grafana k6 documentation typical load वाले test को average-load test कहता है और आम average से ज़्यादा load को stress testing मानता है। अपने plan में लिखें कि आप कौन-से levels टेस्ट कर रहे हैं।

Steady state कितनी देर चलनी चाहिए?

इतनी देर कि हर transaction के, दुर्लभ वालों के भी, बहुत सारे samples मिलें और दिखे कि response times और resource use सपाट हैं या बढ़ रहे हैं। Load test के लिए यह आम तौर पर दसियों मिनट होता है। अगर आपको जानना है कि system कई घंटों में कैसा व्यवहार करता है, तो वह soak test है।

Virtual users configure करूँ या requests प्रति सेकंड?

दोनों चलते हैं, अगर आप achieved throughput जाँचें। Virtual users की तय संख्या (closed model) में हर user अगली request भेजने से पहले अपने response का इंतज़ार करता है, इसलिए system धीमा होने पर request rate गिर जाता है और run planned से कम load लगाता है। Tools सीधे arrival rate को भी target कर सकते हैं (open model), जैसे k6 के arrival-rate executors या JMeter का throughput timer, बशर्ते उस rate को बनाए रखने के लिए काफ़ी virtual users उपलब्ध हों। Concurrent users और workload models वाले पाठ का Little’s law users और rates के बीच बदलाव करता है।

क्या मैं production पर load test चला सकता हूँ?

सिर्फ़ system owners की स्पष्ट मंज़ूरी, planned window, असली users और data की सुरक्षा, और operations team की निगरानी के साथ। ज़्यादातर load tests production जैसे test environment में चलते हैं। ऐसे system पर कभी load न डालें जो आपका नहीं है या जिसे टेस्ट करने की लिखित अनुमति नहीं है, इसमें वे third-party services भी शामिल हैं जिन्हें आपका system call करता है।

संदर्भ

  • Certified Tester Performance Testing (CT-PT)ISTQB · 2018performance testing पर ISTQB का specialist पाठ्यक्रम: बुनियादी अवधारणाएँ, performance measurements, टेस्ट गतिविधियाँ व कार्य, और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • Load test types — Grafana k6 documentationGrafana Labsआम load test प्रकारों की परिभाषाएँ — smoke, average-load, stress, soak, spike और breakpoint — और हर एक से क्या पता लगाना होता है।
  • ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023उत्पाद गुणवत्ता मॉडल: कार्यात्मक उपयुक्तता, प्रदर्शन दक्षता, संगतता, इंटरैक्शन क्षमता, विश्वसनीयता, सुरक्षा, रखरखाव-योग्यता और लचीलापन।
टूल्स

Mutqan tools से अभ्यास करें

HTTP रिक्वेस्ट बेंचमार्क

किसी सार्वजनिक endpoint पर छोटा, सुरक्षित बेंचमार्क चलाएँ (सीमित रिक्वेस्ट व concurrency) और throughput तथा latency percentile पाएँ।

परफ़ॉर्मेंस

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा