यूनिट टेस्ट टाइमआउट का उपयोग करके विधि के प्रदर्शन को मापना एक अच्छा विचार है?

Question

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

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

ऐसा करने के लिए, क्या यह एक अच्छा विचार है:

• इकाई परीक्षण का उपयोग करने के समय ही action² को क्रियान्वित करने में खर्च की एक विचार है करने के लिए एन बार,

• C # में विशेषता के माध्यम से प्रति-परीक्षण टाइमआउट का उपयोग करने के लिए [TestMethod, Timeout(200)]?

मैं इस दृष्टिकोण के साथ कई समस्याओं की उम्मीद करता हूं:

• वैचारिक रूप से , यूनिट परीक्षण वास्तव में इसके लिए नहीं हैं: उनसे एक कोड के एक छोटे हिस्से का परीक्षण करने की अपेक्षा की जाती है, इससे अधिक कुछ नहीं: न तो कार्यात्मक आवश्यकता की जांच, न ही एकीकरण परीक्षण, और न ही प्रदर्शन परीक्षण।

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

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

• टेस्ट ड्रिवेन डेवलपमेंट (टीडीडी) उन परीक्षणों के लिए असंभव है। कोड लागू करना शुरू करने से पहले, पहली जगह में यह कैसे विफल होगा?

• बहुत से प्रदर्शन परीक्षण परीक्षणों को चलाने के लिए आवश्यक समय को प्रभावित करेंगे, इसलिए यह दृष्टिकोण केवल छोटी क्रियाओं तक सीमित है।

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

क्या मै गलत हु? क्या ऐसी अन्य समस्याएं हैं जो इसके लिए यूनिट परीक्षणों का उपयोग करने के लिए पूरी तरह से अस्वीकार्य हैं?

यदि मैं गलत हूं, तो डेवलपर को सचेत करने का सही तरीका क्या है कि स्रोत कोड स्रोत नियंत्रण तक पहुंचने से पहले स्रोत कोड में गंभीर रूप से प्रभावित प्रदर्शन, और क्यूए विभाग द्वारा सत्यापित है?

---

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

^{Code कार्रवाई से, मेरा मतलब कोड का एक छोटा टुकड़ा है जो चलाने के लिए कुछ मिलीसेकेंड खर्च करता है।}

Answer 1

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

आपने सही ढंग से बताया, कि इससे सत्यापन से इंकार नहीं करना चाहिए। हम अपने परीक्षण को गैर-कार्यात्मक आवश्यकता का परीक्षण नहीं मानते हैं। इसके बजाय, हम इसे एक मात्र क्षमता-समस्या-संकेतक मानते हैं।

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

कहा जा रहा है, यहां आपके संबंधित मुद्दों पर कुछ बिंदु दिए गए हैं:

• वैचारिक रूप से: यह सच है, कि यह इकाई परीक्षणों के बारे में नहीं है। लेकिन जब तक सभी को पता है, कि परीक्षण किसी भी चीज़ को सत्यापित करने के लिए नहीं है जो कि क्यूए को करना चाहिए, यह ठीक है।

• विजुअल स्टूडियो: उस बारे में कुछ नहीं कह सकता, क्योंकि हम वी.एस. से यूनिट टेस्ट फ्रेमवर्क का उपयोग नहीं करते हैं।

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

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

• रन-टाइम: जैसा कि उल्लेख किया गया है, हम डेवलपर मशीनों पर इन परीक्षणों को नहीं चलाते हैं, बल्कि एक तरह के एकीकरण परीक्षण में निर्माण प्रणाली के भाग के रूप में।

Answer 2

मैं ज्यादातर आपकी सोच के साथ इनलाइन हूं। बस स्वतंत्र प्रवाह के साथ मेरे तर्क डाल रहा हूँ।

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

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

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

मुझे विजुअल स्टूडियो कार्यक्षमता के बारे में पता नहीं है, लेकिन आम तौर पर आपको व्यापक प्रोफाइलिंग टूल की आवश्यकता होती है।

Answer 3

मैंने कुछ समय पहले ऐसा ही काम किया है और अंतिम समाधान यूनिट-परीक्षण और पूर्ण-स्वचालित स्वचालित प्रदर्शन परीक्षण के बीच में था।

कोई विशेष क्रम में कुछ विचार, जो उपयोगी हो सकते हैं:

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

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

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

Answer 4

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