paint-brush
परीक्षण एल्गोरिदम में सुधार: सॉफ्टवेयर परीक्षण में गणितीय दृष्टिकोणद्वारा@shad0wpuppet
23,867 रीडिंग
23,867 रीडिंग

परीक्षण एल्गोरिदम में सुधार: सॉफ्टवेयर परीक्षण में गणितीय दृष्टिकोण

द्वारा Konstantin Sakhchinskiy7m2024/01/24
Read on Terminal Reader
Read this story w/o Javascript

बहुत लंबा; पढ़ने के लिए

लेख परीक्षण पद्धतियों की पड़ताल करता है, कोड कवरेज को अनुकूलित करने में गणितीय मॉडल की भूमिका पर जोर देता है। इसमें तार्किक अभिव्यक्तियों को न्यूनतम करने, जोड़ीवार परीक्षण को अनुकूलित करने और एल्गोरिदम का उपयोग करके बदलते सिस्टम स्थितियों का परीक्षण करने पर चर्चा की गई है। मुख्य निष्कर्ष न्यूनतम प्रयास के साथ अधिकतम परीक्षण कवरेज प्राप्त करने में इन तरीकों की प्रभावकारिता पर प्रकाश डालते हैं। इन एल्गोरिदम को विभिन्न प्रणालियों में अनुकूलित करने में चुनौतियाँ और अंतर्दृष्टि हैं। प्रभावी परीक्षण के लिए सैद्धांतिक नींव को समझना महत्वपूर्ण है।
featured image - परीक्षण एल्गोरिदम में सुधार: सॉफ्टवेयर परीक्षण में गणितीय दृष्टिकोण
Konstantin Sakhchinskiy HackerNoon profile picture
0-item

नई परीक्षण डिज़ाइन पद्धतियाँ हमेशा एक साथ सामने नहीं आती हैं। आधुनिक परीक्षण प्रथाओं का एक महत्वपूर्ण हिस्सा गणितीय मॉडल को अपनाने में सावधानीपूर्वक सैद्धांतिक और प्रयोगात्मक कार्य के माध्यम से विकसित हुआ है। हालाँकि एक अच्छा परीक्षक बनने के लिए गणितज्ञ होना आवश्यक नहीं है, परीक्षण विधियों के पीछे के सैद्धांतिक आधार को समझना फायदेमंद हो सकता है।

कवरेज को अधिकतम करना और परीक्षण मामलों की संख्या को न्यूनतम करना

किसी सिस्टम के लिए कोड कवरेज को अनुकूलित करने के लिए गणितीय तर्क लागू किया जा सकता है। आइए "if" कथन के साथ एक सरल उदाहरण पर विचार करें जिसमें दो शाखाएँ और स्थिति में एक लंबा तार्किक सूत्र है:

 if ( (& a2) & (!(a2 || a4) ) || a3 ) { # action 1 } else { # action 2 }


दोनों शाखाओं को कवर करने के लिए सूत्र की संरचना को समझना आवश्यक है। किसी को आश्चर्य हो सकता है कि क्या किया जा सकता है? आप हमेशा कोड के इस टुकड़े (तार्किक सूत्र) का विस्तृत परीक्षण कर सकते हैं, जिसके परिणामस्वरूप 16 परीक्षण होंगे। हालाँकि, यह काफी है और परीक्षणों की संख्या कम करने के प्रयास किये जाने चाहिए। संशोधित स्थिति/निर्णय कवरेज (एमसी/डीसी) पद्धति (11-12 परीक्षण प्राप्त करने) का उपयोग करके परीक्षणों की संख्या को कम किया जा सकता है। यदि शाखा कवरेज जोखिमों के परीक्षण के लिए पर्याप्त है, तो केवल दो परीक्षणों की आवश्यकता है, लेकिन यह स्पष्ट नहीं है कि कौन से परीक्षण होंगे।


इस समस्या को हल करने के लिए, बूलियन बीजगणित को तार्किक सूत्र पर लागू किया जा सकता है:

 if( (& a2) & (! (a2 || a4) ) || a3 ) = = ( (& a2) & ( (!a2 || !a4) ) || a3 ) = = ( a1 & a2 & !a2 & !a4 || a3 ) = = 0 || a3 = a3


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


निष्कर्ष के तौर पर:

  • यदि संपूर्ण परीक्षण का उपयोग किया जाता है तो 2 परीक्षण

  • एमसी/डीसी पद्धति से 2 परीक्षण

  • यदि शाखा कवरेज लागू है तो 2 परीक्षण


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

जोड़ीवार परीक्षण का अनुकूलन

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


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

  • Pairwise finds 65-97% of errors
  • 3-way finds 89-99% of errors
  • 4-way finds 96-100% of errors
  • 5-way finds 96-100% of errors
  • 6-way finds 100% of errors

अध्ययनों के अनुसार, जोड़ीवार परीक्षण में 65-97% मामलों में त्रुटियाँ पाई जाती हैं। यदि हम मापदंडों के जोड़े को नहीं बल्कि त्रिगुणों या चतुर्गुणों को संयोजित करना शुरू करते हैं, यानी, के-वे परीक्षण का उपयोग करते हुए, हमें अधिक संख्या में परीक्षण मिलते हैं लेकिन अधिक त्रुटियां भी मिलती हैं।


उदाहरण के लिए, मान लीजिए कि किसी सिस्टम में तीन मान वाले दो पैरामीटर हैं और प्रत्येक दो मान वाले तीन पैरामीटर हैं:

  • Pairwise: 10 tests with 14% coverage
  • 3-way: 18 tests with 25% coverage
  • 4-way: 36 tests with 50% coverage
  • 5-way: 72 tests with 100% coverage

आप परीक्षण कवरेज का संतोषजनक स्तर और परीक्षण मामलों की स्वीकार्य संख्या चुन सकते हैं।

जोड़ीवार का आधार ऑर्थोगोनल सरणियाँ हैं जिनमें बराबर संख्या में मानों के n-टुपल्स (जोड़े, त्रिगुण, चतुर्भुज, ...) होते हैं।


जोड़ीवार और के-वे परीक्षण के लिए सामान्य आधार OA(N, V^k, t) है, जहां:

  • N पंक्तियों की संख्या है

  • k स्तंभों की संख्या है

  • V एक कॉलम में विभिन्न मानों की संख्या है

  • t ताकत है (जोड़ी के लिए t=2)


OA में, t कॉलम के प्रत्येक सेट में सभी t टुपल्स को समान संख्या में शामिल किया जाता है।

ऑर्थोगोनल मैट्रिसेस के बजाय, कवरिंग मैट्रिसेस का उपयोग करना बेहतर है। ये आव्यूह ऑर्थोगोनल आव्यूहों से इस मायने में भिन्न हैं कि मानों का प्रत्येक सेट कम से कम एक बार आता है, "समान संख्या में" नहीं। ऐसे में टेस्ट थोड़े कम होते हैं. कवरिंग मैट्रिसेस के साथ गलत परीक्षण मामले सामने आ सकते हैं, लेकिन कुल मिलाकर, परीक्षण प्रक्रिया बहुत तेज है। इस प्रकार, परीक्षण प्रक्रिया काफी सरल हो गई है।

सीए(एन, वी^के, टी), जहां:

  • N पंक्तियों की संख्या है
  • k स्तंभों की संख्या है
  • V एक कॉलम में विभिन्न मानों की संख्या है
  • t ताकत है (जोड़ी के लिए t=2)

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

सिस्टम स्थितियाँ और बदलती सिस्टम अवस्थाओं का परीक्षण

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


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


ग्राफ़ और परिमित ऑटोमेटा

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

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


आइए स्थिति का विश्लेषण करने के लिए निम्नलिखित उदाहरण पर विचार करें:

तीन परीक्षक हैं. पहला पहला परीक्षण करेगा, दूसरा - दूसरा परीक्षण, तीसरा - तीसरा परीक्षण करेगा। पहले दो पहले दो परीक्षणों को बहुत जल्दी पूरा कर लेंगे क्योंकि रास्ते छोटे हैं (तीसरे की तुलना में, क्योंकि पहले दो रास्ते छोटे हैं), लेकिन आखिरी वाले में बहुत लंबा समय लगेगा (क्योंकि तीसरा रास्ता बहुत छोटा है) लंबा)।

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


हम अधिक परीक्षणों के साथ समाप्त हो सकते हैं, लेकिन समानांतर निष्पादन के मामले में, परीक्षण बहुत तेजी से समाप्त होंगे क्योंकि परीक्षण छोटे होते हैं।


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


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


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


मुख्य निष्कर्षों पर इस प्रकार विचार किया जा सकता है:


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


जहाँ तक छोटी-मोटी कमियों का सवाल है, यह ध्यान देने योग्य है:


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

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