2009-04-23 12 views
7

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

लेकिन यह यादृच्छिक मूल्यों पर

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

मुझे लगता है कि यह दोनों दृष्टिकोण कोई अच्छा नहीं हैं। रेंज-परीक्षण के साथ मैं कल्पना कर सकता हूं कि ऐसा करने के लिए व्यावहारिक नहीं है, क्योंकि यह समय ले रहा है, लेकिन यादृच्छिकता के साथ?

अद्यतन:

मैं इस तकनीक को अपने आप का उपयोग नहीं कर रहा हूँ, इसके बारे में सिर्फ सोच रहा था। यादृच्छिकता एक अच्छा उपकरण हो सकता है, अब मुझे पता है, अगर आप इसे करने के लिए पुन: उत्पन्न कर सकते हैं।

http://en.wikipedia.org/wiki/Fuzz_testing

tx

+3

@ पीटर: मैं अपने टेस्टकेस में यादृच्छिकता का उपयोग कर रहा हूं। मुझे एसयूटी में कुछ त्रुटियां मिलीं और इसने मुझे अपने टेस्टकेस में कुछ त्रुटियां दीं। टेस्टकेस इसके द्वारा अधिक जटिल हो जाता है। आपको अपने टेस्टकेस को उस यादृच्छिक मान (एस) के साथ चलाने के लिए एक विधि की आवश्यकता होगी, जिस पर यह असफल रहा है ... सब कुछ, मैं यादृच्छिकता का उपयोग करने पर वापस थकाऊ हूं लेकिन इसे आंतरिक रूप से खारिज नहीं कर रहा हूं। हर तकनीक के साथ, इसके मूल्य हैं। आपको "फज़िंग" शब्द देखना चाहिए। –

+1

लिवन, waarom maak je er geen antwoord van? Ik zou het graag accepteren। – Peter

+0

@ पीटर, डेटा geval में ... –

उत्तर

3

मैं अपने टेस्टकेस में यादृच्छिकता का उपयोग कर रहा हूं। मुझे एसयूटी में कुछ त्रुटियां मिलीं और उसने मुझे अपने टेस्टकेस में कुछ त्रुटियां दीं।

ध्यान दें कि टेस्टकेस यादृच्छिक उपयोग करके अधिक जटिल हो जाता है।

  • आप यादृच्छिक मूल्य (रों) यह
  • पर विफल आप हर परीक्षण के लिए इस्तेमाल किया यादृच्छिक मान लॉग इन करना होगा के साथ अपने testcase को चलाने के लिए एक विधि की आवश्यकता होगी।
  • ...

कुल मिलाकर, मैं अनियमितता के प्रयोग पर वापस throthling रहा हूँ, लेकिन यह enterly खारिज नहीं। हर तकनीक के साथ, इसके मूल्य हैं।

आप के बाद क्या कर रहे हैं की एक बेहतर विवरण के लिए, अवधि fuzzing

2

आप क्या परीक्षण कर रहे हैं:
सबसे दिलचस्प जबाब Lieven से 'fuzzing' टिप था? यादृच्छिक संख्या जेनरेटर? या आपका कोड?

यदि आपका कोड, तो कोड में कोई बग है जो यादृच्छिक संख्या उत्पन्न करता है?

क्या होगा यदि आप एक समस्या पुन: पेश करने की जरूरत है, तो आप परीक्षण उम्मीद है कि यह अंततः उसी क्रम के रूप में आप के लिए किया था जब आप समस्या की खोज की का उपयोग करेगा पुन: प्रारंभ रखने करते हैं?

आप एक यादृच्छिक संख्या जनरेटर का उपयोग करने के एक ज्ञात निरंतर मूल्य के साथ यह बीज कम से कम, डेटा उत्पन्न करने के निर्णय लेते हैं, तो यह पुन: पेश करने में आसान है तो।

दूसरे शब्दों में, आपकी "यादृच्छिक संख्या" केवल "संख्याओं का अनुक्रम है जो मुझे वास्तव में बहुत ज्यादा परवाह नहीं है"।

+0

मुझे लगता है कि woul पुन: उत्पन्न कोई समस्या नहीं है, मैं लॉग में देख सकते हैं कि किस संख्या ने दावा किया है, नहीं? – Peter

+0

जो विवाद टूटता है, वह आपको समस्याग्रस्त इनपुट मान का पुनर्निर्माण करने की अनुमति नहीं दे सकता है (उदाहरण के लिए जब यह किसी व्युत्पन्न मूल्य पर जोर न दें या assertTrue) –

+0

वास्तव में, मुझे लगता है कि समस्या का कोई समाधान नहीं हो रहा है, तो यह इस तकनीक को रद्द कर सकता है, लेकिन हो सकता है कि पाठ्यक्रम के लिए सरल समाधान – Peter

5

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

1

जब तक यह आपको कुछ तरीकों से बताएगा कि यह यादृच्छिक मूल्य कितना असफल रहा है, मुझे नहीं लगता कि यह बुरा है। हालांकि, आप अपने आवेदन में समस्या खोजने के लिए भाग्य पर निर्भर हैं।

पूरी श्रृंखला का परीक्षण कर आपको हर अवसर को कवर किया है, लेकिन यह overkill की तरह लगता है जब आप किनारों को कवर किया है और, मुझे लगता है, कुछ मध्यम जमीन मूल्यों को स्वीकार कर लिया सुनिश्चित करेगा।

+2

@ गैरी, इसे भाग्य नहीं कहा जाता है, इसे फ़ज़िंग कहा जाता है। –

5
  1. रैंडम इनपुट - परीक्षण नहीं होगा repeatable (हर बार जब वे चलाए जा रहे हैं और इसलिए अच्छा इकाई परीक्षण नहीं माना जाता है का उत्पादन संगत परिणामों टेस्ट अपना मन बदल नहीं करना चाहिए
  2. रेंज परीक्षण/RowTests।। - जब तक वे टेस्ट सूट रन को धीमा नहीं करते हैं तब तक अच्छे होते हैं ..प्रत्येक परीक्षण को जितना संभव हो सके के रूप में चलाना चाहिए। (एक पूर्ण-इन -30sec परीक्षण सूट 10 मिनट से अधिक बार चला जाता है) - अधिमानतः 100 मिमी या उससे कम। उस ने कहा कि प्रत्येक इनपुट (परीक्षण डेटा) 'प्रतिनिधि' इनपुट होना चाहिए। यदि सभी इनपुट मान समान हैं, तो प्रत्येक का परीक्षण कोई मूल्य नहीं जोड़ रहा है और केवल नियमित संख्या क्रंचिंग है। आपको मूल्यों के उस सेट से केवल एक प्रतिनिधि की आवश्यकता है। आपको सीमा परिस्थितियों और 'विशेष' मूल्यों के लिए प्रतिनिधियों की भी आवश्यकता है।

दिशा-निर्देश या thumbrules के बारे में अधिक के लिए - देखने 'What makes a Good Unit Test?'

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

प्रतिक्रिया:

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

पुनरावर्तनीय - यह दर्शाता है कि प्रत्येक बार जब परीक्षण एसयूटी पर चलाया जाता है, तो यह एक ही परिणाम (पास/असफल) उत्पन्न करता है .. नहीं 'क्या मैं फिर से परीक्षण विफलता पुन: उत्पन्न कर सकता हूं?' (पुनरावर्तनीय! = पुन: उत्पादित)। दोहराने के लिए .. इस तरह के अन्वेषण परीक्षण अधिक परीक्षण मामलों की पहचान करने के लिए अच्छा हो सकता है लेकिन मैं इसे अपने परीक्षण सूट में नहीं जोड़ूंगा जो हर बार जब मैं दिन में कोड बदलता हूं तो मैं इसे चलाता हूं। मैं मैन्युअल रूप से अन्वेषण परीक्षण करने की अनुशंसा करता हूं, कुछ अच्छे (कुछ दुःखद का उपयोग कर सकते हैं) टेस्टर्स जो आपके कोड पर हथौड़ा और टोंग जायेंगे .. आपको एक यादृच्छिक इनपुट जेनरेटर से अधिक परीक्षण केस मिलेंगे।

+0

लिंक – Peter

+0

के लिए टीएक्स दोहराने योग्य नहीं होगा -> हाँ वे पोस्ट करेंगे: "परीक्षण डेटा संरक्षित है। अगर फ़ज़ स्ट्रीम छद्म-यादृच्छिक संख्या उत्पन्न होती है तो बीज मूल्य को स्टोर करना आसान हो सकता है फज़ प्रयास को पुन: उत्पन्न करने के लिए। " – Peter

+0

प्रतिक्रिया मेरे उत्तर के अपडेट के रूप में जोड़ा गया .. चूंकि मुझे अपने कीबोर्ड की आवाज़ पसंद है :) – Gishu

0

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

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

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

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

अंत में मैं शायद "यादृच्छिक" मानों का उपयोग करने के लिए कोड लिखने के लिए अधिक समय का उपयोग कर समाप्त हो गया था, क्योंकि मैं पहले स्थान पर सार्थक मूल्यों को चुनने के लिए उपयोग करता था।

+0

ये यादृच्छिक मान निश्चित रूप से पूरक हैं। अच्छी तरह से चुने गए मूल्य निश्चित रूप से मूल मूल्य हैं। – Peter

+0

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

3

आप क्या वर्णन आमतौर पर विनिर्देशन आधारित परीक्षण कहा जाता है और इस तरह के QuickCheck (हास्केल), scalacheck (स्काला) और Quviq QuickCheck (Erlang) के रूप में चौखटे से लागू किया गया है।

डेटा आधारित परीक्षण उपकरण (जैसे DataProviderTestNG में) इसी तरह के परिणाम प्राप्त कर सकते हैं।

अंतर्निहित सिद्धांत किसी प्रकार के विनिर्देश के आधार पर परीक्षण के तहत विषय के लिए इनपुट डेटा उत्पन्न करना है और "खराब अभ्यास" से बहुत दूर है।

+0

+1। Spec- आधारित परीक्षण का एक बड़ा लाभ यह है कि आप डेटा के महत्वपूर्ण गुणों पर जोर देते हैं और कुछ आकस्मिक हार्ड कोडित मूल्य नहीं। –

1

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

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

+0

लक्ष्य विश्वास हासिल करने के लिए सस्ते रूप से बग खोजने के लिए है। –

1

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

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

यादृच्छिक घटनाओं ने अंततः उन घटनाओं का एक अनुक्रम प्रकट किया जो एक रिसाव उत्पन्न करते थे। पहली मशीन से पुनर्प्राप्त करते समय दूसरी त्रुटि हुई जब राज्य मशीन ने संसाधन को लीक किया।

हम तब क्षेत्र में रिसाव को पुन: पेश करने में सक्षम थे।

तो यादृच्छिकता को ऐसी समस्या मिली जो अन्यथा ढूंढना मुश्किल था। थोड़ा सा बल बल लेकिन कंप्यूटर सप्ताहांत काम करने में कोई फर्क नहीं पड़ता।

0

Theory-Based Testing पर देखें डेविड Saff के काम को देखने के।

आम तौर पर मैं यूनिट परीक्षणों में यादृच्छिकता से बचता हूं, लेकिन सिद्धांत सामग्री दिलचस्प है।

0

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

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

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