यूनिट परीक्षण निष्पादन गति (प्रति सेकंड कितने परीक्षण?)

आप अपने यूनिट परीक्षण (प्रति सेकेंड # टेस्ट) के साथ किस प्रकार की निष्पादन दर का लक्ष्य रखते हैं? एक व्यक्तिगत इकाई परीक्षण के लिए कितना समय लंबा है?

मुझे यह जानने में दिलचस्पी होगी कि क्या लोगों के पास यह निर्धारित करने के लिए कोई विशिष्ट सीमा है कि उनके परीक्षण बहुत धीमे हैं या क्या यह तब होता है जब लंबे समय तक चलने वाले परीक्षण सूट की घर्षण आपके लिए बेहतर हो जाती है?

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

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


Response roundup: Thanks for the great responses so far. Most advice seems to be don't worry about the speed -- concentrate on quality and just selectively run them if they are too slow. Answers with specific numbers have included aiming for <10ms up to 0.5 and 1 second per test, or just keeping the entire suite of commonly run tests under 10 seconds.

यह सुनिश्चित नहीं है कि जब वे सभी सहायक हों तो एक को "स्वीकृत उत्तर" के रूप में चिह्नित करने का अधिकार है :)

0
ro fr bn
प्रति सेकंड 1 सेकंड का मतलब है कि आपका टेस्ट सूट उस बिंदु तक पहुंच जाएगा जहां आप इसे हर समय चलाना बंद कर देते हैं क्योंकि यह बहुत धीमा लगता है। जब आप 100 टेस्ट/सेकंड चला सकते हैं तो आप सूट को 100 गुना अधिक समय से अधिक बार चलाएंगे।
जोड़ा लेखक Jeffrey Fredrick, स्रोत

11 उत्तर

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

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

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

0
जोड़ा

डेटा प्वाइंट - पायथन रिग्रेशन टेस्ट

पाइथन 2.5.2 के लिए "परीक्षण करें" चलाने के लिए मेरे लैपटॉप पर संख्याएं यहां दी गई हैं:

  • परीक्षणों की संख्या: 3851 (लगभग)
  • निष्पादन समय: 9 मिनट, 6 सेकंड
  • निष्पादन दर: 7 परीक्षण/सेकंड
0
जोड़ा

पावर ऑफ टू गेम्स से इस पर एक अच्छा लेख था, यूनिटटेस्ट ++

0
जोड़ा

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

0
जोड़ा

वर्तमान में हम लगभग 3.0 सेकंड में 270 परीक्षण कर रहे हैं। फाइल आईओओ करने वाले लगभग 8 परीक्षण संभवतः हैं।

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

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

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

विकास के आपके क्षेत्र के आधार पर आपका लाभ स्पष्ट रूप से अत्यधिक चर होगा।

0
जोड़ा

मैं अपने यूनिट परीक्षणों का परीक्षण प्रति परीक्षण आधार पर करता हूं, न कि प्रति सेकंड # परीक्षणों द्वारा। जिस लक्ष्य का मैं लक्ष्य रखता हूं वह 500ms या उससे कम है। यदि यह उस से ऊपर है, तो मैं यह जानने के लिए परीक्षण में देखूंगा कि यह इतना समय क्यों ले रहा है।

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

0
जोड़ा

कुछ ढांचे में अंतिम-संशोधित समय जैसे हेरिस्टिक पर आधारित विशिष्ट इकाई परीक्षणों के स्वचालित निष्पादन प्रदान करते हैं। रूबी और रेल के लिए, ऑटोटेस्ट परीक्षणों के बहुत तेज और उत्तरदायी निष्पादन प्रदान करता है - जब मैं रेल मॉडल app/models/foo.rb को सहेजता हूं, तो test/unit/foo_test.rb चलाएं।

मुझे नहीं पता कि अन्य प्लेटफार्मों के लिए कुछ भी समान है, लेकिन यह समझ में आता है।

0
जोड़ा

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

मैं कहूंगा कि यह संकलन गति पर निर्भर करता है। एक आम तौर पर प्रत्येक संकलन में परीक्षण निष्पादित करता है। इकाई परीक्षण का उद्देश्य धीमा नहीं होना है, लेकिन एक संदेश लाने के लिए " कुछ भी टूटा नहीं है, " (या " कुछ तोड़ दिया, बंद करें ")।

मैं परीक्षण निष्पादन की गति के बारे में परेशान नहीं करता जब तक यह ऐसा कुछ न हो जो परेशान हो जाए।

खतरा परीक्षण चलाने से रोकना है क्योंकि वे बहुत धीमी हैं।

अंत में, जब आप परीक्षण का निर्णय लेते हैं   तेजी से चलाने की जरूरत है, क्या तकनीकें करते हैं   आप अपने परीक्षणों को तेज करने के लिए उपयोग करते हैं?

ऐसा करने के लिए सबसे पहले यह पता लगाने के लिए प्रबंधन करना है कि वे बहुत धीमी क्यों हैं, और समस्या को गीला करना यूनिट परीक्षणों में या परीक्षण के तहत कोड में है?

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

0
जोड़ा

लक्ष्य प्रति सेकेंड परीक्षण 100 है। माइकल फेदर के यूनिट परीक्षणों के नियम का पालन करके आप जिस तरह से प्राप्त करते हैं, ।

एक महत्वपूर्ण बिंदु जो पिछले CITCON चर्चा में आया था, यह है कि यदि आपके परीक्षण इस तेज़ नहीं हैं तो यह है काफी संभावना है कि आपको इकाई परीक्षण के डिजाइन लाभ नहीं मिल रहे हैं।

0
जोड़ा

सभी यूनिट परीक्षणों को एक सेकंड के तहत चलाना चाहिए (जो कि सभी यूनिट परीक्षण संयुक्त रूप से 1 सेकंड में चलाना चाहिए)। अब मुझे यकीन है कि इसमें व्यावहारिक सीमाएं हैं, लेकिन मेरे पास एक 1000 परीक्षणों वाला एक प्रोजेक्ट है जो लैपटॉप पर तेजी से चलता है। आप वास्तव में इस गति को चाहते हैं ताकि आपके डेवलपर्स मॉडल के कुछ मूल भाग को दोबारा तैयार न करें (यानी, लेमेम कुछ परीक्षण प्राप्त करते हैं जबकि मैं इन परीक्षणों को चलाता हूं ... 10 मिनट बाद वह वापस आता है)।

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

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

0
जोड़ा
आप किस भाषा, कंपाइलर और टेस्ट इंजन का उपयोग कर रहे हैं? प्रति सेकंड 1000 परीक्षण पागल हैं - मुझे सी #/विजुअल स्टूडियो 2010 में 4 टेस्ट/सेकेंड से बेहतर कुछ भी मिल रहा है।
जोड़ा लेखक Nilzor, स्रोत
मुझे संदेह है (प्रमाण के लिए नहीं देखा है) कि वीएस में लोकप्रिय टेस्ट धावकों को अपनी गति को अनुकूलित करने में अधिक प्रयास नहीं किया जाता है। 4 एक सेकंड का परीक्षण बहुत धीमा है। यदि आपके पास परीक्षणों का एक बड़ा सूट होगा, तो आप सैकड़ों सेकेंड के माध्यम से मंथन करने में सक्षम होना चाहते हैं। उन्हें एक दूसरे में चलाने के लिए बड़ी विकास परियोजनाओं के लिए एक स्केलेबल आवश्यकता नहीं है।
जोड़ा लेखक Niall Connaughton, स्रोत

यूनिट परीक्षणों के बारे में सबसे महत्वपूर्ण नियमों में से एक यह है कि उन्हें तेज़ चलाया जाना चाहिए।

एक व्यक्तिगत इकाई परीक्षण के लिए कितना समय लंबा है?

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

आप अपने यूनिट परीक्षणों के साथ किस प्रकार की निष्पादन दर का लक्ष्य रखते हैं (प्रति सेकंड # टेस्ट)?

आपको मिलीसेकंड के क्रम में चलाने के लिए प्रत्येक परीक्षण का लक्ष्य रखना चाहिए, 1 सेकंड से अधिक कुछ भी शायद परीक्षण कर रहा है।

वर्तमान में हमारे पास लगभग 800 परीक्षण हैं जो 30 सेकंड के भीतर चलते हैं, प्रति सेकेंड 27 परीक्षण। इसमें उन्हें चलाने के लिए आवश्यक मोबाइल एमुलेटर लॉन्च करने का समय शामिल है। उनमें से ज्यादातर 0-5ms लेते हैं (अगर मुझे सही याद है)।

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

हमारे पास एक कॉन्फ़िगर करने योग्य टाइमआउट सीमा भी 5 सेकंड तक सेट है - जो कुछ भी अधिक समय ले रहा है वह असफल हो जाएगा।

0
जोड़ा
QAIndia
QAIndia
160 प्रतिभागियों की

QA India ! Unite Here we share job postings , prepare for interviews and share tips/techniques in QA. Please follow following guideline while sharing any job ... QA job # location : # title Company : Title : Requirement: Responsibility: Apply: