कॉम्बिनेटोरियल टेस्ट डिज़ाइन तकनीकों का विश्लेषण

मैं यहां प्रसिद्ध और व्यापक रूप से उपयोग की जाने वाली परीक्षण डिजाइन तकनीकों जैसे समतुल्यता वर्ग, सीमा मूल्य परीक्षण और जोड़ीदार परीक्षण पर चर्चा करना छोड़ दूंगा, मैं अन्य, कम सामान्य तकनीकों पर चर्चा करूंगा। आप के बारे में मेरा लेख भी पढ़ सकते हैं। कॉम्बिनेटरियल टेस्ट डिज़ाइन तकनीकों से संबंधित मुद्दों निर्णय तालिका परीक्षण निर्णय तालिकाएँ आवश्यकताओं का दस्तावेजीकरण करने और किसी एप्लिकेशन की कार्यक्षमता का वर्णन करने के लिए एक उत्कृष्ट उपकरण हैं। ये तालिकाएँ एप्लिकेशन के व्यावसायिक तर्क का वर्णन करने के लिए बहुत सुविधाजनक हैं, और इसके अलावा, वे परीक्षण मामले बनाने के लिए एक ठोस आधार के रूप में काम कर सकते हैं। यदि परीक्षण किए गए एप्लिकेशन में उचित दस्तावेज़ीकरण का अभाव है, तो यह निर्णय तालिकाओं का उपयोग करने का एक अच्छा कारण है। आवश्यकताओं को संक्षिप्त और सरल रूप में प्रस्तुत करने से परीक्षण मामले बनाना काफी आसान हो जाता है। दृष्टिकोण: निर्णय तालिकाएँ सिस्टम स्थिति की संस्थाओं (गुणों/स्थितियों) के आधार पर एप्लिकेशन के तर्क का वर्णन करती हैं। प्रत्येक निर्णय तालिका में सिस्टम की केवल एक स्थिति का वर्णन होना चाहिए। नियम 1 नियम 2 … नियम एन इकाइयां, संपत्ति 1 … संपत्ति एम कार्रवाई क्रिया 1 … कार्रवाई पी 1 से एम तक इकाई (संपत्ति) सिस्टम के विभिन्न गुणों का प्रतिनिधित्व करती है; उन्हें तालिका में इनपुट डेटा के रूप में प्रस्तुत किया गया है जिसे सिस्टम में दर्ज किया जा सकता है। 1 से पी तक की कार्रवाइयां ऐसी कार्रवाइयां हैं जो संस्थाओं के निर्दिष्ट संयोजन के साथ हो सकती हैं। संस्थाओं के सभी इनपुट डेटा के संयोजन के आधार पर, क्रियाएँ आवश्यक मान लेती हैं। प्रत्येक नियम सभी संपत्तियों के लिए इनपुट डेटा के एक अद्वितीय सेट को परिभाषित करता है जो विशिष्ट क्रियाओं के निष्पादन की ओर ले जाता है। निर्णय तालिका बनाने के बाद, आमतौर पर तालिका को सरल बनाना संभव होता है, उदाहरण के लिए, कुछ या सभी असंभव परिदृश्यों को हटाकर। फिर, तालिका को परीक्षण मामलों में बदला जा सकता है। राज्य-संक्रमण परीक्षण राज्य-संक्रमण परीक्षण, निर्णय तालिका परीक्षण की तरह, आवश्यकताओं का दस्तावेजीकरण करने और सिस्टम की संरचना और डिजाइन का वर्णन करने के लिए एक मूल्यवान उपकरण है। निर्णय तालिका परीक्षण के विपरीत, जो एक विशिष्ट सिस्टम स्थिति का वर्णन करता है, राज्य-संक्रमण परीक्षण बताता है कि सिस्टम की ये स्थितियाँ कैसे बदल सकती हैं। आरेख एप्लिकेशन के संचालन के दौरान होने वाली सभी घटनाओं को परिभाषित करते हैं और एप्लिकेशन इन घटनाओं पर कैसे प्रतिक्रिया करता है। दृष्टिकोण: इस तकनीक के दो प्रकार के दृश्य प्रतिनिधित्व हैं: राज्य-संक्रमण आरेख राज्य-संक्रमण तालिकाएँ राज्य-संक्रमण आरेख उदाहरण के तौर पर, आइए एयरलाइन टिकटों के आरक्षण पर विचार करें। यह मोटे तौर पर इस प्रकार संचालित होता है: प्रारंभ में, ग्राहक एयरलाइन को आरक्षण के लिए जानकारी प्रदान करते हैं - प्रस्थान स्थान, गंतव्य, तिथि और प्रस्थान का समय। एक एयरलाइन कर्मचारी आरक्षण बनाने के लिए ग्राहक द्वारा प्रदान की गई जानकारी का उपयोग करके ग्राहक और टिकट आरक्षण प्रणाली के बीच इंटरफेस के रूप में कार्य करता है। उसके बाद, ग्राहक का आरक्षण "निर्मित" स्थिति में है। इसके अतिरिक्त, आरक्षण बनाने के बाद, सिस्टम एक टाइमर शुरू करता है। जब टाइमर समाप्त हो जाता है और आरक्षित टिकट का भुगतान नहीं किया जाता है, तो सिस्टम उस टिकट का आरक्षण रद्द कर देता है। सर्कल एयरलाइन टिकट आरक्षण प्रणाली की स्थिति, "निर्मित" स्थिति का प्रतिनिधित्व करता है। तीर "निर्मित" स्थिति में संक्रमण का संकेत देता है। तीर के नीचे का विवरण ("get_info") सिस्टम के बाहर से उत्पन्न होने वाली एक घटना है। तीर के नीचे विवरण में कमांड ("/" के बाद) दर्शाता है कि सिस्टम ने घटना के जवाब में कुछ कार्रवाई की है - इस मामले में, एक टाइमर शुरू करना। काला वृत्त आरेख के प्रारंभ/प्रवेश बिंदु को इंगित करता है। यदि टाइमर समाप्त नहीं होता है, और हमने आरक्षित टिकट के लिए भुगतान कर दिया है, तो सिस्टम "भुगतान" स्थिति में प्रवेश करता है। इसे "पेमनी" लेबल वाले तीर और "निर्मित" स्थिति से "भुगतान" स्थिति में संक्रमण द्वारा दर्शाया गया है। (आरेख पर एक वृत्त के रूप में दर्शाया गया है) यह सिस्टम की वह स्थिति है जहां यह एक या अधिक घटनाओं की प्रतीक्षा करता है। राज्य अब तक प्राप्त इनपुट डेटा को याद रखता है और इंगित करता है कि सिस्टम प्राप्त घटनाओं पर कैसे प्रतिक्रिया करेगा। घटनाएँ कार्रवाई को गति दे सकती हैं और/या स्थिति में बदलाव ला सकती हैं। स्थिति : (आरेख पर एक तीर के रूप में दर्शाया गया है) यह एक घटना के कारण होने वाले एक राज्य से दूसरे राज्य में संक्रमण का प्रतिनिधित्व करता है। संक्रमण : (तीर के ऊपर एक आयत के रूप में दर्शाया गया है) एक घटना कुछ ऐसी चीज है जो एप्लिकेशन को अपनी स्थिति बदलने का कारण बनती है। ईवेंट एप्लिकेशन के बाहर से आ सकते हैं, जैसे एप्लिकेशन के उपयोगकर्ता इंटरफ़ेस के माध्यम से। साथ ही, एप्लिकेशन स्वयं ईवेंट उत्पन्न कर सकता है, उदाहरण के लिए, "टाइमर समाप्त हो गया" जैसा ईवेंट। जब कोई घटना घटती है, तो एप्लिकेशन उसी स्थिति में रह सकता है, स्थिति बदल सकता है, या कोई कार्रवाई कर सकता है। घटनाओं में पैरामीटर हो सकते हैं; उदाहरण के लिए, "pay_money" ईवेंट में "कैश," "चेक," "डेबिटकार्ड," या "क्रेडिटकार्ड" जैसे पैरामीटर हो सकते हैं। घटना : (संक्रमण के ऊपर लेबल में "/" के बाद दर्शाया गया) यह स्थिति में परिवर्तन द्वारा शुरू की गई एक कार्रवाई है। यह "प्रिंट टिकट," "स्क्रीन पर डिस्प्ले" आदि जैसी क्रियाएं हो सकती हैं। आमतौर पर, क्रियाएं आउटपुट बनाती हैं जो सिस्टम के आउटपुट डेटा के रूप में काम करती हैं। परिवर्तन के दौरान क्रियाएँ होती हैं; राज्य स्वयं निष्क्रिय हैं। क्रिया : आरेख पर एक काले बिंदु के रूप में दिखाया गया है। प्रवेश बिंदु को आरेख पर "बुल्सआई" प्रतीक के रूप में दिखाया गया है। निकास बिंदु को राज्य-संक्रमण तालिकाएँ राज्य-संक्रमण तालिकाएँ वे तालिकाएँ होती हैं जिनमें चार कॉलम होते हैं: वर्तमान स्थिति, घटना, क्रिया और अगली स्थिति। राज्य-संक्रमण तालिकाओं का लाभ यह है कि वे सभी संभावित राज्य-संक्रमण परिदृश्यों को परिभाषित करते हैं, न कि केवल सही परिदृश्यों को। इसलिए, राज्य-संक्रमण तालिकाएँ अक्सर अपरिभाषित, अनिर्दिष्ट राज्य-संक्रमण संयोजनों की खोज की ओर ले जाती हैं, जिन्हें कोड लिखने से पहले पहचानना बेहतर होता है। राज्य-संक्रमण आरेखों का उपयोग परीक्षण मामले बनाने के लिए आसानी से किया जा सकता है। परीक्षण मामलों का एक सेट बनाना आवश्यक है जो कम से कम एक बार सभी संक्रमणों को कवर करे। राज्य-संक्रमण तालिकाओं से, परीक्षण मामले उत्पन्न करना भी अपेक्षाकृत सरल है। किसी को सभी वैध संयोजनों से गुजरना होगा (यदि समय अनुमति देता है या जोखिम निषिद्ध नहीं करता है, तो सभी अमान्य संयोजनों से गुजरना भी संभव है)। ऑर्थोगोनल सारणियाँ "1" और "2" मानों की जोड़ी के लिए कितने संयोजन मौजूद हैं? {1,1}, {1,2}, {2,1}, और {2,2}। एक ऑर्थोगोनल सरणी एक विशेष गुण के साथ एक द्वि-आयामी सरणी है - सरणी के किन्हीं दो स्तंभों में, उन स्तंभों में मानों के सभी संयोजन मौजूद होते हैं। अर्थात्, यदि आप ऑर्थोगोनल सरणी से कोई दो कॉलम लेते हैं, जहां मान केवल "1" या "2" हो सकते हैं, तो आपको उन कॉलमों के लिए निम्नलिखित पंक्तियाँ मिलेंगी - {1,1}, {1,2}, { 2,1}, और {2,2}। उदाहरण के तौर पर, तीन इनपुट पैरामीटर वाले सिस्टम पर विचार करें, जिनमें से प्रत्येक बाइनरी है (यानी, मान "1" या "2" लेता है)। पंक्तियों परिवर्तनशील 1 परिवर्तनशील 2 परिवर्तनशील 3 1 1 1 1 2 2 1 1 3 1 2 1 4 1 1 2 5 2 2 1 6 1 2 2 7 2 1 2 8 2 2 2 ऑर्थोगोनल ऐरे को इस प्रकार दर्शाया गया है - L_4(2^3), जहां L_4 इंगित करता है कि ऑर्थोगोनल ऐरे में चार पंक्तियाँ हैं, और (2^3) इंगित करता है कि ऐरे में तीन कॉलम हैं, जिनका मान या तो "1" या "2" हो सकता है ". पंक्तियों परिवर्तनशील 1 परिवर्तनशील 2 परिवर्तनशील 3 1 1 1 1 2 1 2 2 3 2 1 2 4 2 2 1 L_4, जहां 4 पंक्तियों की संख्या है 2^3, जहां 2 अधिकतम मान है (== 2, 3,…, N) और 3 स्तंभों की संख्या है ऑर्थोगोनल ऐरे - निम्नलिखित गुण के साथ एक द्वि-आयामी ऐरे है: ऐरे के कोई भी दो कॉलम चुनें, और आपको उन कॉलमों में मानों के सभी संयोजन मिलेंगे। ऑर्थोगोनल सरणियों का उपयोग करना: चर (इनपुट डेटा की संख्या) की पहचान करें। इनपुट डेटा, मूल्यों के किसी भी संयोजन का चयन करना आवश्यक है जो तार्किक रूप से मौजूद हो सकता है। प्रत्येक चर द्वारा लिए जा सकने वाले मानों की संख्या निर्धारित करें। जब तक मूल्यों की संख्या निर्धारित की जाती है, तब तक मूल्यों की संख्या को कम करने के लिए अन्य परीक्षण डिजाइन तकनीकों को पहले ही लागू किया जाना चाहिए (उदाहरण के लिए, सीमा मूल्य, समतुल्य वर्ग और कोई अन्य)। एक ऑर्थोगोनल सरणी निर्धारित करें जहां प्रत्येक वेरिएबल के लिए एक कॉलम होगा (ऑर्थोगोनल एरे के कॉलम में वेरिएबल के समान कई मान विकल्प होते हैं)। परीक्षण कार्य को ऑर्थोगोनल सरणी पर प्रोजेक्ट करें। परीक्षण मामले लिखें. ऑलपेयर्स एल्गोरिथम ऑलपेयर एल्गोरिदम का सार यह है कि सभी चर के लिए मानों के सभी संयोजनों का परीक्षण करने की कोई आवश्यकता नहीं है। इसके बजाय, यह चर के प्रत्येक जोड़े के लिए मूल्यों के सभी संयोजनों का परीक्षण करने पर केंद्रित है। एक क्यूए पेशेवर के रूप में, इन बारीकियों को समझना महत्वपूर्ण है। कुछ मामलों में सैद्धांतिक होते हुए भी, कॉम्बिनेटरियल टेस्ट डिज़ाइन तकनीकों की जटिलता को समझने से क्यूए पेशेवरों को ऐप्स के जटिल व्यावसायिक तर्क का प्रभावी ढंग से परीक्षण करने और अपने उपयोगकर्ताओं को उच्च गुणवत्ता वाले सॉफ़्टवेयर वितरित करने की अनुमति मिलती है।