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

स्ट्रेस टेस्टिंग

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

Stress testing एक प्रकार की performance testing है जो system को उसके anticipated या specified workload की सीमा पर या उससे आगे, या सामान्य से कम resources के साथ evaluate करती है। पिछले lesson का load test पूछता था कि expected peak पर system अपने targets पूरे करता है या नहीं। Stress test तीन अलग सवाल पूछता है: उस peak से कितना आगे तक system serve करता रहता है, जब वह रुकता है तो क्या होता है, और load घटने पर क्या वह सामान्य हालत में लौटता है?

उदाहरण: एक online pharmacy का order API 200 requests प्रति सेकंड के expected peak पर अपना load test pass कर गया। Stress test वहीं से शुरू होता है और हर पाँच मिनट में 50 requests प्रति सेकंड जोड़ता है। 400 पर API सिर्फ़ लगभग 380 serve करता है और पहली requests time out होने लगती हैं; 500 पर एक application instance की memory ख़त्म हो जाती है और वह restart होता है। फिर load को वापस 200 पर लाया जाता है, यह देखने के लिए कि system अपने आप recover करता है या नहीं।

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

Expected peaks forecasts हैं, और forecasts कभी-कभी गलत होते हैं: कोई campaign योजना से ज़्यादा फैल जाता है, किसी competitor के outage से उसके customers आपके पास आ जाते हैं, कोई batch job busy hour में चल जाता है, या तीन में से एक server fail हो जाता है और बाकी दो उसका traffic उठाते हैं। सवाल यह नहीं कि system कभी अपने expected peak से ज़्यादा देखेगा या नहीं, बल्कि यह है कि ऐसा होने पर वह क्या करता है। जो system धीमा होकर excess को साफ़ तौर पर reject करता है वह कुछ orders खोता है; जो crash होता है, data खोता है या वापस आने में एक घंटा लेता है, वह पूरा दिन खो देता है।

Tester के लिए stress test "इसे झेल लेना चाहिए" की जगह मापे हुए facts देता है: वह load जिस पर system ने serve करना बंद किया, वह resource जो सबसे पहले ख़त्म हुआ, failure mode और recovery time। ये facts product owner को expected peak और limit के बीच का headroom देते हैं, operations को बताते हैं कि क्या monitor करना है, और developers को एक reproducible failure देते हैं जिसे वे production के customers के सामने दिखने से पहले ठीक कर सकें।

Expected peak से आगे: stress profile

Stress test वहाँ से शुरू होता है जहाँ load test ख़त्म हुआ था। Expected peak reference line है; stress profile उसे जान-बूझकर पार करता है और तब तक बढ़ता रहता है जब तक system टूट न जाए या कोई abort rule run रोक न दे। क्योंकि result "pass या fail" नहीं बल्कि "कहाँ और कैसे" है, plan में load test के objectives पढ़ने में मदद के लिए रखे जाते हैं, और साथ में एक abort rule environment की रक्षा करता है, जैसे "जब errors एक मिनट तक 20% से ऊपर रहें या कोई instance crash हो, तो रोक दें"।

  • एक छलाँग नहीं, steps: load को बराबर steps में बढ़ाएँ और हर step पर तब तक रुकें जब तक metrics settle न हो जाएँ, जैसे हर पाँच मिनट में expected peak का +25%। हर step एक छोटा load test है, और जिस step पर किसी metric का व्यवहार बदलता है, वही finding है। लगातार ramp तेज़ है, लेकिन धुंधला कर देता है कि बदलाव कहाँ हुआ।
  • पहले peak की पुष्टि करें: पहला step expected peak दोहराता है, और उसके numbers load test से मिलने चाहिए। जो system peak पर ही unhealthy है, उसकी finding load test की है, stress test की नहीं।
  • Resources घटाकर stress: expected load वही रखें और load बढ़ाने की जगह resources हटाएँ। तीन में से एक instance निकाल दें, memory limit आधी कर दें, network bandwidth सीमित कर दें। यह ISTQB की definition का दूसरा हिस्सा है, और production में busy hour के दौरान fail हुआ server ठीक ऐसा ही दिखता है।
  • नाम: Grafana k6 की documentation उस run को breakpoint test कहती है जो system के fail होने तक चढ़ता रहता है, और "stress test" average load से ऊपर रोके गए run के लिए इस्तेमाल करती है। ISTQB दोनों को stress testing में गिनता है; plan में लिखें कि आपका मतलब किस profile से है।

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

Breaking point और failure mode को पहचानना

Breaking point वह load है जिसके आगे system जो उसे भेजा जाता है उसे serve नहीं कर पाता। यह शायद ही कभी crash के साथ अपनी घोषणा करता है। Performance metrics lesson के metrics (throughput, response time, error rate और resource use) को साथ-साथ, step by step पढ़ें, और वह पल खोजें जब वे एक साथ चलना बंद कर दें: load बढ़ता रहता है, लेकिन throughput नहीं।

  • Saturation: applied load चढ़ता रहता है पर throughput flat हो जाती है, और फ़र्क कहीं queue में जमा होता है। Response time, जो तब तक धीरे-धीरे बढ़ रहा था, अब तेज़ी से चढ़ता है, क्योंकि हर request अपने से पहले वाली requests के पीछे इंतज़ार करती है।
  • Responses की जगह errors: gateway timeouts (504), refused connections, 503 Service Unavailable, और अंत में ऐसे failures जो HTTP के हैं ही नहीं: बहुत ज़्यादा memory इस्तेमाल करने पर kill हुआ instance, नए connections refuse करता database, logs से भरी disk।
  • सबसे पहले ख़त्म होने वाला resource: CPU 100% पर, पूरी तरह busy connection pool, exhausted thread pool, process के kill होने तक बढ़ती memory। (Pool दोबारा इस्तेमाल होने वाले database connections या worker threads का एक तय set है; सब busy हों तो नई requests इंतज़ार करती हैं।) यही bottleneck है, और वह fact जिसकी developer को सबसे ज़्यादा ज़रूरत है।
  • Failure mode, graceful: system धीमा होता है, excess को जल्दी और साफ़ तौर पर reject करता है (Retry-After header के साथ 503, जो client को बताता है कि दोबारा कब try करे, एक bounded queue, error page की जगह छोटा result) और जितना load serve कर सकता है, करता रहता है। Excess को जान-बूझकर reject करने को load shedding कहते हैं। Catastrophic: वह hang होता है, crash होता है, दूसरी services को अपने साथ गिरा देता है (cascading failure, जिसे retry करते clients अक्सर और बढ़ा देते हैं), या ऐसा काम स्वीकार करता है जिसे फिर खो देता है।
  • हर step पर record करें: भेजा गया load, serve हुई throughput, p95 और p99, type के हिसाब से error rate, saturated resource और पहले symptom का मिनट। Breaking point एक कहानी वाला load level है, एक अकेला number नहीं।

आज़माएँ: HTTP स्टेटस कोड लुकअप

Recovery: load घटने पर क्या होता है

कुछ टूटने पर stress test ख़त्म नहीं होता। उसका दूसरा आधा हिस्सा load को वापस सामान्य स्तर पर लाता है, expected peak या उससे नीचे, उसे hold करता है और देखता है कि system अपने आप baseline पर लौटता है या नहीं। Load test ने ऐसे load से ramp-down के बाद recovery जाँची थी जिसे system उठा सकता था; यहाँ system overload से recover कर रहा है, जो एक अलग और कठिन सवाल है। Recovery एक मापा हुआ result है: baseline वापस आने में कितना समय लगा, रास्ते में क्या खोया, और क्या किसी को हाथ लगाना पड़ा।

  • Recover होने का समय: load घटने से लेकर p95, error rate और resource use के load-test baseline पर लौटने तक के मिनट। जो system सामान्य load पर भी धीमा रहता है, वह recover नहीं हुआ: कोई queue अभी भी drain हो रही है, कोई pool अभी भी leak कर रहा है, या कोई instance कभी वापस नहीं आया।
  • Automatic या manual: crash हुए instances restart होते हैं, circuit breakers (ऐसे switches जो fail हो रही dependency को calls कुछ समय के लिए रोक देते हैं) फिर close होते हैं और traffic बिना हाथ से restart या cache flush के resume हो जाता है। हर manual step एक finding है, क्योंकि रात के दो बजे उसे कोई नहीं करेगा।
  • Backlog: queue में रुका काम, जैसे emails, notifications, payment confirmations और search indexing, एक बार process होता है, न गिराया जाता है न duplicate होता है, और queue तय समय के अंदर शून्य पर पहुँचती है।
  • Data integrity: system ने जो स्वीकार किया उसकी तुलना उससे करें जो उसने record किया; test data में unique order या user ids हों तो दोनों lists आसानी से match होती हैं। बिना payment record के user को confirm हुए orders, आधी लिखी rows और retried requests से बने duplicates stress की सबसे महँगी findings हैं, और कोई latency graph उन्हें नहीं दिखाता।

आज़माएँ: रिस्पॉन्स टाइम एनालाइज़र आज़माएँ: लोड टेस्ट डेटा जनरेटर

Worked example: peak से आगे steps में ले जाया गया order API

Pharmacy का order API (release 5.1, तीन application instances, एक database) 200 requests प्रति सेकंड के expected peak पर load test pass कर गया था, p95 620 ms, objective 800 ms के मुक़ाबले। नीचे का stress run हर पाँच मिनट में 50 requests प्रति सेकंड जोड़ता है, errors एक मिनट तक 20% से ऊपर रहने या किसी instance के crash होने पर abort करता है, और फिर पंद्रह मिनट तक 200 requests प्रति सेकंड hold करता है। Tester इसे इस क्रम में पढ़ता है:

  • 350 पर objective पहली बार पार हुआ: p95 1,250 ms, और database connection pool के 50 में से 48 connections busy। यह पहली limit है, उसी तरह का number जिसे capacity test ठीक-ठीक मापता है (capacity lesson देखें)।
  • लगभग 385 requests प्रति सेकंड पर breaking point: 400 और 450 वाले steps पर API जो भी भेजा जाए, सिर्फ़ 380 से 385 serve करता है; requests pool के लिए queue में लगती हैं, response times उछलते हैं और पहले timeouts दिखते हैं। Bottleneck database connection pool है।
  • Failure mode: queue में रुकी requests memory रोके रखती हैं; 500 पर instance 2 बहुत ज़्यादा memory इस्तेमाल करने पर kill हो जाता है, बाकी दो उसका load उठाते हैं और errors 71% तक पहुँचते हैं। Abort rule मिनट 36 पर fire होता है। Graceful नहीं, catastrophic: न 503, न load shedding, सिर्फ़ gateway timeouts (504) और एक crash।
  • Recovery: वापस 200 requests प्रति सेकंड पर instance अपने आप restart होता है और चार मिनट के अंदर p95 650 ms पर है; email queue मिनट 49 तक खाली हो जाती है। Data check में 12 orders बिना payment record के confirmed मिलते हैं। तीन defect reports बनती हैं: connection pool भरने पर load shedding का न होना, queueing के दौरान memory growth, और payment record होने से पहले भेजा गया confirmation।
Order API का stress run: load को expected peak 200 से 500 requests प्रति सेकंड तक steps में बढ़ाया गया; 400 से API सिर्फ़ लगभग 385 serve करता है, मिनट 36 पर एक instance crash होता है, और वापस 200 पर baseline चार मिनट में लौट आता है।
  1. भेजा गया load: expected peak से आगे stepsLoad tool क्या भेजता है: abort rule fire होने तक हर 5 मिनट में +50 requests प्रति सेकंड।

    संदर्भ रेखा:expected peak: 200 requests प्रति सेकंड (यहाँ load test pass हुआ)

    1. 1expected peak पर 0–10 min200 req/s तक ramp और hold: load test का result confirm
    2. 2peak से आगे steps 10–37 min250 से 500 req/s; मिनट 36 पर instance 2 crash होने पर abort
    3. 3recovery 37–55 minवापस 200 req/s पर 15 मिनट, फिर शून्य
  2. Serve हुई throughput: API ने क्या पूरा कियाServe हुई requests प्रति सेकंड; भेजे गए load के नीचे का gap queueing है, फिर failure।

    संदर्भ रेखा:breaking point: जो भी भेजा जाए लगभग 385 serve (database pool full)

    मिनट 36: instance 2 kill (out of memory), errors 71%

    1. 1served, sent के साथ चलता है 0–25 min350 req/s तक; 350 से p95 800 ms objective से ऊपर
    2. 2saturation, फिर crash 25–37 min400 और 450 भेजने पर सिर्फ़ 380–385 serve; timeouts, फिर मिनट 36 पर instance 2 गिरता है
    3. 3recovery 37–55 mininstance restart; मिनट 41 तक p95 650 ms; email queue मिनट 49 पर खाली

Numbers lesson के worked example के हैं, measurements नहीं; load के steps को vertical jumps के रूप में दिखाया गया है।

Stress test: order API, release 5.1, perf environment (3 app instances, 1 database)
Start:       expected peak 200 req/s (load test passed: p95 620 ms, 0.1 % errors)
Profile:     +50 req/s every 5 min; abort if errors > 20 % for 1 min or an instance
             crashes; then back to 200 req/s for 15 min (recovery)
Objectives:  p95 <= 800 ms, errors < 0.5 % (a reading aid here, not pass criteria)
Columns:     Sent and Served in req/s (Served = successful responses);
             Errors = % of the requests sent

Step  Sent  Served         p95 Errors  Observed
200   200   200         620 ms  0.1 %  baseline, as in the load test
250   250   250         690 ms  0.1 %
300   300   300         780 ms  0.2 %  app CPU 85 %
350   350   350       1,250 ms  0.4 %  DB pool 48/50 busy; p95 past the objective
400   400   380       2,900 ms  3.1 %  pool full, requests queue; first timeouts
450   450   385       4,800 ms   14 %  gateway 504s; throughput flat since 400
500   500    90            n/a   71 %  min 36: instance 2 killed (out of memory)
                                       -> abort, load back to 200 req/s

Recovery at 200 req/s (min 37-52)
  min 37-41   instance 2 restarting; p95 2,100 -> 650 ms; errors 8 % -> 0.1 %
  min 41-52   p95 640 ms, errors 0.1 %, DB pool 31/50; email queue empty at min 49
  data check  12 orders confirmed with no payment record; 0 duplicate orders

आम गलतियाँ

  • ऐसे system को stress test करना जिसने load test pass नहीं किया, जिससे हर finding असल में load test की finding होती है।
  • Steps में जाने की जगह सीधे extreme load पर छलाँग लगाना, जिससे पता चलता है कि system टूटता है, पर नहीं कि कहाँ, या सबसे पहले क्या ख़त्म हुआ।
  • कुछ टूटने पर run रोक देना और recovery phase छोड़ देना, जहाँ महँगी findings होती हैं।
  • Crash को ही अकेला failure मानना: silent timeouts, तेज़ error pages और स्वीकार करके खो दिए गए orders भी failures हैं।
  • सिर्फ़ response times पढ़ना; breaking point सबसे पहले load का पीछा करना बंद करती throughput और saturated resource में दिखता है।
  • बिना लिखित permission, abort rules और standby पर operations के shared environment या production को stress करना; system तोड़ने के लिए बना test उसके पड़ोसियों को भी तोड़ सकता है।

QA का नज़रिया

Stress tests तब plan होते हैं जब load test pass हो जाए और system के पास साबित करने लायक headroom हो: ऐसे peaks से पहले जिनका आकार अनिश्चित है (launch, campaign, सार्वजनिक घोषणा), architecture या infrastructure बदलने के बाद, और हर उस चीज़ के लिए जिसे सुरक्षित तरीके से degrade होना चाहिए, जैसे payments या bookings। Profile, abort rules और observations tester के हैं; operations monitoring देता है और time window पर सहमत होता है; developers को saturated resource और reproducible run चाहिए; product owner को headroom (expected peak से कितना आगे तक system काम करता है) और सादे शब्दों में failure mode चाहिए।

Run से पहले पूछें: इस product के लिए "acceptable failure" कैसा दिखता है, और क्या fallback (retry message के साथ 503, कोई छोटा feature) कहीं specified है? कौन-सी dependency सबसे पहले परेशान होगी? आज कौन क्या restart करता है, और क्या वह automatic होना चाहिए? Breaking point को उसके bottleneck के साथ एक load level के रूप में report करें, failure mode को evidence के साथ graceful या catastrophic के रूप में, और recovery time और data check को। हर catastrophic व्यवहार, हर manual step और हर integrity समस्या अपनी अलग defect report बनती है।

अभ्यास

Ticket booking API के stress run को पढ़ें

आपका काम

एक ticket seller का booking API 300 requests प्रति सेकंड के expected peak पर load test pass कर गया (objectives: p95 ≤ 700 ms, errors 1% से कम)। नीचे की सामग्री stress run का step log और recovery phase है। वह step पहचानें जिस पर कोई objective पहली बार पार हुआ, breaking point और उसका bottleneck खोजें, failure mode classify करें, recovery को judge करें और वे defects सूचीबद्ध करें जो आप report करेंगे।

सामग्री
Booking API, 4 instances, 1 database, 1 payment provider (sandbox)
Expected peak 300 req/s; objectives p95 <= 700 ms, errors < 1 %
Profile: +75 req/s every 5 min from 300; then back to 300 req/s for 15 min
Abort rule: errors > 20 % for 1 min, or any instance down
Columns: Sent and Served in req/s (Served = successful responses);
         Errors = % of the requests sent

Step  Sent  Served         p95 Errors  Observed
300   300   300         480 ms  0.2 %  baseline
375   375   375         560 ms  0.3 %
450   450   450         690 ms  0.6 %  app CPU 78 %; payment calls 1.1 s on average
525   525   518         980 ms  1.2 %  payment thread pool 64/64 busy
600   600   522       3,400 ms    9 %  queue in front of payment calls; 503s with
                                       Retry-After from the API gateway
675   675   518       4,100 ms   23 %  abort at min 32; no instance down

Recovery at 300 req/s (min 33-48)
  min 33-36   p95 1,900 -> 500 ms; errors 4 % -> 0.2 %; 503s stop at min 34
  min 36-48   p95 490 ms, errors 0.2 %, payment pool 22/64 busy
  backlog     confirmation SMS queue: 9,400 messages, empty at min 47
  data check  0 bookings without payment; 37 payments charged twice (retried
              requests created a second booking for the same seat, later cancelled)
चरण
  1. वह पहला step खोजें जिस पर कोई objective fail होता है, और नोट करें कौन-सा।
  2. वह step खोजें जिस पर served throughput load का पीछा करना बंद कर देती है; saturate हुए resource का नाम लें।
  3. Log के evidence के साथ failure mode को graceful या catastrophic classify करें।
  4. Recovery को judge करें: baseline तक का समय, manual steps, backlog और data integrity।
  5. Defect reports की सूची लिखें, हर व्यवहार के लिए एक।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Objective पहली बार 525 requests प्रति सेकंड पर पार हुआ: p95 980 ms, 700 ms के मुक़ाबले, और errors 1.2%, 1% के मुक़ाबले, payment thread pool पूरी तरह busy (64 में से 64) के साथ।

Breaking point लगभग 520 requests प्रति सेकंड पर: step 525 से आगे API जो भी भेजा जाए 518 से 522 ही serve करता है, इसलिए payment thread pool bottleneck है; धीमी payment provider calls (step 450 पर औसत 1.1 s) ने उसे भर दिया।

Failure mode: ज़्यादातर graceful। Gateway ने excess को 503 और Retry-After के साथ reject किया, कोई instance down नहीं हुआ और throughput लगभग 520 पर टिकी रही। अपवाद data check है: retried requests से 37 double charges, जो graceful आकार के अंदर एक catastrophic नतीजा है।

Recovery: automatic; p95 और errors तीन मिनट के अंदर baseline पर, 503s मिनट 34 पर रुक गए, और SMS backlog 14 मिनट में drain हुआ, जिसकी तुलना business जो स्वीकार करता है उससे करनी चाहिए।

Defects: booking request idempotent नहीं है (पहले से process हो चुकी request का retry दूसरी booking और दूसरा charge बनाता है), यह सबसे गंभीर finding है; और अगर 14 मिनट तय limit से ज़्यादा है, तो 9,400 SMS के backlog का धीमा drain। Payment thread pool को defect की तरह नहीं, bottleneck की तरह report करें, क्योंकि API gracefully degrade हुआ: ज़्यादा headroom चाहिए तो सबसे पहले इसी को बदलना है। Product owner के लिए headroom भी नोट करें: पहला objective fail होने से पहले 450 और 525 requests प्रति सेकंड के बीच, यानी expected peak से 50% से 75% ऊपर।

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

Stress testing और load testing में क्या फ़र्क है?

Load test expected load लगाता है और results को पहले से तय pass criteria से जाँचता है। Stress test जान-बूझकर expected peak से आगे जाता है, या resources हटाता है, यह खोजने के लिए कि system कहाँ serve करना बंद करता है, कैसे fail होता है और क्या recover करता है। Load test का pass criteria के सामने एक verdict होता है; stress test की ज़्यादातर findings होती हैं।

क्या breaking point और capacity एक ही चीज़ हैं?

नहीं। Capacity वह अधिकतम load है जिस पर हर performance objective अभी भी पूरा होता है; breaking point वह load है जिसके आगे system जो भेजा जाता है उसे serve नहीं कर पाता। दोनों के बीच आम तौर पर एक gap होता है जहाँ system काम करता है पर अपने targets चूकता है। Capacity testing, एक बाद का lesson, पहला number ठीक-ठीक मापती है; stress testing दूसरा खोजती है।

क्या system टूटने पर stress test fail हो जाता है?

नहीं। हर system किसी load पर टूटता है; यह अपेक्षित है। Findings ये हैं: वह peak से कितना आगे टूटा, failure graceful था या catastrophic, क्या वह बिना मदद recover हुआ और क्या data consistent रहा। वह तभी fail होता है जब overload के लिए तय किसी requirement को तोड़े, जैसे अधिकतम recovery time या कोई order न खोना; जो system excess को साफ़ तौर पर reject करता है और मिनटों में recover करता है, उसने वही किया जो stress test देखना चाहता है।

क्या मैं production को stress test कर सकता हूँ?

सिर्फ़ लिखित permission, abort rules, standby पर operations और business से तय time window के साथ, और बेहतर है कि पहले run के लिए कभी नहीं; stress test system तोड़ने के लिए बना है, और वह shared dependencies भी तोड़ सकता है। Production जैसा environment चुनें, और production को expected peak या उससे नीचे के load tests के लिए रखें।

संदर्भ

  • 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 — और हर एक से क्या पता लगाना होता है।
  • Site Reliability Engineering: How Google Runs Production SystemsGoogle / O'Reilly Media · 2016सर्विस लेवल ऑब्जेक्टिव, एरर बजट, "चार गोल्डन सिग्नल" की निगरानी और ओवरलोड संभालना — लचीलेपन का परिचालन पक्ष।
टूल्स

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

HTTP स्टेटस कोड लुकअप

किसी भी HTTP स्टेटस कोड का अर्थ, RFC संदर्भ और उसे कब इस्तेमाल करना है — सब एक जगह देखें।

वेब

और गहराई से

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

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

इस topic से पहले