परीक्षण में असतत गणित का उपयोग करना

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

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

अपने दैनिक कार्य में, सॉफ्टवेयर क्वालिटी एश्योरेंस (QA) इंजीनियर फॉर्मूला ऑपरेशन, फ़ंक्शन व्यवहार और डेटा संरचनाओं के साथ काम करते हैं। वे हमेशा बदलते सिस्टम की निगरानी और सत्यापन करते हैं, इसलिए उन्हें सॉफ्टवेयर के तर्क को समझने के लिए एल्गोरिथम और गणितीय सोच की आवश्यकता होती है।

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

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

दुर्भाग्य से, हम एक आदर्श दुनिया में नहीं रहते हैं, और सॉफ़्टवेयर और वास्तविक परिणामों का उपयोग करने के अपेक्षित वास्तविक परिणाम भिन्न हो सकते हैं। इसलिए, गुणवत्ता आश्वासन विभाग (क्यूए) का मुख्य लक्ष्य प्रभावी रूप से यथासंभव कई परीक्षण मामलों को कवर करना है।

आपको इस अवधारणा को और अधिक विस्तार से दिखाने के लिए, हमने निम्नलिखित वेन आरेख को एक उदाहरण के साथ बनाया है जिसे हमने पहले उल्लिखित किया था:

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

सिद्धांत सेट करें

मूल सेट सिद्धांत के सिद्धांतों का उपयोग करते हुए, हम अगले दिन के आवेदन के लिए सभी संभावित मामलों को चित्रित करने के लिए छद्म-कोड बना सकते हैं (एक कार्यक्रम जो गणना करता है कि प्रवेश की तारीख का उपयोग करके अगले दिन कौन सा गणना करेगा):

M1={month:month has 30 days} M2={month:month has 31 days except December} M3={month:month is February} M4={month:month is December} D1={day:1<=day<=28} D2={day:1<=day<=29} D3={day:1<=day<=30} D4={day:1<=day<=31} Y1={year:year is a leap year} Y2={year:year is not a leap year} 

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

ग्राफ सिद्धांत

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

सॉफ्टवेयर विकास प्रक्रिया के लिए ग्राफ भी मूलभूत हैं। उदाहरण के लिए, एक ग्राफ़ का उपयोग करके, हम जटिल कार्यों को कई छोटे भागों में विघटित कर सकते हैं, जो हमें व्यापार तर्क को बेहतर ढंग से समझने में मदद करता है।

ग्राफ़ दिशात्मक और गैर-दिशात्मक हो सकते हैं, जिसका अर्थ है कि हम नोड से नोड तक एक दिशा में या दोनों दिशाओं (एक निर्देशित ग्राफ के मामले में) में स्थानांतरित कर सकते हैं, या हम एक नोड से दूसरे में नहीं जा सकते हैं (यदि ग्राफ़ एक में सख्ती से निर्देशित किया गया है दिशा)

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

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

अब कल्पना करें कि नोड्स कुछ संस्थाओं की स्थितियां हैं, और अगर हम इस ग्राफ के लिए आसन्न मैट्रिक्स का निर्माण करते हैं (संस्थाओं का सेट), तो हम उन कार्यों का एक सीमित सेट देखेंगे जो हम ले सकते हैं। उदाहरण के लिए, नोड "0" से नोड "1" की स्थिति बदलना क्योंकि वे एक दूसरे से संबंधित हैं। लेकिन इकाई "0" को "2" या "3" चरण में नहीं बदला जा सकता है, जैसा कि हम अपने मैट्रिक्स से देख सकते हैं - "शून्य" को कोशिकाओं में लिखा गया है। इस मैट्रिक्स का उपयोग करके, हम इकाई चरणों के अनावश्यक सेट को समाप्त कर सकते हैं और परीक्षण मामलों के सेट को कम कर सकते हैं।

एक अन्य मैट्रिक्स जिसे हम परीक्षण मामलों को इकट्ठा करने के लिए उपयोग कर सकते हैं, वह घटना मैट्रिक्स है, जो वस्तुओं के दो वर्गों के बीच संबंध को दर्शाता है। अगले आंकड़े में हम एक अप्रत्यक्ष ग्राफ और इसके घटना मैट्रिक्स देखते हैं: "1", "2", "3" और "4" नोड्स (निकाय), "e1", "e2", "e3" "e4" ग्राफ के किनारे हैं , और मैट्रिक्स उन संस्थाओं और कार्यों को दिखाता है जो हम उनके साथ कर सकते हैं। नोड "1" के साथ हम एक्शन "ई 1", "ई 2" और "ई 3" कर सकते हैं, लेकिन नोड "1." के लिए एक्शन "ई 4" उपलब्ध नहीं है। यह विधि परीक्षण मामलों का एक सेट बनाने में बहुत सहायक है।

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

सॉफ़्टवेयर परीक्षकों का लक्ष्य प्रभावी परीक्षण मामलों का उपयोग करके उत्पाद को कवर करना है जो आपको कार्यों के सभी संभावित संयोजनों का परीक्षण करने की अनुमति देते हैं। परीक्षण मामलों के इष्टतम सेट को खोजने और सॉफ़्टवेयर परीक्षण प्रक्रिया की प्रभावशीलता को अधिकतम करने के लिए असतत गणित दृष्टिकोण (एल्गोरिदम) का उपयोग करके परीक्षक न्यूनतम प्रयास के साथ सफल हो सकते हैं।

असतत गणित हमें यह समझने में भी मदद करता है कि सॉफ्टवेयर वास्तव में कैसे बनाया जाता है, क्योंकि सभी सॉफ्टवेयर एल्गोरिदम और असतत गणित और गणितीय तर्क के तरीकों का उपयोग करते हैं। इसलिए, अगर हम समझते हैं कि यह कैसे काम करता है, तो हम उस प्रोग्राम के भीतर त्रुटियों या समस्याओं का पता लगा सकते हैं जो उपयोगकर्ता द्वारा पता नहीं लगाया जा सकता है।

पेट्री नेट

आइए एक उदाहरण देखें कि पेट्री नेट (डायनेमिक ग्राफ) का उपयोग करके माइक्रोसेवा तकनीक पर एप्लिकेशन कैसे काम करता है:

यहां हम देखते हैं कि सिस्टम में एक प्रारंभिक स्थिति है और कुछ संकेत प्राप्त करना चाहिए जो किसी अन्य सेवा (एक मार्कर प्रकट होता है) से भेजा जाता है। परिणाम के आधार पर, निम्नलिखित कार्रवाई की जानी चाहिए। इस प्रकार, पेट्री नेट पूरे सिस्टम की गतिशीलता को दिखाता है। यदि कोई समस्या मौजूद है, तो हम दोष को तेजी से स्थानीय कर सकते हैं।

तंत्रिका नेटवर्क

कृत्रिम तंत्रिका नेटवर्क भी ग्राफ सिद्धांतों पर आधारित हैं। वे मानव मस्तिष्क के न्यूरॉन्स द्वारा सूचना के प्रसंस्करण की नकल करते हैं। तंत्रिका तंत्र का प्रत्येक भाग एक ग्राफ पर आधारित होता है जिसमें "इनपुट" नोड्स, एक "छिपी हुई" परत और "आउटपुट" नोड्स होते हैं।

कुछ डेटा इनपुट लेयर में जाते हैं, और हिडन लेयर एल्गोरिदम इस डेटा को प्रोसेस करते हैं और आउटपुट स्टेज पर भेजते हैं। इस प्रकार, एक तंत्रिका नेटवर्क इस डेटा के आधार पर क्रियाएं कर सकता है। तंत्रिका नेटवर्क में विभिन्न लॉजिक के साथ कई समान ग्राफ़ शामिल होते हैं, इसलिए वे इनपुट मापदंडों के आधार पर निर्णय ले सकते हैं।

मिलेनियम परीक्षण

परीक्षण में असतत गणित का उपयोग करने के हमारे अंतिम उदाहरण में सॉफ्टवेयर परीक्षण प्रक्रिया का निर्माण करना शामिल है। वर्तमान में, "मिलेनियम परीक्षण" नामक कई कार्यप्रणाली और दृष्टिकोण हैं, जो कि उनके वास्तविक उपयोग से बहुत पहले विकसित किए गए थे, जो 2000 के दशक में शुरू हुए, जब सॉफ्टवेयर विकास तेजी से विकसित होना शुरू हुआ।

BDD (बिहेवियर ड्रिवेन डेवलपमेंट) तथाकथित मिलेनियम टेस्टिंग का हिस्सा है, यह कार्यप्रणाली TDD (टेस्ट ड्रिवेन डेवलपमेंट) का विस्तार है। BDD परीक्षकों को किसी दिए गए फ़ंक्शन के लिए स्वीकृति मानदंड और इस कार्यक्षमता का परीक्षण करने के लिए उपयोग किए जाने वाले परीक्षणों के बीच घनिष्ठ संबंध स्थापित करने की अनुमति देता है। BDD एक प्राकृतिक भाषा में संरचित कथनों को निष्पादन योग्य परीक्षणों में बदल सकता है, जिससे व्यावसायिक पक्ष और विकास पक्ष में अधिक स्पष्टता और समझ का परिचय होता है, क्योंकि वे एक सामान्य भाषा बोलने लगते हैं। BDD वर्कफ़्लो की मूल संरचना एक डायनेमिक ग्राफ़ (पेट्री नेट) पर भी आधारित है।

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

अंत में, मैं एक बार फिर से सॉफ्टवेयर विकास प्रक्रिया में असतत गणित का उपयोग करने के लाभों की सूची बनाना चाहूंगा:

• आवश्यक कार्यक्षमता के व्यावसायिक तर्क को समझने में सहायता
• जटिल कार्यों को सरल लोगों में विभाजित करने की क्षमता को सरल बनाएं
• कम प्रयास के साथ प्रभावी परीक्षण करने के लिए पेशेवरों को सक्षम करना
• हम जो कुछ भी चाहते हैं उसकी संरचना को समझने और कल्पना करने में सहायता करें

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