परीक्षण दोहन से आपको क्या चाहिए?

Question

मैं Test Anything Protocol (TAP) IETF group में शामिल लोगों में से एक हूं (यदि दिलचस्पी है, तो मेलिंग सूची में शामिल होने के लिए स्वतंत्र महसूस करें)। कई प्रोग्रामिंग भाषाएं टीएपी को उनके प्राथमिक परीक्षण प्रोटोकॉल के रूप में अपनाने शुरू कर रही हैं और वे वर्तमान में जो पेशकश करते हैं उससे उससे अधिक चाहते हैं। नतीजतन, हम उन लोगों से प्रतिक्रिया प्राप्त करना चाहते हैं जिनके पास xUnit, TestNG या किसी अन्य परीक्षण ढांचे/पद्धति में पृष्ठभूमि है।

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

• फ़ाइल का नाम और लाइन नंबर (यदि लागू हो)
• निदान उत्पादन इस तरह आप क्या मिला है और क्या आप की उम्मीद के बीच अंतर के रूप में
• प्रारंभ और समाप्ति समय: बस आप कुछ उदाहरण देने के लिए।

और इसी तरह ...

Answer 1

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

Answer 2

करने के लिए

तो आप जो बोलते मैं जोड़ेंगे:

• विधि/समारोह/वर्ग के नाम
• कवरेज गिनती उपकरण, अपवादों को छोड़कर (इन तरीकों का हिसाब न रखें) एन के
• परिणाम पिछले उपलब्ध रन
• जनादेश कि तरीके आसानी से परीक्षण के परिणाम पार्स करने के लिए मौजूद होना चाहिए

Answer 3

सबसे निश्चित रूप से प्रत्येक के लिए अपनी सूची से सभी चीजों अलग-अलग आइटम:

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

मेरे सिर में ज्यादा और कुछ नहीं लेकिन परीक्षण के समूह के लिए के ऊपर से मुझे पता है

• समूह नाम
• कुल निष्पादन समय

Answer 4

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

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

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

Answer 5

टैग का एक मनमाना सेट - इसलिए मैं एक परीक्षण को चिह्नित कर सकता हूं, उदाहरण के लिए "एकीकरण, यूआई, व्यवस्थापक"।

(आप मैं इस के लिए पूछने के लिए जा रहा था पता था कि नहीं था आप :-)

Answer 6

मैं श्रेणीबद्ध करने की क्षमता और घोंसला नल धाराओं चाहते हैं।

Answer 7

मैं साधारण सी परीक्षण तरीकों की ++ एक सेट के लिए उत्पादन प्रोटोकॉल के रूप में नल का उपयोग करें, और निम्नलिखित कमियों को देखा है:

• परीक्षण चरणों समूहों में नहीं रखा जा सकता (वहाँ केवल है कई परीक्षण स्क्रिप्ट में उनका समूह बनाने, लेकिन हमारे सॉफ़्टवेयर में सभी परीक्षणों को चलाने के लिए, मुझे कम से कम एक और समूह की आवश्यकता है, ताकि एक टेस्ट चरण की पहचान "डीबी कनेक्शन" -> "रिकोनक्शन टेस्ट" -> "टेस्ट चरण # 3" -
• अपेक्षित और वास्तविक आउटपुट के बीच अंतर देखकर उपयोगी है; मैं या तो stderr (टिप्पणी के रूप में) को मुद्रित करता हूं या वास्तव में एक ग्राफिकल diff उपकरण
• प्रोटोकॉल और उपकरण वास्तव में भाषा-स्वतंत्र होना चाहिए। उदाहरण के लिए, अब तक मुझे केवल परीक्षण चलाने के लिए पर्ल "साबित" टूल के बारे में पता है, जो कि पर्ल स्क्रिप्ट्स

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

Answer 8

एक अद्वितीय आईडी (यूयूआईडी, एमडी 5 एसयूएम) एक व्यक्तिगत परीक्षण की पहचान करने में सक्षम होने के लिए - कहें, किसी डेटाबेस में परीक्षण परिणाम डालने के दौरान उपयोग के लिए, या एक बग ट्रैकर में पहचानने के लिए क्यूए को फिर से चालू करने के लिए इसे संभव बनाने के लिए व्यक्तिगत परीक्षण

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

मैं यह भी सोच रहा हूं कि टीएपी को स्टडआउट के साथ मिश्रित के बजाय एक समर्पित साइड-चैनल के माध्यम से उत्सर्जित किया जाना चाहिए। मुझे यकीन नहीं है कि यह प्रोटोकॉल परिभाषा के दायरे में है।

Answer 9

• वैकल्पिक ascii रंग का उत्पादन, अच्छे के लिए हरे, लंबित के लिए पीला, त्रुटियों

• बातें होने के विचार के लिए लाल लंबित

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

• सूची आइटम

  • कुछ चला गया परीक्षण में गलत

  • कुछ लंबित था

  नल के लिए

Answer 10

एक्सटेंशन विचार:

1..4 
ok 1 - yay 
not ok 2 - boo 
ok 3 - yay #json:{...} 
ok 4 - see my json 

एक #json टिप्पणी संलग्न करने की क्षमता ... - मौजूदा कोड द्वारा सुरक्षित रूप से अनदेखा किया जा सकता है - अच्छी तरह से परिभाषित टैग testanything.orgपर आसानी से आरक्षित किया जा सकता है- जटिल प्रकारों का उत्पादन, विश्लेषण और पढ़ने के लिए आसान - याम एक दर्द है