🖱️ 🐔 👩‍👩‍👧‍👧 परीक्षण में द्विसंयोजक विभाजन विधि 🏬 🍷 😷

सामग्री

कभी-कभी कीड़े हमें खुद ही मिल जाते हैं। इसलिए हमने डेटा की एक बड़ी पंक्ति को देखा - और सिस्टम लटका दिया। क्या 1 मिलियन पात्रों के कारण यह गिर गया? या वह एक विशेष की तरह नहीं था?

या फ़ाइल सिस्टम पर अपलोड की गई थी और वह क्रैश हो गई थी। क्यों? नाम, विस्तार, डेटा के अंदर या आकार के कारण? आप डेवलपर पर स्थानीयकरण को धक्का दे सकते हैं, उसे यह सोचने दें कि फ़ाइल में क्या बुरा है। लेकिन अक्सर आप स्वयं कारण पा सकते हैं, और फिर समस्या का अधिक सटीक वर्णन कर सकते हैं।

यदि आपको खेलने के लिए न्यूनतम डेटा मिलता है, तो:

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

बग खेलने के लिए न्यूनतम डेटा कैसे प्राप्त करें? यदि लॉग में कोई संकेत हैं, तो उन्हें लागू करें। यदि कोई सुराग नहीं है, तो सबसे अच्छा तरीका द्विविभागीय विभाजन विधि है (जिसे "द्विभाजन" या "द्विभाजन" विधि के रूप में भी जाना जाता है)।

विधि का वर्णन

गिरने के लिए सटीक स्थान खोजने के लिए विधि का उपयोग किया जाता है:

डेटा का गिरता हुआ पैकेट लें।
आधे में टूट गया।
आधा आधा जांचें
- अगर यह गिर गया, तो समस्या है। हम उसके साथ आगे काम करते हैं।
- यदि यह गिरता नहीं है तो → आधा 2 जांचें।
1-3 चरण दोहराएँ जब तक एक गिरता मूल्य रहता है।

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

परीक्षकों द्वारा आवेदन

डेटा पंक्ति

1 मिलियन डेटा की एक लाइन लोड की गई - सिस्टम जमा देता है।
हम 500 हजार की कोशिश करते हैं (आधे में विभाजित) - यह अभी भी लटका हुआ है।
हम 250 हजार की कोशिश करते हैं - यह लटका नहीं है, सब कुछ ठीक है।

↓

इसलिए निष्कर्ष यह है कि समस्या 250 और 500 हजार के बीच है। फिर से हम द्विविभागीय विभाजन को लागू करते हैं।

हम 350 हज़ार का प्रयास करते हैं (इसे "आँख से विभाजित करना" - यह काफी स्वीकार्य है, आपको मैन्युअल रूप से खेलते समय सटीक संख्या में नहीं चलना होगा) - सब कुछ ठीक है
हम 450 हजार की कोशिश करते हैं - यह बुरा है।
हम 400 हजार की कोशिश करते हैं - यह बुरा है।

↓

सामान्य तौर पर, आप पहले से ही एक बग प्राप्त कर सकते हैं। परीक्षक को यह रिपोर्ट करने के लिए बहुत कम ही आवश्यकता होती है कि सीमा या बग स्पष्ट रूप से 286 586 की संख्या में है। यह लगभग स्थानीय करने के लिए पर्याप्त है - 290 हजार।

यह "10" और तुरंत "300 हजार" की जांच करने के लिए सिर्फ एक चीज है, और अधिक पूरी जानकारी प्रदान करने के लिए यह पूरी तरह से अलग है: "10 हजार तक सब कुछ ठीक है, 10 से 280 हजार ब्रेक शुरू होते हैं, यह पहले से ही 290 हजार तक गिर जाता है"।

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

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

फ़ाइल

एक फ़ाइल अपलोड की गई - दुर्घटनाग्रस्त! कैसे, क्यों? सबसे पहले, हम अपने लिए विश्लेषण करने की कोशिश करते हैं कि हमारे परीक्षण का परीक्षण क्या प्रभावित कर सकता है? यह मुख्य नियम चिप है "पहले सकारात्मक, फिर नकारात्मक।" यदि आप एक बार में एक परीक्षण में सब कुछ सामान करने की कोशिश नहीं करते हैं:

एक छोटी नमूना फ़ाइल की जाँच की
हमने कॉलम की एक गुच्छा, स्तंभों का एक गुच्छा, और आंतरिक डेटा के विभिन्न रूपों के साथ एक विशाल 2 जीबी फ़ाइल की जांच की

यहां स्थानीयकरण करना कठिन होगा। और यदि आप चेक अलग करते हैं:

बहुत सारी लाइनें (लेकिन डेटा सकारात्मक और पहले सत्यापित है)
कई कॉलम
भारी वजन
...

यह पहले से ही लगभग समझ में आता है, क्या कारण है। उदाहरण के लिए, यह बड़ी संख्या में लाइनों पर पड़ता है - 100 हजार से। ठीक है, हम द्विविभागीय विभाजन का उपयोग करके अधिक सटीक सीमा की तलाश कर रहे हैं:

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

यदि ड्रॉप लाइनों की संख्या पर निर्भर करता है, तो हम एक अनुमानित सीमा की तलाश करते हैं: "5000 के बाद गिरता है, 4000 हजार नहीं होते हैं।" किसी विशिष्ट स्थान (4589) की खोज करना आवश्यक नहीं है। बहुत लंबा और समय के लायक नहीं।

यह बग छात्रों को दादात में मिला था। डेटा फ़ाइलों को वहां लोड किया जा सकता है, सिस्टम इस डेटा को संसाधित और मानकीकृत करेगा: सही टाइपोस, निर्देशिकाओं से गायब जानकारी (KLADR कोड, FIAS, भू-निर्देशांक, शहर जिला, ज़िप कोड ...)।

लड़की ने एक बड़ी फ़ाइल डाउनलोड करने की कोशिश की और परिणाम मिला: सिस्टम 100% लोड पर प्रगति बार दिखाता है और 30 मिनट से अधिक समय तक लटका रहता है।

स्थानीयकरण आगे बढ़ गया - फ्रीज कब शुरू होता है? यह महत्वपूर्ण है क्योंकि यह कार्य की प्राथमिकता को प्रभावित करता है। विशिष्ट डाउनलोड आकार क्या है? उपयोगकर्ता कितनी बार सीधे LOTS जहाज करते हैं?

हो सकता है कि सिस्टम को हजारों लाइनों को संसाधित करने के लिए डिज़ाइन किया गया हो, तो इस तरह के बग को "किसी दिन ठीक करें" में ढंक दिया जाता है। या विशिष्ट डाउनलोड - 10-50 हजार लाइनें जो सामान्य रूप से प्रक्रिया करती हैं, ठीक है, इसका मतलब है कि बग नहीं जल रहा है, हम इसे थोड़ा बाद में ठीक कर देंगे।

कार्य स्थानीयकरण:

50 हजार पंक्तियों वाली फ़ाइल के लिए, 15 सेकंड लटकाएं,
100 हज़ार लाइनों वाली फ़ाइल के लिए, 30 सेकंड लटकाएं,
150 हज़ार लाइनों वाली फ़ाइल के लिए, 1 मिनट हैंग होता है,
165 हज़ार लाइनों वाली एक फ़ाइल के लिए 4 मिनट,
एक फ़ाइल के लिए 100% पूर्ण प्रगति पट्टी के साथ 172 हजार लाइनें आधे घंटे से अधिक समय तक जमा होती हैं

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

सत्यापन में भी अधिक समय नहीं लगता है। आप जा सकते हैं या अंत से - यहां हमने 200 हजार लाइनें डाउनलोड की हैं, और समस्या कब शुरू होती है? हम द्विविभागीय विभाजन विधि का उपयोग करते हैं!

या अपेक्षाकृत कम संख्या के साथ शुरू करें - 50 हजार, धीरे-धीरे बढ़ते हुए (आधे से, द्विविभागीय विभाजन की विधि, बस विपरीत)। यह जानते हुए कि 200 हजार पर सब कुछ खराब होगा, हम समझते हैं कि कई परीक्षण नहीं होंगे। हमने 50, 100, 150 की जाँच की - तीन परीक्षणों के लिए हमें एक अनुमानित सीमा मिली। और फिर खुदाई करना अब आवश्यक नहीं है।

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

यद्यपि आप बिल्कुल सकारात्मक मूल्य के साथ 10 हजार लाइनें आजमा सकते हैं। संभव है कि गिरावट फिर से हो। बस आपकी स्रोत फ़ाइल कई स्तंभों पर थी। या अंदर ऐसे पात्र थे जो सकारात्मक मूल्य से अधिक बाइट्स लेते थे ... सामान्य तौर पर, फ़ाइल आकार या लाइनों की संख्या के सिद्धांत को तुरंत अस्वीकार नहीं करते हैं। इसके विपरीत द्विविभागीय विभाजन का प्रयास करें - फ़ाइल को डबल करें।

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

लेकिन क्या होगा यदि समस्या पंक्तियों की संख्या में नहीं है, लेकिन डेटा में ही है? और आपको नहीं पता कि वास्तव में कहां है। शायद आपने "वॉर एंड पीस" के डेटा को एक परीक्षण फ़ाइल में बदल दिया, या इंटरनेट पर कहीं से एक बड़ी स्प्रेडशीट डाउनलोड की ... या उपयोगकर्ता को एक समस्या मिली - उसने अपनी फ़ाइल अपलोड की और सब कुछ नीचे गिर गया। वह समर्थन करने के लिए आया था, समर्थन आपके पास आया था: फ़ाइल आप पर है, इसे खेलें।

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

लेकिन अगर आपको खुद एक गलती मिली है, यानी खुद को खोदने का समय। फिर, सामान्य ज्ञान को नहीं भूलना, हमेशा स्थानीयकरण के साथ। पहले तो हमने खुद निष्कर्ष निकालने की कोशिश की, फिर मदद के लिए गए। खुद निष्कर्ष निकालने के लिए, आपको चाहिए:

लॉग की जांच करें, सही उत्तर हो सकता है;
फ़ाइल की सामग्री देखें: कुछ आपकी आंख को पकड़ सकता है, यह पहला सिद्धांत है;
द्विविभागीय विभाजन विधि का उपयोग करें।

नतीजतन, "फॉल्स फ़ाइल, क्यों xs, यहाँ 2GB फ़ाइल अटैचमेंट" बग के बजाय, आपने एक अच्छी तरह से सोची-समझी और लोकल बग डाल दिया: "अगर डीडी / MM / YYYYY प्रारूप की तारीख अंदर है तो फाइल गिर जाती है"। और फिर आपको पहले से 2GB फ़ाइल की आवश्यकता नहीं है, आपको केवल एक लाइन और एक कॉलम के लिए एक फ़ाइल की आवश्यकता है!

डेवलपर्स द्वारा आवेदन

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

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

1000 प्रविष्टियाँ मिलीं
200 रिकॉर्ड की प्रक्रिया की
400 रिकॉर्ड बनाए गए
ओह, 200 रिकॉर्ड के एक पैकेट पर गिर गया!
मैं आकार 100 के एक पैकेट को संसाधित करने का प्रयास करता हूं
मैं आकार 50 के एक पैकेट को संसाधित करने का प्रयास करता हूं
मैं आकार 25 के पैक को संसाधित करने का प्रयास करता हूं

...
ऐसे पहचानकर्ताओं पर त्रुटि: आवश्यक ईमेल फ़ील्ड नहीं भरी गई है
600 रिकॉर्ड बनाए गए

...

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

लेकिन क्या होगा अगर पूरा पैक अलग हो जाए? हमने रिकॉर्ड को त्रुटिपूर्ण के रूप में चिह्नित किया है, लेकिन शेष 199 भी प्रक्रिया में असमर्थ थे। क्यों? हम एक ही विधि लागू करते हैं, एक नई समस्या की तलाश में। चाल यह है कि आपको हमेशा समय पर रोकने में सक्षम होने की आवश्यकता है।

यदि त्रुटियों की संख्या 10-50-100 से अधिक है, तो डाउनलोड को रोकना बेहतर है। यह संभव है कि मूल प्रणाली में एक अपलोड त्रुटि हुई और हमें डेटा का एक लाख "घटता" प्राप्त हुआ। यदि सिस्टम 200 के प्रत्येक पैक को आधे में विभाजित करेगा, और फिर शेष 199 को विभाजित करेगा, और इसी तरह, तो यह सभी के लिए बुरा होगा:

लॉग सामान्य 15 एमबी से 3 जीबी तक बढ़ता है और अपठनीय हो जाता है;
अंतिम त्रुटि संदेश उत्पन्न करने की कोशिश करने पर सिस्टम क्रैश हो सकता है (मैंने बीएमडब्ल्यू मेनेमोनिक्स सेक्शन में इस स्थिति के बारे में बात की);
सभी त्रुटियों की खोज में बहुत समय व्यतीत होता है। हां, सिस्टम इसे एक व्यक्ति की तुलना में तेजी से करता है, लेकिन यदि आप 200 रिकॉर्ड के एक लाख पैक को विभाजित करते हैं, तो इसमें समय लगेगा।

इसलिए मस्तिष्क को हर जगह शामिल किया जाना चाहिए - मैन्युअल परीक्षण और प्रोग्राम कोड लिखते समय। आपको हमेशा समझना चाहिए कि कब रुकना है। केवल मैन्युअल परीक्षण के मामले में यह "सीमा को खोजने के बारे में" होगा, और विकास में "बंद करो अगर बहुत सारे गिरते हैं"।

सारांश

बग के गिरने और स्थानीयकरण के सटीक स्थान की खोज के लिए द्विविभागीय विभाजन की विधि का उपयोग किया जाता है।

संख्या देखें और इसे आधे में विभाजित करना शुरू करें:

लाइन की लंबाई;
फ़ाइल का आकार
फ़ाइल वजन;
पंक्तियों / स्तंभों की संख्या;
एक मोबाइल फोन में मुफ्त मेमोरी की मात्रा;
...

लेकिन याद रखें - किसी दिन आपको रोकना होगा! हजारों अतिरिक्त परीक्षणों की आवश्यकता होने पर सटीक संख्या को रोकने और देखने की आवश्यकता नहीं है। लेकिन 5-10 मिनट स्थानीयकरण के लिए दिया जा सकता है।

PS - "उपयोगी" टैग द्वारा मेरे ब्लॉग पर अधिक उपयोगी लेख देखें

परीक्षण में द्विसंयोजक विभाजन विधि