SpecFlow, ककड़ी या अन्य बीडीडी स्वीकृति परीक्षण ढांचे के साथ विभिन्न परीक्षण प्रकारों के बीच कैसे चयन करें?

Question

मैं SpecFlow उदाहरण से देख रहा हूँ, और यह MVC नमूना परीक्षण के लिए कई विकल्प शामिल है: नियंत्रक द्वारा उत्पन्न परिणामों को मान्य करने पर आधारित

• स्वीकृति परीक्षण;
• एमवीसी इंटीग्रेशनटेस्टफ्रेमवर्क का उपयोग कर एकीकरण परीक्षण;
• सेलेनियम का उपयोग कर स्वचालित स्वीकृति परीक्षण;
• मैन्युअल स्वीकृति परीक्षण जब परीक्षक को परिणामों को मैन्युअल रूप से सत्यापित करने के लिए कहा जाता है।

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

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

यदि आप वेब विकास में स्पेकफ्लो, ककड़ी या अन्य बीडीडी स्वीकृति परीक्षण ढांचे का उपयोग करते हैं, तो क्या आप विभिन्न परीक्षण प्रकारों के बीच चयन करने के संबंध में अपने अभ्यास साझा कर सकते हैं।

अग्रिम धन्यवाद।

Answer 1

यह सब व्यवहार है।

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

दायरा एक संपूर्ण आवेदन, एक प्रणाली या एक वर्ग का हिस्सा हो सकता है। यहां तक ​​कि एक समारोह भी इस तरह से व्यवहार करता है, इनपुट के रूप में इनपुट और आउटपुट के रूप में आउटपुट के साथ (आप कार्यात्मक भाषा के लिए बीडीडी का भी उपयोग कर सकते हैं!)

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

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

उसके बाद, मैं देखता हूं कि निर्माण प्रणाली के साथ ढांचा कैसे खेलेंगे, और हम इच्छुक हितधारकों के लिए उचित रूप से पढ़ने या लिखने की क्षमता कैसे देंगे।

Here's an example I wrote सरल डीएसएल का उपयोग करके परिदृश्यों के साथ आप जो चीज कर सकते हैं उसे दिखाने के लिए। यह सिर्फ नुनीत में लिखा गया है।

Here's an example in the same codebase दिखा रहा है, कब, फिर कक्षा-स्तर की उदाहरण टिप्पणियों में।

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

मैंने जो उदाहरण प्रदान किया है वह स्वयं एक स्वचालन उपकरण है, इसलिए परिदृश्य नकली गुई के व्यवहार का प्रदर्शन करके स्वचालन उपकरण के व्यवहार का प्रदर्शन कर रहे हैं, बस भ्रमित हो जाता है। उम्मीद है कि यह वैसे भी मदद करता है!

Answer 2

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

तो यह एक व्यापार बंद है, जो प्रत्येक स्थिति के लिए अलग हो सकता है (यही कारण है कि हमने विकल्प प्रदान किए हैं)।

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