static testing dynamic testing difference between these two important testing techniques
परीक्षण है जाँच और वैधता । हम सभी जानते हैं कि परीक्षण को पूरा करने में 2 Vs लगते हैं।
आज के लेख में, हम कुछ प्रकाश डालेंगे स्थैतिक परीक्षण । इसे वेरिफिकेशन भी कहा जाता है। हम इसके बारे में सब जानेंगे और इस पर विशेष जोर देंगे गतिशील परीक्षण अक्सर अधिकतम ध्यान प्राप्त होता है और इसमें असंख्य लेख होते हैं जो इसे विस्तार देते हैं।
हालांकि, स्थैतिक परीक्षण पर कोई भी चर्चा इसके समकक्ष, गतिशील परीक्षण का क्या अर्थ है, इस बारे में स्पष्टीकरण के बिना पूरी नहीं होगी। डायनेमिक परीक्षण सत्यापन है, अन्य 'वी'।
डायनेमिक परीक्षण तब होता है जब आप वास्तविक प्रणाली के साथ काम कर रहे होते हैं (न कि कुछ कलाकृतियों या मॉडल जो प्रतिनिधित्व करते हैं सिस्टम), इनपुट प्रदान करता है, आउटपुट प्राप्त करता है और आउटपुट को अपेक्षित व्यवहार से तुलना करता है। यह सिस्टम में त्रुटियों को खोजने के इरादे से काम कर रहा है।
इस प्रक्रिया के दौरान, हम समझेंगे कि परीक्षण के बारे में निम्नलिखित दो आम गलतफहमी कैसे सच नहीं हैं:
- परीक्षण एक गतिविधि है जो अंत में आती है
- यह केवल परीक्षकों द्वारा किया जाता है और उनमें से कुछ भी नहीं करना है
हमें एक त्वरित संदर्भ के साथ शुरू करते हैं वि मॉडल :
- पर बाएं हाथ की ओर वी-मॉडल में, हमारे पास ऐसी गतिविधियाँ हैं जो क्यूए टीम द्वारा नहीं की जाती हैं।
- पर दाहिने हाथ की ओर , हमारे पास उनमें से कुछ हैं जो देव टीम द्वारा, कुछ परीक्षक द्वारा और कुछ उपयोगकर्ताओं द्वारा ध्यान रखे जाते हैं।
चलो साथ - साथ शुरू करते हैं - ज़रूरत इकट्ठा । यह व्यापार विश्लेषक और अन्य उच्च-स्तरीय प्रबंधन द्वारा किया जाता है - इस चरण के लिए आउटपुट दस्तावेज़ व्यावसायिक आवश्यकता दस्तावेज़, BRD है।
इनर ज्वाइन आउटर जॉइन लेफ्ट जॉइन राइट राइट जॉइन
अगला चरण है प्रणाली की रूपरेखा । सिस्टम डिज़ाइन एक ऐसा चरण है जहाँ व्यावसायिक आवश्यकताओं को कार्यात्मक आवश्यकताओं में अनुवादित किया जाता है, FRD (कार्यात्मक आवश्यकताओं दस्तावेज़) में।
जब अनुवाद हो रहा है, तो देव टीम (जो इस चरण में मुख्य अभिनेता है) कदम से कदम, पृष्ठ द्वारा पृष्ठ और रेखा से BRD दस्तावेज़ पर जाने वाली है। भले ही प्राथमिक लक्ष्य अनुवाद की खातिर व्यावसायिक आवश्यकताओं का उपभोग करना है, लेकिन बीआरडी दस्तावेज़ की समीक्षा की जा रही है।
एक उदाहरण: कहें कि यह एक बैंकिंग साइट के लिए BRD है जो सुरक्षा पर बड़ी है। BRD में एक खंड है जो ऑनलाइन बैंकिंग साइट के साथ खाता बनाने वाले विभिन्न उपयोगकर्ताओं के लिए पासवर्ड नियमों के बारे में बात करता है। नियमों में से एक है: एक उपयोगकर्ता एक पासवर्ड का उपयोग नहीं कर सकता है जो वह / वह अन्य खातों के लिए उपयोग करता है।
यह सक्षम नहीं है। क्योंकि, एक साइट केवल सुझाव दे सकती है कि उपयोगकर्ता को लॉगिन क्रेडेंशियल कैसे सेट करना चाहिए लेकिन कोई रास्ता नहीं है, यह प्रतिबंध लगाया जा सकता है। तो, यह आवश्यकता संभव नहीं है - दूसरे शब्दों में, इसे सॉफ्टवेयर के माध्यम से पूरा नहीं किया जा सकता है।
आइए अब इस उदाहरण के आधार पर निम्नलिखित बातों पर विचार करें:
- यह कैसे निर्धारित किया जाता है कि यह आवश्यकता निर्माण योग्य नहीं है और इसलिए, परीक्षण नहीं किया जा सकता है (दूसरे शब्दों में, संभव नहीं है)? क्या हमारे पास बैंक की साइट है और फिर क्या हम लॉगिन और पासवर्ड सेट करते हैं - और फिर महसूस करते हैं कि यह संभव नहीं है? नहीं, हम बस बीआरडी की समीक्षा और निश्चित रूप से कुछ सामान्य व्यापारिक समझ के आधार पर इसे आधार बना रहे हैं।
- क्या हम इस आवश्यकता का परीक्षण कर रहे हैं? यकीन है, लेकिन विशुद्ध रूप से सैद्धांतिक, वैचारिक भावना पर आधारित है लेकिन वास्तविक ऑटो (टेस्ट के तहत आवेदन) पर नहीं।
- इस परीक्षण का भौतिक रूप क्या है? -एक साधारण पढ़ना या बीआरडी की औपचारिक समीक्षा या व्यावसायिक आवश्यकताओं का एक और भी अधिक औपचारिक व्यवहार्यता विश्लेषण।
हमारी गलत धारणाओं पर वापस आ रहे हैं:
- BRD की यह समीक्षा कौन कर रहा है? - ज्यादातर देव टीम और अन्य तकनीकी दल जो उत्पाद बनाने के लिए जिम्मेदार हैं। परीक्षक नहीं।
- क्या यह समीक्षा उत्पाद निर्माण के अंत में चल रही है? नहीं, परियोजना के विकास के बहुत प्रारंभिक चरण में। इसलिए, सिर्फ अंत नहीं है।
स्थैतिक परीक्षण तकनीक:
सारांशित करने के लिए, स्थैतिक परीक्षण सॉफ्टवेयर परीक्षण का सत्यापन हिस्सा है जो निम्न विधियों का पालन करता है:
- दस्तावेज़ समीक्षा
- प्रायोगिक प्रदर्शन
- निरीक्षण
- व्यवहार्यता विश्लेषण या किसी अन्य प्रकार का विश्लेषण यह निर्धारित करने के लिए कि क्या सॉफ्टवेयर होना चाहिए या नहीं
- को़ड समीक्षा
CSTE CBOK को उद्धृत करने के लिए, 'सत्यापन प्रश्न का उत्तर देता है,' क्या हमने सही प्रणाली का निर्माण किया? ' मान्यताओं के पते पर, 'क्या हमने सिस्टम को सही बनाया है?'
वी-मॉडल के बाईं ओर होने वाली सभी स्थिर परीक्षण गतिविधियाँ निम्नलिखित हैं।
| एसडीएलसी चरण | उत्पादन | सत्यापन | अभिनेताओं |
|---|---|---|---|
| व्यापार की आवश्यकता एकत्रित | BRD (व्यावसायिक आवश्यकता दस्तावेज़) | स्कोप दस्तावेज़ (यदि कोई हो) | |
| सिस्टम आवश्यकता डिजाइन | FRD (कार्यात्मक आवश्यकता दस्तावेज़) | BRD की समीक्षा / सत्यापन करता है | देव, तकनीकी दल |
| तकनीकी आवश्यकताओं के डिजाइन | टीडीडी (तकनीकी डिज़ाइन दस्तावेज़) | FRD की समीक्षा / सत्यापन करता है | देव, तकनीकी दल |
| डिजाइन (कोड) | कोड | TDD की समीक्षा / सत्यापन करता है। पूर्णता, प्रारूप आदि के लिए देव टीम द्वारा कोड समीक्षा। | देव, तकनीकी दल |
ध्यान दें: यह जानकारी किसी भी विकास के तरीके के बाद परियोजनाओं के लिए अतिरिक्त रूप से बनाई जा सकती है क्योंकि कदम कमोबेश इसी तरह के होते जा रहे हैं।
V- मॉडल के दाईं ओर सत्यापन है।
गतिशील परीक्षण तकनीक:
- इकाई का परीक्षण
- एकीकरण जांच
- सिस्टम परीक्षण
यूनिट, एकीकरण, प्रणाली और यूएटी चरण सभी इसके विकास के विभिन्न चरणों के दौरान ऑटो पर किए जाने वाले परीक्षण बनाने के बारे में हैं। भले ही परीक्षण विभिन्न प्रकार की आवश्यकताओं को मान्य करने पर लक्षित हों, फिर भी वे सभी परीक्षण समान हैं।
इसलिए, परीक्षण का कोई भी रूप जहां हमारे पास एक परीक्षण है जिसे एक ऑटो पर निष्पादित करने की आवश्यकता है और परीक्षण के परिणाम (सफल या नहीं) का निर्धारण करने के लिए इसके आउटपुट की आवश्यकता है - यह सत्यापन है।
अब, यह सामान्य करना ठीक होगा कि वी-मॉडल के दाहिने हाथ (आरएचएस) पर कोई सत्यापन नहीं है? जवाब न है।
परीक्षण के निर्माण / अंतिम चरण के दौरान आरएचएस पर प्रत्येक चरण में बनने वाले सभी परीक्षणों की कई बार समीक्षा की जाती है। परीक्षण प्रलेखन समीक्षा की विस्तृत प्रक्रिया है https://www.softwaretestinghelp.com/test-documentation-reviews/
RHS पर:
- डेवलपर्स द्वारा यूनिट / एकीकरण परीक्षण चरणों में टेस्ट और कोड की समीक्षा की जाती है।
- सिस्टम टेस्ट उनके प्रलेखन के दौरान एक सहकर्मी समीक्षा से गुजरते हैं और पूरा होने पर देव टीम और बिजनेस एनालिस्ट द्वारा एक समीक्षा से गुजरते हैं।
- यूएटी परीक्षण क्यूए टीम द्वारा और साथ ही यूएटी शुरू होने से पहले उपयोगकर्ताओं की समीक्षा से गुजरते हैं।
निष्कर्ष
अंत में, स्थैतिक परीक्षण एक महत्वपूर्ण परीक्षण तकनीक है जो व्यावसायिक आवश्यकता समीक्षा, कार्यात्मक आवश्यकता समीक्षा, डिज़ाइन समीक्षा, कोड वाकथ्रू और परीक्षण प्रलेखन समीक्षा का रूप लेती है। यह एक निरंतर गतिविधि है और सिर्फ परीक्षकों द्वारा नहीं किया जाता है।
सत्यापन, गतिशील परीक्षण भाग अधिक हाथों पर होता है और उत्पाद पर ही होता है और उत्पाद या कलाकृतियों के प्रतिनिधित्व पर नहीं। परीक्षण मामले / स्थिति की पहचान, कवरेज के विचार, निष्पादन और दोष रिपोर्टिंग की बहुत औपचारिक प्रक्रिया सभी गतिशील परीक्षण विधियों को चिह्नित करती है।
लेखक के बारे में: यह लेख एसटीएच टीम की सदस्य स्वाति एस ने लिखा है।
कृपया अपनी टिप्पणियों, प्रश्नों और अनुभवों को स्थैतिक और गतिशील परीक्षण विषय पर साझा करें।
अनुशंसित पाठ
- डेस्कटॉप, क्लाइंट सर्वर परीक्षण और वेब परीक्षण के बीच अंतर
- चंचल अनुमान तकनीक: एक चुस्त परियोजना में एक सच्चा अनुमान
- ब्लैक बॉक्स परीक्षण: उदाहरणों और तकनीकों के साथ एक गहराई से ट्यूटोरियल
- अनुपालन परीक्षण (अनुरूपता परीक्षण) क्या है?
- SIT Vs UAT टेस्टिंग में क्या अंतर है?
- अल्फा परीक्षण और बीटा परीक्षण (एक पूर्ण गाइड)
- ब्लैक बॉक्स परीक्षण और व्हाइट बॉक्स परीक्षण के बीच मुख्य अंतर
- यूनिट परीक्षण, एकीकरण परीक्षण और कार्यात्मक परीक्षण के बीच अंतर