मैं GUI का परीक्षण कैसे कर सकता हूं?

Question

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

उदाहरण के लिए, मेरे ऐप में ग्राफ़ हैं। मैं यह पता लगाने में सक्षम नहीं हूं कि रेखांकन के परीक्षण को कैसे स्वचालित किया जाए। ग्राफ सही है या नहीं, यह जांचने के लिए एक मानव आंख, AFAIK लेता है।

(मैं जावा स्विंग का उपयोग कर रहा हूं)

Comments

मार्टिन फाउलर ( martinfowler.com/eaaDev/uiArchs.html ) द्वारा विभिन्न GUI आर्किटेक्चर के बारे में एक बढ़िया लेख है । यह यूनिट परीक्षण के संदर्भ में GUI वास्तुकला ट्रेडऑफ का वर्णन करता है।

— रोमन ह्वांग

आजकल, इस सवाल को programmers.stackexchange.com पर बेहतर ढंग से पूछा जाएगा (और शायद स्टैक ओवरफ्लो पर बहुत अधिक व्यापक होने के आधार पर ऑफ-टॉपिक है), लेकिन पुराने प्रश्नों को माइग्रेट नहीं किया जा सकता है। यह सवाल कि क्या यह एक तरफ यहाँ है, समस्या एक दिलचस्प और मुश्किल बनी हुई है।

— मार्क अमेरी

कोड के कुछ GUI टुकड़े और JUnit के साथ उदाहरण देना बहुत अच्छा होगा।

— विटोल्ड काकज़ुरबा

मैं कहूंगा कि बस आराम करो और परेशान मत करो। यूनिट परीक्षणों में लगाए गए प्रयास हमेशा शुद्ध उत्पादक नहीं होते हैं।

— कोडुलिक

पुराना प्रश्न अभी भी, आप GU11

— अबी

Answer 1

एमवीपी और एमवीसी जैसी डिजाइन आमतौर पर वास्तविक जीयूआई से अधिक से अधिक तर्क को अमूर्त करने की कोशिश करते हैं। इस बारे में एक बहुत लोकप्रिय लेख माइकल पंख द्वारा "द हंबल डायलॉग बॉक्स" है। व्यक्तिगत रूप से मेरे पास यूआई से तर्क को स्थानांतरित करने की कोशिश के साथ मिश्रित अनुभव हैं - कभी-कभी यह बहुत अच्छी तरह से काम करता है, और अन्य समय में इसके लायक होने पर अधिक परेशानी होती है। हालांकि यह मेरी विशेषज्ञता के क्षेत्र से बाहर है।

Comments

??? "कभी-कभी यह बहुत अच्छी तरह से काम किया है, और अन्य समय में यह अधिक परेशानी की तुलना में इसके लायक है" बहुत अजीब है क्योंकि अधिकांश नई भाषा एमवीसी उन्मुख होती है ... जो कि तर्क से बाहर है गुई (मॉडल-विज़ुअल) ...

— पैट्रिक डेसजार्डिन्स

फिर भी, प्रस्तुति तर्क GUI में होगा। कभी-कभी, यह तुच्छ से दूर हो सकता है

— एंड्रिया

दर्पण: विनम्र संवाद बॉक्स

— c24w

मार्टिन फाउलर की अवधारणा का उपचार (यदि आपका नेटवर्क, जैसे मेरा, फ़िल्टर आर्काइव। ओआरजी

— क्रिस्टोफर बर्मन

@ c24w आपको उस दर्पण को खींचने के लिए धन्यवाद, आप असली एमवीपी हैं :)

— जॉन बेकर

Answer 2

बेशक, उत्तर एमवीसी का उपयोग करना और जितना संभव हो उतना जीयूआई से बाहर तर्क को स्थानांतरित करना है।

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

Comments

मुझे यह तरीका पसंद है। बोझिल और स्थापित करने के लिए, लेकिन यह मुझे प्रतिगमन परीक्षण क्षमताओं की आवश्यकता होगी।

— स्टीव मैक्लोड

danatel तुम बात चूक गए। ओपनजीएल एक पिक्सेल सटीक ग्राफिक्स एपीआई प्रतिपादन है। क्यूटी जैसे जीयूआई एप्लीकेशन फ्रेमवर्क सिस्टम क्रोम पर अत्यधिक निर्भर रहने वाले हैं, इसलिए फ्रेम बफर का हैशिंग एक अच्छा तरीका नहीं है।

— बॉब सोमरस

एक MD5? क्रिप्टोग्राफिक हैश का इससे क्या लेना-देना है? सुरक्षा कैसे शामिल है? एक हैश, ठीक है, यह पिक्सेल-परिपूर्ण ग्राफिक्स के लिए एक महान विचार है, लेकिन एक क्रिप्टोग्राफिक हैश है? आप तेजी से हैश का उपयोग कर सकते हैं जो गैर-क्रिप्टोग्राफिक हैं और जिनके टकराव की संभावना नगण्य है। क्या आप सुनिश्चित हैं कि यह एक क्रिप्टोग्राफिक हैश था और न केवल एक हैश? (इसके अलावा, समानांतर कंप्यूटिंग के इस दिन और उम्र में, हैशिंग एल्गोरिथ्म [गैर-क्रिप्टोग्राफिक उद्देश्यों के लिए उपयोग किया जाता है] जिसे समानांतर नहीं किया जा सकता है, इसे संदेह की नजर से देखा जाना चाहिए)

— SyntaxT3rr0r

@ SyntaxT3rr0r: इस प्रकार के गैर-सुरक्षा-संबंधित एप्लिकेशन में आप किस हैश फ़ंक्शन की सिफारिश करेंगे, और MD5 की तुलना में प्रदर्शन के स्तर को किस स्तर की उम्मीद की जा सकती है?

— लेसे मेजेस्टे

आप जवाब देते हैं, "कभी भी आपको GUI डिज़ाइन नहीं करना चाहिए और इसलिए इसका परीक्षण न करें"। ठंडा।

— डिम्स

Answer 3

आप कोशिश कर सकते हैं UISpec4J एक मुक्त स्रोत कार्यात्मक और / या इकाई परीक्षण लाइब्रेरी है जो स्विंग-आधारित जावा अनुप्रयोगों के लिए है ...

Comments

मैंने एक महीने के लिए UISpec4J का उपयोग करना शुरू कर दिया है, इसलिए जावा स्विंग GUI पर आवश्यकताओं के सत्यापन की आवश्यकता है। मैं इसे अब तक बहुत पसंद कर रहा हूं।

— बासम

github.com/UISpec4J/UISpec4J बताता है कि आपका लिंक आधिकारिक वेबसाइट है, लेकिन यह मेरे लिए आधिकारिक नहीं है। सभी मैं देख रहा हूँ vlog के बारे में एक ब्लॉग है

— lucidbrot

Answer 4

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

Answer 5

आप स्विंग GUI अनुप्रयोगों के लिए सादे अंग्रेजी में कार्यात्मक स्वीकृति परीक्षण लिखने के लिए ककड़ी और स्विंगर का उपयोग करने का प्रयास कर सकते हैं । स्विंगर ऐप को चलाने के लिए हुड के नीचे नेटबीन्स जेम्मी लाइब्रेरी का उपयोग करता है।

ककड़ी आपको इस तरह परीक्षण लिखने की अनुमति देता है:

 Scenario: Dialog manipulation
    Given the frame "SwingSet" is visible
    When I click the menu "File/About"
    Then I should see the dialog "About Swing!"
    When I click the button "OK"
    Then I should not see the dialog "About Swing!"

इसे कार्रवाई में देखने के लिए इस स्विंगर वीडियो डेमो पर एक नज़र डालें ।

Answer 6

यहाँ कुछ सुझाव दिए गए हैं:

GUI (नियंत्रक, और मॉडल ऑब्जेक्ट) से आप कर सकते हैं सबसे अधिक कोड को निकालने का प्रयास करें इस तरह से आप उन्हें GUI के बिना परीक्षण कर पाएंगे।

ग्राफिक के लिए, आपको उस मूल्य का परीक्षण करना चाहिए जो आप ग्राफिक को उत्पन्न करने वाले कोड को आपूर्ति करते हैं।

Answer 7

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

दूसरा सवाल यह है कि आप वास्तव में UI परत पर परीक्षण करने की कोशिश कर रहे हैं। UI परीक्षण सबसे महंगा परीक्षण है क्योंकि इसे बनाने, बनाए रखने में आमतौर पर अधिक समय लगता है और यह सबसे भंगुर होता है। यदि आप तर्क जानने के लिए निर्देशांक का परीक्षण करते हैं कि लाइन खींचने की कोशिश करने से पहले निर्देशांक सही हैं तो आप विशेष रूप से क्या परीक्षण कर रहे हैं? यदि आप एक रेखांकन का परीक्षण करना चाहते हैं तो लाल रेखा खींची गई है। क्या आप इसे एक निश्चित पूर्वनिर्धारित निर्देशांक दे सकते हैं और परीक्षण कर सकते हैं कि कुछ पिक्सेल लाल हैं या नहीं? जैसा कि बिटमैप तुलनात्मक कार्य के ऊपर सुझाव दिया गया है, सेलेनियम लेकिन मेरा मुख्य ध्यान GUI का परीक्षण करना नहीं होगा, बल्कि तर्क का परीक्षण करना होगा जो UI बनाने में मदद करेगा और फिर UI के किस भाग पर ध्यान केंद्रित करेगा या संदिग्ध है और मुट्ठी भर परीक्षणों पर ध्यान केंद्रित करेगा। वहाँ।

Answer 8

आप अपने GUI का परीक्षण करने के लिए JFCUnit का उपयोग कर सकते हैं , लेकिन ग्राफिक्स अधिक चुनौतीपूर्ण हो सकते हैं। मैंने अपने GUI के स्नैपशॉट लिए कुछ अवसरों पर और इसकी तुलना पिछले संस्करण से की है। हालांकि यह एक वास्तविक परीक्षण प्रदान नहीं करता है, यह आपको सचेत करता है अगर एक स्वचालित निर्माण अपेक्षित उत्पादन का उत्पादन करने में विफल रहता है।

Answer 9

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

यूनिट टेस्टिंग फ्रेमवर्क स्वचालित परीक्षण करने का एक तरीका प्रदान करते हैं, लेकिन मुझे लगता है कि आप जिस तरह के परीक्षण करना चाहते हैं, वह जटिल एकीकरण परीक्षण हैं, जो कि कई वर्गों के सही व्यवहार को सत्यापित करते हैं, जिनमें से आपके GUI टूलकिट / लाइब्रेरी के वर्ग, जिन्हें आप परीक्षण नहीं करना चाहिए।

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

Answer 10

स्विंग और अजाक्स के लिए विंडो लिकर

Answer 11

जीयूआई परीक्षण के लिए मेरा दृष्टिकोण विकसित हो रहा है, जैसा कि उद्योग सहमति है। लेकिन मुझे लगता है कि कुछ प्रमुख तकनीकें उभरने लगी हैं।

मैं इन तकनीकों में से एक या अधिक का उपयोग करता हूं, स्थिति पर निर्भर करता है (जैसे कि यह किस प्रकार का जीयूआई है, इसे कितनी जल्दी बनाने की आवश्यकता है, एंड-यूज़र कौन होगा, आदि)।

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

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

3. घटक खोजकर्ता। आप एक 'एक्सप्लोरर' स्क्रीन बनाते हैं जिसकी एकमात्र भूमिका आपके जीयूआई को बनाने वाले प्रत्येक पुन: प्रयोज्य घटकों को प्रदर्शित करना है। यह स्क्रीन आपको नेत्रहीन सत्यापित करने के लिए एक त्वरित और आसान तरीका देता है कि हर घटक का सही रूप और अनुभव हो। घटक एक्सप्लोरर आपके पूरे एप्लिकेशन के माध्यम से मैन्युअल रूप से जाने की तुलना में अधिक कुशल है, क्योंकि ए) आपको केवल प्रत्येक घटक को एक बार सत्यापित करना होगा, और बी) आपको घटक को देखने के लिए एप्लिकेशन में गहराई से नेविगेट करने की आवश्यकता नहीं है, आप बस देख सकते हैं। इसे तुरंत सत्यापित करें।

4. स्वचालन परीक्षण। आप एक परीक्षण लिखते हैं जो स्क्रीन या घटक के साथ बातचीत करता है, माउस क्लिक, डेटा प्रविष्टि आदि का अनुकरण करता है, यह दावा करते हुए कि इन फ़ंक्शन को सही ढंग से इन जोड़तोड़ दिए गए हैं। यह एक अतिरिक्त बैकअप परीक्षण के रूप में उपयोगी हो सकता है, संभावित बगों को पकड़ने के लिए जो आपके अन्य परीक्षण छूट सकते हैं। मैं GUI के उन हिस्सों के लिए स्वचालन परीक्षण आरक्षित करता हूं, जिनके टूटने का खतरा सबसे अधिक है और / या अत्यधिक महत्वपूर्ण हैं। ऐसे हिस्से जहां मैं जल्द से जल्द जानना चाहता हूं अगर कुछ टूट गया है। इसमें अत्यधिक जटिल इंटरैक्टिव घटक शामिल हो सकते हैं जो ब्रेकिंग या महत्वपूर्ण मुख्य स्क्रीन के लिए असुरक्षित हैं।

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

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

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

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

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

यह सब मेरे व्यक्तिगत अनुभव और शोध के साथ-साथ हैम वॉके द्वारा यूआई टेस्ट पर एक शानदार लेखन पर आधारित है ।

Answer 12

जो मैं जानता हूं, यह काफी जटिल है, और वास्तव में भाषा पर निर्भर करता है - कई भाषाओं का GUI परीक्षण का अपना तरीका है, लेकिन अगर आपको वास्तव में GUI (मॉडल / गुई इंटरैक्शन के विपरीत) का परीक्षण करने की आवश्यकता है, तो आपको अक्सर करना होगा वास्तविक उपयोगकर्ता क्लिक बटन का अनुकरण करें। उदाहरण के लिए, ग्रहण में प्रयुक्त SWT फ्रेमवर्क SWTBot प्रदान करता है , JFCUnit पहले ही उल्लेख किया जा चुका है, मोज़िला का XUL में इसे अनुकरण करने का अपना तरीका है (और मैंने उनके ब्लॉग पर जो पढ़ा है, ये परीक्षण काफी भंगुर लगते हैं)।

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

Answer 13

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

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

मुझे लगता है कि आपको बस यह स्वीकार करना होगा कि GUI के कुछ पहलुओं को स्वचालित इकाई परीक्षणों द्वारा प्रभावी ढंग से परीक्षण नहीं किया जा सकता है और आपको उन्हें अन्य तरीकों से परीक्षण करना होगा।

Answer 14

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