संभाव्य इकाई परीक्षण। (अराजकता संचालित इकाई परीक्षण।)

सभी या कम जटिल सॉफ्टवेयर सिस्टम में त्रुटियां होती हैं (यदि उनका अपना नहीं है, तो उपयोग किए गए पुस्तकालयों से प्रेरित हैं या उपयोग किए गए ढांचे के व्यवहार प्रतिमानों की गलत जागरूकता के कारण)।

अक्सर, विकास के स्तर पर प्रणाली का परीक्षण करने के लिए इकाई परीक्षणों का उपयोग किया जाता है।



तो प्रोग्रामर नियंत्रण बिंदुओं और सीमा मूल्यों पर प्रणाली के व्यवहार को नियंत्रित कर सकता है।

अक्सर यह सीमा मूल्यों का गलत प्रसंस्करण है जो समस्याओं की ओर जाता है। और अनुभवी प्रोग्रामर इसे जानते हैं और यूनिट परीक्षणों को डिजाइन करते समय इसे ध्यान में रखते हैं।



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



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



हालांकि, कोई भी उपयोगकर्ता हमेशा यादृच्छिकता का एक तत्व वहन करता है।



एक अनुभवी प्रोग्रामर एक गुणवत्ता परीक्षक की प्रतिभा को जोड़ता है और कार्यक्रम जारी होने से पहले कई त्रुटियों को पकड़ सकता है।



यदि प्रोग्राम "हैलो वर्ल्ड!" प्रिंट से अधिक करता है, तो छिपी हुई त्रुटियां वैसे भी बनी रहती हैं।

यह तर्क में भी त्रुटि हो सकती है।



कार्यक्रम संकलित करता है, सभी वार्निंग को समाप्त कर दिया जाता है ... लेकिन कभी-कभी कुछ गलत हो जाता है ... उपयोगकर्ता के लिए (जो प्रशांत महासागर में एक द्वीप पर एक घर में बहुत दूर रहता है - उसके पास आने और महसूस करने का कोई तरीका नहीं है)। प्रोग्रामर ने बुलाया और वह सब कुछ परीक्षण किया जो वह कर सकता था, लेकिन कोई त्रुटि नहीं मिली। क्या करें?



किसी भी एप्लिकेशन को एक तार्किक नेटवर्क से जुड़े इंटरकनेक्टेड सी घटकों के एक सरणी के रूप में माना जा सकता है।

प्रत्येक घटक इनपुट के रूप में I के तर्क को स्वीकार करता है, और O को उसके आउटपुट के रूप में आउटपुट करता है।

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



इसलिए हम एक यादृच्छिक डेटा सेट के साथ प्रत्येक घटक का परीक्षण करते हैं। विधि को घटकों या चयनित सबनेट से बने एक पूर्ण नेटवर्क तक बढ़ाया जा सकता है।



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



हम अधिक से अधिक यादृच्छिक डेटा के हजारों पुनरावृत्तियों को चलाते हैं, इस डेटा पर यादृच्छिक (वैध) संचालन से घटकों का चयन और अनुरोध करते हैं।



बेशक, 1 चरण में, आपको अखंडता नियंत्रण सबसिस्टम को कॉन्फ़िगर करना होगा, लेकिन फिर सब कुछ घड़ी की कल की तरह चलेगा।

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



त्रुटि की तलाश करने से पहले, इस स्क्रिप्ट को न्यूनतम लंबाई तक कम करने की कोशिश की जा सकती है, ताकि त्रुटि अभी भी दिखाई दे।

त्रुटि को समाप्त करने के बाद, यह स्क्रिप्ट विफलताओं के बिना काम करना चाहिए, और हमारे पास भविष्य के लिए हमारे परीक्षणों के गुल्लक में एक और यूनिट परीक्षण है।



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

निम्नलिखित कार्यों को प्रतिष्ठित किया जा सकता है:

• शब्द जोड़ें
• मौजूदा शब्द को अर्थ पर सेट करें
• शब्द हटाओ
• अखंडता की जाँच करें

टेस्ट कोड रूपरेखा (उद्देश्य-सी पर टुकड़ा):

 srand (समय (0));

 NSMutableString * log = [NSMutableString string]; // कमांड के लिए
 int prev = -1;
 अहस्ताक्षरित i;
 #define ST_COUNT 2000

 आईडी मॉडल = [SomeModelFactory createModelObject];

 के लिए (i = 0; स्थिति && i <ST_COUNT; i ++)
 {
     int todo;
     करना
     {
         todo = रैंड ()% 4;
     }
      जबकि (3 == todo && todo == prev);
     prev = todo;

     if (i + 1 == ST_COUNT) // अंतिम पुनरावृति।
         todo = 3; // बल int।  चेक

     स्विच (टूडू)
      {
         स्थिति 0: // मॉडल में नया शब्द जोड़ें
         {
             ...
         }
         स्थिति 1: // मौजूदा शब्द सेट करें
         {
             ...
         }
         स्थिति 2: // शब्द हटा दें
         {
             ...
         }
         केस 3: // पिंट।  चेक
         {
             अगर (i + 1 == ST_COUNT || रैंड ()% 2)
             {
                 ...
                 स्थिति = 3; // विफल होने पर कुछ त्रुटि कोड सेट करें
             }
         }
     }
 }

 अगर (स्थिति)
 {
     [लॉग राइट टाइप करें: @ "/ tmp / command.log" atomically: YES एन्कोडिंग: NSUTF8StringEncoding त्रुटि: NULL];
     निकास (स्थिति);
 }

तर्क जनरेटर:

 चार जीनहार ()
 {
     // अनुमति दी
     स्थिर चार की अनुमति [] = "ABCDEFGHIJKLMNOPQRSTUVWXUZabcdefghijklmnopqrstuvwxyz1234567890/";
     वापसी की अनुमति दी [रैंड ()% (sizeof (अनुमति) -1)];
 }

 एनएसएसट्रिंग * जीनवर्ड (इंट मिन, इंट मैक्स)
 {
     NSMutableString * res = [NSMutableString string];

     यदि (अधिकतम <मिनट)
         अधिकतम = मिनट;

     int toen = min + rand ()% (अधिकतम - न्यूनतम + 1); 

     int i;
     के लिए (i = 0; i <toGen; i ++)
          [Res appendFormat: @ "% c", genChar ()];

     वापसी Res;
 }

आप सभी त्रुटि लॉग / tmp से स्थानांतरित कर सकते हैं, उदाहरण के लिए, मामले फ़ोल्डर के लिए, केस -1, केस -2, ... फ़ोल्डर के लिए

ताकि भविष्य में केस नंबर से कोई भी जांच चल सके।



कुछ कार्यों (ऊपर सूचीबद्ध वस्तुओं से) चुनने की संभावना को समायोजित किया जा सकता है।

इसलिए, अखंडता जांच हर पुनरावृत्ति नहीं की जा सकती है, और विफलता की स्थिति में, आप प्रत्येक ऑपरेशन के बाद चेक का प्रदर्शन करते हुए, जगह की सही पहचान कर सकते हैं।

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



सत्यापन प्रणाली को प्रभावित करने के लिए, आप तर्क जनरेटर के आउटपुट को बदल सकते हैं - अधिक चौराहों को मजबूर कर सकते हैं ... और इस प्रकार कुछ घटनाओं की घटना की संभावना को स्थानांतरित कर सकते हैं।

उपरोक्त उदाहरण के लिए, हम 1 से 10 अक्षरों और 1 से 100 अक्षरों के लेखों से शब्द उत्पन्न कर सकते हैं।

हम परिस्थितियों को बदल सकते हैं और क्रमशः 1-3 अक्षरों और लेखों में 1 से 10 अक्षरों तक के शब्द उत्पन्न कर सकते हैं, हम खुद को अन्य त्रुटियों के संभावित क्षेत्र में पा सकते हैं।

हम उपलब्ध संचालन को चुनने की संभावना को भी प्रभावित कर सकते हैं और या तो शब्दकोश को तेजी से बढ़ा सकते हैं या नाटकीय रूप से अपना वजन कम कर सकते हैं।

हम भी पसंद संभावनाओं की राजनीति को एक यादृच्छिक तरीके से बदल सकते हैं, एक हवा की तरह जो दिशा बदलती है ...



वास्तव में, केवल हमारी परियोजना में संभाव्य परीक्षण पद्धति के लिए धन्यवाद, जिसने पहले से ही परीक्षण किए गए इंजन में 5 छिपे हुए और बहुत ही परिष्कृत त्रुटियों को पकड़ा जिसमें खराबी के कोई संकेत नहीं थे!



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