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

सोक और एंड्योरेंस टेस्टिंग

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

Soak testing, जिसे endurance testing भी कहते हैं, performance testing का एक प्रकार है जिसमें system पर एक realistic, स्थिर load लंबे समय तक रखा जाता है — कई घंटे, कभी-कभी कई दिन — ताकि वे problems मिलें जो सिर्फ़ समय के साथ दिखती हैं। ISTQB का performance testing syllabus endurance testing नाम इस्तेमाल करता है और duration को system के operational context से जोड़ता है — व्यवहार में, वह restarts, deployments या maintenance windows के बीच असल में कितनी देर चलता है। वह यह भी बताता है कि ऐसा test क्या खोजता है: resource capacity problems, जैसे memory leaks या ख़त्म होते database connections और thread pools, जो धीरे-धीरे performance गिराती हैं या failures में बदल जाती हैं।

उदाहरण: एक order API 180 requests per second पर 30 मिनट का load test pass करता है, और उसका 95th percentile (p95) response time 310 ms है। वही load 12 घंटे तक रखने पर कहानी बदल जाती है: memory हर घंटे लगभग 0.24 GB बढ़ती है, p95 1.4 seconds से ऊपर चला जाता है, और लगभग 11.5 घंटे बाद container अपनी 4 GB memory limit पार करने पर kill हो जाता है। Load कभी नहीं बदला; सिर्फ़ समय बीता।

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

छोटे tests ऐसे system को मापते हैं जो अभी-अभी start हुआ है: pools साफ़ हैं, logs छोटे हैं और हर leak अभी बहुत छोटा है। Production में वही service deployments के बीच दिनों या हफ़्तों तक चल सकती है। जो defect हर घंटे कुछ megabytes leak करता है, या हर timed-out payment के बाद एक database connection अपने पास रख लेता है, वह 30 मिनट के run में नहीं दिखता और चौथे दिन outage बन जाता है — अक्सर restart से "ठीक" किया जाता है, जो cause को अगली बार तक छिपा देता है।

Product के लिए soak test इस बात का सबूत है कि performance और reliability असली operating period तक टिकती हैं, सिर्फ़ पहले कुछ मिनटों तक नहीं; ISO/IEC 25010 की भाषा में यह समय के साथ resource utilisation और time behaviour को जाँचता है। Tester के लिए यह सवाल बदल देता है: "क्या यह तेज़ है?" से "क्या यह तेज़ बना रहता है, और क्या यह चलता रहता है?" — और test environment में, पूरी monitoring के साथ और किसी customer पर असर डाले बिना, मिला leak production में उसी leak से कहीं आसानी से diagnose होता है।

Soak test को अलग क्या बनाता है

पिछले lessons में हर test type load बदलता था: load test अपेक्षित workload लगाता है, stress test अपेक्षित peak से आगे जाता है, और spike test load को अचानक उछालता है। Soak test load को स्थिर रखता है और duration को variable बनाता है। इसलिए आप जो result खोजते हैं वह एक trend है: load स्थिर रहते हुए क्या कोई चीज़ लगातार बढ़ या घट रही है?

Soak testing और endurance testing एक ही activity के दो नाम हैं। ISTQB endurance testing कहता है; कई tools और teams, k6 documentation समेत, soak testing कहते हैं। कुछ teams दोनों के बीच अपनी रेखा खींचती हैं, जैसे load level के आधार पर, लेकिन कोई standard बँटवारा नहीं है, इसलिए अपने test plan में मतलब लिख दें।

  • Load: आम तौर पर अपेक्षित average production load, या किसी busy period का realistic load, जो स्थिर रखा जाता है। Stress testing में मिले breaking point से साफ़ नीचे रहें, वरना overload और धीमे leak में फ़र्क नहीं कर पाएँगे।
  • Duration: operational context से तय होती है — कम से कम एक पूरा business cycle, जैसे nightly batch jobs समेत पूरा एक दिन, या restarts या deployments के बीच service के चलने का सबसे लंबा समय।
  • सवाल: क्या system घंटे 12 में वैसा ही व्यवहार करता है जैसा घंटे 1 में, और load रुकने पर क्या वह अपने resources वापस छोड़ता है?

समय के साथ क्या बिगड़ता है: leaks, exhaustion और drift

Memory leak तब होता है जब program ऐसी memory पकड़े रहता है जिसकी उसे अब ज़रूरत नहीं, इसलिए वह memory कभी free नहीं होती। कई runtimes (Java, .NET, JavaScript, Go) memory अपने-आप free करते हैं: garbage collector (GC) नियमित रूप से heap से — यानी memory का वह हिस्सा जहाँ program अपने objects रखता है — हर वह object हटा देता है जिसे अब कोई refer नहीं करता। इसलिए इन runtimes में leak का मतलब है कि program ऐसे objects के references अब भी पकड़े हुए है जिन्हें वह इस्तेमाल नहीं करता: बिना size limit वाला in-memory cache, कभी साफ़ न होने वाली sessions की list, हर request पर जोड़ा गया और कभी न हटाया गया listener। Collector चलने के साथ memory sawtooth की तरह ऊपर-नीचे होती है। असली signal हर collection के बाद का level है: healthy service में यह warm-up के बाद स्थिर हो जाता है; leak होने पर यह तब तक चढ़ता रहता है जब तक process की memory ख़त्म न हो जाए या platform उसे kill न कर दे। उससे पहले collector ज़्यादा मेहनत करता है और response times बढ़ते हैं।

Resource exhaustion वही pattern है, बस ऐसे resource के साथ जिसकी fixed limit हो। जो code path error आने पर अपना database connection pool को वापस नहीं करता, वह हर बार चलने पर एक connection leak करता है। Pool ख़ाली होने पर नई requests इंतज़ार करती हैं और फिर time out हो जाती हैं, जबकि CPU और memory सामान्य दिखते हैं।

  • Memory: garbage collection के बाद process या heap memory का घंटे-दर-घंटे बढ़ना।
  • Pools और handles: database connections, threads, open files या sockets का इस्तेमाल धीरे-धीरे अपनी configured maximum की तरफ़ बढ़ना।
  • Disk: logs, temporary files या uploads का disk भरते जाना; log rotation के बिना disk भरते ही service रुक जाती है।
  • Queues: consumer अपने producer से थोड़ा धीमा, इसलिए backlog और waiting time बिना रुके बढ़ते हैं।
  • Leak के बिना गिरावट: run के दौरान बढ़ती tables बिना index वाली queries को धीमा करती हैं, और backups जैसे scheduled jobs किसी तय घंटे पर traffic से टकराते हैं। ये भी असली findings हैं, पर इनका fix अलग है, इसलिए इन्हें सटीक नाम दें।
एक ही स्थिर load में healthy service की memory warm-up के बाद स्थिर हो जाती है, memory leak process के kill होने तक चढ़ता है, और leak हुए connections pool को तब तक भरते जाते हैं जब तक requests time out न होने लगें। वैचारिक मॉडल
  1. स्वस्थ service: memoryGarbage collection के बाद memory service के warm-up के दौरान बढ़ती है, फिर limit से काफ़ी नीचे स्थिर रहती है।

    संदर्भ रेखा:memory limit (4 GB)

    1. 1warm-up 0–1 h
    2. 2steady state 1–12 h
  2. Memory leak (worked example वाला)Garbage collection के बाद heap लगभग 0.24 GB प्रति घंटे बढ़ता है, घंटे 1 पर 1.2 GB से घंटे 11 पर 3.6 GB तक, और कभी स्थिर नहीं होता।

    संदर्भ रेखा:memory limit (4 GB)

    11:35 पर container kill: memory ख़त्म

  3. Connection leakइस्तेमाल में database connections कुछ-कुछ करके बढ़ते हैं; pool ख़ाली होने पर नई requests इंतज़ार करती हैं और time out हो जाती हैं।

    संदर्भ रेखा:pool size

    pool ख़त्म: requests time out

सांकेतिक चित्र: 12 घंटे का स्थिर load, हर resource उसकी limit के हिस्से के रूप में। Memory leak वाला plot worked example पर आधारित है; बाकी दो सिर्फ़ उदाहरण हैं।

Soak test की planning और execution

Server-side monitoring के बिना soak test सिर्फ़ इतना बताता है कि system धीमा हो गया। Response times वाली timeline पर ही, एक तय interval पर, Google की SRE book के चार golden signals — latency, traffic, errors और saturation — इकट्ठा करें, और साथ में हर वह resource जो leak हो सकता है: garbage collection के बाद memory, इस्तेमाल में connections और threads, open files, free disk और queue depth।

Pass criteria run से पहले लिखें, और average निकालने की बजाय time windows की तुलना करें। 12 घंटे का average trend छिपा देता है; पहले steady घंटे की तुलना आख़िरी घंटे से करें, और errors के लिए छोटी windows जाँचें।

  • Realistic workload mix और पर्याप्त distinct test data इस्तेमाल करें: 12 घंटे तक दोबारा इस्तेमाल हुए 20 accounts सब कुछ cache में रखते हैं और growth छिपा देते हैं, और order numbers जैसी unique values run के बीच में ख़त्म नहीं होनी चाहिए।
  • Environment production जैसा रखें — वही memory limits, log level और scheduled jobs — और तय कर लें कि run के दौरान कोई deploy या restart नहीं करेगा।
  • Load generator पर भी नज़र रखें: अगर उसकी memory या ports कम पड़ जाएँ, तो system under test धीमा दिखेगा जबकि वह धीमा नहीं है।
  • Ramp-down के बाद भी observe करते रहें: memory, connections और threads को लगभग अपने शुरुआती level पर लौटना चाहिए।
Soak test plan: order API
Workload:  180 requests/s (expected weekday average), held constant
           60% browse, 25% search, 10% add to cart, 5% checkout
           5,000 distinct test users
Duration:  15 min ramp-up, 12 h steady state, 10 min ramp-down,
           then 30 min observation with no load
Monitor:   every minute: p95 and p99 per endpoint, throughput, errors,
           heap after GC, DB connections in use (pool max 50),
           threads, open files, free disk, queue depth
Pass if:   1. p95 in the last hour <= 1.2 x p95 in the first steady hour
           2. error rate < 0.5% in every 15-minute window
           3. heap after GC: no upward trend over the last 6 hours
           4. no restarts and no out-of-memory kills
           5. after ramp-down: heap and connections back near baseline

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

Worked example: 12 घंटे का run पढ़ना

Plan वाला order API 12 घंटे तक स्थिर 180 requests per second पर चला। नीचे की table में वे चुने हुए घंटे हैं जिन्हें tester ने monitoring dashboard से export किया।

इसे column-दर-column पढ़ें। Throughput स्थिर है, इसलिए slowdown ज़्यादा traffic से नहीं है। Connections 50 में से 12 से 14 के बीच रहते हैं, इसलिए pool समस्या नहीं है। Garbage collection (GC) के बाद heap लगभग 0.24 GB प्रति घंटे बढ़ता है और कहीं स्थिर नहीं होता: यह memory leak है। p95 भी साथ बढ़ता है क्योंकि heap भरने के साथ collector ज़्यादा देर और ज़्यादा बार चलता है, और आख़िरी घंटों में errors आने लगते हैं। Run criteria 1 से 4 में fail होता है; criterion 5 जाँचा नहीं जा सका क्योंकि run ramp-down तक पहुँचा ही नहीं।

Defect report तथ्य और trend बताती है, cause का अंदाज़ा नहीं: build, load profile, duration, heap chart, kill का समय, और यह projection कि average load पर production लगभग हर 11 से 12 घंटे में उसी limit तक पहुँचेगा। Developers से test environment में दो heap dumps लेने को कहें, घंटे 1 और घंटे 6 में; उनकी तुलना दिखाती है कि कौन-से objects बढ़ते जा रहे हैं। Fix के बाद वही profile confirmation testing के रूप में दोबारा चलाएँ और curves की तुलना करें।

Hour   Req/s  p95 ms  Errors  Heap after GC  DB conns in use
1        180     310    0.1%         1.2 GB         12 of 50
3        180     325    0.1%         1.7 GB         13 of 50
6        180     410    0.2%         2.4 GB         12 of 50
9        180     690    0.4%         3.1 GB         14 of 50
11       180    1450    1.9%         3.6 GB         13 of 50
11:35    container killed: memory limit (4 GB) exceeded

आम गलतियाँ

  • Resources monitor किए बिना लंबे load test को soak test कहना: आप देखेंगे कि system धीमा हुआ, पर क्यों, यह नहीं।
  • Stress testing में मिले breaking point से ऊपर चलाना, जिससे overload और धीमे leaks मिल जाते हैं और किसी का diagnosis नहीं हो पाता।
  • पहले और आख़िरी घंटों की तुलना करने और छोटी windows जाँचने की बजाय run को उसके overall average से आँकना।
  • Duration सुविधा से चुनना ("lunch से पहले एक घंटा"), असली operating period से नहीं।
  • गिने-चुने test users या records दोबारा इस्तेमाल करना, जिससे caches growth छिपा देते हैं — या run के बीच unique data ख़त्म हो जाना और गलत वजह से fail होना।
  • Scheduled restart या बड़ी memory limit को fix मान लेना: इससे failure सिर्फ़ आगे खिसकता है।

QA का नज़रिया

Soak test calendar time और environment time दोनों लेता है, इसलिए इसे जल्दी plan करें। Product owner और operations के साथ तय करें कि service को बिना दखल कितनी देर चलना है, रात भर या weekend के लिए production जैसा environment reserve करें, और पक्का करें कि run के दौरान कोई उस पर deploy न करे। Developers और operations से पूछें कि किन resources की hard limits हैं — memory limits, pool sizes, disk quotas, queue sizes — ताकि run शुरू होने से पहले ही पता हो कि क्या monitor करना है, fail होने के बाद नहीं।

Results के साथ build, workload profile, duration और pass criteria record करें, और charts संभालकर रखें: soak report का सबसे मज़बूत सबूत वह resource है जो स्थिर load में चढ़ता जाता है। कई teams हर release candidate के लिए छोटा soak और major releases या infrastructure changes से पहले लंबा soak चलाती हैं। हर run की तुलना पिछले run से करें: पिछले महीने से 20% ऊपर स्थिर होती memory, या run के भीतर ज़्यादा drift करता p95, उठाने लायक है, भले ही सारे criteria pass हों।

अभ्यास

8 घंटे के soak run का diagnosis करें

आपका काम

एक payment service पर 8 घंटे तक स्थिर 60 requests per second का soak test चला। Pass criteria: p95 पहले घंटे के p95 के 1.2 गुना से ज़्यादा न हो, हर घंटे error rate 0.5% से कम हो, और किसी monitored resource में ऊपर जाता trend न हो। Monitoring export नीचे है।

तय करें कि run pass हुआ या नहीं, क्या बिगड़ा और आप ऐसा क्यों मानते हैं, अनुमान लगाएँ कि इस load पर problem production में कब आएगी, और defect report में डाले जाने वाले सबूत लिखें।

सामग्री
Payment service soak test: 60 requests/s, 8 hours, DB pool max 40

Hour  Req/s  p95 ms  Errors  Heap after GC  DB conns in use  Threads
   1     60     220    0.0%         610 MB          8 of 40       52
   2     60     225    0.0%         615 MB         12 of 40       52
   4     60     230    0.0%         612 MB         20 of 40       53
   6     60     235    0.1%         618 MB         29 of 40       52
   7     60     610    1.8%         615 MB         34 of 40       53
   8     60    5000    9.6%         614 MB         40 of 40       52

Most frequent error from hour 7: "Timeout waiting for a connection from the pool"
Bank simulator timeouts (planned in the test data): 4 to 6 per hour
Request timeout configured in the service: 5 s
चरण
  1. जाँचें कि load स्थिर रहा या नहीं।
  2. हर resource column देखें और तय करें कि किसमें trend है और कौन-से स्थिर हैं।
  3. सबसे आम error को trend वाले resource से जोड़ें।
  4. Results की हर pass criterion से तुलना करें और pass या fail तय करें।
  5. Failure तक का समय estimate करें, और developers के लिए सबूत और सवाल लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Load 60 requests per second पर स्थिर रहा, इसलिए बदलाव का कारण समय है, traffic नहीं। GC के बाद heap (610–618 MB) और threads (52–53) स्थिर हैं: memory या thread leak नहीं। DB connections in use 40 में से 8 से 40 तक चढ़ते हैं, लगभग 4 से 6 प्रति घंटे, जब तक pool ख़त्म नहीं हो जाता।

Errors इसकी पुष्टि करते हैं: घंटे 7 से सबसे आम error pool से connection का इंतज़ार करते हुए timeout है, और p95 235 ms से 610 ms और फिर 5,000 ms तक उछलता है, जो service में configured request timeout है। Run fail है: घंटे 7 और 8 में p95 1.2 × 220 = 264 ms से ऊपर है, घंटे 7 और 8 में error rate 0.5% से ऊपर है, और connections पहले घंटे से ही ऊपर जाते trend में हैं। Run घंटे 6 पर रुक जाता तब भी trend वाली criterion पर fail होता, जबकि response times और errors ठीक दिख रहे थे — इसीलिए soak test resources monitor करता है।

Failure तक का समय: इस load पर fresh start के बाद system लगभग 6 घंटे सामान्य चलता है; लगभग घंटे 7 से users को धीमे responses और errors मिलते हैं, और लगभग घंटे 8 पर pool ख़ाली हो जाता है (40 connections, हर घंटे 4 से 6 leak)। Production में यह जल्दी भी हो सकता है: leak rate bank simulator के प्रति घंटे 4 से 6 timeouts से मेल खाता है, इसलिए जिस दिन bank के timeouts ज़्यादा हों, pool और जल्दी ख़ाली होगा। इस संबंध को developers के लिए एक hypothesis मानें, साबित cause नहीं।

Defect report के सबूत: build और environment, load profile और duration, स्थिर heap और threads के बगल में connections in use का chart, पहला समय जब p95 और errors ने criteria तोड़े, error message और उसकी counts, और bank timeouts से संबंध। Developers से पूछें कि क्या timeout वाला path अपना connection pool को लौटाता है, और क्या इस्तेमाल हो रहे pool में leak-detection setting है जो log करे कि connection कहाँ लिया गया था — कुछ pools यह देते हैं। Fix के बाद वही 8 घंटे का profile दोबारा चलाएँ और पक्का करें कि connection count स्थिर रहता है।

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

Soak test कितनी देर चलना चाहिए?

उतनी देर जितने operating period पर आपको भरोसा चाहिए: कम से कम scheduled jobs समेत एक पूरा business cycle, या restarts या deployments के बीच service के चलने का सबसे लंबा समय। अगर कोई resource धीरे बढ़ता है, तो इतनी देर चलाएँ कि साफ़ trend दिखे और आप अनुमान लगा सकें कि वह अपनी limit तक कब पहुँचेगा। हफ़्तों चलने वाले systems को कई दिनों की testing चाहिए हो सकती है।

क्या soak test बस एक लंबा load test है?

Load profile एक जैसा दिख सकता है, लेकिन goal और सबूत अलग हैं। Load test जाँचता है कि अपेक्षित load पर targets पूरे होते हैं; soak test जाँचता है कि समय के साथ व्यवहार स्थिर रहता है, इसलिए उसे resource monitoring और शुरुआती व बाद की windows की तुलना चाहिए, सिर्फ़ response-time targets नहीं।

अगर memory बढ़ती ही जाए, तो क्या वह हमेशा leak है?

नहीं। Caches भरते समय memory जायज़ तौर पर बढ़ सकती है, बशर्ते वह किसी configured limit पर स्थिर हो जाए। कई घंटों तक garbage collection के बाद का level देखें: जो curve स्थिर हो जाए वह warm-up है; जो curve स्थिर load में चढ़ता रहे वह leak की ओर इशारा करता है। Trend report करें और cause की पुष्टि developers को heap analysis से करने दें।

क्या मैं Mutqan tools से soak test चला सकता हूँ?

Run खुद नहीं: soak test के लिए Apache JMeter, k6, Gatling या Locust जैसा load tool चाहिए जो घंटों तक किसी ऐसे environment पर चले जिस पर load डालने की आपको अनुमति हो। Mutqan tools तैयारी में मदद करते हैं: request mixes और ramp profiles, distinct test data के बड़े sets, और load tool के लिए एक शुरुआती script।

संदर्भ

टूल्स

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

और गहराई से

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

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

इस topic से पहले