2010-05-20 19 views
11

मैं पढ़ रहा हूँ Osherove की 'यूनिट टेस्टिंग की कला, "और मैं अभी तक नहीं देखा है उसे प्रदर्शन परीक्षण के बारे में कुछ भी कहना, दो विचार अभी भी मेरे मन को पार:निष्पादन परीक्षण बनाम यूनिट टेस्टिंग

  • प्रदर्शन आम तौर पर परीक्षण यूनिट परीक्षण नहीं हो सकते हैं, क्योंकि प्रदर्शन परीक्षणों को आम तौर पर लंबे समय तक चलाने की आवश्यकता होती है।
  • प्रदर्शन परीक्षण आम तौर पर यूनिट परीक्षण नहीं हो सकते हैं, क्योंकि प्रदर्शन मुद्दे अक्सर एकीकरण या सिस्टम स्तर पर प्रकट होते हैं (या कम से कम एकीकरण परीक्षण के पुन: निर्माण के लिए आवश्यक एक यूनिट परीक्षण का तर्क भी होगा एक इकाई परीक्षण होने के लिए शामिल)।

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

मेरा प्रश्न है: क्या मेरे निष्कर्ष/झुकाव समुदाय के विचारों से मेल खाते हैं?

उत्तर

4

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

+1

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

2

प्रदर्शन परीक्षण यूनिट परीक्षणों से बहुत अच्छी तरह से किए जा सकते हैं।

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

4

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

1

सभी उस पर निर्भर करता है जिसे आप प्रदर्शन परीक्षण कहते हैं। जब माइक्रो कोडिंग विशिष्ट कोड मैं आमतौर पर यूनिट परीक्षण के समान कुछ उपयोग करता हूं (क्या मुझे इसे इकाई प्रदर्शन परीक्षण कहा जाना चाहिए?)। यह मूल रूप से मैं इस question में करता हूं (हालांकि वास्तव में यूनिट परीक्षण ढांचे का उपयोग करने के लिए वहां परवाह नहीं है)। लेकिन मैं बूस्ट यूनिट परीक्षण ढांचे के भीतर अपने सी ++ उत्पादन कोड को अनुकूलित करने के लिए इस तरह की चीजें भी करता हूं।

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

2

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

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

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

Rake Test:All   #Run all unit tests 
Rake Test:Acceptance #Run all acceptance tests 
Rake Test:Performance #Run all performance tests 
Rake Test:Integration #Run all integration tests 
फिर अपने निरंतर एकीकरण, टेस्ट के साथ

: दिन में एक बार 12 बजे प्रदर्शन प्रदर्शन किया जाता है।

+0

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

+0

आपके पास एक निर्दिष्ट स्थान (वर्चुअल बॉक्स, या रिमोट सर्वर) पर सर्वर कार्यान्वयन बनाया और तैनात किया जा सकता है, और उसके बाद सभी प्रदर्शन/एकीकरण परीक्षण उस स्थान के विरुद्ध निष्पादित किए जाएंगे। प्रतिष्ठानों को तैनात करने के लिए पैकेज हैं। –

3

मैं मानता हूं कि प्रदर्शन परीक्षण यूनिट परीक्षण नहीं हो सकते हैं, लेकिन ऐसा कोई कारण नहीं है कि हमारे पास प्रदर्शन परीक्षण नामक परीक्षणों का एक और सेट न हो। मोटे तौर पर परीक्षण दो श्रेणियों

क) ईकाई परीक्षण

ख) एकता

परीक्षण हम एकीकरण परीक्षण फिर से वास्तविक डेटाबेस (स्मृति में चलाने के बजाय) एसक्यूएल स्क्रिप्ट सुनिश्चित करने के लिए, हाइबरनेट के अंतर्गत आते हैं भंडार

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

मैं JunitPerf पर आया हूं जो मुझे इस उद्देश्य को प्राप्त करने में मदद कर सकता है।

0

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

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

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

0

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

संबंधित मुद्दे