2009-08-18 11 views
12

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

प्राथमिक लक्ष्य ऐप के मूल इंस्टॉल और रन-थ्रू को स्वचालित करना है, इसलिए यदि कोई डेवलपर एक प्रमुख ब्रेकेज का कारण बनता है (उदाहरण: ऐप इंस्टॉल नहीं होगा, नेटवर्क कनेक्ट नहीं होगा, विंडो प्रदर्शित नहीं होगी, आदि) परीक्षकों स्थापित करने और एक टूटी हुई निर्माण

एक माध्यमिक लक्ष्य जब दोहराए जाने वाले कार्यों के साथ काम कर परीक्षकों की मदद करना है को विन्यस्त अपने समय बर्बाद (और से परेशान हो जाते) की जरूरत नहीं है।

मेरा प्रश्न है: इस प्रकार के परीक्षण किसको बनाना चाहिए? हमारी टीम में अंतर्निहित धारणा यह रही है कि परीक्षक इसे करेंगे, लेकिन नेट पर जो भी मैंने पढ़ा है, वह हमेशा यह दर्शाता है कि डेवलपर्स उन्हें 'विस्तारित इकाई परीक्षण' के रूप में बनाएंगे।

कुछ विचार:

  • डेवलपर्स, यह करने के लिए एक बेहतर स्थिति में होना करने के लिए दिया वे नियंत्रित आईडी, वर्ग, आदि पता है, और कैसे अनुप्रयोग है की एक बेहतर तस्वीर है कि लगता है काम कर

  • परीक्षकों नहीं जानते हुए भी कैसे एप्लिकेशन काम कर रहा है, और इसलिए परीक्षण जो अधिक उपयोगी हो सकता है

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

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

  • हमारे परीक्षक कोड नहीं कर सकते हैं, और जब वे बहुत स्मार्ट हैं, तो मुझे लगता है कि टेस्टर्स संभावित रूबी स्क्रिप्ट लिख सकते हैं (भले ही स्क्रिप्ट्स पढ़ने और लिखने के लिए लगभग 100x आसान हो बटन और डेटाग्रिड्स की उलझन वाली गड़बड़ी की तुलना में जो स्वचालित यूआई परीक्षण उपकरण के लिए मानक मानते हैं)।

मैं उन लोगों से किसी भी प्रतिक्रिया की सराहना करता हूं जिन्होंने डेवलपर्स और परीक्षकों दोनों की एक टीम में यूआई स्वचालन की कोशिश की है। किसने किया, और यह अच्छी तरह से काम किया? अग्रिम में धन्यवाद!

संपादित करें: प्रश्न में आवेदन एक सी # WPF "अमीर ग्राहक" आवेदन जो एक सर्वर WCF

उत्तर

4

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

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

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

अंत में ... मुझे लगता है कि अमीर ग्राहक क्षुधा तरह से अधिक इस तरह से परीक्षण करने के लिए मुश्किल हो जाता है, लेकिन यह भाषा की प्रकृति और उपकरण आप के लिए उपलब्ध पर निर्भर करता है ...

+0

हमने क्यूए लोगों को मूल 'स्टब' स्क्रिप्ट लिखने के विकल्प के साथ जाने का विकल्प तय किया है (आयरन रूबी का उपयोग करके, जो पढ़ने और लिखने में बहुत आसान है), और उसके बाद डेवलपर कोड को ठीक कर रहे हैं और उन हिस्सों को कार्यान्वित कर रहे हैं क्यूए लोग ऐसा करने में सक्षम नहीं थे। उम्मीद है कि यह –

+0

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

4

उपयोग करते हुए मेरे अनुभव में से जोड़ता है, परीक्षकों जो कोड कर सकते हैं डेवलपर्स के रूप में एक भुगतान उठाने के लिए नौकरियों स्विच करेंगे।

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

+1

मैं क्यूए :-) –

+1

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

1

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

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

+1

क्यूए लोक परीक्षण को कैसे रोक देगा? क्या वे परीक्षण से भरे एक वास्तविक कोड फ़ाइल लिखेंगे? या आप आवश्यकताओं से भरा एक शब्द दस्तावेज़ हाथ? मुझे लगता है कि डेवलपर्स फिर वास्तविक यूआई-ऑटोमेशन कोड के साथ स्टब्स भरेंगे? –

+0

क्यूए वास्तव में स्टब्स कार्य करता है, या जो कुछ भी हो सकता है। नाम चुस्त दस्तावेज के रूप में काम करना चाहिए। आपको इसे पार्स करने में सक्षम होना चाहिए, और ऊंट के मामले पर एक साधारण विभाजन को चलाने के लिए प्रत्येक आवश्यकता को अस्तर से बाहर निकालना चाहिए। – Saem

1

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

2

क्या परीक्षकों के बारे में प्रस्ताव परीक्षण, और डेवलपर्स वास्तव में इसे लिख रहे हैं?

+1

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

+1

विचारधारा "ट्विस्ट" एप्लिकेशन इस तरह की चीज के साथ मॉडलिंग किया जाता है –

2

मुझे विश्वास है कि पहले यह आपके द्वारा उपयोग किए जाने वाले टूल पर निर्भर करता है।

हमारी कंपनी वर्तमान में Selenium (हम एक जावा शॉप हैं) का उपयोग करती है।

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

एक चीज जिसे मैंने अतीत में (कुछ सफलता के साथ) की कोशिश की थी, सेलेनियम कार्यों के लिए लाइब्रेरी फ़ंक्शंस को रैपर के रूप में लिखना था। वे सादे अंग्रेजी के रूप में पढ़ते हैं:

selenium.clickButton("Button Text") 

...लेकिन दृश्यों के पीछे बटन पर उचित लेआउट और टैग की जांच करें, एक आईडी इत्यादि है।

दुर्भाग्यवश इसे परीक्षणों की आसान लेखन की अनुमति देने के लिए बहुत सारे सेट अप की आवश्यकता है।

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

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

+0

यह मूल रूप से मैंने अपनी रूबी स्क्रिप्ट्स (सफेद ढांचे पर सारणित) के साथ किया है। मेरे पास कोड है "ok_button = window.find_button (" OK "); ok_button.click" –

4

मैंने अंततः परीक्षण और परीक्षण स्वचालन के लिए स्विच करने से पहले 7 साल से अधिक एप्लिकेशन डेवलपर के रूप में काम किया। परीक्षण कोडिंग से कहीं अधिक चुनौतीपूर्ण है, और कोई भी स्वचालन डेवलपर जो सफल होना चाहता है उसे मास्टर परीक्षण कौशल होना चाहिए।

कुछ समय पहले मैंने कुछ ब्लॉग पोस्ट में कौशल मैट्रिस पर अपने विचार डाले।

रुचि रखते हैं पर चर्चा के लिए:

http://automation-beyond.com/2009/05/28/qa-automation-skill-matrices/

धन्यवाद।

+0

ओह, और इंस्टॉल और मूल रन-थ्रू स्वचालन के लिए, वास्तविक कार्यात्मक परीक्षण के बिना, आपको वास्तव में QTP या TestComplete की आवश्यकता नहीं है। ऑटोआईट (यह मुफ़्त है) आज़माएं। –

+0

मुझे कोई संदेह है कि किसी भी क्यूए वेतन में एक अच्छे डेवलपर के वेतन से मेल खाता है, इसलिए देव से क्यूए में स्विच करना कैरियर के अनुसार एक अजीब बात है। कह रहा है कि 'कोडिंग की तुलना में परीक्षण अधिक चुनौतीपूर्ण है' एक बहुत ही राय आधारित है .. मैं दोनों करता हूं और कोडिंग को और अधिक पसंद करता हूं – vsync

0

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

अन्य कारकों पर विचार करने के लिए:

अन्य क्या परीक्षण कार्य परीक्षकों के प्लेट पर कर रहे हैं? आपके ग्राहक कौन हैं और गुणवत्ता से संबंधित उनकी अपेक्षाएं क्या हैं? विकास टीम का कौशल स्तर क्या है और परीक्षण स्वचालन कार्य करने की उनकी इच्छा क्या है?

-Ron

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