परफ़ॉर्मेंस और सुरक्षा रेज़िलिएंस टेस्टिंग
रेज़िलिएंस वह है जो उत्पाद तब करता है जब हालात आदर्श नहीं रहते: ट्रैफ़िक दोगुना हो जाता है, पेमेंट प्रोवाइडर टाइमआउट हो जाता है, कोई बॉट लॉगिन फ़ॉर्म पर हथौड़ा चलाता है, समाप्त हो चुका टोकन दोबारा भेजा जाता है। फ़ंक्शनल टेस्ट साबित करते हैं कि उत्पाद काम करता है; रेज़िलिएंस टेस्टिंग साबित करती है कि वह काम करता रहता है, सुरक्षित रूप से घटता है और उबरता है — लोड में, विफलता में और हमले में।
यह गाइड तीनों हिस्सों को साथ रखती है क्योंकि प्रोडक्शन में वे साथ ही विफल होते हैं। यह टेस्ट के प्रकार परिभाषित करती है, बताती है कि क्या मापना है और "अच्छा" संख्या के रूप में कैसा दिखता है, वेब ऐप और API के लिए OWASP बेसलाइन समझाती है, और एक-पेज की योजना के साथ ख़त्म होती है जिसे टीम लॉन्च से पहले चला सकती है।
रेज़िलिएंस टेस्टिंग क्या है?
रेज़िलिएंस टेस्टिंग उन गतिविधियों का समूह है जो मापती हैं कि सिस्टम अपनी सामान्य परिचालन स्थितियों के बाहर कैसे व्यवहार करता है। ISO/IEC 25010 इसे तीन गुणवत्ता विशेषताओं के तहत रखता है — परफ़ॉर्मेंस दक्षता (समय-व्यवहार, संसाधन उपयोग, क्षमता), विश्वसनीयता (उपलब्धता, फ़ॉल्ट टॉलरेंस, रिकवरी) और सुरक्षा (गोपनीयता, अखंडता, प्रामाणिकता, जवाबदेही)। कोई उत्पाद फ़ंक्शनल उपयुक्तता में अच्छा और तीनों में ख़राब स्कोर कर सकता है।
टेस्ट के तीनों परिवार तरीक़े में अलग हैं पर एक नियम साझा करते हैं: हर एक को टेस्ट चलने से पहले संख्या में लिखा लक्ष्य चाहिए। "API तेज़ होना चाहिए" लक्ष्य नहीं है; "200 अनुरोध प्रति सेकंड पर p95 लेटेंसी 400 ms से कम और एरर रेट 0.1% से नीचे" लक्ष्य है। संख्या के बिना टेस्ट ऐसी रिपोर्ट देता है जिसे कोई पास या फ़ेल नहीं कर सकता।
- परफ़ॉर्मेंस — लोड, स्ट्रेस, सोक और स्पाइक टेस्ट: माँग बढ़ने पर, सीमा पार होने पर और समय के साथ सिस्टम कैसे व्यवहार करता है।
- विफलता — जब कोई निर्भरता धीमी, ग़लत या ग़ायब हो तो क्या होता है, और क्या सिस्टम अपने आप उबरता है।
- सुरक्षा — क्या OWASP द्वारा सूचीबद्ध आम कमज़ोरियाँ मौजूद हैं, और क्या नियंत्रण (ऑथेंटिकेशन, सेशन, हेडर, इनपुट हैंडलिंग) टिकते हैं।
परफ़ॉर्मेंस टेस्टिंग: लोड, स्ट्रेस, सोक और स्पाइक
लोड टेस्ट अपेक्षित ट्रैफ़िक — वर्कलोड मॉडल — लागू करता है और लक्ष्यों के विरुद्ध लेटेंसी, थ्रूपुट और एरर रेट मापता है। स्ट्रेस टेस्ट लोड को अपेक्षित पीक से ऊपर तब तक बढ़ाता है जब तक कुछ टूट न जाए, ताकि सीमा मिले और दिखे कि सिस्टम कैसे विफल होता है: धीरे और सुरक्षित रूप से, या एक साथ। सोक (एंड्योरेंस) टेस्ट घंटों तक यथार्थ लोड बनाए रखता है ताकि लीक, बढ़ती क़तारें और कनेक्शन की थकान सामने आएँ जो दस-मिनट का टेस्ट कभी नहीं देखता। स्पाइक टेस्ट सेकंडों में शून्य से पीक पर छलाँग लगाता है — वही जो कोई मार्केटिंग कैंपेन या ख़बर में ज़िक्र करता है।
- लोड टेस्टअपेक्षित ट्रैफ़िक (वर्कलोड मॉडल); लेटेंसी, थ्रूपुट और एरर रेट लक्ष्यों के विरुद्ध मापे जाते हैं।
संदर्भ रेखा:अपेक्षित पीक
- स्ट्रेस टेस्टअपेक्षित पीक से ऊपर, जब तक कुछ टूट न जाए: सिस्टम धीरे और सुरक्षित रूप से विफल होता है, या एक साथ?
संदर्भ रेखा:अपेक्षित पीक
कुछ टूट जाता है
- सोक (एंड्योरेंस) टेस्टघंटों तक यथार्थ लोड: लीक, बढ़ती क़तारें, कनेक्शन की थकान।समय · घंटे
संदर्भ रेखा:अपेक्षित पीक
- स्पाइक टेस्टसेकंडों में शून्य से पीक तक, जैसे किसी मार्केटिंग कैंपेन या ख़बर में ज़िक्र के बाद।
संदर्भ रेखा:अपेक्षित पीक
एक ही साझा लोड स्केल पर सांकेतिक आकार: ऊँचाइयाँ और समय-अवधि सिर्फ़ उदाहरण हैं।
वर्कलोड मॉडल टूल से ज़्यादा मायने रखता है। यह असली ट्रैफ़िक से आना चाहिए — कौन-से एंडपॉइंट, किस मिश्रण में, किस डेटा के साथ, कितनी कॉन्करेंसी पर — न कि लूप में पीटे गए एक एंडपॉइंट से। Apache JMeter, k6 और ऐसे टूल उपयोगकर्ताओं, टोकन और पेलोड की डेटा फ़ाइल लेते हैं; सही विविधता के साथ वह डेटा बनाना (अलग उपयोगकर्ता, अलग रिकॉर्ड आकार, बीच में अमान्य इनपुट) तैयारी का बड़ा हिस्सा है। प्रोडक्शन जैसे आकार के एनवायरनमेंट पर चलाएँ, वरना संख्याएँ किसी और सिस्टम का वर्णन करेंगी।
- औसत नहीं, p50, p95 और p99 लेटेंसी दर्ज करें — औसत उस धीमी पूँछ को छिपा देता है जो उपयोगकर्ता सचमुच महसूस करते हैं।
- एरर रेट और एरर का प्रकार अलग-अलग दर्ज करें: जो सिस्टम 500 लौटाकर तेज़ बना रहे, वह पास नहीं हुआ।
- बदलाव से पहले और बाद में एक ही वर्कलोड से मापें, ताकि तुलना ईमानदार हो।
- वेब फ़्रंट-एंड के लिए असली डिवाइस पर मापे Core Web Vitals (LCP, INP, CLS) जोड़ें; सर्वर लेटेंसी उपयोगकर्ता की प्रतीक्षा का सिर्फ़ एक हिस्सा है।
आज़माएँ: लोड टेस्ट डेटा जनरेटर आज़माएँ: JMeter टेस्ट डेटा जनरेटर आज़माएँ: Concurrent रिक्वेस्ट टेस्ट जनरेटर आज़माएँ: HTTP रिक्वेस्ट बेंचमार्क आज़माएँ: रिस्पॉन्स टाइम एनालाइज़र आज़माएँ: API परफ़ॉर्मेंस कंपेरेटर
विफलता और रिकवरी: जब कोई निर्भरता मर जाए तो क्या होता है, यह टेस्ट करना
ज़्यादातर आउटेज टेस्ट किए जा रहे सिस्टम से नहीं, बल्कि उस चीज़ से होते हैं जिस पर वह निर्भर है: धीमा पड़ता डेटाबेस, 503 लौटाने लगा थर्ड-पार्टी API, भरती हुई क़तार। विफलता को स्थानीय रखने वाले पैटर्न अच्छी तरह दस्तावेज़ हैं — हर आउटबाउंड कॉल पर टाइमआउट, एक्सपोनेंशियल बैकऑफ़ और सीमा के साथ रीट्राई, सर्किट ब्रेकर जो विफल निर्भरता को कॉल करना बंद कर दें, बल्कहेड जो एक थके पूल को बाक़ी गिराने से रोकें, और ग्रेसफ़ुल डिग्रेडेशन जो एरर पेज की जगह घटा हुआ परिणाम दे। माइकल नाइगार्ड की Release It! इन स्थिरता पैटर्न का मानक संदर्भ बनी हुई है।
इन्हें टेस्ट करने का मतलब है जानबूझकर विफलता पैदा करना। API स्तर पर यह सरल है: सिस्टम को ऐसी मॉक की ओर मोड़ें जो Retry-After हेडर के साथ 500, 503 या 429 लौटाए, जो 30 सेकंड बाद जवाब दे, या जो विकृत बॉडी लौटाए, और सिस्टम का व्यवहार देखें — क्या वह टाइमआउट करता है, समझदारी से रीट्राई करता है, अपने कॉलर को स्पष्ट एरर देता है, और मॉक के लौटने पर उबरता है? रेट लिमिटिंग अपना अलग टेस्ट माँगती है: RFC 6585 429 Too Many Requests परिभाषित करता है, और जो क्लाइंट 429 पर तुरंत रीट्राई करे वह समस्या बढ़ाता है।
- हर आउटबाउंड कॉल का टाइमआउट कॉलर के अपने टाइमआउट से छोटा हो।
- रीट्राई सीमित हों, बैकऑफ़ इस्तेमाल करें, और नॉन-आइडेम्पोटेंट अनुरोधों को आँख मूँदकर कभी न दोहराएँ।
- विफल निर्भरता एक विशिष्ट, लॉग किया गया एरर दे — न सामान्य 500, न हैंग।
- रिकवरी स्वचालित हो: निर्भरता लौटते ही ट्रैफ़िक बिना रीस्टार्ट के फिर चले।
आज़माएँ: API स्टेटस कोड सिम्युलेटर आज़माएँ: Mock एरर रिस्पॉन्स जनरेटर आज़माएँ: Mock एरर पेलोड जनरेटर
सुरक्षा टेस्टिंग: OWASP बेसलाइन
लॉन्च से पहले की सुरक्षा टेस्टिंग किसी विशेषज्ञ टीम का पेनेट्रेशन टेस्ट नहीं है — वह बाद में आता है और ज़्यादा गहराई में जाता है। यह एक बेसलाइन है: यह जाँचना कि असली सेंधों में सबसे ज़्यादा मिलने वाली कमज़ोरियाँ मौजूद नहीं हैं। OWASP Top 10 उन्हें वेब एप्लिकेशन के लिए सूचीबद्ध करता है (ब्रोकन एक्सेस कंट्रोल, सुरक्षा मिसकॉन्फ़िगरेशन, इंजेक्शन, ऑथेंटिकेशन विफलताएँ और सॉफ़्टवेयर सप्लाई-चेन विफलताएँ, आदि) और OWASP API Security Top 10 API के लिए, जहाँ ब्रोकन ऑब्जेक्ट-लेवल ऑथराइज़ेशन — एक उपयोगकर्ता का id बदलकर दूसरे का रिकॉर्ड पढ़ना — सबसे आम खोज है। OWASP ASVS इन्हें टेस्ट-योग्य आवश्यकताओं में बदलता है, और WSTG टेस्ट प्रक्रियाओं में।
बेसलाइन का एक उपयोगी हिस्सा बिना किसी विशेष एक्सेस के बाहर से जाँचा जा सकता है। रिस्पॉन्स हेडर दिखाते हैं कि HSTS, Content-Security-Policy, X-Content-Type-Options और फ़्रेम सुरक्षा सेट हैं या नहीं। कुकीज़ दिखाती हैं कि सेशन कुकी में Secure, HttpOnly और SameSite हैं या नहीं। टोकन दिखाते हैं कि एल्गोरिद्म पिन है, एक्सपायरी छोटी है और ऑडियंस जाँची जाती है या नहीं। CORS दिखाता है कि ऑरिजिन पॉलिसी है या वाइल्डकार्ड उसका काम कर रहा है। इनमें से हर एक दस मिनट की जाँच है और हर एक ने असली इंसिडेंट पैदा किए हैं।
- एक्सेस कंट्रोल — हर एंडपॉइंट ग़लत उपयोगकर्ता और ग़लत रोल के वैध टोकन से टेस्ट किया गया।
- इंजेक्शन — SQL, शेल, LDAP या टेम्पलेट तक पहुँचने वाले इनपुट शत्रुतापूर्ण मानों से टेस्ट किए गए; पैरामीटराइज़्ड क्वेरी की पुष्टि।
- ऑथेंटिकेशन और सेशन — पासवर्ड नियम, लॉकआउट, टोकन की आयु, ऐसा लॉगआउट जो सचमुच अमान्य करे।
- कॉन्फ़िगरेशन — सुरक्षा हेडर मौजूद, वर्बोज़ एरर बंद, डिफ़ॉल्ट क्रेडेंशियल हटे, TLS वर्तमान।
- डेटा — व्यक्तिगत डेटा ट्रांज़िट और स्टोरेज में एन्क्रिप्टेड, और लॉग या टेस्ट एनवायरनमेंट में कभी मौजूद नहीं।
आज़माएँ: सिक्योरिटी हेडर एनालाइज़र आज़माएँ: कुकी एनालाइज़र आज़माएँ: API ऑथेंटिकेशन टेस्टर आज़माएँ: JWT डिकोडर आज़माएँ: CORS टेस्टर
मापना: SLO, एरर बजट और क्या रखना है
सर्विस लेवल ऑब्जेक्टिव (SLO) लिखा हुआ लक्ष्य है — "30 दिनों में 99.9% अनुरोध 400 ms के भीतर सफल" — और एरर बजट वह विफलता है जिसकी वह अनुमति देता है। Google की SRE पुस्तक में वर्णित साइट रिलायबिलिटी इंजीनियरिंग प्रैक्टिस इनसे तय करती है कि टीम कब फ़ीचर शिप करे और कब रुककर विश्वसनीयता ठीक करे; वही संख्याएँ हैं जिनके विरुद्ध लॉन्च से पहले परफ़ॉर्मेंस टेस्ट जाँचा जाता है और जिन्हें बाद में मॉनिटरिंग देखती है।
कैशिंग सबसे सस्ता परफ़ॉर्मेंस काम है और सबसे कम टेस्ट किए जाने वालों में से एक। जो रिस्पॉन्स सही Cache-Control और ETag हेडर रखता है, उसे ब्राउज़र और CDN ऑरिजिन को छुए बिना परोसते हैं; जिसमें कुछ नहीं, वह हर बार फ़ेच होता है। सबसे भारी एंडपॉइंट के कैशिंग हेडर जाँचना लोड टेस्ट वाले सेशन का ही हिस्सा है, क्योंकि यह बदलता है कि ऑरिजिन को कौन-सा लोड दिखता है।
- हर रन का वर्कलोड मॉडल, एनवायरनमेंट विवरण और कच्चे परिणाम रखें; संदर्भ के बिना संख्या की अगली तिमाही तुलना नहीं हो सकती।
- CPU पर नहीं, SLO पर अलर्ट करें: उपयोगकर्ता लेटेंसी और एरर महसूस करते हैं, संसाधन ग्राफ़ नहीं।
- इन्फ़्रास्ट्रक्चर, ऑथेंटिकेशन या हॉट पाथ को छूने वाली हर रिलीज़ पर रेज़िलिएंस सूट फिर चलाएँ — सिर्फ़ पहले लॉन्च से पहले नहीं।
आज़माएँ: कैश हेडर एनालाइज़र आज़माएँ: रिस्पॉन्स साइज़ एनालाइज़र
सऊदी अरब में नियामक संदर्भ
किंगडम के संगठनों के लिए रेज़िलिएंस टेस्टिंग अनुपालन गतिविधि भी है। राष्ट्रीय साइबर सुरक्षा प्राधिकरण के आवश्यक साइबर सुरक्षा नियंत्रण (ECC) में दायरे के सिस्टम के लिए वल्नरेबिलिटी मैनेजमेंट, पेनेट्रेशन टेस्टिंग और सुरक्षित कॉन्फ़िगरेशन पर नियंत्रण शामिल हैं, और व्यक्तिगत डेटा संरक्षण क़ानून तय करता है कि व्यक्तिगत डेटा कैसे इस्तेमाल हो सकता है — जो ग्राहक डेटा को लोड-टेस्टिंग डेटासेट में कॉपी करने को ख़ारिज करता है। सही आकार का सिंथेटिक डेटा (सऊदी फ़ोन फ़ॉर्मेट, राष्ट्रीय पते, IBAN) टेस्ट और क़ानून दोनों को संतुष्ट करता है।
- हर रेज़िलिएंस गतिविधि को उस ECC नियंत्रण से जोड़ें जिसका वह प्रमाण है; टेस्ट रिपोर्ट ही प्रमाण है।
- लोड-टेस्ट और सुरक्षा-टेस्ट डेटा जनरेट करें; उसे कभी प्रोडक्शन रिकॉर्ड से न निकालें।
आज़माएँ: सऊदी एड्रेस टेस्ट डेटा आज़माएँ: टेस्ट IBAN जनरेटर आज़माएँ: फ़ेक फ़ोन नंबर जनरेटर
एक पेज में रेज़िलिएंस टेस्ट प्लान
- लक्ष्य: अपेक्षित और पीक लोड पर p95 और p99 लेटेंसी, थ्रूपुट और एरर रेट, टेस्टिंग से पहले लिखे हुए।
- वर्कलोड मॉडल: एंडपॉइंट मिश्रण, डेटा विविधता और कॉन्करेंसी असली ट्रैफ़िक या बिज़नेस पूर्वानुमान से।
- अपेक्षित लोड पर लोड टेस्ट; टूटने के बिंदु तक स्ट्रेस टेस्ट; कम से कम दो घंटे का सोक टेस्ट; शून्य से पीक तक स्पाइक टेस्ट।
- फ़ेल्योर इंजेक्शन: हर महत्वपूर्ण निर्भरता को धीमा, ग़लत और अनुपलब्ध बनाया गया; रिकवरी देखी गई।
- OWASP बेसलाइन: एक्सेस कंट्रोल, इंजेक्शन, ऑथेंटिकेशन और सेशन, हेडर और कुकीज़, CORS, डेटा एक्सपोज़र।
- सबसे भारी एंडपॉइंट पर कैशिंग हेडर सत्यापित।
- परिणाम अपने संदर्भ के साथ रखे गए; SLO और अलर्ट उन्हीं संख्याओं से कॉन्फ़िगर; हर इन्फ़्रास्ट्रक्चर या ऑथेंटिकेशन बदलाव के लिए सूट निर्धारित।
अक्सर पूछे जाने वाले सवाल
लोड टेस्टिंग और स्ट्रेस टेस्टिंग में क्या अंतर है?
लोड टेस्ट अपेक्षित ट्रैफ़िक लागू करता है और जाँचता है कि सिस्टम अपने लक्ष्य पूरे करता है। स्ट्रेस टेस्ट लोड को अपेक्षित पीक से ऊपर तब तक बढ़ाता है जब तक सिस्टम विफल न हो, ताकि सीमा मिले और दिखे कि वह सुरक्षित रूप से विफल होता है — धीमे रिस्पॉन्स और स्पष्ट एरर — या विनाशकारी रूप से। दोनों चाहिए: पहला वादा साबित करता है, दूसरा मार्जिन खोजता है।
हमें कितने वर्चुअल यूज़र चाहिए?
इसे असली संख्याओं से निकालें: एनालिटिक्स से पीक कॉन्करेंट सेशन, या लॉन्च के लिए बिज़नेस पूर्वानुमान, साथ में मार्जिन। JMeter या k6 में एक वर्चुअल यूज़र थिंक-टाइम के साथ लूप में अनुरोध भेजता है, इसलिए "200 वर्चुअल यूज़र" अपने आप में कम अर्थ रखता है; लक्ष्य को एंडपॉइंट-मिश्रण के अनुसार अनुरोध प्रति सेकंड में बताएँ और उस तक पहुँचने के लिए यूज़र तय करें।
क्या सुरक्षा टेस्टिंग के लिए वल्नरेबिलिटी स्कैनर काफ़ी है?
स्कैनर ज्ञात पैटर्न — गुम हेडर, पुराने कंपोनेंट, कुछ इंजेक्शन बिंदु — जल्दी और सस्ते में ढूँढता है, और उसकी जगह पाइपलाइन में है। यह ब्रोकन एक्सेस कंट्रोल नहीं ढूँढता, जो OWASP की दोनों सूचियों में सबसे आम कमज़ोरी है, क्योंकि उसके लिए यह जानना ज़रूरी है कि कौन-सा उपयोगकर्ता कौन-सा रिकॉर्ड देख सकता है। बेसलाइन टेस्टिंग वे जाँचें हाथ से जोड़ती है; पेनेट्रेशन टेस्ट और आगे जाता है।
क्या परफ़ॉर्मेंस टेस्ट प्रोडक्शन पर चलाने चाहिए?
लोड और स्ट्रेस टेस्ट नहीं — वे असली उपयोगकर्ताओं के लिए सेवा घटाते हैं और फ़्रॉड या रेट-लिमिट नियंत्रण ट्रिगर कर सकते हैं। उन्हें प्रोडक्शन जैसे आकार के एनवायरनमेंट पर चलाएँ। रीड-ओनली सिंथेटिक जाँचें (प्रति मिनट एक अनुरोध जो लेटेंसी मापे) प्रोडक्शन में मॉनिटरिंग के रूप में सुरक्षित और उपयोगी हैं।
रेज़िलिएंस टेस्टिंग कितनी बार दोहरानी चाहिए?
पहले लॉन्च से पहले पूरी तरह, फिर हर उस रिलीज़ पर जो इन्फ़्रास्ट्रक्चर, ऑथेंटिकेशन, डेटा एक्सेस या हाई-ट्रैफ़िक पाथ बदले, और एक तय समय-सारणी पर — तिमाही आम है — क्योंकि निर्भरताएँ और ट्रैफ़िक तब भी बदलते हैं जब कोड नहीं बदलता।
संदर्भ
- Apache JMeter User's ManualJMeter से लोड टेस्ट कैसे बनाएँ, पैरामीटराइज़ करें और चलाएँ, और उसके लिसनर व रिपोर्ट कैसे पढ़ें।
- Web VitalsCore Web Vitals (LCP, INP, CLS): वे क्या मापते हैं और अच्छे यूज़र अनुभव की सीमाएँ क्या हैं।
- Release It! Second Edition: Design and Deploy Production-Ready Software (Michael T. Nygard)स्थिरता पैटर्न — टाइमआउट, सर्किट ब्रेकर, बल्कहेड, बैक-प्रेशर — और वे विफलता के तरीके जिन्हें लोड टेस्टिंग खोजने के लिए है।
- Site Reliability Engineering: How Google Runs Production Systemsसर्विस लेवल ऑब्जेक्टिव, एरर बजट, "चार गोल्डन सिग्नल" की निगरानी और ओवरलोड संभालना — लचीलेपन का परिचालन पक्ष।
- OWASP Top 10:2025वेब एप्लिकेशन की दस सबसे गंभीर सुरक्षा जोखिम, हर एक की जाँच और रोकथाम के साथ।
- OWASP API Security Top 10 (2023)API की दस सबसे आम कमज़ोरियाँ: ऑब्जेक्ट-लेवल ऑथराइज़ेशन का टूटना, ऑथेंटिकेशन का टूटना, अनियंत्रित रिसोर्स खपत और अन्य।
- OWASP Application Security Verification Standard (ASVS)वेब एप्लिकेशन के लिए सत्यापन-योग्य सुरक्षा आवश्यकताओं की चेकलिस्ट, तीन एश्योरेंस स्तरों में।
- OWASP Web Security Testing Guide (WSTG)वेब एप्लिकेशन और API की सुरक्षा कमज़ोरियों को परखने की संदर्भ कार्यप्रणाली, एक-एक टेस्ट के रूप में।
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessmentसुरक्षा मूल्यांकन की योजना और संचालन: समीक्षा, टार्गेट पहचान, कमज़ोरी की पुष्टि और रिपोर्टिंग।
- RFC 6585: Additional HTTP Status Codes428, 429 Too Many Requests, 431 और 511 को परिभाषित करता है, रेट लिमिटिंग के लिए Retry-After हेडर सहित।
- National Cybersecurity Authority — Regulatory documents and controls (Essential Cybersecurity Controls)सऊदी राष्ट्रीय साइबर सुरक्षा नियंत्रण जिनके विरुद्ध राज्य के संगठन परीक्षण करते हैं, एप्लिकेशन सुरक्षा और कमज़ोरी प्रबंधन सहित।
- ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelउत्पाद गुणवत्ता मॉडल: कार्यात्मक उपयुक्तता, प्रदर्शन दक्षता, संगतता, इंटरैक्शन क्षमता, विश्वसनीयता, सुरक्षा, रखरखाव-योग्यता और लचीलापन।
अभ्यास
टिकट सेल खुलने से पहले प्लेटफ़ॉर्म की रेज़िलिएंस परखें
आप एक टिकटिंग प्लेटफ़ॉर्म (काल्पनिक) के QA इंजीनियर हैं, जिसकी एक वेब साइट और एक मोबाइल ऐप है। सीज़न के पहले फ़ुटबॉल मैच के टिकट गुरुवार 22 अक्टूबर 2026 को रियाद समय 20:00 बजे बिक्री पर आते हैं, और उसी मिनट हर ऐप यूज़र तक push notification पहुँचता है। आज मंगलवार 13 अक्टूबर है। नीचे के material में पूर्वानुमान और product owner के साथ तय लक्ष्य, एक सहकर्मी का ड्राफ़्ट रेज़िलिएंस प्लान, और staging-perf पर पहले ड्राई रन के नतीजे हैं; staging-perf प्रोडक्शन जैसे आकार का परफ़ॉर्मेंस एनवायरनमेंट है। नतीजों में चार परफ़ॉर्मेंस रन, पेमेंट गेटवे की मॉक के सामने पाँच फ़ेल्योर इंजेक्शन जाँचें, और सुरक्षा बेसलाइन के पाँच अवलोकन हैं।
काग़ज़ पर काम करें और गाइड के एक-पेज प्लान को चेकलिस्ट की तरह इस्तेमाल करें। हर नतीजे के लिए फ़ैसला लिखें (पास, फ़ेल, या लक्ष्यों के विरुद्ध नहीं परखा जाता), साथ में उसके पीछे की संख्या या नियम। S1 में Security Header Analyzer और Cookie Analyzer, और S2 में Unix Timestamp Converter मदद करते हैं। इसके लिए 60–90 मिनट रखें।
Material की सुरक्षा जाँचें प्लेटफ़ॉर्म के अपने staging एनवायरनमेंट पर उसके मालिक की लिखित अनुमति से चलाई गईं। ऐसी जाँचें सिर्फ़ उन्हीं सिस्टम पर चलाएँ जो आपके हैं या जिन्हें टेस्ट करने की आपके पास लिखित अनुमति है।
टिकटिंग प्लेटफ़ॉर्म (काल्पनिक) - वेब साइट और मोबाइल ऐप
सेल: सीज़न का पहला फ़ुटबॉल मैच, गुरुवार 22 अक्टूबर 2026, 20:00-24:00 (रियाद समय)।
20:00 बजे हर ऐप यूज़र तक push notification पहुँचता है। आज: मंगलवार 13 अक्टूबर 2026।
बिज़नेस पूर्वानुमान
सामान्य शाम: 40 अनुरोध प्रति सेकंड (req/s)।
सेल: 20:00 के बाद पहले मिनट से 450 req/s; 21:00 से 24:00 तक 300 req/s।
एंडपॉइंट मिश्रण: seat map 55 %, SMS कोड से sign-in 10 %, seats hold 20 %,
pay 10 %, order status 5 %।
1 अक्टूबर को product owner के साथ तय लक्ष्य
T1 Seat map, GET /api/events/{id}/seatmap: p95 <= 800 ms और p99 <= 1,500 ms
T2 Pay, POST /api/orders/{id}/pay (पेमेंट गेटवे सहित): p95 <= 3,000 ms
T3 एरर रेट 0.1 % से कम (5xx, टाइमआउट, और प्लेटफ़ॉर्म के भेजे 429)
T1-T3 एंडपॉइंट मिश्रण के साथ सेल के पहले मिनट से अंत तक लागू हैं।
ड्राफ़्ट रेज़िलिएंस प्लान v0.1 (एक सहकर्मी का लिखा)
1 लक्ष्य: सेल के दौरान साइट तेज़ रहे और क्रैश न हो।
2 लोड टेस्ट: 200 वर्चुअल यूज़र लूप में GET /api/events/77/seatmap कॉल करें, 10 मिनट।
3 इसे प्रोडक्शन पर 03:00 बजे चलाएँ, जब कोई नहीं ख़रीद रहा, ताकि संख्याएँ असली हों।
4 पास, अगर औसत रिस्पॉन्स टाइम 1 सेकंड से कम हो।
5 टेस्ट डेटा: प्रोडक्शन से पिछले सीज़न के 50,000 ग्राहक एक्सपोर्ट करें।
6 सोक टेस्ट: 15 मिनट।
7 सुरक्षा: सेल से पहले वाली रात वल्नरेबिलिटी स्कैनर चलाएँ।
staging-perf पर ड्राई रन (प्रोडक्शन जैसा आकार, एंडपॉइंट मिश्रण, सिंथेटिक डेटा)
Seat map लेटेंसी और pay p95 ms में; errors सभी अनुरोधों के प्रतिशत के रूप में।
Run Type Load and length avg p50 p95 p99 Pay p95 Errors
R1 load 450 req/s, 30 min 240 180 620 1,350 2,400 0.04 %
R2 spike 40 to 450 req/s in 30 s 520 210 2,900 7,800 5,100 2.1 %
R3 soak 300 req/s, 4 h: hour 1 170 150 540 1,100 2,300 0.02 %
hour 4 410 230 1,450 3,900 4,800 0.9 %
R4 stress 450 req/s, +50 req/s every 5 min until it breaks (नीचे नोट देखें)
एरर के प्रकार: R1 में सभी 503; R2 में 500 और 504।
R2: आँकड़े छलाँग के बाद पहले 5 मिनट के हैं; छठे मिनट से वैल्यू R1 जैसी हैं।
R3: इस्तेमाल में डेटाबेस कनेक्शन पहले घंटे में 200 में से 60,
चौथे घंटे में 200 में से 200।
R4: 800 req/s वाले स्टेप तक errors 0.1 % से नीचे रहते हैं; 850 req/s पर टूटता है,
जहाँ 41 % रिस्पॉन्स 503 हैं (एक सामान्य HTML पेज) और seat map p95 गिरकर 95 ms
हो जाता है। 450 req/s पर लौटने पर 2 मिनट में errors 0.1 % से नीचे, बिना रीस्टार्ट के।
staging-perf पर फ़ेल्योर इंजेक्शन: पेमेंट गेटवे की जगह एक मॉक
F1 मॉक विकृत JSON बॉडी लौटाती है: पेमेंट सर्विस "gateway response invalid" लॉग करती है;
ऐप "Payment failed, you were not charged" दिखाता है; ऑर्डर बिना भुगतान।
F2 मॉक 30 सेकंड बाद जवाब देती है। प्लेटफ़ॉर्म के आगे का API gateway 20 सेकंड पर
टाइमआउट करता है और ऐप "Something went wrong" दिखाता है; पेमेंट सर्विस 60 सेकंड
तक रुकती है, और ऑर्डर अनुरोध के 31 सेकंड बाद "Paid" हो जाता है।
F3 मॉक 503 लौटाती है: पेमेंट सर्विस POST /charges एक साथ 3 बार फिर भेजती है,
बिना idempotency key के। मॉक का लॉग: एक ऑर्डर के लिए 4 charge अनुरोध।
F4 मॉक Retry-After: 30 के साथ 429 लौटाती है। पेमेंट सर्विस 1 सेकंड में 10 बार
रीट्राई करती है, फिर ऐप को 500 Internal Server Error लौटाती है।
F5 मॉक 5 मिनट अनुपलब्ध, फिर वापस: पेमेंट तब तक फ़ेल होते रहते हैं जब तक 25 मिनट
बाद पेमेंट सर्विस रीस्टार्ट नहीं होती।
staging पर सुरक्षा बेसलाइन (प्लेटफ़ॉर्म के मालिक की लिखित अनुमति से)
S1 GET https://staging.tickets.example/ के रिस्पॉन्स हेडर
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
X-Content-Type-Options: nosniff
Set-Cookie: sid=7f3c9a51e2; Path=/; Secure
S2 sign-in के बाद मोबाइल ऐप का एक्सेस टोकन, डिकोड किया हुआ
header {"alg":"HS256","typ":"JWT"}
payload {"sub":"u-1042","role":"customer","iat":1791874800,"exp":1794466800}
S3 ग्राहक u-1042 का टोकन: GET /api/orders/88213 (ग्राहक u-2210 का एक ऑर्डर)
200 OK, उस ग्राहक के नाम, मोबाइल नंबर और सीटों के साथ
S4 Origin: https://unknown-site.example के साथ OPTIONS /api/orders
Access-Control-Allow-Origin: https://unknown-site.example
Access-Control-Allow-Credentials: true
S5 R2 के दौरान 500 रिस्पॉन्स की बॉडी
{"error":"TimeoutError: pool exhausted at /srv/app/db/pool.js:41"}- ड्राफ़्ट प्लान को गाइड से मिलाएँ: हर बिंदु में क्या ग़लत है और क्या छूटा है, लिखें, फिर इसे इस सेल के लिए एक-पेज रेज़िलिएंस प्लान के रूप में दोबारा लिखें।
- R1–R4 को T1–T3 के विरुद्ध, एक-एक लक्ष्य करके परखें, और लिखें कि हर रन संख्याओं के अलावा क्या बताता है। क्या ड्राफ़्ट का पास मानदंड इन समस्याओं को पकड़ पाता?
- F1–F5 में से हर एक के लिए तय करें कि व्यवहार स्वीकार्य है या नहीं; अगर नहीं, तो गाइड का वह स्थिरता नियम बताएँ जो टूटता है, और अपेक्षित व्यवहार लिखें।
- S1–S5 में से हर एक के लिए finding, OWASP बेसलाइन का वह हिस्सा जिससे वह जुड़ी है, और expected result लिखें। फिर बेसलाइन की वे जाँचें लिखें जो material में अभी नहीं हैं।
- Release manager के लिए go/no-go नोट लिखें: सेल से पहले क्या ठीक करके दोबारा टेस्ट करना ज़रूरी है, और क्या ठीक करना है, फ़िक्स के बाद क्या फिर चलाना है, और इन रनों से क्या सँभालकर रखना है।
मॉडल उत्तर दिखाएँ
ड्राफ़्ट प्लान, बिंदु दर बिंदु। 1: "तेज़" और "क्रैश न हो" लक्ष्य नहीं हैं; टेस्ट चलने से पहले संख्या चाहिए, और T1–T3 पहले से percentiles, लोड और एरर रेट देते हैं। 2: लूप में एक एंडपॉइंट वर्कलोड मॉडल नहीं है; यहाँ वर्कलोड मॉडल तय एंडपॉइंट मिश्रण के साथ 450 req/s है। "200 वर्चुअल यूज़र" अपने आप में कम बताता है, क्योंकि वर्चुअल यूज़र अनुरोधों के बीच थिंक-टाइम तक रुकता है: लोड को req/s में लिखें और वर्चुअल यूज़र तब तक बढ़ाएँ जब तक टूल वहाँ न पहुँच जाए। 3: लोड टेस्ट प्रोडक्शन पर नहीं चलते, न 03:00 बजे, न किसी और समय: वे असली ग्राहकों के लिए सेवा घटाते हैं और फ़्रॉड या रेट-लिमिट नियंत्रण ट्रिगर कर सकते हैं, पेमेंट गेटवे के नियंत्रण भी। staging-perf इस्तेमाल करें; प्रोडक्शन में सिर्फ़ रीड-ओनली सिंथेटिक जाँचें, मॉनिटरिंग के रूप में। 4: औसत धीमी पूँछ छिपा देता है; p50, p95 और p99 दर्ज करें, और एरर रेट व एरर का प्रकार अलग-अलग। 5: 50,000 असली ग्राहकों की कॉपी व्यक्तिगत डेटा संरक्षण क़ानून और गाइड के नियम, दोनों को तोड़ती है; सही आकार का सिंथेटिक डेटा जनरेट करें (नाम, सऊदी मोबाइल नंबर, कई अलग accounts और सीट चुनाव, कुछ अमान्य अनुरोध)। 6: 15 मिनट का सोक टेस्ट ऐसा कुछ नहीं देखता जो लोड टेस्ट न देखे; सेल चार घंटे चलती है, इसलिए सोक टेस्ट 300 req/s पर कम से कम चार घंटे चले। 7: स्कैनर ज्ञात पैटर्न ढूँढता है, ब्रोकन एक्सेस कंट्रोल नहीं, और सेल से पहले की रात कुछ ठीक करने का समय नहीं छोड़ती; उसकी जगह अभी से पाइपलाइन में है, हाथ से की जाने वाली बेसलाइन जाँचों के साथ।
पूरी तरह छूटा हुआ: स्पाइक टेस्ट, जबकि push notification प्लेटफ़ॉर्म को सेकंडों में लगभग 40 से 450 req/s पर ले जाता है; मार्जिन खोजने वाला स्ट्रेस टेस्ट; पेमेंट गेटवे और SMS प्रोवाइडर पर फ़ेल्योर इंजेक्शन; कैशिंग की जाँच; और नतीजे रखने का नियम। इस सेल के लिए एक-पेज प्लान। लक्ष्य: एंडपॉइंट मिश्रण के साथ 450 req/s और 300 req/s पर T1–T3, पूरी सेल में 20:00 से 24:00 तक, टेस्टिंग से पहले लिखे हुए। वर्कलोड मॉडल: पूर्वानुमान वाला मिश्रण, सिंथेटिक यूज़र और टोकन, पूरे स्टेडियम में फैले seat holds जिनमें एक ही सीटों के लिए होड़ भी हो, और कुछ हिस्सा अमान्य अनुरोधों का। staging-perf पर रन: 450 req/s पर 30 मिनट का लोड टेस्ट; एक मिनट से कम में 40 से 450 req/s का स्पाइक टेस्ट; 450 req/s से टूटने के बिंदु तक स्ट्रेस टेस्ट; 300 req/s पर कम से कम चार घंटे का सोक टेस्ट। फ़ेल्योर इंजेक्शन: पेमेंट गेटवे और SMS प्रोवाइडर, दोनों में से हर एक को धीमा, ग़लत (विकृत बॉडी, 500, 503, Retry-After के साथ 429) और अनुपलब्ध बनाया जाए, और रिकवरी देखी जाए। OWASP बेसलाइन: ग़लत उपयोगकर्ता और ग़लत रोल के वैध टोकन से एक्सेस कंट्रोल, इंजेक्शन, sign-in और सेशन, हेडर और कुकीज़, टोकन, CORS, वर्बोज़ एरर, लॉग में व्यक्तिगत डेटा। कैशिंग: सबसे भारी रिस्पॉन्स (इवेंट पेज, इमेज, सीटों का लेआउट) पर Cache-Control और ETag, हर एक की ज़रूरी ताज़गी के हिसाब से जाँचे हुए। रिकॉर्ड: हर रन का वर्कलोड मॉडल, एनवायरनमेंट विवरण और कच्चे परिणाम; T1–T3 से कॉन्फ़िगर SLO अलर्ट; इन्फ़्रास्ट्रक्चर, ऑथेंटिकेशन या सेल पाथ को छूने वाली हर रिलीज़ पर सूट फिर चले।
R1: पास। Seat map p95 620 ≤ 800 और p99 1,350 ≤ 1,500 (T1), pay p95 2,400 ≤ 3,000 (T2), errors 0.04 % < 0.1 % (T3): स्थिर पीक पर प्लेटफ़ॉर्म अपना वादा निभाता है। R2: तीनों लक्ष्यों पर फ़ेल। Seat map p95 2,900 और p99 7,800, जबकि सीमा 800 और 1,500 है; pay p95 5,100, जबकि सीमा 3,000 है; errors 2.1 %, जबकि सीमा 0.1 % है। T1–T3 पहले मिनट से लागू हैं, और notification पहले मिनटों को स्पाइक बना देता है, इसलिए सेल की शुरुआत R2 जैसी ही दिखेगी: यह लॉन्च रोकता है। छठे मिनट से वैल्यू R1 जैसी हो जाती हैं, यानी प्लेटफ़ॉर्म संभल जाता है, पर सबसे पहले आने वाले ख़रीदारों के लिए बहुत देर से। ड्राफ़्ट का मानदंड इस रन को पास कर देता: 520 ms का औसत 1 सेकंड से कम है, जबकि हर बीस में से एक अनुरोध 2.9 सेकंड या उससे ज़्यादा लेता है।
R3: पहले घंटे में पास, चौथे घंटे में फ़ेल। Seat map p95 1,450 और p99 3,900, pay p95 4,800 और errors 0.9 % सब अपने लक्ष्य तोड़ते हैं, जबकि लोड नहीं बदला, और इस्तेमाल में डेटाबेस कनेक्शन 60 से बढ़कर पूल की अधिकतम सीमा 200 तक पहुँच जाते हैं। यह उन कनेक्शनों का पैटर्न है जो लिए जाते हैं पर लौटाए नहीं जाते, और इसे सिर्फ़ घंटों चलने वाला टेस्ट दिखाता है। यह भी लॉन्च रोकता है, क्योंकि सेल चार घंटे चलती है; ड्राफ़्ट का 15 मिनट का सोक टेस्ट और उसका औसत वाला मानदंड (चौथे घंटे में 410 ms) दोनों इसे चूक जाते। R4: T1–T3 के विरुद्ध नहीं परखा जाता, क्योंकि लोड लक्ष्य से ऊपर है; स्ट्रेस टेस्ट दो दूसरे सवालों का जवाब देता है। सीमा कहाँ है? 800 req/s तक errors 0.1 % से नीचे रहते हैं और 850 पर उछल जाते हैं, इसलिए सीमा इन दोनों के बीच है; आख़िरी टिका हुआ स्टेप, 800 req/s, यानी पूर्वानुमानित पीक का क़रीब 1.8 गुना, मार्जिन के रूप में दर्ज करें। विफल कैसे होता है? बुरी तरह: 50 req/s का एक स्टेप errors को 0.1 % से नीचे से 41 % तक ले जाता है, जबकि लोड सिर्फ़ लगभग 6 % बढ़ा; यानी सिस्टम धीरे और सुरक्षित रूप से नहीं, एक साथ विफल होता है। अच्छा आधा यह है कि वह 2 मिनट में बिना रीस्टार्ट के अपने आप उबर जाता है। 95 ms का p95 भी अच्छा परफ़ॉर्मेंस नहीं है: वह सिर्फ़ इसलिए कम है क्योंकि 41 % जवाब तेज़ एरर हैं, और जो सिस्टम एरर लौटाकर तेज़ बना रहे, वह पास नहीं हुआ। API के लिए सामान्य HTML पेज भी ग़लत जवाब है; अपेक्षित है एक स्पष्ट 503 जिसे ऐप दिखा सके, Retry-After हेडर के साथ (RFC 9110 इसे 503 के साथ अनुमति देता है), और ऐसे errors जो उछलने के बजाय अतिरिक्त लोड के हिसाब से बढ़ें।
F1: स्वीकार्य। विकृत जवाब से एक विशिष्ट, लॉग किया गया एरर, स्पष्ट संदेश और बिना भुगतान वाला ऑर्डर मिलता है। F2: फ़ेल। पेमेंट सर्विस गेटवे के लिए 60 सेकंड तक रुकती है, यानी अपने ही कॉलर, API gateway (20 सेकंड), से ज़्यादा; इसलिए ग्राहक को एरर दिखता है जबकि भुगतान 11 सेकंड बाद हो जाता है, और वह दोबारा भुगतान कर सकता है। अपेक्षित: आउटबाउंड टाइमआउट 20 सेकंड से साफ़ कम; और जब नतीजा पता न हो, तो ऑर्डर बताए कि भुगतान की पुष्टि हो रही है, और ऐप दोबारा भुगतान का विकल्प देने के बजाय ऑर्डर का status जाँचे। F3: फ़ेल, और यह लॉन्च रोकता है। एक नॉन-आइडेम्पोटेंट अनुरोध आँख मूँदकर दोहराया जाता है, एक साथ तीन बार और बिना बैकऑफ़; असली गेटवे के साथ, जो charge हो चुका हो पर जिसका जवाब खो गया या देर से आया, वह फिर से charge होगा। अपेक्षित: POST /charges का कोई स्वचालित रीट्राई नहीं, या बैकऑफ़ के साथ सीमित रीट्राई, वह भी सिर्फ़ ऐसी idempotency key के साथ जिसे गेटवे सपोर्ट करे। F4: फ़ेल। एक सेकंड में दस रीट्राई Retry-After: 30 को अनदेखा करते हैं; RFC 6585 429 को परिभाषित करता है और सर्वर को बताने देता है कि कब लौटना है, और तुरंत रीट्राई उस गेटवे पर लोड बढ़ाता है जिसने अभी कम लोड माँगा है। फिर ऐप को सामान्य 500 मिलता है। अपेक्षित: Retry-After के समय से पहले कोई नया अनुरोध नहीं, और ऐसा विशिष्ट एरर जिसे ऐप दिखा सके, जैसे कि भुगतान व्यस्त है और ग्राहक 30 सेकंड बाद फिर कोशिश कर सकता है। F5: फ़ेल, क्योंकि रिकवरी स्वचालित नहीं है। अपेक्षित: गेटवे लौटते ही भुगतान बिना रीस्टार्ट के फिर चलें, और यही वह सर्किट ब्रेकर देता है जो कुछ देर रुककर निर्भरता को फिर आज़माता है। अभी टेस्ट नहीं हुआ: SMS प्रोवाइडर के लिए यही जाँचें; कोड के बिना कोई sign-in नहीं कर सकता।
S1: X-Content-Type-Options: nosniff और कुकी का Secure attribute सही हैं। गुम (कॉन्फ़िगरेशन): Strict-Transport-Security, Content-Security-Policy और फ़्रेम सुरक्षा (X-Frame-Options या CSP का frame-ancestors directive)। सेशन कुकी में HttpOnly नहीं है, इसलिए पेज पर चलने वाली कोई भी स्क्रिप्ट उसे पढ़ सकती है, cross-site scripting (XSS) defect से डाली गई स्क्रिप्ट भी; और SameSite भी नहीं है (सेशन)। दोनों को स्पष्ट रूप से सेट करें, ब्राउज़र के डिफ़ॉल्ट पर भरोसा न करें, क्योंकि वे अलग-अलग होते हैं। S2 (ऑथेंटिकेशन और सेशन, टोकन की आयु): exp - iat = 2,592,000 सेकंड, यानी 30 दिन, 13 अक्टूबर से 12 नवंबर 2026, 07:00 UTC तक। लीक हुआ एक्सेस टोकन एक महीने तक काम करेगा; अपेक्षित है टीम के साथ तय छोटी आयु, मिनटों में, जिसे refresh token से नया किया जाए। aud claim नहीं है, इसलिए कोई API नहीं जाँच सकता कि टोकन उसी के लिए जारी हुआ था। टोकन से यह नहीं दिखता कि सर्वर एल्गोरिद्म पिन करता है या नहीं: staging पर ऐसे टोकन से टेस्ट करें जिसके हेडर में none लिखा हो और जिसका कोई signature न हो; अपेक्षित 401।
S3 (एक्सेस कंट्रोल): ब्रोकन ऑब्जेक्ट-लेवल ऑथराइज़ेशन, यानी OWASP API Security Top 10 में API1:2023, और OWASP Top 10 में ब्रोकन एक्सेस कंट्रोल। एक ग्राहक id बदलकर दूसरे ग्राहक का व्यक्तिगत डेटा पढ़ लेता है। Severity: Critical; यह लॉन्च रोकता है। अपेक्षित: जो ऑर्डर कॉलर का नहीं है उसके लिए 403 या 404। यह जाँच id लेने वाले हर एंडपॉइंट पर दोहराएँ (orders, tickets, seat holds), और ग़लत रोल के साथ भी, यानी स्टाफ़ एंडपॉइंट पर ग्राहक का टोकन; स्कैनर इसे नहीं ढूँढता। S4 (CORS): API कोई भी ऑरिजिन वापस लौटा देता है और credentials की अनुमति देता है, इसलिए ऑरिजिन पॉलिसी कुछ नहीं करती। यह वाइल्डकार्ड से भी बुरा है: ब्राउज़र credentials के साथ * को ठुकराते हैं, पर लौटाया गया ऑरिजिन मान लेते हैं। अपेक्षित: प्लेटफ़ॉर्म के अपने ऑरिजिन की allow-list, और किसी और ऑरिजिन के लिए कोई Access-Control-Allow-Origin नहीं। S5 (कॉन्फ़िगरेशन): वर्बोज़ एरर चालू हैं, और फ़ाइल पाथ वाला exception किसी को भी बता देता है कि सिस्टम कैसे बना है। अपेक्षित: correlation id के साथ सामान्य एरर बॉडी, और विवरण सिर्फ़ लॉग में। यह R2 और R3 का सुराग भी है: डेटाबेस कनेक्शन पूल स्पाइक में ख़त्म हो जाता है और सोक के दौरान धीरे-धीरे खाली होता जाता है। अभी कवर नहीं: डेटाबेस तक पहुँचने वाले हर इनपुट पर इंजेक्शन; SMS कोड की कोशिशों और दोबारा भेजने की सीमा; ऐसा लॉगआउट जो सेशन और टोकन को सचमुच अमान्य करे; TLS कॉन्फ़िगरेशन; लॉग में व्यक्तिगत डेटा।
Release manager के लिए नोट। फ़ैसला: जिस हालत में टेस्ट हुआ, उसमें सेल के लिए no-go। 22 अक्टूबर से पहले ठीक करके दोबारा टेस्ट करना ज़रूरी: R2 (शुरुआती मिनट हर लक्ष्य तोड़ते हैं), R3 (चौथे घंटे तक कनेक्शन ख़त्म हो जाते हैं), F2 और F3 (ग्राहकों से दो बार पैसा कट सकता है), F5 (रीस्टार्ट के बिना रिकवरी नहीं) और S3 (ग्राहक एक-दूसरे के ऑर्डर पढ़ सकते हैं)। सेल से पहले ये भी ठीक करें, हर एक की जल्दी दोबारा जाँच के साथ: F4, S1, S2, S4, S5 और R4 में दिखा ओवरलोड रिस्पॉन्स। सेल से पहले अभी चलाना बाक़ी: SMS प्रोवाइडर पर फ़ेल्योर इंजेक्शन, और बेसलाइन की वे जाँचें जो अभी कवर नहीं हुईं। फ़िक्स के बाद: हर फ़ेल बिंदु की confirmation testing, चार घंटे के पूरे सोक टेस्ट समेत; उसी वर्कलोड के साथ R1 फिर से, regression test के रूप में, क्योंकि फ़िक्स सेल पाथ को छूते हैं और तुलना ईमानदार होनी चाहिए; और नया मार्जिन दर्ज करने के लिए R4 फिर से। वर्कलोड मॉडल, staging-perf का विवरण और R1–R4 के कच्चे परिणाम नोट के साथ रखें, सेल की शाम के अलर्ट T1–T3 पर सेट करें, और अगर प्लेटफ़ॉर्म राष्ट्रीय साइबर सुरक्षा प्राधिकरण के आवश्यक साइबर सुरक्षा नियंत्रण (ECC) के दायरे में है, तो रिपोर्ट को संबंधित नियंत्रणों के प्रमाण के रूप में रखें।
अपना काम जाँचने के लिए: R1 अकेला रन है जो पास होता है, और R4 अकेला रन जिसे लक्ष्यों के विरुद्ध नहीं परखा जाता; F1–F5 में सिर्फ़ F1 स्वीकार्य है, और S1–S5 में सिर्फ़ nosniff हेडर और कुकी का Secure attribute सही हैं। अगर आपने R2 या R3 को इसलिए पास किया कि औसत एक सेकंड से कम रहा, तो गाइड में percentiles वाला बिंदु फिर पढ़ें; अगर R4 के 95 ms को अच्छी ख़बर माना, तो एरर लौटाकर तेज़ बने रहने वाले सिस्टम वाला बिंदु फिर पढ़ें। Blockers और बाक़ी फ़िक्स के बीच अलग बँटवारा ठीक है, अगर हर फ़ैसले का कारण दर्ज हो; बिना संख्या या नियम वाला फ़ैसला ठीक नहीं।
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।
QA रोडमैप का हिस्सा
इस गाइड में बताए गए टूल्स
k6, JMeter, Gatling और Locust लोड टेस्ट के लिए बड़े पैरामीटर डेटासेट (users, token, id, payload) बनाएँ।
फ़ील्ड स्कीमा से JMeter के लिए तैयार टेस्ट डेटा बनाएँ (CSV Data Set Config फ़ाइलें और User Defined Variables)।
JMeter CSV Data Set Config के लिए सही quoting, delimiter और encoding वाली CSV फ़ाइलें बनाएँ।
किसी लक्षित endpoint के लिए सुरक्षित डिफ़ॉल्ट वाली concurrency टेस्ट स्क्रिप्ट बनाएँ (k6, JMeter JMX, Locust, Artillery, Node.js)।
किसी सार्वजनिक endpoint पर छोटा, सुरक्षित बेंचमार्क चलाएँ (सीमित रिक्वेस्ट व concurrency) और throughput तथा latency percentile पाएँ।
किसी endpoint का रिस्पॉन्स टाइम कई सैंपल पर मापें: न्यूनतम, अधिकतम, औसत, माध्यिका और p95।
दो endpoint के रिस्पॉन्स टाइम और साइज़ की आमने-सामने तुलना करें (जैसे v1 बनाम v2, staging बनाम production)।
रिस्पॉन्स साइज़ का विश्लेषण: कच्चे बनाम compressed बाइट, हेडर का साइज़, JSON ढाँचे का भार और सबसे बड़े फ़ील्ड।
ऐसा सार्वजनिक endpoint पाएँ जो कोई भी HTTP स्टेटस कोड लौटाए, वैकल्पिक देरी और कस्टम JSON बॉडी के साथ, ताकि क्लाइंट की error हैंडलिंग टेस्ट हो सके।
लोकप्रिय फ़ॉर्मेट में संरचित एरर रिस्पॉन्स बनाएँ (validation, auth, not found, rate limit, सर्वर एरर)।
पेस्ट किए गए हेडर या किसी सार्वजनिक URL से HTTP सुरक्षा हेडर (CSP, HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy, COOP/CORP) को ग्रेड दें।
Set-Cookie हेडर पार्स करें और Secure, HttpOnly, SameSite, Domain, Path, एक्सपायरी तथा साइज़ की सर्वोत्तम प्रथाएँ जाँचें।
किसी endpoint पर Bearer, Basic, API-key और कस्टम-हेडर प्रमाणीकरण टेस्ट करें और अधिकृत बनाम अनधिकृत रिस्पॉन्स की तुलना करें।
JWT का हेडर और पेलोड डिकोड करें, क्लेम जाँचें और एक्सपायरी देखें — पूरी तरह आपके ब्राउज़र में।
CORS कॉन्फ़िगरेशन जाँचें: किसी origin से preflight और सामान्य रिक्वेस्ट भेजकर Access-Control-* हेडर देखें।
Cache-Control, Expires, ETag, Last-Modified, Vary और Age हेडर जाँचें और समझें कि ब्राउज़र तथा CDN रिस्पॉन्स को कैसे कैश करेंगे।