परफ़ॉर्मेंस और सिक्योरिटी टेस्टिंग सेवाएँ

परफ़ॉर्मेंस टेस्टिंग: लोड, स्ट्रेस और सोक

परफ़ॉर्मेंस टेस्टिंग सेवा तभी काम की है जब हर रन ऐसे सवाल का जवाब दे जिस पर कोई फ़ैसला लिया जाएगा। लोड, स्ट्रेस और सोक टेस्ट अलग-अलग सवालों का जवाब देते हैं, इसलिए टेस्ट रणनीति तय करती है कि आपकी रिलीज़ को इनमें से किनकी ज़रूरत है और हर एक को क्या दिखाना है। तीनों Apache JMeter से चलाए जाते हैं। वर्कलोड मॉडल आमतौर पर आपके एनालिटिक्स या बिज़नेस पूर्वानुमान से आता है: कौन-से एंडपॉइंट, किस मिश्रण में, किस डेटा के साथ, कितनी कॉन्करेंसी पर।

जब कोई संख्या अपना लक्ष्य चूक जाए, तो वह संख्या अभी निष्कर्ष नहीं है। बॉटलनेक विश्लेषण धीमी रिक्वेस्ट को उनके पीछे की सर्विसेज़ और डेटाबेस तक ले जाता है — क्या थ्रूपुट सपाट रहते हुए लेटेंसी बढ़ रही है (CPU या कनेक्शन पूल जैसा कोई संसाधन भर गया), क्या धीमेपन से पहले एरर आ रहे हैं (कोई कठोर सीमा), और कौन-सी क्वेरी कॉन्करेंसी में धीमी होती है — ताकि निष्कर्ष सिर्फ़ लक्षण नहीं, कारण भी बता सके।

• लोड टेस्ट — क्या अपेक्षित ट्रैफ़िक पर उत्पाद अपने लक्ष्य पूरे करता है? सामान्य और पीक स्तर पर अपेक्षित वर्कलोड, आपके तय किए लक्ष्यों से तुलना के साथ।
• स्ट्रेस टेस्ट — सीमा कहाँ है, और सिस्टम कैसे फ़ेल होता है? लोड अपेक्षित पीक से ऊपर तब तक बढ़ाया जाता है जब तक एरर या टाइमआउट न दिखें, यह देखने के लिए कि सिस्टम स्पष्ट एरर के साथ धीमा पड़ता है और अपने आप उबरता है, या क्रैश होकर रीस्टार्ट माँगता है।
• सोक टेस्ट — क्या सिस्टम घंटों तक ठीक रहता है? कई घंटों तक यथार्थ लोड बनाए रखने से मेमोरी लीक, कनेक्शन पूल का ख़त्म होना, और ऐसी टेबल या क़तारें सामने आती हैं जो बढ़ते-बढ़ते सब कुछ धीमा कर देती हैं।
• मेट्रिक्स — लेटेंसी, थ्रूपुट और एरर रेट। लेटेंसी आमतौर पर परसेंटाइल में पढ़ी जाती है (औसत नहीं, p50, p95 और p99, क्योंकि औसत धीमी पूँछ छिपा देता है), हर एंडपॉइंट के लिए अलग — ताकि तेज़ होम पेज धीमे checkout को छिपा न सके।

Pass/fail मानदंड: रन से पहले थ्रेशोल्ड तय करें

तय थ्रेशोल्ड के बिना टेस्ट मापता तो है, पर पास या फ़ेल नहीं हो सकता। थ्रेशोल्ड पहले रन से पहले तय होने चाहिए — किसी वर्कलोड और समय-खिड़की से जुड़ी संख्याओं के रूप में; आपके लोड टेस्ट जो भी चलाए, उससे इन्हें माँगें। तालिका एक काल्पनिक दुकान Bustan Market के checkout का उदाहरण भर है — आपके मान आपके अपने ट्रैफ़िक, जर्नी और प्रतिबद्धताओं से आते हैं, इस पेज से नहीं।

रिस्पॉन्स टाइम कैसे मापा जाता है, यह सीमा जितना ही अहम है। हर रिक्वेस्ट के लिए JMeter elapsed time दर्ज करता है — रिक्वेस्ट भेजने से ठीक पहले से लेकर रिस्पॉन्स का आख़िरी हिस्सा आने के ठीक बाद तक; इसमें ब्राउज़र रेंडरिंग या JavaScript शामिल नहीं होते। फिर ये समय परसेंटाइल में समेटे जाते हैं — JMeter का HTML डैशबोर्ड डिफ़ॉल्ट रूप से 90वाँ, 95वाँ और 99वाँ परसेंटाइल दिखाता है — थ्रूपुट और एरर रेट के साथ। उपयोगी मानदंड यह भी बताते हैं कि कौन-सी खिड़की गिनी जाएगी (आमतौर पर रैम्प-अप के बाद की स्टेडी स्टेट), एरर किसे माना जाएगा (5xx रिस्पॉन्स, टाइमआउट, और ऐसे 200 रिस्पॉन्स जिनकी बॉडी में एरर हो और assertion उसे पकड़े), और कब रन पास नहीं बल्कि अमान्य है: लोड जनरेटर ख़ुद भर गया, रन के बीच बिल्ड बदल गया, या एनवायरनमेंट वह नहीं था जो तय हुआ था।

सिक्योरिटी टेस्टिंग: वेब ऐप और API में आम OWASP कमज़ोरियाँ

सिक्योरिटी वाला हिस्सा आपके वेब ऐप और उसके API में उन आम कमज़ोरियों की जाँच करता है जो OWASP की दो सूचियों में दर्ज हैं: वेब एप्लिकेशन के लिए OWASP Top 10:2025 और API के लिए OWASP API Security Top 10 (2023 संस्करण)। जाँचें तय एनवायरनमेंट पर चलती हैं; एक्सेस-कंट्रोल जाँचों के लिए हर रोल के टेस्ट अकाउंट चाहिए। दोनों सूचियाँ संदर्भ हैं, टिक करने की चेकलिस्ट नहीं: OWASP Web Security Testing Guide (WSTG) बताती है कि हर कमज़ोरी कैसे टेस्ट होती है, और Application Security Verification Standard (ASVS) टेस्ट-योग्य आवश्यकताएँ देता है — दोनों आपकी टीम के काम आते हैं जब वह सुधार और उसका अपना रिग्रेशन टेस्ट लिखती है।

इस सेवा में ऑथेंटिकेशन, ऑथराइज़ेशन और इनपुट हैंडलिंग की समीक्षा होती है। यहीं दोनों सूचियाँ मिलती हैं, और यहीं ऑटोमेटेड स्कैनर सबसे कमज़ोर हैं: स्कैनर नहीं जानता कि ग्राहक A को ग्राहक B का ऑर्डर नहीं पढ़ना चाहिए। कुछ श्रेणियाँ — जैसे Software Supply Chain Failures (A03:2025) और Insecure Design (A06:2025) — बाहर से केवल आंशिक रूप से दिखती हैं, और अकेली टेस्टिंग उन्हें ख़ारिज नहीं कर सकती।

स्कोप की सीमा: यह सेवा क्या दावा नहीं करती

यह आम कमज़ोरियों की टेस्टिंग और मापी गई परफ़ॉर्मेंस है, हर निष्कर्ष के पीछे प्रमाण के साथ। यह क्या नहीं है, इस पर सटीक रहना उपयोगी है, ताकि आप बाक़ी ज़रूरतों की योजना बना सकें।

• यह सर्टिफ़ाइड पेनेट्रेशन टेस्ट या अनुपालन प्रमाणन (compliance attestation) नहीं है। रिपोर्ट टेस्ट का प्रमाण है: यह किसी नियम या मानक के अनुपालन को प्रमाणित नहीं करती। अगर किसी ऑडिटर, नियामक या ग्राहक अनुबंध को इनमें से कुछ चाहिए, तो उसकी अलग योजना बनाएँ; इस काम के निष्कर्ष और री-टेस्ट परिणाम तब भी उपयोगी इनपुट रहते हैं।
• मोबाइल ऐप: मोबाइल ऐप जिन API को कॉल करता है वे स्कोप में हैं और उन पर वही जाँचें होती हैं जो किसी भी दूसरे API पर। ऐप पैकेज ख़ुद — डिवाइस पर रखा डेटा, प्लेटफ़ॉर्म से इंटरैक्शन, रिवर्स इंजीनियरिंग और छेड़छाड़ से बचाव, यानी वे क्षेत्र जो OWASP MASVS परिभाषित करता है — यहाँ बताई गई इस सेवा का हिस्सा नहीं है।
• यह डिनायल-ऑफ़-सर्विस अभ्यास नहीं है। स्ट्रेस टेस्ट एक लोड जनरेटर के नियंत्रित लोड से आपके सिस्टम की क्षमता-सीमा खोजता है; यह किसी डिस्ट्रिब्यूटेड हमले का सिमुलेशन नहीं है।
• थर्ड-पार्टी सेवाओं — पेमेंट गेटवे, SMS प्रदाता, राष्ट्रीय इंटीग्रेशन — पर उनके मालिक की अनुमति के बिना टेस्ट लोड नहीं जाना चाहिए। आपके लिए जो भी टेस्ट करे, सुनिश्चित करें कि स्कोप में लिखा हो कि हर एक को stub से बदला जाएगा या उसके sandbox से कॉल किया जाएगा।
• प्रोडक्शन: टेस्टिंग टेस्ट या स्टेजिंग एनवायरनमेंट पर होती है। प्रोडक्शन पर कुछ भी चलाना आपका निर्णय है; अगर आप यह तय करें, तो टार्गेट, दर, समय-खिड़की और रोकने की शर्तें पहले स्पष्ट रूप से तय करें (FAQ देखें)।

काम कैसे चलता है

काम उन्हीं छह चरणों से चलता है जिनसे मुतक़न सॉफ्ट का हर प्रोजेक्ट चलता है, परफ़ॉर्मेंस और सिक्योरिटी के अनुसार ढाले हुए। आउटपुट के बिना कोई चरण बंद नहीं होता।

जो इंजीनियर टेस्ट चलाता है वही निष्कर्ष लिखता है और सुधार का सत्यापन करता है, इसलिए समस्या ढूँढने वाले और उसके हटने की पुष्टि करने वाले के बीच कुछ छूटता नहीं।

आपको क्या मिलता है

निष्कर्ष उसी ट्रैकर में पहुँचते हैं जो आपकी टीम पहले से इस्तेमाल करती है, और टेस्ट दस्तावेज़ व रिपोर्ट अरबी या अंग्रेज़ी में होते हैं — जो भी आपकी टीम उपयोग करती है। तालिका एक परफ़ॉर्मेंस निष्कर्ष का ढाँचा दिखाती है, ऊपर वाले उसी काल्पनिक checkout पर।

• लेटेंसी, थ्रूपुट और एरर-रेट मेट्रिक्स — आमतौर पर हर एंडपॉइंट और हर रन के परसेंटाइल के रूप में। आपके लिए जो भी मापे, उससे हर संख्या उस वर्कलोड और एनवायरनमेंट के साथ माँगें जिसमें वह मापी गई; उनके बिना अगली बार तुलना नहीं हो सकती।
• गंभीरता के अनुसार क्रमबद्ध निष्कर्ष, हर एक के साथ पुनरुत्पादन चरण, एनवायरनमेंट और प्रमाण (रिक्वेस्ट, रिस्पॉन्स, टाइमिंग या रिकॉर्डिंग)। क्रिटिकल निष्कर्ष की रिपोर्ट तुरंत होती है, अंतिम रिपोर्ट तक रोकी नहीं जाती।
• सुधार की सिफ़ारिशें: क्या और कहाँ बदलना है — कोई इंडेक्स, कनेक्शन पूल का आकार, गुम ओनरशिप जाँच, कोई हेडर।
• सुधारों के बाद पुनः मापन (आमतौर पर उसी वर्कलोड से, ताकि तुलना ईमानदार रहे), और हर सुधार की दोबारा जाँच।
• एक्ज़ीक्यूशन लॉग और लिखित रिलीज़ निर्णय: क्या टेस्ट हुआ, क्या खुला रह गया, और कौन-से जोखिम स्वीकार किए गए।

हमें आपसे क्या चाहिए

प्रोडक्ट, स्टैक और रिलीज़ की तारीख़ — बातचीत शुरू करने के लिए इतना काफ़ी है। टेस्ट चलाने के लिए ये चीज़ें तैयार होनी चाहिए:

• एनवायरनमेंट: टेस्ट या स्टेजिंग एनवायरनमेंट, आकार और कॉन्फ़िगरेशन में जितना हो सके प्रोडक्शन जैसा; जहाँ अंतर हो, वह रिपोर्ट में लिखा जाता है ताकि संख्याएँ सही पढ़ी जाएँ। और ऐसा बिल्ड जो रन के दौरान न बदले।
• ट्रैफ़िक और तारीख़ें: अपेक्षित पीक उपयोगकर्ता या रिक्वेस्ट प्रति सेकंड, मुख्य जर्नी, रिलीज़ की तारीख़ और कोई भी मौसमी पीक — या एनालिटिक्स जिनसे ये निकाले जा सकें।
• पर्याप्त मात्रा में टेस्ट डेटा: सिंथेटिक अकाउंट (एक्सेस-कंट्रोल जाँचों के लिए हर रोल के कम से कम दो), और यथार्थ आकार तक भरा डेटाबेस — असली ग्राहक रिकॉर्ड की प्रतियाँ नहीं।
• एक्सेस: API कॉन्ट्रैक्ट (OpenAPI या Postman कलेक्शन), टेस्ट अकाउंट, और रन के दौरान मॉनिटरिंग, लॉग या डेटाबेस मेट्रिक्स का रीड एक्सेस। रिपॉज़िटरी एक्सेस मूल-कारण विश्लेषण में मदद करता है, पर ज़रूरी नहीं।
• स्पष्ट अनुमति: किसी भी प्रदाता के साथ यह लिख लेना उचित है कि कौन-से होस्ट और एंडपॉइंट लोड और सिक्योरिटी टेस्ट के स्कोप में हैं और वे कब चल सकते हैं, और जाँच लें कि क्या WAF या रेट लिमिटर में लोड जनरेटर को allow-list करना होगा।
• एक संपर्क व्यक्ति: एक तकनीकी व्यक्ति जो लॉग पढ़ सके, कोई सर्विस रीस्टार्ट कर सके, और कुछ अप्रत्याशित हो तो रन रोक सके।

परफ़ॉर्मेंस और सिक्योरिटी टेस्टिंग कब करवाएँ

• लॉन्च या बड़ी रिलीज़ से पहले — इससे पहले कि लॉन्च के दिन हज़ारों उपयोगकर्ता ख़ुद परफ़ॉर्मेंस मापें।
• मौसमी पीक से पहले: सरकारी डिजिटल सेवाएँ अपने मौसमी चरम लोड से पहले, ई-कॉमर्स अपने सेल सीज़न से पहले — वर्कलोड अपेक्षित पीक पर सेट, किसी सामान्य दिन पर नहीं।
• आर्किटेक्चर बदलने के बाद: नया डेटाबेस या कैशिंग लेयर, दूसरे क्लाउड या रीजन में जाना, नया API गेटवे या मैसेज क्यू — बेहतर है कि बदलाव से पहले वाले उसी वर्कलोड से पुनः मापन हो, ताकि तुलना ईमानदार रहे।
• ऑथेंटिकेशन या अनुमतियाँ बदलने के बाद: नया SSO प्रदाता, नई टोकन व्यवस्था, नए रोल या टेनेंट — एक्सेस-कंट्रोल और सेशन की जाँचें दोबारा।
• जब API पार्टनर्स या मोबाइल ऐप के लिए खोला जाए — तब API ऐसे क्लाइंट्स की पहुँच में आ जाता है जिन्हें आप नियंत्रित नहीं करते।
• जब प्रोडक्शन पहले से धीमा हो — टेस्ट एनवायरनमेंट में नियंत्रित लोड पर धीमापन दोहराया जाता है, और अगले पीक से पहले बॉटलनेक खोजा जाता है।

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

संदर्भ

• Apache JMeter User's ManualApache Software FoundationJMeter से लोड टेस्ट कैसे बनाएँ, पैरामीटराइज़ करें और चलाएँ, और उसके लिसनर व रिपोर्ट कैसे पढ़ें।
• OWASP Top 10:2025OWASP Foundation · 2025वेब एप्लिकेशन की दस सबसे गंभीर सुरक्षा जोखिम, हर एक की जाँच और रोकथाम के साथ।
• OWASP API Security Top 10 (2023)OWASP Foundation · 2023API की दस सबसे आम कमज़ोरियाँ: ऑब्जेक्ट-लेवल ऑथराइज़ेशन का टूटना, ऑथेंटिकेशन का टूटना, अनियंत्रित रिसोर्स खपत और अन्य।
• OWASP Web Security Testing Guide (WSTG)OWASP Foundationवेब एप्लिकेशन और API की सुरक्षा कमज़ोरियों को परखने की संदर्भ कार्यप्रणाली, एक-एक टेस्ट के रूप में।
• OWASP Application Security Verification Standard (ASVS)OWASP Foundationवेब एप्लिकेशन के लिए सत्यापन-योग्य सुरक्षा आवश्यकताओं की चेकलिस्ट, तीन एश्योरेंस स्तरों में।
• OWASP Mobile Application Security Verification Standard (MASVS)OWASP Foundationमोबाइल ऐप के लिए OWASP की सुरक्षा आवश्यकताएँ, storage, cryptography, authentication, network और platform interaction जैसे नियंत्रण समूहों में।