ग्राफ़ संरचनाओं का उपयोग करके आप यूनिट-टेस्ट कोड कैसे बनाते हैं?


18

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

जबकि आमतौर पर 100% लाइन या ब्रांच कवरेज पर्याप्त है कि कुछ कोड काम करता है, ऐसा लगता है कि 100% पथ कवरेज के साथ भी आपको संदेह है।

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


PS- यदि यह मायने रखता है, तो मेरे ग्राफ के सभी किनारों पर "xor" होना आवश्यक नहीं है "लेबल है और कोई तुच्छ चक्र नहीं हैं, और किसी भी दो नोड्स के बीच केवल एक किनारे है।


PPS- यह अतिरिक्त समस्या कथन मूल रूप से प्रश्न के लेखक द्वारा नीचे टिप्पणी में पोस्ट किया गया था:

For all vertices N in forest F, for all vertices M, in F, such that if there are any walks between N and M they all must either use only edges labelled 'conflict' or 'requires'.


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

@ डंक हम सोचते हैं कि हमारे पास सभी पेचीदा कवर हैं और तब हमें पता चलता है कि एक निश्चित संरचना उन समस्याओं का कारण बनती है जिन्हें हमने पहले नहीं माना था। हर मुश्किल का परीक्षण करना, जिसके बारे में हम सोच सकते हैं कि हम क्या कर रहे हैं, मैं जो ढूंढने की उम्मीद कर रहा हूं, वह कुछ दिशा-निर्देश / प्रक्रियाएँ हैं, जो परेशान करने वाले उदाहरणों को उत्पन्न करने के लिए संभवत: मौलिक रूपों के पुनर्विकास का उपयोग कर रही हैं
Sled

6
परीक्षण के किसी भी रूप के साथ यही समस्या है। आप सभी जानते हैं कि परीक्षण जो आपने काम के बारे में सोचा था। इसका मतलब यह नहीं है कि आपका स्व त्रुटि मुक्त है क्योंकि आपके परीक्षण पास हैं। हर प्रोजेक्ट की यही समस्या है। मैं अपनी वर्तमान परियोजना को वितरित करने के अंतिम चरण में हूं ताकि हम विनिर्माण शुरू कर सकें। अब हमारे सामने आने वाली त्रुटियों के प्रकार अस्पष्ट होते हैं। जैसे कि, जहां हार्डवेयर अभी भी कल्पना करने के लिए काम करता है, लेकिन बस मुश्किल से और जब एक ही मुद्दे के साथ एक साथ अन्य हार्डवेयर के साथ संयुक्त होता है तो समस्याएं होती हैं; लेकिन कभी-कभी :( स्व का अच्छी तरह से परीक्षण किया जाता है, लेकिन हमने सब कुछ नहीं सोचा
डंक

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

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

जवाबों:


5

हम सोचते रहते हैं कि हमारे पास सभी पेचीदा कवर हैं और तब हमें पता चलता है कि एक निश्चित संरचना उन समस्याओं का कारण बनती है जिन्हें हमने पहले नहीं माना था। हर मुश्किल का परीक्षण करना जो हम सोच सकते हैं कि हम क्या कर रहे हैं।

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

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

अंत में, यह स्वीकार करना सीखें कि हर परीक्षा केवल बग के अस्तित्व का प्रमाण दे सकती है, लेकिन बग की अनुपस्थिति नहीं।


5

1. यादृच्छिक परीक्षण पीढ़ी

एक एल्गोरिथ्म लिखें जो ग्राफ़ उत्पन्न करता है, क्या यह कुछ सौ (या अधिक) यादृच्छिक ग्राफ़ उत्पन्न करता है और प्रत्येक को आपके एल्गोरिथ्म में फेंक देता है।

रेखांकन के यादृच्छिक बीज रखें जो दिलचस्प विफलताओं का कारण बनते हैं और उन्हें इकाई परीक्षणों के रूप में जोड़ते हैं।

2. हार्ड-कोड मुश्किल भागों

कुछ रेखांकन संरचनाएं जिन्हें आप जानते हैं कि आप मुश्किल से कोड कर सकते हैं या कुछ कोड लिख सकते हैं जो उन्हें जोड़ती है और उन्हें आपके एल्गोरिथ्म में धकेल देती है।

3. संपूर्ण सूची बनाएं

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


प्रश्नकर्ता ने लिखा है कि वे यह बताने में असमर्थ हैं कि क्या उन्होंने सभी मामलों पर विचार किया है, जिसका अर्थ है कि उनके पास कोई रास्ता नहीं है। जब तक वे समस्या डोमेन को अच्छी तरह से समझ नहीं लेते हैं, तब तक परीक्षण कैसे करना है, यह एक प्रश्न है।
श्रीधाम

@sdenham आप किस तरह से किसी ऐसी चीज़ की गणना करने जा रहे हैं जिसमें लिटरेचर संभव अनंत संख्या में है? मैं "ये सबसे पेचीदा ग्राफ संरचनाएं हैं जो अक्सर आपके कार्यान्वयन में कीड़े को पकड़ लेंगे" की तर्ज पर कुछ खोजने की उम्मीद कर रहे थे। मैं डोमेन को अच्छी तरह समझता हूं क्योंकि यह सरल है: For all vertices N in forest F, for all vertices M, in F, such that if there are any walks between N and M they all must either use only edges labelled 'conflict' or 'requires'.डोमेन समस्या नहीं है।
स्लेज

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

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

4

कोई भी परीक्षण जो इस मामले में पर्याप्त नहीं होने जा रहा है, वास्तविक दुनिया डेटा या फ़ज़िंग के टन भी नहीं। एक 100% कोड कवरेज, या यहां तक ​​कि 100% पथ कवरेज पुनरावर्ती कार्यों का परीक्षण करने के लिए अपर्याप्त है।

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

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

foreach nodes as node
    foreach nodes as tmp
        tmp.status = unmarked

    tovisit = []
    tovisit.push(node)
    node.status = required

    while |tovisit| > 0 do
        next = tovisit.pop()
        foreach next.requires as requirement
            if requirement.status = unmarked
                tovisit.push(requirement)
                requirement.status = required
            else if requirement.status = blacklisted
                return false
        foreach next.collides as collision
            if collision.status = unmarked
                requirement.status = blacklisted
            else if requirement.status = required
                return false
return true

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

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

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

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

जैसा कि आप देख सकते हैं, पहिया को सुदृढ़ करने की कोई आवश्यकता नहीं है, बिल्कुल भी नहीं।


3

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

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


हालांकि यह परीक्षण के लिए एक अच्छा दृष्टिकोण है, यह प्रश्न की केंद्रीय समस्या को हल नहीं करता है: यह सुनिश्चित करने के लिए कि सभी मामलों को कैसे कवर किया जाता है। मेरा मानना ​​है कि, अधिक विश्लेषण की आवश्यकता होगी और संभवत: रिफैक्टरिंग - मेरे प्रश्न को ऊपर देखें।
श्रीधाम


2

जब एल्गोरिथ्म का परीक्षण करने के लिए इस तरह की मुश्किल आती है, तो मैं टीडीडी के लिए जाऊंगा, जहां आप परीक्षणों के आधार पर एल्गोरिथ्म का निर्माण करते हैं,

टीडीडी संक्षेप में,

  • परीक्षण लिखें
  • यह असफल हो रहा है
  • कोड को संशोधित करें
  • सुनिश्चित करें कि सभी परीक्षण पास हो रहे हैं
  • refactor

और चक्र को दोहराएं,

इस विशेष स्थिति में,

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

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

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


2

समस्या की मेरी समझ, जैसा कि मूल रूप से कहा गया है और फिर मैके की प्रतिक्रिया के तहत टिप्पणियों द्वारा अद्यतन किया गया है, में निम्नलिखित शामिल हैं: 1) दोनों प्रकार के किनारे (निर्भरता और संघर्ष) निर्देशित हैं; 2) यदि दो नोड्स एक किनारे से जुड़े हुए हैं, तो उन्हें दूसरे से जुड़ा हुआ नहीं होना चाहिए, भले ही वह दूसरे प्रकार का हो या उल्टा हो; 3) यदि दो नोड्स के बीच एक पथ का निर्माण विभिन्न प्रकारों के किनारों को मिलाकर किया जा सकता है, तो यह एक त्रुटि है, बजाय एक परिस्थिति के जिसे अनदेखा किया गया है; 4) यदि एक प्रकार के किनारों का उपयोग करते हुए दो नोड्स के बीच एक रास्ता है, तो हो सकता है कि दूसरे प्रकार के किनारों का उपयोग करके उनके बीच एक और मार्ग न हो; 5) एकल बढ़त प्रकार या मिश्रित धार प्रकारों के चक्रों की अनुमति नहीं है (आवेदन पर एक अनुमान से, मुझे यकीन नहीं है कि संघर्ष-केवल चक्र एक त्रुटि है, लेकिन इस शर्त को हटाया जा सकता है, यदि नहीं।)

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

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

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

पहले नोड से संयुक्त ग्राफ़ के चौड़ाई-प्रथम ट्रैवर्सल पर, आप प्रत्येक पहुंच योग्य नोड के लिए सभी पथों का सेट बना सकते हैं, और जैसा कि आप ऐसा करते हैं, आप सभी शर्तों के उल्लंघन की जांच कर सकते हैं (चक्र का पता लगाने के लिए, आप कर सकते हैं) टारजन के एल्गोरिथ्म का उपयोग करें ।)

आपको केवल पहले नोड से रास्तों पर विचार करना होगा, भले ही ग्राफ काट दिया जाए, क्योंकि किसी अन्य नोड से पथ किसी अन्य मामले में पहले नोड से पथ के रूप में दिखाई देंगे।

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

यदि आपको एन -1 नोड्स के रेखांकन की जांच में पाए गए रास्ते याद हैं, तो आप उन्हें एन नोड्स के ग्राफ बनाने और मूल्यांकन के लिए शुरुआती बिंदु के रूप में उपयोग कर सकते हैं।

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

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.