मैं ऐसा करने के तरीके पर एक ब्लॉग पोस्ट में लिखा था कि आपके लिए उपयोगी
http://rburnham.wordpress.com/2011/03/15/bdd-ui-automation-with-specflow-and-coded-ui-tests/
समर्थक है और चोर के कोडित यूआई टेस्ट की है कि मैं के बारे में सोच सकते हैं अपने परीक्षण कर रहा है हो सकता है आवेदन वास्तव में कैसे उपयोगकर्ता होगा इसका इस्तेमाल कर रहे हैं। यह स्वीकृति परीक्षण के लिए अच्छा है लेकिन इसकी सीमाएं भी हैं। यह अंत परीक्षण के अंत के लिए भी वास्तव में अच्छा है। पिछले यूआई टेस्ट में नाजुक होने के बारे में पता चला है। उदाहरण के लिए जब एमएस ने वीएस -2010 यूआई बनाया तो लगभग सभी UI परीक्षण टूट गए। मुख्य कारण प्रौद्योगिकी परिवर्तन है। कोडित यूआई परीक्षण इसे नियंत्रण से मेल खाने के तरीके से होने से रोकने में मदद करते हैं। यह एक संभाव्यता आधारित मैच का अधिक उपयोग करता है। इसका मतलब यह है कि यह नियंत्रण नाम जैसे सूचना के आधार पर सबसे अच्छा मैच खोजने का प्रयास करेगा। हमारे लिए कोडित यूआई परीक्षण तकनीकी सीमाओं के कारण हमारी पसंद थी। हमारा लीगेसी ऐप वीबी है और हालांकि सीयूआईटी बहुत अच्छा काम नहीं करता है, मैं बेहतर नियंत्रण जानकारी प्राप्त करने के लिए एक एक्सटेंशन लिखने की प्रगति में हूं, यह अभी भी हमारी एकमात्र पसंद थी। यह भी ध्यान रखें कि सीयूआईटी नई है और इसकी अपनी सीमाएं हैं। वीएस -2010 में अंत व्यवहार के वर्तमान अंत के कारण, आप अपने यूआईएमएपी को बनाए रखने के तरीके के रूप में बहुत ही संरचित होने के लिए तैयार रहना चाहिए, उदाहरण के लिए, मौजूदा कार्रवाई रिकॉर्डिंग से सीयूआईटी बनाना UIMap.uitest नामक UIMap में परीक्षण और उसे बदलने या किसी अन्य UIMap में स्थानांतरित करने का कोई तरीका नहीं है। यदि आप एकाधिक यूई मानचित्रों का उपयोग करते हैं तो इसका मतलब है कि आपको पहले अपने चरणों को रिकॉर्ड करना होगा और फिर अपने परीक्षण में उनका उपयोग करना होगा। हालांकि यह अभी भी बहुत लचीला है।
specflow के बारे में सबसे अच्छी बात यह है कि पठनीयता और जीवित दस्तावेज़ीकरण के लिए इसका जर्किन वाक्यविन्यास है। आम तौर पर आपके ऐप के परीक्षण परीक्षण या व्यवहार, जहां से मूल्य आता है, आम तौर पर यूआई के नीचे परीक्षण का लक्ष्य होता है। जब यूआई यहां बदलता है तो परीक्षण तोड़ने का थोड़ा कम मौका होता है। जब आपका आवेदन निरंतर परिवर्तन में है और आप यह सुनिश्चित करना चाहते हैं कि मौजूदा सुविधाएं काम कर रही हों, तो मेरे लिए स्पीकफ़्लो बहुत अच्छा है। यह एक स्क्रम पर्यावरण में अच्छी तरह से फिट बैठता है, साथ ही आप अपने परिदृश्य को इस बारे में विवरण के रूप में लिख सकते हैं कि इसे कैसे काम करना चाहिए। Specflow के लिए एक सीमा मैं देख सकता हूँ यह व्याख्या के लिए खुला है। इस वजह से एक परीक्षण लिखना आसान हो सकता है जो बहुत ही पुन: प्रयोज्य और बनाए रखने में कठोर नहीं है। मैं "लॉग इन पेज पर जाएं, उपयोगकर्ता नाम और पासवर्ड दर्ज करें, लॉगिन पर क्लिक करें" के बजाय "उपयोगकर्ता के रूप में लॉग इन करें" जैसे मेरे चरणों का वर्णन करने के लिए और अधिक सामान्य शब्दों का उपयोग करना चाहता हूं। इसे और अधिक दानेदार बताते हुए यूआई को कसकर जोड़ों का पुन: उपयोग करना मुश्किल हो जाता है। वास्तव में लॉगिन कैसे काम करता है, specflow सुविधा के पीछे कोड तक होना चाहिए।
हालांकि 2 को जोड़ना हमें कोडित यूआई टेस्ट का उपयोग करने से अधिक फायदेमंद लगता है। अगर हम यूआई को पूरी तरह से बदलने का फैसला करते हैं तो हमारे पास कम से कम ऐसे व्यवहार होंगे जो हमारी specflow सुविधाओं में किसी भी तरह से समझने की अपेक्षा की जाती हैं। अंत में आपको यह विचार करने की आवश्यकता है कि एप्लिकेशन कैसे विकसित होगा और एप्लिकेशन का प्रकार कैसा होगा।
स्रोत
2011-08-19 04:38:58