Mail.Ru Group में परीक्षण

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

लेख में मैं आपको बताऊंगा कि परीक्षण वास्तव में क्या हो सकता है, हमने परीक्षण को कैसे उत्पादक और दिलचस्प काम बनाया है, हम किन कार्यों को हल करते हैं, और क्यों हम अच्छी तरह से काम करते हैं।

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

परीक्षण: उबाऊ कार्य और दिलचस्प कार्य

कार्यक्रम के पहले संस्करण का परीक्षण करने के लिए क्या करने की आवश्यकता है?

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

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

स्थिति विशेष रूप से कठिन हो सकती है यदि कार्यक्रम को कई अलग-अलग कॉन्फ़िगरेशन में जांचने की आवश्यकता हो। इस स्थिति में, प्रत्येक कॉन्फ़िगरेशन के लिए समान चरणों को दोहराना होगा।

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

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

काम के इस संगठन के साथ, परीक्षण अप्रभावी हो जाता है, और इसमें काम करना वास्तव में दुखद और निर्बाध है।

हमने इस समस्या को कैसे हल किया?

उबाऊ काम से छुटकारा

कॉन्फ़िगरेशन सेटिंग

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

इन सभी समस्याओं को हल करने के लिए, हम Opscode बावर्ची स्वचालित कॉन्फ़िगरेशन सिस्टम का उपयोग करते हैं।

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

त्वरित स्टैंड निर्माण

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

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

तो, परीक्षण बेंच प्रबंधन स्वचालित है, और आप परीक्षण स्वचालन पर आगे बढ़ सकते हैं।

परीक्षण स्वचालन

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

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

स्वचालित रूप से परीक्षण चलाएं

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

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

दिलचस्प कार्यों के उदाहरण

समानांतर सेलेनियम

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

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

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

एक संभावित प्रश्न का अनुमान लगाते हुए, मैं कहना चाहता हूं कि हम वास्तव में चाहते हैं कि हमारे सुधार आधिकारिक सेलेनियम का हिस्सा बनें। हमने अपने पैच जीथब पर पोस्ट किए (उदाहरण के लिए, https://github.com/wladich/operadriver पर ) और उन्हें डेवलपर्स को भेजा। हालांकि, विभिन्न कारणों से, कोई भी पैच पूरी तरह सेलेनियम का हिस्सा नहीं बन पाया है, हालांकि हम अपनी कुछ पंक्तियों को सेलेनियम के नवीनतम संस्करणों के कोड में देखते हैं। हमारे सुधारों का नवीनतम भाग अभी तक नहीं खोला गया है, और यदि सेलेनियम डेवलपर्स को इसमें रुचि है, तो हमें खुशी होगी।

आकस्मिकता ट्रिगर होती है

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

हमने लेट्रेस टूल को संशोधित करके इस समस्या को हल किया।

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

टाइम मशीन

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

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

कॉल और टाइम मशीनों के परिणाम को स्थान देने के लिए कार्यों के साथ लेट्रेस https://github.com/zenovich.lt पर जीथब पर उपलब्ध है।

ब्लूम फ़िल्टर की जाँच करें

हमारे द्वारा हल किए गए दिलचस्प कार्यों में से एक ब्लूम फ़िल्टर की जांच करना था।

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

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

संरचना एम बिट्स की एक छोटी सरणी है। प्रारंभ में, जब डेटा संरचना एक खाली सेट संग्रहीत करती है, तो सभी एम बिट्स शून्य पर रीसेट हो जाते हैं। उपयोगकर्ता को k स्वतंत्र हैश फ़ंक्शंस h ₁ , ..., h _k को निर्धारित करना चाहिए जो प्रत्येक तत्व को बिट एरे के m पदों में से एक में एक समान रूप से एक समान रूप से मैप करता है।

एक तत्व ई जोड़ने के लिए, बिट पदों के प्रत्येक h ₁ ( e ), ..., h _k ( e ) के लिए इकाइयों को लिखना आवश्यक है।

यह जांचने के लिए कि क्या कोई तत्व संग्रहीत तत्वों के सेट से संबंधित है, बिट्स एच ₁ ( ई ), ..., एच _के ( ई ) की स्थिति की जांच करना आवश्यक है। यदि उनमें से कम से कम एक शून्य के बराबर है, तो तत्व सेट से संबंधित नहीं हो सकता है। यदि वे सभी एक के बराबर हैं, तो डेटा संरचना रिपोर्ट करती है कि ई सेट के अंतर्गत आता है। इस स्थिति में, दो स्थितियां उत्पन्न हो सकती हैं: या तो तत्व वास्तव में सेट के अंतर्गत आता है, या ये सभी बिट्स यादृच्छिक रूप से सेट हो जाते हैं जब अन्य तत्व जोड़े जाते हैं, जो इस डेटा संरचना में गलत सकारात्मकता का स्रोत है।
बढ़ते हुए मीटर (बिटमैप के आकार) के साथ झूठी सकारात्मकता की संभावना कम हो जाती है, और बढ़ते एन (सम्मिलित तत्वों की संख्या) के साथ बढ़ जाती है। निश्चित m और n के लिए, इष्टतम संख्या k (हैश फ़ंक्शंस की संख्या) जो इस संभावना को कम करती है (यह मानते हुए कि हैश फ़ंक्शंस के सेट को यादृच्छिक रूप से चुना जाता है, और किसी भी तत्व x के लिए, प्रत्येक हैश फ़ंक्शन h _मैं इसे बिट्स में से एक में असाइन करता है। समान संभावना वाला एक सरणी, और h _i ( x ) के मान सामूहिक रूप से स्वतंत्र यादृच्छिक चर हैं):

।

इस मामले में, झूठी सकारात्मक की संभावना के बराबर है

।

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

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

रैंडम डिलीवरी की जाँच

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

ऐसे कार्यात्मक को सत्यापित करने के लिए, हम पियर्सन मानदंड या or ² मानदंड का उपयोग करते हैं। हम एन प्रश्न बनाते हैं, और सेट के प्रत्येक तत्व के लिए हम गिनते हैं कि इसे कितनी बार वापस किया गया ( ओ _आई )। इस मामले में, हम जानते हैं कि प्रत्येक तत्व को परिकल्पना ( ई _i ) की पूर्ण पूर्ति के साथ कितनी बार वापस किया जाना चाहिए था। इन आंकड़ों के आधार पर, हम मूल्य की गणना करते हैं

।

जब परिकल्पना पूरी हो जाती है, तो यह मात्रा यादृच्छिक होती है (यदि प्रोग्राम बेतरतीब ढंग से तत्वों को देता है) और the- वर्ग वितरण का पालन ​​करना चाहिए। इस प्रकार, दिए गए महत्व स्तर α के लिए, be ² का हमारा मान परिमाण से अधिक होना चाहिए जहां k सेट में तत्वों की संख्या है। यदि ऐसा नहीं है, तो मुद्दा यादृच्छिक नहीं है। दूसरी ओर, हमारा value ² मान मात्रात्मक से कम होना चाहिए अन्यथा परिकल्पना विफल हो जाती है।

, . . N

।

.., , «» 10%, 50 .

, , .

. , , 4000 : ।

सत्यापन के लिए, हमें कार्यक्रम के लिए N = 5 * 4000 = 20,000 अनुरोध करने होंगे। जैसे ही अनुरोधों को निष्पादित किया जाता है, हम प्रत्येक तत्व को गिने हुए सरणी में बूंदों की संख्या के लिए बचाते हैं। यदि आप इसे मल्टीप्रोसेस लागू करते हैं तो यह परीक्षण बहुत तेजी से किया जा सकता है।

अजगर भाषा के लिए एक अद्भुत पुस्तकालय है SciPy , जिसके साथ बहुत आसान है के मूल्य की गणना करने χ ² और पी-मूल्य (यानी, प्रायिकता वितरण के साथ एक यादृच्छिक चर कि χ ² उसके लिए एक मूल्य वास्तविक नहीं की तुलना में कम समय लगता है)। यदि परिकल्पना मानों का एक समान वितरण मानती है, जैसा कि हमारे सरल मामले में है, तो oth ² और P मान को पायथन कोड की इस लाइन का उपयोग करके गणना की जाती है:

chi_square, p_value = scipy.stats.chisquare(counted) 

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

निष्कर्ष

हमारे काम के दौरान, हमने परीक्षण कॉन्फ़िगरेशन, प्रतिगमन परीक्षणों के प्रदर्शन, परीक्षा परिणामों के विश्लेषण और रिपोर्टों के प्रकाशन को स्वचालित किया। चूंकि रोबोट अब यह सब उबाऊ और नीरस काम कर रहे हैं, हम अपना सारा समय दिलचस्प कार्यों में लगा सकते हैं - नए परीक्षण बना रहे हैं, उन्हें स्वचालित कर रहे हैं और नए उपकरण विकसित कर रहे हैं।



इस प्रकार, जैसा कि आप देख सकते हैं, उबाऊ और नीरस काम से छुटकारा पाना एक दिलचस्प और रोमांचक काम का परीक्षण करता है, जिसमें प्रोग्रामिंग, हैकिंग और गणित के लिए एक जगह है।

दिमित्री Zenovich, टेस्ट मैनेजर, Mail.Ru समूह द्वारा पोस्ट किया गया।