सॉफ्टवेयर में सोक टेस्ट: अर्थ और उदाहरण

⚡ स्मार्ट सारांश

सोक टेस्टिंग किसी एप्लिकेशन पर लंबे समय तक लगातार और वास्तविक भार डालती है ताकि समय के साथ सामने आने वाली समस्याओं का पता लगाया जा सके। मेमोरी लीक, कनेक्शन की समस्या और धीमी गति से होने वाली परफॉर्मेंस जैसी समस्याओं को पकड़ने के लिए इसे डिज़ाइन किया गया है।

  • 🕒 लंबी अवधि: कई घंटों या दिनों तक लगातार चलने वाला वास्तविक भार, न कि थोड़े समय का झटपट भार।
  • 💧 प्राथमिक Target: मेमोरी लीक और कोई भी संसाधन जो आवंटित तो किया गया है लेकिन कभी जारी नहीं किया गया है।
  • 📉 गिरावट की जाँच: पूरी प्रक्रिया के दौरान प्रतिक्रिया समय स्थिर रहना चाहिए, न कि केवल अच्छी शुरुआत होना।
  • ️ डेटाबेस फोकस: यहां कनेक्शन पूल, ओपन कर्सर और बढ़ती हुई लॉग टेबल दिखाई देती हैं।
  • ⏰ समय यथार्थवाद: इसमें निर्धारित कार्य और बैच विंडो शामिल करें जो सोक अवधि के दौरान होती हैं।
  • 📊 निर्णय नियम: एक सपाट संसाधन वक्र सफल होता है; जबकि लगातार बढ़ता हुआ वक्र सीमित दायरे में भी विफल हो जाता है।

सोक टेस्ट क्या है?

सोक परीक्षण क्या है?

सोख परीक्षण यह एक प्रकार का गैर-कार्यात्मक परीक्षण है जिसका उपयोग किसी सॉफ़्टवेयर एप्लिकेशन के प्रदर्शन को मापने के लिए किया जाता है, जो लंबे समय तक बहुत अधिक लोड के तहत होता है। सोक परीक्षण का लक्ष्य यह सुनिश्चित करना है कि सॉफ़्टवेयर एप्लिकेशन उच्च मात्रा में उपयोग को बनाए रखता है या नहीं और यह जांचना है कि इसकी डिज़ाइन अपेक्षाओं के बाहर क्या होगा।

नीचे दी गई छवि एक परीक्षण चक्र को दर्शाती है जो यह दर्शाती है कि सोख परीक्षण (सोख परीक्षण) किस चरण पर हैप्रदर्शन परीक्षण का प्रकार) किसी अनुप्रयोग पर किया जाता है।

सोख परीक्षण

इस प्रकार के परीक्षण में, मूल रूप से सिस्टम में किसी एप्लिकेशन द्वारा मेमोरी उपयोग की निगरानी की जाती है। यह सिस्टम स्तर पर परीक्षण है, यह पता लगाने के लिए कि क्या सिस्टम बहुत अधिक उपयोग को झेल पाएगा और यह देखने के लिए कि इसकी डिज़ाइन अपेक्षाओं के बाहर क्या होगा।

सोख परीक्षण क्यों करें?

एक सिस्टम 2 घंटे तक इस्तेमाल किए जाने पर सामान्य रूप से काम कर सकता है, लेकिन जब उसी सिस्टम का लगातार 10 घंटे या उससे ज़्यादा इस्तेमाल किया जाता है तो यह विफल हो सकता है या असामान्य/अनियमित रूप से व्यवहार कर सकता है/क्रैश हो सकता है। ऐसी विफलता की भविष्यवाणी करने के लिए सोक परीक्षण किया जाता है।

सोख परीक्षण कब करें?

सोख परीक्षण निम्नलिखित परिदृश्यों में किया जाना चाहिए: –

  1. किसी भी एप्लिकेशन को क्लाइंट पर तैनात करने से पहले यानी किसी विशिष्ट प्लेटफ़ॉर्म पर रिलीज़ करने से पहले, उसे उच्च या समकक्ष ट्रैफ़िक स्तरों पर लोड परीक्षणों की एक सफल श्रृंखला से गुज़रना पड़ता है। उसके बाद सोख परीक्षण किया जाता हैयह हमें यह निर्धारित करने में मदद करता है कि किसी विशेष एप्लिकेशन को विस्तारित अवधि के लिए कैसे चलाया जाए। यदि इस अवधि के दौरान मेमोरी लीक/मेमोरी करप्शन जैसी समस्याएं पाई जाती हैं, यानी जब यह सोक पर हो, तो इसकी तुरंत रिपोर्ट की जानी चाहिए।
  2. सोक टेस्टिंग करने का सबसे अच्छा समय सप्ताहांत है क्योंकि किसी एप्लिकेशन को एक दिन या रात से ज़्यादा समय तक चालू अवस्था में रखना पड़ता है। यह पूरी तरह से परीक्षण की स्थिति की सीमाओं पर निर्भर करता है। सोक टेस्ट सबसे महत्वपूर्ण अनुपालन आवश्यकताओं में से एक है जिसका हर कंपनी को बहुत सख्ती से पालन करना चाहिए।

सोख परीक्षण रणनीति

दीर्घ सत्र सोख परीक्षण एक ऐसी रणनीति है जिसमें सिस्टम को लम्बे समय तक लोड के अधीन रखा जाता है।

एक सरल उदाहरण वह है जहाँ उपयोगकर्ता कई घंटों तक सिस्टम में लॉग इन रहता है और कई व्यावसायिक लेनदेन करता है। इस तरह, बहुत सारा डेटा बन जाता है। सिस्टम/डेटाबेस सर्वर पर बहुत अधिक लोड हो सकता है जिसके परिणामस्वरूप सिस्टम/डेटाबेस सर्वर ठप/क्रैश हो सकता है।

लॉन्ग सेशन सोक टेस्टिंग के तहत, कई दिनों (जैसे 30 दिन) की गतिविधियाँ एक सीमित समय सीमा (जैसे 2 दिन) में की जाती हैं। इस सीमित समय सीमा में लेन-देन की संख्या कई दिनों के लेन-देन के बराबर या उससे अधिक होनी चाहिए। ध्यान संसाधित किए गए लेन-देन की संख्या पर होना चाहिए। सोक टेस्टिंग का सबसे महत्वपूर्ण हिस्सा सीपीयू में उपलब्ध मेमोरी और उपयोग में आने वाली मेमोरी की मात्रा की जाँच करना है। हमें सोक टेस्ट की शुरुआत और अंत में मेमोरी उपयोग को रिकॉर्ड करने की आवश्यकता है। यदि आवश्यक हो, तो सुविधाओं जैसे मेमोरी उपयोग को रिकॉर्ड करें Java वर्चुअल मशीनें भी महत्वपूर्ण हैं और उन पर निगरानी रखने की आवश्यकता है।

नीचे कुछ और जांचें दी गई हैं जो किसी भी उपयोगकर्ता/परीक्षक को सोक परीक्षण शुरू करने से पहले करनी चाहिए:

क) डेटाबेस संसाधन उपभोग की निगरानी करें।

b) सर्वर संसाधन खपत (उदाहरण: CPU उपयोग) पर नज़र रखें।

ग) सोक परीक्षण यथार्थवादी उपयोगकर्ता समवर्तीता के साथ चलाया जाना चाहिए।

सोख परीक्षण की विशेषताएं

एक मानक सोख परीक्षण विधि में निम्नलिखित विशेषताएं होनी चाहिए: –

  • अधिकांश सोक टेस्ट की अवधि अक्सर उपलब्ध समय के आधार पर निर्धारित होती है।
  • यदि किसी एप्लिकेशन को लंबे समय तक चलाने की आवश्यकता हो तो उसे बिना किसी रुकावट के चलना चाहिए।
  • इसमें उन सभी परिदृश्यों को शामिल किया जाना चाहिए जिन पर हितधारकों द्वारा सहमति व्यक्त की गई हो।
  • अधिकांशतः प्रत्येक प्रणाली में एक नियमित रखरखाव अवधि होती है और ऐसी अवधियों के बीच का समय, सोख परीक्षण के दायरे को निर्धारित करने के लिए एक प्रमुख चालक होता है।

सोख परीक्षण के उदाहरण

  • बैंकिंग डोमेन के मामले में, जब व्यापारियों से बड़ी मात्रा में डेटा प्राप्त होता है, तो परीक्षक सिस्टम को लगातार 70 घंटे से 150 घंटे तक लोड पर रखेगा, ताकि यह जांचा जा सके कि इस लोडिंग अवधि के दौरान एप्लीकेशन कैसा व्यवहार करता है।
  • मान लीजिए कि 33,000 लॉगिन हैं, जिन्हें सिस्टम के ज़रिए डाला जाना है, तो यह साढ़े सात दिन की गतिविधि को दर्शाता है। इस मामले में, शुक्रवार शाम 60 बजे के आसपास 70-6 घंटे का सोक टेस्ट शुरू किया जा सकता है जिसे XNUMX मिनट में पूरा किया जा सकता है। Monday सुबह 6 बजे। केवल इस तरह के परीक्षण से ही नियंत्रित परिस्थितियों में प्रदर्शन में किसी भी गिरावट का निरीक्षण करना संभव होगा।
  • वीडियो गेम के मामले में, मोबाइल एप्लिकेशन आदि में गेम या एप्लिकेशन को लंबे समय तक चालू अवस्था में छोड़ना शामिल है, संचालन के विभिन्न तरीकों में - जैसे कि निष्क्रिय रहना, शीर्षक स्क्रीन पर रुक जाना आदि, ताकि यह पता लगाया जा सके कि कोई एप्लिकेशन निरंतर अपेक्षित लोड को संभाल सकता है या नहीं।

सोक परीक्षण के दौरान देखी जाने वाली सामान्य समस्याएं

  1. मेमोरी आवंटन (स्मृति रिसाव जिसके परिणामस्वरूप अंततः मेमोरी संकट या राउंडिंग त्रुटियां उत्पन्न होती हैं जो केवल समय के साथ ही प्रकट होती हैं)।
  2. डेटाबेस संसाधन उपयोग (कुछ स्थितियों के तहत डेटाबेस कर्सर को बंद करने में विफलता जिसके परिणामस्वरूप अंततः संपूर्ण सिस्टम ठप्प हो जाएगा)।
  3. इससे प्रदर्शन में गिरावट भी आ सकती है, अर्थात यह सुनिश्चित करना कि लंबे समय तक लगातार गतिविधि के बाद प्रतिक्रिया समय उतना ही अच्छा है जितना परीक्षण की शुरुआत में था।
  4. कुछ परिस्थितियों में बहु-स्तरीय प्रणाली के स्तरों के बीच कनेक्शन बंद करने में विफलता, जिसके कारण प्रणाली के कुछ या सभी मॉड्यूल ठप्प हो सकते हैं।
  5. लम्बे परीक्षण के दौरान आंतरिक डेटा-संरचनाओं के कम कुशल हो जाने के कारण कुछ कार्यों के प्रतिक्रिया समय में धीरे-धीरे गिरावट आती है।

यह परीक्षण प्रदर्शन परीक्षण श्रेणी में कैसे फिट बैठता है?

प्रदर्शन परीक्षण एक व्यापक शब्द है। नीचे दिए गए विभिन्न प्रकार केवल लगाए गए भार के स्वरूप और उसे बनाए रखने की अवधि में भिन्न होते हैं, यही कारण है कि अक्सर इन्हें एक दूसरे के साथ भ्रमित किया जाता है।

परीक्षण प्रकार लोड पैटर्न प्रश्न इसका उत्तर है
लोड परीक्षण अपेक्षित अधिकतम भार, अल्प अवधि क्या यह प्रणाली सामान्य व्यस्त यातायात के दौरान अपने लक्ष्यों को पूरा करती है?
तनाव परीक्षण क्षमता से अधिक वृद्धि होने पर विफलता हो जाती है इसमें खराबी कहाँ आती है, और क्या यह शालीनता से विफल होती है?
स्पाइक परीक्षण अचानक अत्यधिक उछाल, फिर गिरावट क्या यह यातायात के झटके से बच पाता है और उससे उबर पाता है?
सहनशक्ति परीक्षण सामान्य भार कई घंटों तक बना रहता है क्या समय के साथ प्रदर्शन में गिरावट आती है?
भिगोने का परीक्षण लंबे समय तक निरंतर भार क्या मेमोरी लीक या संसाधनों की कमी की समस्या है?
स्थिरता परीक्षण विभिन्न परिस्थितियों में भार में भिन्नता क्या परिस्थितियाँ बदलने पर भी सिस्टम विश्वसनीय बना रहता है?
वॉल्यूम परीक्षण सामान्य उपयोगकर्ता, बहुत बड़ी मात्रा में डेटा क्या यह डेटाबेस के बढ़ने पर भी काम कर पाता है?

धीरज और जलमग्नता परीक्षण को अक्सर पर्यायवाची माना जाता है। सामान्य तौर पर, दोनों में अंतर यह है कि दोनों लंबे समय तक निरंतर भार सहन कर सकते हैं। जहां टीमें इनमें अंतर करती हैं, वहां एंड्योरेंस टेस्टिंग इस बात पर केंद्रित होती है कि क्या प्रतिक्रिया समय में वृद्धि होती है, जबकि सोक टेस्टिंग मेमोरी, फ़ाइल हैंडल और कनेक्शन पूल जैसे संसाधनों की खपत पर केंद्रित होती है। एक को चलाने से आमतौर पर दोनों के प्रमाण मिल जाते हैं।

परीक्षण के दौरान प्राप्त किए जाने वाले प्रमुख मापदंड

किसी भी परफॉर्मेंस रन की गुणवत्ता इस बात पर निर्भर करती है कि आप उसे चलते समय कितना रिकॉर्ड करते हैं। सर्वर और क्लाइंट साइड पर इन छह चीजों को कैप्चर करें, फिर उनकी तुलना बेसलाइन से करें, न कि अपने अंतर्ज्ञान से।

मैट्रिक यह आपको क्या बताता है? चेतावनी का संकेत
औसत प्रतिक्रिया समय सामान्य उपयोगकर्ता अनुभव रन के पार कोई भी ऊपर की ओर बहाव
95वें प्रतिशतक प्रतिक्रिया समय सबसे धीमे उपयोगकर्ताओं का अनुभव औसत से काफी ऊपर, यानी असंगति
प्रवाह प्रति सेकंड संभाले गए अनुरोध भार स्थिर रहते हुए गिरना
त्रुटि दर असफल या समय समाप्त हो चुके अनुरोधों का हिस्सा सहमत सीमा से ऊपर कोई भी वृद्धि
सीपीयू और मेमोरी का उपयोग सर्वर संसाधन सीमा यादें जो ऊपर चढ़ती हैं और कभी वापस नहीं आतीं।
डेटाबेस कनेक्शन और थ्रेड्स पूल की थकावट बिना रिलीज हुए लगातार बढ़ती संख्या

औसत और प्रतिशतक दोनों को एक साथ पढ़ें। 95वें परसेंटाइल 900 मिलीसेकंड के साथ औसत 800 मिलीसेकंड एक सुसंगत प्रणाली को दर्शाता है। 95वें परसेंटाइल 9 सेकंड के साथ यही औसत दर्शाता है कि बीस में से एक उपयोगकर्ता को समस्या हो रही है, और औसत इसे छिपा रहा है।

सिर्फ मूल्य पर नहीं, आकार पर भी ध्यान दें। किसी भी लंबे समय तक चलने वाले परीक्षण में, एक सपाट संसाधन रेखा सफलता का संकेत है और एक बढ़ती हुई रेखा विफलता का संकेत है, भले ही परीक्षण समाप्त होने के समय निरपेक्ष संख्या अभी भी सीमा के भीतर आराम से हो।

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

सामान्य तौर पर दोनों एक ही हैं। जहां टीमें इनमें अंतर करती हैं, वहां एंड्योरेंस टेस्टिंग प्रतिक्रिया समय में विचलन को देखती है, जबकि सोक टेस्टिंग संसाधन खपत को देखती है। आमतौर पर एक ही परीक्षण दोनों के प्रमाण प्रदान करता है।

कम से कम एक पूर्ण व्यावसायिक चक्र को कवर करने के लिए पर्याप्त समय, आमतौर पर 8 से 72 घंटे। इस प्रक्रिया में कोई भी निर्धारित बैच कार्य या रात्रिकालीन प्रक्रिया शामिल होनी चाहिए, क्योंकि अक्सर इन्हीं से डेटा लीक होता है।

एक मेमोरी कर्व जो लगातार ऊपर की ओर बढ़ता है और गार्बेज कलेक्शन के बाद कभी भी अपने पहले के स्तर पर वापस नहीं आता। निरपेक्ष मान से अधिक ढलान मायने रखता है: कोई भी निरंतर ऊपर की ओर रुझान एक दोष है।

एआई-आधारित निगरानी कई घंटों के टेलीमेट्री का विश्लेषण करती है और उस सटीक बिंदु को चिह्नित करती है जहां एक प्रवृत्ति बदलती है, जिसे हजारों डेटा बिंदुओं में मैन्युअल रूप से पहचानना अव्यावहारिक है।

कुछ हद तक। मॉडल संसाधनों के रुझान का अनुमान लगा सकते हैं और उनकी कमी का पहले से पूर्वानुमान लगा सकते हैं, लेकिन रिलीज़ का निर्णय लेने से पहले पूर्वानुमान की पुष्टि के लिए वास्तविक परीक्षण की आवश्यकता होती है।

इस पोस्ट को संक्षेप में इस प्रकार लिखें: