एल्गोरिथम जटिलता के लिए एक परीक्षण करना चाहिए? यदि हां, तो कैसे?


14

मान लीजिए कि मैं कुछ सरल लागू कर रहा हूं जैसे कि एक क्रमबद्ध सूची / सरणी खोजना। फ़ंक्शन (c # में) समान दिखाई देगा:

static int FindIndex(int[] sortedList, int i);

मैं इसे कार्यक्षमता के संदर्भ में लागू कर सकता हूं और परीक्षण कर सकता हूं, लेकिन स्पष्ट कारणों से मैं आमतौर पर एक रैखिक खोज या किसी जानबूझकर बेवकूफ पर एक द्विआधारी खोज को प्राथमिकता दूंगा।

तो मेरा सवाल है: क्या हमें एल्गोरिदम जटिलता के संदर्भ में प्रदर्शन की गारंटी देने वाले परीक्षण लिखने का प्रयास करना चाहिए और यदि हां, तो कैसे?

मैंने इस प्रश्न के "आप को चाहिए" दोनों पक्षों पर तर्क देना शुरू कर दिया है, लेकिन मैं यह देखना चाहूंगा कि लोग मेरे तर्कों के बिना क्या कहते हैं उन्हें संकेत दें।

"कैसे" के संदर्भ में, यह बहुत दिलचस्प हो जाता है :) आप तुलना ऑपरेटर के पैरामीटर को देख सकते हैं और एक परीक्षण कर सकते हैं जिसका तुलना ऑपरेटर तुलना या ऐसा कुछ गिनता है। लेकिन सिर्फ इसलिए कि आप का मतलब यह नहीं हो सकता है कि आपको ...

क्या किसी और ने इस पर विचार किया है (शायद)? धन्यवाद।


@ steenhulthin - मैं इस सिमर को यहाँ रहने दूँगा और जाँच करूँगा। मैं वहाँ कभी नहीं गया था।
SirPentor

btw, अच्छा सवाल है। +1
राफेल कोलूकी

जवाबों:


13

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

निरपेक्ष प्रदर्शन को यंत्रवत् परीक्षण किया जा सकता है और उपयोगी इकाई परीक्षण कर सकते हैं। यदि प्रदर्शन मायने रखता है, तो आप एक सीमा निर्दिष्ट कर सकते हैं: "इस क्वेरी को 10 6 नंबरों पर चलाने के लिए 50ms से अधिक नहीं लेना चाहिए , और 10 7 नंबरों पर 60ms से अधिक नहीं ।" कि आप के लिए एक इकाई परीक्षण का निर्माण कर सकते हैं

अंतिम उपयोगकर्ता को परवाह नहीं है कि आपका एल्गोरिथ्म रैखिक है या लॉगरिदमिक; वे परवाह करते हैं कि क्या उनके यूआई अभी भी तुरंत जवाब देते हैं, भले ही उन्हें ऐप में एक साल का मूल्य मिला हो।


यह मेरी वृत्ति भी है। लेकिन मुझे इसके बारे में सोचने से क्या मिला, जब फ्रेमवर्क पर परफॉर्मेंस परफॉर्म किया गया। उदाहरण: यदि मुझे सही ढंग से याद है, तो stl के पास एल्गोरिथम कॉम्प्लेक्सिटी (यहाँ से हटकर हो सकता है) के आस-पास कुछ ज्यूरिस्ट हैं।
SirPentor

सिर्फ इसलिए कि एक पुस्तकालय कुछ गारंटी प्रदान करता है इसका मतलब यह नहीं है कि उन्हें इकाई-परीक्षण योग्य होना चाहिए।
svick

@ टोबियास ईंट: किसी चीज का परीक्षण करना और किसी चीज को परिभाषित करना दो अलग चीजें हैं।
डेडएमजी

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

3

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

उम्मीद है की यह मदद करेगा!


0

मुख्य बात यह है कि इसे बड़े डेटा के साथ आज़माएं और देखें कि क्या यह बहुत लंबा है।

मेरे प्रदर्शन ट्यूनिंग अनुभव में, इस उदाहरण में , क्या होता है अगर कुछ एल्गोरिथ्म है (उदाहरण के लिए) हे (एन ^ 2) यह ठीक हो सकता है जब तक कि समय का प्रतिशत रडार पर कभी नहीं होता है।

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

यदि आप परीक्षण में ऐसा कर सकते हैं, तो यह बहुत अच्छी बात है, क्योंकि यह समस्या को खोजने के लिए बहुत आसान है, जैसे कि यह एक वास्तविक अनंत लूप था।


0

मुझे नहीं लगता कि आप जो करना चाहते हैं वह यूनिट टेस्टिंग है।

AFAIK, इकाई परीक्षण केवल यह सुनिश्चित करने के लिए है कि कोड वह करता है जो उसे करना चाहिए और यह प्रदर्शन पर ध्यान केंद्रित नहीं करता है।

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

प्रदर्शन को मापने के लिए अन्य प्रकार के उपकरण और पैटर्न हैं। उनमें से एक मुझे याद है कि अब गैर-कार्यात्मक आवश्यकताओं पर केंद्रित स्वीकृति परीक्षण है

प्रदर्शन परीक्षण जैसे कुछ अन्य हैं (जो तनाव परीक्षण, लोड परीक्षण आदि का उपयोग करते हैं)।

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

तो संक्षिप्त उत्तर नहीं है, आपको इस बात की चिंता नहीं करनी चाहिए कि यूनिट कब किसी कोड का परीक्षण कर रही है।


0

तुलनित्र में गुजरना और उस समय की संख्या का ट्रैक रखना जिसे कहा जाता है, साधारण उद्देश्यों के लिए काम करेगा जैसे कि यह जाँचना कि किसी निश्चित इनपुट में खोज करते समय तुलना की संख्या (कहना new int[] { 1,2,3, ... , 1024 }) नीचे रहती है 10. यह कम से कम होगा एल्गोरिथ्म को कैसे व्यवहार करना चाहिए, इसके बारे में अपने इरादे स्पष्ट करें।

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

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