परीक्षकों के लिए गणित

निकिता नाइलूटिन द्वारा एसक्यूए डेज़ सम्मेलन में रिपोर्ट - 13 अप्रैल, 26-27, 2013 सेंट पीटर्सबर्ग, रूस

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




शुभ दोपहर, प्रिय सहयोगियों! मेरा नाम निकिता नेलुटिन है । मुझे उम्मीद है कि मैं परीक्षण में थोड़ी गणित की बात के साथ आपकी दोपहर की झपकी को रोशन कर सकता हूं। सबसे पहले, मैं इस बारे में थोड़ी बात करूंगा कि मैं कौन हूं और मैं परीक्षण के लिए कैसे आया।

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



आज हम किस बारे में बात करेंगे? हमें परीक्षण में गणित की आवश्यकता क्यों है। हम गणित के बिना परीक्षा क्यों नहीं दे सकते। जिन मामलों में यह विकल्प संभव है, और जिनमें नहीं। कुछ उदाहरणों के लिए, आइए देखें कि गणित को व्यवहार में कैसे लागू किया जा सकता है। कैसे और कहाँ देखना है जब हम कुछ नया परीक्षण करना शुरू करते हैं।



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



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



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



वास्तव में एक दिलचस्प सवाल है: हम अपनी दैनिक गतिविधियों में गणित का उपयोग क्यों नहीं करते हैं। जवाब आसान है - हम उसे प्यार नहीं करते। सरल आँकड़े: Google से अनुरोध करें "मुझे नफरत है ..."। और हम प्राप्त करते हैं:
• 703 हजार जवाब: मुझे स्टार वार्स से नफरत है
• 701 हजार उत्तर: मुझे गणित से नफरत है
मैथ स्टार वार्स के बाद दूसरे स्थान पर है! बुरा नहीं है, है ना? यदि यह घृणा कुछ हद तक विघटित हो जाती है, तो तीन अवरोधकों को अलग किया जा सकता है जो हमें गणित का उपयोग करने से रोकते हैं।



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

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

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

सिर में पर्याप्त विचार हैं और इन विचारों का थोड़ा क्रम है, अर्थात्। विश्लेषणात्मक कौशल।

और सबसे प्रसिद्ध अवरोधक यह विचार है कि

गणित कुछ बहुत जटिल है

यह सच नहीं है। मैंने अपनी खुद की आँखों के साथ 5 वीं कक्षा के छात्रों के लिए गणितीय तर्क में एक ऐच्छिक देखा, लोगों ने बैठकर जटिल तार्किक समस्याओं को हल किया। क्या आप पांचवें ग्रेडर की तुलना में परीक्षक बदतर हैं? यह मुझे लगता है कि नहीं।



यदि आप यह पता लगाने की कोशिश करते हैं कि गणितज्ञ कैसे सोचते हैं, तो परिणाम काफी दिलचस्प होगा। जाने-माने डोनाल्ड नट ने एक लेख "एल्गोरिथम थिंकिंग एंड मैथमेटिकल थिंकिंग" (http://www.jstor.org/discover/10.2307/2322871?uid=3738936&uid=2&uid=4&sid=21103388081621) लिखा। इसमें, उन्होंने गणितज्ञों की कई प्रकार की सोच - एल्गोरिदमिक सोच और गणितीय सोच की पहचान की।

इन सभी प्रकार की सोच परीक्षकों पर लागू होती है:

• वास्तविकता का प्रतिबिंब
वास्तव में, आपके परीक्षणों से आप वास्तविकता को दर्शाते हैं, यह दिखाते हैं कि सिस्टम कैसे सही ढंग से काम करता है।

• एक साधारण मामले में कमी
हम सभी परीक्षण लिखने की कोशिश करते हैं ताकि वे यथासंभव सरल हो और, एक ही समय में, उन्हें फिर से जटिल करने की आवश्यकता न हो।

• सामान्यीकरण
हम परीक्षणों का वर्णन करने की कोशिश कर रहे हैं ताकि उनका पुन: उपयोग किया जा सके। हम पहले परीक्षण के लिए एक टेम्पलेट लिखने की कोशिश करते हैं, और फिर टेम्पलेट के लिए बहुत सारे विशिष्ट परीक्षण।

• अमूर्त तर्क
हम सभी अपने सिर में सिस्टम के कुछ अमूर्त मॉडल का निर्माण करते हैं, और फिर इसका परीक्षण करते हैं।

• सिस्टम की स्थिति बदलना
कम से कम, हमारे पास सिस्टम के दो राज्य हैं: सब कुछ काम करता है या सब कुछ टूट गया है। आमतौर पर ऐसे कई और राज्य हैं, और परीक्षण के दौरान हम सिस्टम की स्थिति को बदलते हैं।

यदि यह तालिका आपको आश्वस्त नहीं करती है, तो आप अध्ययन के परिणामों को देख सकते हैं। कप्लुनोविच (I. कप्लुनोविच। मनोविज्ञान की स्थानिक सोच की संरचना में मानसिक संचालन की सामग्री // 1987। सं। 6। 6), जो शिक्षण मनोविज्ञान के क्षेत्र में अनुसंधान में लगी हुई है। अपने अध्ययन में, वह सोच की पांच श्रेणियों की पहचान करता है।



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



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



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



दसवीं कक्षा में मेरे ज्यामिति शिक्षक ने लंबे, लंबे सूत्र "मगरमच्छ" कहे। यहाँ हमारे कोड में ऐसा एक मगरमच्छ मिला है। कोड की दोनों शाखाओं को कवर करने के लिए, आपको सूत्र की संरचना को समझने की आवश्यकता है, आपको यह पता लगाने की आवश्यकता है कि चर X1, x2, x3, x4 को किन मूल्यों से लेना है। यह संभव है, लेकिन किसी तरह मैं वास्तव में नहीं करना चाहता। सवाल यह है: हम क्या कर सकते हैं? आप आलसी अनुत्पादक हो सकते हैं और, तर्क को भूलकर, इस कोड को पूर्ण पुनः खोज के साथ परख सकते हैं। 16 परीक्षण करें। "लंबे, महंगे, उबाऊ।" खैर, मैं इसे महसूस नहीं करता।
हम परीक्षणों की संख्या को कम करने की कोशिश कर रहे हैं - हम एमसी / डीसी (11-12 परीक्षण) का उपयोग करते हैं, हम तय करते हैं कि हमारे पास शाखाओं के साथ पर्याप्त कवरेज है - हमें दो परीक्षण मिलते हैं ...
और फिर हम अचानक बुलियन बीजगणित को याद करते हैं। मूल अभिव्यक्ति को बदलने के बाद, हम देखते हैं कि केवल चर x3 सत्य मूल्य को प्रभावित करता है। नतीजतन, हमें न केवल परीक्षण उत्पन्न करने का एक सरल तरीका मिलता है (एक x3 = सच में, दूसरे x3 = झूठ में), लेकिन हमें डेवलपर के साथ बात करने का अवसर भी मिलता है। आखिरकार, यह अजीब है जब कोड में एक जटिल तार्किक अभिव्यक्ति होती है, लेकिन वास्तव में यह केवल एक चर पर निर्भर करता है, शायद कहीं त्रुटि है।



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



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



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




आपने शायद यात्रा विक्रेता समस्या के बारे में सुना है - ग्राफ़ पर अनुकूलन समस्या। इस कार्य के साथ एक डी ब्रिन एल्गोरिथ्म जुड़ा हुआ है।



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



पहले दो रास्ते काफी छोटे हैं। हम एक तीसरा रास्ता बनाना शुरू करते हैं और एक बहुत, बहुत लंबा रास्ता तय करते हैं।




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






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




तीसरा उदाहरण। परीक्षण में एक मूल अवधारणा है - समतुल्यता वर्ग। ऐसा लगता है कि आप यहां एक नए के साथ आ सकते हैं?



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



एक बहुत ही वास्तविक उदाहरण। एक सिस्टम है जो डेटाबेस में लंबाई में 0 से 5 एमबी तक की लाइनों को बचाता है। आवश्यकताओं का कहना है कि इस लाइन को बचाने का समय लगभग समान होना चाहिए। परीक्षण के लिए शास्त्रीय दृष्टिकोण हमें तीन परीक्षण देता है: एक खाली रेखा, 5 एमबी की रेखा और 2.5 एमबी की औसत रेखा। हमने जाँच की कि भंडारण समय समान है और त्रुटि के मार्जिन में फिट बैठता है। सब ठीक है।



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



यह पता चला है कि इन महत्वपूर्ण बिंदुओं के अलावा, दो और भी हैं: 256 बी और 32 Kb। क्यों? हमने डेवलपर के साथ बात की, और जवाब में हमें एक कहानी मिली कि एक शांत अनुकूलन डेवलपर ने क्या किया: 256 बाइट्स तक तार को स्ट्रिंग के रूप में संग्रहीत किया जाता है, डेटाबेस में बाइनरी ऑब्जेक्ट के रूप में 32K तक और फ़ाइल सिस्टम पर फ़ाइलों के रूप में 32k तक। "सभी समान, आपके पास ऐसी कुछ लाइनें हैं, लेकिन डेटाबेस आसान है।" औद्योगिक वातावरण से या स्वीकृति परीक्षण वातावरण से हमारी सहायता के लिए इस तरह के समतुल्य वर्गों और परिणामों के विश्लेषण के लिए खोज करना अधिक कठिन है। यदि हम इन आंकड़ों के विश्लेषण के लिए सक्षम रूप से संपर्क करते हैं, तो हम विषम क्षेत्रों को पा सकते हैं।



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



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



दूसरी दृष्टि से पता चला कि हमने विषम क्षेत्र को अधिक सटीक पाया। और हम अपने प्रारंभिक तीन सीमा मूल्यों में छह और जोड़ सकते हैं - प्रत्येक दो विसंगतियों वाले क्षेत्रों के लिए।



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



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



लेकिन यह विधि हमेशा काम नहीं करती है। हमारी प्रणाली अधिक से अधिक जटिल हो सकती है ...



कठिन और कठिन ...।



और यह इतना जटिल हो जाता है कि यह बिग बैंग थ्योरी के प्रशंसकों से अपील करना शुरू कर देता है।



क्या हमारे लिए बड़ी संख्या में इनपुट मापदंडों के साथ एक जटिल प्रणाली का परीक्षण करने के लिए जोड़ीदार काफी है? यह सवाल कई वैज्ञानिकों और यहां तक ​​कि अमेरिकन नेशनल इंस्टीट्यूट ऑफ स्टैंडर्ड एंड टेक्नोलॉजी (NIST) के लिए भी दिलचस्पी का था।



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



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



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



ऑर्थोगोनल मैट्रिसेस के बजाय, एनआईएसटी कवर मैट्रिस (http://math.nist.gov/coveringarrays/coveringarray.html) का उपयोग करने का सुझाव देता है। ऐसे मेट्रिक्स ऑर्थोगोनल लोगों से भिन्न होते हैं, जिसमें मूल्यों का प्रत्येक सेट कम से कम एक बार होता है, न कि "समान संख्या में"। इस मामले में, परीक्षण थोड़े कम हैं, गलत परीक्षण मामले कवरिंग मैट्रिस में बन सकते हैं, लेकिन सामान्य तौर पर परीक्षण स्वयं बहुत तेज होता है। NIST ACTS वेबसाइट पर, आप मैट्रिक्स जनरेटरों को कवर कर सकते हैं और पहले से ही दी गई संख्याओं और उनके मूल्यों की संख्या के लिए पहले से ही गणना किए गए मैट्रिसेस पा सकते हैं। इस प्रकार, हम फिर से गणित की मदद से अपने जीवन को सरल बनाते हैं, एक बार जब हम दहनशील परीक्षण को समझते हैं और आलसी होना जारी रखते हैं।



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



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



परीक्षण प्रबंधन में विभिन्न क्षेत्रों में बहुत सारे हैं और हर जगह आप आवश्यक और उपयोगी गणितीय तरीके पा सकते हैं। यहां तक ​​कि रूसी आईटी समुदाय के कई प्रमुख प्रतिनिधि हैं, जो हर संभव तरीके से गणित को बढ़ावा दे रहे हैं।



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



एक चित्र से नायक की तरह न बनने के लिए, यह अभी भी सार्थक है कि विश्वविद्यालय में आपको जो ज्ञान दिया जाता है, उसे अवशोषित करना। उनमें से सभी बेकार बकवास नहीं हैं, वहां कुछ उपयोगी है। कम से कम नाम याद रखें, तब पढ़ें जब आपको इसकी आवश्यकता हो। ठीक है, अपने दिमाग को क्रम में रखना न भूलें - संरचित चेतना - इन सबसे ऊपर।



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



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



परीक्षण शिक्षा विश्वविद्यालयों तक सीमित नहीं है। आप खुद सीख सकते हैं। उदाहरण के लिए, गुणवत्ता आश्वासन संस्थान प्रमाणन परीक्षा उत्तीर्ण करने के लिए तैयारी करने के लिए - ISTQB परीक्षा की तुलना में थोड़ी अधिक बुनियादी और सैद्धांतिक चीजें हैं।आप अंतर्राष्ट्रीय परीक्षण सम्मेलनों का अनुसरण (और कर सकते हैं) कर सकते हैं। उदाहरण के लिए, ICST सम्मेलन में, सैद्धांतिक और व्यावहारिक रिपोर्टों का एक बहुत अच्छा संयोजन। वहाँ www.arxiv.org - आप हमेशा सहित और परीक्षण के क्षेत्र में अनुसंधान से संबंधित विभिन्न क्षेत्रों में नवीनतम लेख पा सकते हैं। आप हमेशा scholar.google.com पर भी कुछ दिलचस्प पा सकते हैं। आप हमेशा सीख सकते हैं और सीखना चाहिए, मुख्य बात धीरे-धीरे सही जानकारी के लिए सीखना है।



यदि आप अध्ययन करना पसंद करते हैं (और शायद सीख भी लेते हैं), तो आप शोध को अपना मुख्य व्यवसाय बनाने के बारे में सोच सकते हैं।



ऐसा करने के लिए, पहली जगह में "क्यों?" प्रश्न का उत्तर देना आवश्यक है। इस प्रश्न का सभी के पास अलग-अलग उत्तर है, लेकिन इसका उत्तर देना आवश्यक है ताकि अनुसंधान में रुचि न खोएं।

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




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



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



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



इस पर मेरी रिपोर्ट पूरी हो गई है, मैं आपके सवालों का जवाब देने के लिए तैयार हूं।

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

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

प्रश्न।
और जब आपने लोड का परीक्षण किया तो आपको ये अंक कहां से मिले?

जवाब है।
वास्तविक ऑपरेशन डेटा से प्रदर्शन की समस्याओं के आंकड़े थे, साथ ही कुछ विशेषज्ञ आकलन भी थे कि किन मापदंडों पर सिस्टम गिरना शुरू हो सकता है।

प्रश्न।
क्या आपके पास कंपनियों में आपके द्वारा बताए गए तरीकों के बारे में कहां और कैसे व्यापक रूप से आवेदन किया गया है?

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

प्रश्न।
आपके पास सिस्टम स्थिति आरेखों के बारे में एक स्लाइड थी। आपके पास ऐसी स्थितियां थीं जिन्हें आपने सशर्त रूप से बुरा कहा था और इन नई स्थितियों का उपयोग करके, आपको पूरी तरह से सब कुछ फिर से लिखना पड़ सकता है या नहीं?

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

प्रश्न।
तनाव परीक्षण के दौरान इष्टतम भार का एक मॉडल बनाने के लिए आपके द्वारा बताई गई विधियाँ कितनी प्रभावी हैं? क्या उपलब्ध आँकड़ों के आधार पर लोड प्रोफ़ाइल बनाना संभव है?

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