बिल्ड प्रक्रिया में स्वचालित वेब परीक्षण को एकीकृत करना

Question

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

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

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

इस तरह, कोई नया नया हमारे स्रोत नियंत्रण से नवीनतम हो सकता है और हमारी बिल्ड स्क्रिप्ट चला सकता है, और सभी परीक्षण चला सकता है। वे आईडीई से सभी परीक्षणों को भी चला सकते हैं।

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

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

अधिक जानकारी चूंकि लोगों ने अधिक जानकारी मांगी है, यहां यह है। मैं विजुअल स्टूडियो और कैसिनी (वेब ​​सर्वर में निर्मित) का उपयोग कर एएसपी.नेट चला रहा हूं। मेरा यूनिट परीक्षण MbUnit में चलाया जाता है (लेकिन यह इतना महत्वपूर्ण नहीं है। NUnit या XUnit.NET हो सकता है)। आम तौर पर, मेरे पास एक अलग इकाई परीक्षण ढांचा है जो मेरे सभी वैटिन परीक्षण चलाता है। असेंबली लोड चरण में, मैं वेबसर्वर शुरू करता हूं और अपने सभी वेब एप्लिकेशन कोड को स्थानीय रूप से कॉपी करता हूं।

मुझे किसी भी प्लेटफ़ॉर्म के लिए समाधान में रूचि है, लेकिन मुझे प्रत्येक चीज़ का क्या अर्थ है इसके बारे में अधिक विवरणों की आवश्यकता हो सकती है। :)

Answer 1

फिल,

स्वचालन सिर्फ बनाए रखने के लिए कठिन हो सकता है, लेकिन अधिक आप तैनाती के लिए अपने स्वचालन का उपयोग, और अधिक आप परीक्षण सेटअप (और इसके विपरीत) के लिए यह लाभ उठा सकते हैं।

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

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

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

टेस्ट डेटा सेटअप कभी-कभी बट में केवल दर्द होता है। इसे करना होगा।

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

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

मैं इन नियंत्रकों को उस क्षेत्र में रखता हूं जिसे मैं आमतौर पर "test_support" कहता हूं।

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

मैं पूरे पर्यावरण पर नियंत्रण स्वचालित करने के लिए test_support कोड का उपयोग करता हूं - नकली के साथ सेवाओं को प्रतिस्थापित करता हूं, असफलताओं को विफल करने के लिए उपप्रणाली को बंद करता हूं, प्रमाणीकरण को सक्रिय या निष्क्रिय करता हूं और कार्यात्मक परीक्षण के लिए अभिगम नियंत्रण करता हूं जो इन पहलुओं से संबंधित नहीं है , आदि

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

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

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

के कुछ समय पकड़ने और वर्तमान में हम अपने asp.net MVC अनुप्रयोग के लिए एक स्वचालित निर्माण प्रक्रिया का उपयोग कर रहे के बारे में इस सामान :)

Answer 2

मैवेन का उपयोग करके निर्माण प्रक्रिया में एकीकरण परीक्षण चरण बनाने के लिए यह मुश्किल था, लेकिन असंभव नहीं था। क्या हुआ यह अनिवार्य रूप से यह था:

• एक विशिष्ट निर्देशिका में सभी जूनिट परीक्षणों को अनदेखा करें जब तक कि एकीकरण-परीक्षण चरण आग न हो जाए।
• एकीकरण परीक्षण निष्पादित करने के लिए एक मेवेन प्रोफ़ाइल जोड़ें।

• पूर्व एकीकरण परीक्षण चरण के लिए -

• प्रारंभ जेट्टी आवेदन एक परीक्षण डेटाबेस से टकराने के चल रहा है।

सेलेनियम सर्वर एकीकरण परीक्षण चरण में
• भागो सेलेनियम एकीकरण परीक्षण शुरू
• बंद करो सेलेनियम सर्वर
• बंद करो सेलेनियम

इस चरण में कठिनाई वास्तव में घाट की स्थापना की गई थी - हम नहीं कर सके ' इसे सिर्फ युद्ध से लॉन्च करने के लिए नहीं मिलता है, इसलिए हमें वास्तव में जेटी को युद्ध को अनपैक करना पड़ता है, फिर सर्वर चलाएं - लेकिन यह काम करता है, ठीक है, और स्वचालित है - आपको बस इतना करना है कि mvn -PintegrationTest टाइप करें (वह हमारा था एकीकरण परीक्षण प्रोफ़ाइल नाम) और बंद यह चला गया।

Answer 3

के अन्य 90% अधिक बात करते हैं।

हम निम्नलिखित उपकरणों का उपयोग:

• TeamCity
• SVN
• NUnit
• सेलेनियम

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

सफलता पर यह किसी दिए गए मशीन/फ़ोल्डर में कलाकृतियों को तैनात करता है और आईआईएस में आभासी साइट बनाता है।

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

सफलता पर हम nnnit परीक्षणों को निकाल देते हैं। परीक्षण सेटअप यह सुनिश्चित करता है कि सेलेनियम ऊपर और चल रहा है और फिर सेलेनियम परीक्षणों को उसी तरह से चलाता है जैसे वाटिन करता है। सेलेनियम के परीक्षणों के लिए एक अच्छा रिकॉर्डर है जिसे सी # में निर्यात किया जा सकता है।

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

सफलता पर msbuild फिर svn में निर्माण टैग करता है। टीमसिटी में एक नौकरी है जो रातोंरात चलता है जो व्यवसायियों के लिए तैयार होने वाले स्टेजिंग वातावरण में नवीनतम टैग को अगली सुबह परियोजना की स्थिति की जांच करने के लिए तैयार करेगा।

पिछले जीवन में हमारे पास पर्यावरण को पूरी तरह से प्रबंधित करने के लिए nant & एमएसबिल्ड स्क्रिप्ट्स (जावा, सेलेनियम इत्यादि स्थापित करने के लिए) था, हालांकि इसमें बहुत समय लगता है, क्योंकि एक पूर्व req हम मानते हैं कि प्रत्येक बिल्ड एजेंट ने इन्हें स्थापित किया है। समय में हम इन कार्यों को शामिल करेंगे।

Answer 4

हमने एक परियोजना पर Plasma का उपयोग किया। यह प्रक्रिया में एक वेब सर्वर का अनुकरण करता है - बस इसे अपने वेब एप्लिकेशन प्रोजेक्ट की जड़ पर इंगित करें।

यह आश्चर्यजनक रूप से स्थिर था - कोई प्रतिलिपि बनाने वाली फ़ाइलें या प्रक्रिया सर्वर से बाहर निकलना।

यहाँ

[Test] 
    public void Can_log_in() { 
     AspNetResponse response = WebApp.ProcessRequest("/Login.aspx"); 
     AspNetForm form = response.GetForm(); 

     form["UserName"] = User.UserName; 

     form["Password"] = User.Password; 

     AspNetResponse loggedIn = WebApp.ProcessRequest(Button.Click(form, "LoginUser")); 


     Assert.IsTrue(loggedIn.IsRedirect()); 

     AspNetResponse homePage = WebApp.ProcessRequest(loggedIn.GetRedirectUrl()); 

     Assert.AreEqual(homePage.Status, 200); 
    } 

सभी "AspNetResponse" और "AspNetForm" वर्गों प्लाज्मा के साथ शामिल हैं कैसे प्लाज्मा का उपयोग कर एक परीक्षण हमारे लिए लग रहा है ...।

Answer 5

आपको कोड कॉपी करने की आवश्यकता क्यों है? डिच कैसिनी और विजुअल स्टूडियो को आपके लिए वर्चुअल निर्देशिका बनाने दें। निश्चित रूप से देवताओं को वेब परीक्षण चलाने से पहले निर्माण करना याद रखना चाहिए यदि वेब ऐप बदल गया है। हमने पाया है कि यह एक बड़ा सौदा नहीं है, खासकर यदि आप सीआई में वेब परीक्षण चलाते हैं।

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

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

(बी) का एक लाभ यह है कि आपका सेटअप एप्लिकेशन व्यवहार को भी मान्य करता है। समस्या है ... समय।

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

हम गैलियो (एमबीयूनीट 3) का उपयोग करते हैं, जो हमारी रणनीति का समर्थन करने वाली कुछ अच्छी सुविधाएं प्रदान करता है। सबसे पहले, यह आपको स्थिरता और परीक्षण स्तर पर निष्पादन आदेश निर्दिष्ट करने देता है। हमारे पास चार "सेटअप" फिक्स्चर हैं जिन्हें ऑर्डर किया गया है -4, -3, -2, -1। ये निर्दिष्ट क्रम में और सभी "गैर सेटअप" फिक्स्चर से पहले चलते हैं, जो डिफ़ॉल्ट रूप से 0.

हमारी वेब टेस्ट प्रोजेक्ट केवल एक चीज़ के लिए बिल्ड स्क्रिप्ट पर निर्भर करता है: एक प्रसिद्ध उपयोगकर्ता नाम/पासवर्ड । यह एक युग्मन है जिसके साथ मैं रह सकता हूं। चूंकि सेटअप परीक्षण चलते हैं, वे एक "डेटा संदर्भ" ऑब्जेक्ट बनाते हैं जिसमें डेटा (कंपनियां, उपयोगकर्ता, विक्रेता, क्लाइंट इत्यादि) के पहचानकर्ता होते हैं जिन्हें बाद में उपयोग किया जाता है (लेकिन कभी नहीं बदला जाता है) अन्य सभी फिक्स्चर में। (पहचानकर्ताओं द्वारा, मुझे जरूरी चाबियाँ नहीं हैं। ज्यादातर मामलों में हमारा वेब यूआई अद्वितीय कुंजी का पर्दाफाश नहीं करता है। हमें सही पहचानकर्ताओं के लिए नाम या अन्य प्रॉक्सी का उपयोग करके ऐप पर नेविगेट करना होगा।)

गैलियो भी आपको यह निर्दिष्ट करने की अनुमति देता है कि एक परीक्षण या स्थिरता किसी अन्य परीक्षण या स्थिरता पर निर्भर करती है। जब कोई उदाहरण विफल रहता है, तो आश्रित छोड़ दिया जाता है। इससे "कैस्केडिंग असफलताओं" को रोककर अस्थायी युग्मन की बुराई कम हो जाती है जो बहुत भ्रम पैदा कर सकती है।

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

तो परीक्षण डेटा को साफ करने के बारे में क्या?क्या हमें किसी ज्ञात राज्य से शुरू करने की ज़रूरत नहीं है? यह एक नियम है जिसे हमने इसे तोड़ने के लिए उपयुक्त पाया है। एक रणनीति जो हमारे लिए काम कर रही है, कंपनी नाम, उपयोगकर्ता नाम इत्यादि जैसी चीजों के लिए लंबे यादृच्छिक मूल्यों का उपयोग करना है। हमने पाया है कि लॉजिकल "डेटा स्पेस" के अंदर परीक्षण चलाने में बहुत मुश्किल नहीं है, जैसे कि यह टक्कर नहीं लेता अन्य डेटा में। निश्चित रूप से मैं उस दिन से डरता हूं कि मैं एक प्रेत विफल परीक्षण का पीछा करने में घंटों खर्च करता हूं ताकि यह पता चल सके कि यह कुछ डेटा टकराव है। यह एक व्यापार बंद है जो वर्तमान में हमारे लिए काम कर रहा है।

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

browser.TextField("ctl0_tab2_newNote").TypeText("foo"); 

आप हमारे परीक्षणों में यह देखेंगे:

User.NotesTab.NewNote.TypeText("foo"); 

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

उम्मीद है कि इससे मदद मिलती है।

Answer 6

क्या आपका मतलब निर्माण समाप्त होने के बाद स्वचालित रूप से परीक्षण शुरू करना है? निर्माण कार्य सफलतापूर्वक अनुपालन करते समय बिल्डिंग आईआईएस में बिल्ड फ़ाइलों की प्रतिलिपि बनाने के लिए स्वचालित स्क्रिप्ट लिख सकते हैं। और उसके बाद mstest.exe या अन्य विधियों को कॉल करके स्वचालित BVT प्रारंभ करें।

आप ऑटोइट्क्स या कुछ फ़ंक्शन भाषा जैसे पायथन, रूबी के साथ प्रयास कर सकते हैं।