🙏🏼 🥉 🐘 TextTest GUIs और अधिक के परीक्षण के लिए एक क्रॉस-प्लेटफॉर्म पायथन फ्रेमवर्क है। भाग २ 🍓 🦍 👎🏼

अद्भुत क्रॉस-प्लेटफॉर्म टेक्स्टटेस्ट कार्यात्मक-परीक्षण ढांचे के बारे में कहानी की निरंतरता। लेख का पहला भाग।

जीयूआई परीक्षण के तरीके

जीयूआई परीक्षण उपकरण का विशाल बहुमत दो तरीकों में से एक में काम करता है:

प्रत्येक स्क्रीन परिवर्तन के बाद स्क्रीनशॉट लें और फिर परिवर्तनों की तुलना करें
ऐसे कार्य प्रदान करें जो आपको ऑपरेटिंग सिस्टम एपीआई के माध्यम से विजेट मापदंडों को पढ़ने की अनुमति देते हैं

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

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

ActivateWindow("Unsaved Document 1 - gedit") SetEdit(5, "5") ClickButton("Save") Wait(10) VerifyLabel(2, 10)

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

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

अंत में, दोनों दृष्टिकोणों में गैर-समकालिक घटनाओं के परीक्षण के साथ एक आम समस्या है। मान लीजिए कि आप अपने ब्राउज़र में एक URL दर्ज करते हैं, और यह जांचने के लिए कि पृष्ठ ने लोड किया है या नहीं?

आप एक टाइमआउट कर सकते हैं, लेकिन समस्या यह है कि अगर पेज औसतन 5 सेकंड में लोड होता है, तो आपको टाइमआउट को "निष्ठा" के लिए 5 बार सेट करने की आवश्यकता है, और यहां तक कि यह भी काम नहीं करेगा। यह परीक्षणों की मंदी और उनके निष्पादन की संभावित प्रकृति की ओर जाता है।

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

टेक्स्टटेस्ट क्या विकल्प देता है?

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

तो, यह हमें क्या देता है:

हम फार्म और उनकी उपस्थिति पर तत्वों के स्थान से सार करते हैं, यह हमारे लिए मायने नहीं रखता है कि विभिन्न ओएस पर बटन का एक अलग रूप है, हम केवल तर्क का परीक्षण करते हैं। अगर हमें यह जांचने की आवश्यकता है कि बटन पर क्लिक करने के बाद लेबल मान बदल गए हैं, तो प्रपत्र में कोई भी डिज़ाइन परिवर्तन इस परीक्षण को नहीं तोड़ेंगे।
हम विजेट के लिए पूर्ण पहुंच प्राप्त करते हैं, कोई भी WinApi आपको विजेट के बारे में अधिक जानकारी प्राप्त करने की अनुमति नहीं देगा जो कि इस लाइब्रेरी को बनाता है।
अतुल्यकालिक घटनाओं के लिए, एप्लिकेशन ईवेंट जैसी एक अवधारणा पेश की जाती है, जो यद्यपि कोड को थोड़ा संशोधित करने के लिए मजबूर करती है, यह प्रत्येक एसिंक्रोनस घटना के लिए सिर्फ एक पंक्ति है। संक्षेप में, बाद का सार यह है कि अतुल्यकालिक घटना के पूरा होने पर, हम उस कोड को सूचित करते हैं जो StoryText को सूचित करता है कि ऑपरेशन पूरा हो गया है। स्टोरीटेक्स्ट इस तथ्य को याद करता है और प्लेबैक के दौरान यह ईमानदारी से आवेदन से इस घटना की प्रतीक्षा करेगा और उसके बाद ही परीक्षण जारी रखेगा। वह सब है! कोई टाइमआउट, कोई छिपा हुआ विजेट और अन्य विकृतियाँ नहीं, सब कुछ सरल और तेज़ है
परीक्षण लिखने में आसानी आपको उन्हें ऐसे व्यक्ति के लिए भी बनाने की अनुमति देती है जो प्रोग्रामिंग से बुरी तरह परिचित है। आपको वांछित बटन की खोज नहीं करनी है और उस पर क्लिक करना है, फिर आपको बदले हुए तत्वों के मूल्यों को मुखर करने की आवश्यकता नहीं है, स्टोरीटेक्स्ट उन सभी घटनाओं को रिकॉर्ड करता है जो उपयोगकर्ता ने जीयूआई में सभी परिवर्तनों को निष्पादित और बचाता है, और, जैसा कि आप बाद में देखेंगे, यह एक नहीं बल्कि मानव में ऐसा करता है पठनीय रूप।
समझने में आसानी। पहला परीक्षण रिकॉर्ड करने के बाद, StoryText घटित हुई सभी घटनाओं के लिए उपनाम दर्ज करने की पेशकश करता है, अर्थात्। स्वचालित रूप से उत्पन्न परीक्षण इस तरह नहीं दिखेगा:
```
 entry_in = FindEditByName("entry_in") SetValueForEdit(entry_in, 5) calc_async = FindButtonByName("calc_async") SendEvent(calc_async, <Enter>) SendEvent(calc_async, <Button-1>) SendEvent(calc_async, <ButtonRelease-1>) WaitEvent("data to be loaded") exit = FindButtonByName("exit") SendEvent(exit, <Enter>) SendEvent(exit, <Button-1>) SendEvent(exit, <ButtonRelease-1>) 
```
कि थोड़ा अच्छा सहमत हैं, लेकिन इस तरह:
```
 enter_data 5 run_calc_async wait for data to be loaded exit_from_form 
```
जहाँ enter_data, run_calc_async और exit_from_form उपयोगकर्ता नाम हैं, जो उन्होंने परीक्षण लिखने के बाद दर्ज किए (उपनाम मान - आप हमेशा विशेष सेटिंग फ़ाइल देख सकते हैं)

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

चौथा उदाहरण। Tkinter पर एक तुल्यकालिक GUI का परीक्षण

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

कक्षा TestGUI

 class TestGUI: def __init__(self, root): self.root = root frame1 = Tkinter.Frame(self.root) frame1.pack(fill="both") frame2 = Tkinter.Frame(self.root) frame2.pack(fill="both") frame3 = Tkinter.Frame(self.root) frame3.pack(fill="both") frame4 = Tkinter.Frame(self.root) frame4.pack(fill="both") Tkinter.Label(frame1, text="Input:").pack(side="left") self.var_in = Tkinter.StringVar(value="") Tkinter.Entry(frame1, name="entry_in", textvariable=self.var_in).pack() Tkinter.Label(frame2, text="Output:").pack(side="left") self.label_out = Tkinter.Label(frame2, name="label_out") self.label_out.pack(side="left") Tkinter.Button(frame3, name="entry_calc_sync", text="OnCalcSync", width=15, command=self.on_press_sync).pack(side="left") Tkinter.Button(frame4, name="entry_calc_async", text="OnCalcAsync", width=15, command=self.on_press_async).pack(side="left") Tkinter.Button(frame4, name="entry_exit", text="OnExit", width=15, command=self.on_exit).pack(side="left") self.root.title("Hello World!") self.root.mainloop() def _calc(self): try: return str(int(self.var_in.get()) * 2) except: return "error input" def on_press_sync(self): self.label_out["text"] = self._calc() def _operation_finish(self): storytext.applicationEvent('data to be loaded') self.label_out["text"] = self._calc() def on_press_async(self): self.root.after(10 * 1000, self._operation_finish) def on_exit(self): self.root.destroy()

मैं यह नोट करना चाहता हूं कि परीक्षण शुरू करते समय, tkinter_ex मॉड्यूल आयात किया जाता है (आप इसे यहां से डाउनलोड कर सकते हैं और इसे test.py के आगे रख सकते हैं)। उसकी जरूरत है क्योंकि पुस्तकालय में tkinter समर्थन अभी भी "प्रयोगात्मक और Tkinter के लिए बुनियादी समर्थन है" जैसा कि लेखक खुद लिखते हैं। विशेष रूप से, टिंकर के लिए मानक मॉड्यूल लेबल वर्ग में पाठ परिवर्तनों को ट्रैक करने में पूरी तरह से असमर्थ है, लेकिन सौभाग्य से इसे ठीक करना मुश्किल नहीं है। ऐसा करने के लिए, हम मानक Tkinter.Label को अपने स्वयं के साथ प्रतिस्थापित करते हैं, मूल नाम और कार्यक्षमता को संरक्षित करते हैं, और उन कार्यों में जो लेबल टेक्स्ट को बदल सकते हैं - "कॉन्फ़िगर करें" और "__setitem__" हम इस तरह लॉगिंग जोड़ते हैं: "लेबल के लिए अद्यतित पाठ '% s' ( % s पर सेट) पायथन की गतिशीलता के लिए धन्यवाद, कोड जटिल नहीं है

tkinter_ex.py

 # -*- coding: utf-8 -*- import Tkinter import logging origLabel = Tkinter.Label class Label(origLabel): def __init__(self, *args, **kw): origLabel.__init__(self, *args, **kw) self.logger = logging.getLogger("gui log") def _update_text(self, value): self.logger.info("Updated Text for label '%s' (set to %s)" % (self.winfo_name(), value)) def configure(self, *args, **kw): origLabel.configure(self, *args, **kw) if "text" in kw: self._update_text(kw["text"]) def __setitem__(self, key, value): origLabel.__setitem__(self, key, value) if key == "text": self._update_text(value) config = configure internal_configure = origLabel.configure Tkinter.Label = Label

तो, चलो चलते हैं: एक नया परीक्षण-सूट जोड़ें "Suite_GUI" और एक परीक्षण इसे "Test_GUI_Sync" पैरामीटर "gui" के साथ करें। simpletests \ config.cfg में हम सेटिंग्स जोड़ते हैं जो यह दर्शाता है कि हम tkinter के आधार पर GUI का परीक्षण करेंगे

 # Mode for Use-case recording (GUI, console or disabled) use_case_record_mode:GUI # How long in seconds to wait between each GUI action slow_motion_replay_speed:3.0 # Which Use-case recorder is being used use_case_recorder:storytext # Single program to use as interpreter for the SUT interpreter:storytext -i tkinter virtual_display_count:0

मैं सभी सेटिंग्स को डिक्रिप्ट नहीं करूंगा, आप उनके बारे में यहां पढ़ सकते हैं। मैं केवल एक ही चीज़ पर ध्यान दूंगा: "virtual_display_count", यह केवल UNIX सिस्टम पर ही काम करना चाहिए और आपको Xvfb के माध्यम से वर्चुअल डिस्प्ले पर परीक्षण चलाने की अनुमति देता है। लेकिन कार्यान्वयन त्रुटि के कारण, यदि यह पैरामीटर सेट नहीं है, तो StoryText विंडोज पर वर्चुअल डिस्प्ले बनाने की कोशिश करता है, जहां Xvfb अनुपस्थित है। इसलिए, सेटिंग को स्पष्ट रूप से जोड़ा जाना चाहिए और 0 पर सेट किया जाना चाहिए।

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

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

हमेशा की तरह, हम बचाते हैं और फिर से परीक्षण चलाने की कोशिश करते हैं, सब कुछ ठीक काम करता है।
यह समझने के लिए कि क्या हुआ, आप डिस्क पर दिखाई देने वाली चीज़ों को देख सकते हैं: simpletests \ storytext_files \ ui_map.conf, जो कि हम अभी दर्ज किए गए उपनामों का वर्णन करते हैं। यह फ़ाइल usecase.cfg पर परीक्षण (Test_GUI_Sync) के साथ फ़ोल्डर में देखने लायक भी है, जिसमें परिणामी क्रियाएं पूरी तरह से मानव भाषा में वर्णित हैं:

 enter_data 5 run_calc_sync exit_from_form

stdout.cfg में, आप उपयोगकर्ता की क्रियाओं के बाद होने वाले फ़ॉर्म की स्थिति में सभी परिवर्तन देख सकते हैं। वहां हम लेबल मान "लेबल 'के लिए अपडेटेड पाठ' लेबल_आउट '(10 पर सेट) में परिवर्तन के जवाब में अपनी कक्षा द्वारा बनाई गई एक पंक्ति देखेंगे। तो सब कुछ काम करता है। अगले उदाहरण के लिए महान कदम

पांचवा उदाहरण। Tkinter पर अतुल्यकालिक जीयूआई का परीक्षण

एक नया परीक्षण "Test_GUI_Async" को "Suite_GUI" में जोड़ें और इसे अंतिम बार लिखें, केवल "OnCalcSync" के बजाय "OnCalcAsync" बटन पर क्लिक करें और इस बार आपको 10 सेकंड के लिए गणना परिणामों की प्रतीक्षा करनी होगी। काम पूरा होने पर, आपको किसी तरह नए बटन पर क्लिक करने की कार्रवाई को कॉल करने की आवश्यकता होगी, उदाहरण के लिए, पथ "run_calc_async" होगा। हमने पिछली बार अन्य सभी कार्यों को बुलाया और स्टोरीटेक्स्ट ने उन्हें याद किया।

यह परीक्षण दिलचस्प है क्योंकि प्रपत्र पर क्रियाएँ अब एसिंक्रोनस रूप से होती हैं और "TestGUI._operation_finish" से दस सेकंड पहले बटन पर क्लिक करने के बाद test.py मॉड्यूल से कहा जाता है। इस फ़ंक्शन में, परिणाम की गणना करने के अलावा, लाइन जोड़ी जाती है:

 storytext.applicationEvent('data to be loaded')

जो StoryText को बताता है कि किसी प्रकार के अतुल्यकालिक ऑपरेशन ने अपना काम पूरा कर लिया है और इसे परीक्षण में परिलक्षित करने की आवश्यकता है, और जब स्वचालित रूप से निष्पादित किया जाता है, तो आपको उसी स्थान पर रुकना चाहिए और घटना के होने की प्रतीक्षा करनी चाहिए।
यदि आप नए परीक्षा में usecase.cfg को देखते हैं, तो आप देखेंगे:

 enter_data 5 run_calc_async wait for data to be loaded exit_from_form

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

बैच निष्पादन

हर कोई जानता है कि यदि परीक्षण चलाने के लिए बहुत समय और प्रयास की आवश्यकता होती है, तो कोई भी ऐसा नहीं करेगा, इसलिए परीक्षणों को एक बटन के साथ लॉन्च किया जाना चाहिए या पूरी तरह से स्वचालित मोड में एक अलग सर्वर पर भी चलाया जाना चाहिए। इसके लिए, TextTest एक रिपोर्ट के बाद की पीढ़ी के साथ बैच निष्पादन कार्य प्रदान करता है और या तो इसे एक प्रारूप (HTML, JUnit, Jenkins) पर अपलोड कर रहा है या इसे ई-मेल द्वारा भेज रहा है।

हम सब कुछ html में अनलोड करेंगे। आपको केवल परीक्षण के परिणामों को संग्रहीत करने के लिए फ़ोल्डर में पथ को कॉन्फ़िगर करना होगा और HTML रिपोर्ट को संग्रहीत करने के लिए पथ को चुनना होगा। ऐसा करने के लिए, मुख्य config.cfg में फ़ाइल के अंत में निम्नलिखित पंक्तियाँ जोड़ें:

 [batch_result_repository] default:batchresult [historical_report_location] default:historicalreport

वहां आप काफी कुछ अतिरिक्त मापदंडों को निर्दिष्ट कर सकते हैं, मैं उन पर ध्यान केंद्रित नहीं करूंगा, यहां बैच मोड पर प्रलेखन के लिए एक लिंक है।
परीक्षणों को स्वचालित रूप से चलाने के लिए, आपको अजगर के माध्यम से "-b नाइटजॉब" पैरामीटर के साथ texttest.py मॉड्यूल शुरू करना होगा, कुछ इस तरह से:

 python c:\TextTest\texttest-3.24\source\bin\texttest.py -b nightjob

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

 python c:\TextTest\texttest-3.24\source\bin\texttest.py -b nightjob -coll web

अब एक और ऐतिहासिक फ़ोल्डर दिखाई देगा, जिसमें परिणाम के साथ HTML पृष्ठ निहित है। कई दिनों के काम के बाद, ऐसा लग सकता है:

ठीक है, या आप स्वयं TextTest के परीक्षा परिणाम देख सकते हैं। तो, वैसे, काफी दिलचस्प आँकड़े - लगभग 4,000 परीक्षण दैनिक चलाए जाते हैं, और लगभग सभी मॉड्यूल का परीक्षण कवरेज 100% के करीब है (हालांकि मैं निश्चित रूप से समझता हूं कि कवरेज का प्रतिशत खुद इसके बारे में बहुत कम कहता है)।

संक्षेप में देना

आकर्षण आते हैं

आइए मुख्य रूप से GUI परीक्षण के दृष्टिकोण से, फ्रेमवर्क के सकारात्मक पहलुओं को संक्षेप में प्रस्तुत करने का प्रयास करें:

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

विपक्ष

यह गलत नहीं होगा कि विपक्ष का उल्लेख न करें, खासकर जब से वे हैं:

पहला जीयूआई है, यह बहुत कार्यात्मक नहीं है, सेटिंग्स मुख्य रूप से इसके माध्यम से नहीं की जाती हैं, लेकिन कॉन्फ़िगरेशन के प्रलेखन + मैनुअल संपादन के माध्यम से होती हैं। निष्पक्षता में, मुझे कहना होगा कि सेटअप एक बार किया जाता है, और उसके बाद केवल रिवेट टाइप टेस्ट। लेकिन अध्ययन के प्रारंभिक चरण में, जल्दी से टिक करने और यह समझने के लिए पर्याप्त अवसर नहीं है कि क्या हो।
जीयूआई की स्थिरता, कभी-कभी दुर्घटनाग्रस्त हो जाती है, मुझे यह भी पता नहीं है कि इसे क्या करना है, या तो PyGTK के काम, या विंडोज के तहत कमजोर परीक्षण, लेकिन तथ्य यह है। लेकिन फिर से, जीयूआई का उपयोग केवल परीक्षण बनाते समय किया जाता है, और फिर इसे कई बार चलाया जाता है, और मैंने बाद वाली किसी भी समस्या का अवलोकन नहीं किया।
कभी-कभी त्रुटियां होती हैं और आपको यह समझने के लिए कोड में जाना पड़ता है कि क्या हुआ था (मैंने ऊपर virtual_display_count पैरामीटर के साथ एक उदाहरण दिया था।) हालांकि, जो कुछ भी मैं भर आया था वह एक या दूसरे तरीके से हल हो गया है, जितना अधिक स्रोत कोड खुला है और आप हमेशा देख सकते हैं कि क्या सही करने की आवश्यकता है। यहाँ फिर से, मैं विंडोज पर पाप करता हूं, ऐसा लगता है कि लेखक UNIX सिस्टम के तहत काम करने में अधिक रुचि रखता है, मुझे उम्मीद है कि ऐसी कोई समस्या नहीं है।
प्रलेखन। हो सकता है कि यह मेरे लिए है, लेकिन मुझे यह समझना होगा कि अगली चिप कैसे काम करती है, यह समझने के लिए मुझे कई बार बहुत सोच-समझकर प्रलेखन पढ़ना पड़ता है। कुछ समझने योग्य चीजें बहुत अच्छी तरह से चित्रित की जाती हैं, लेकिन जटिल लोगों में, बारीकियों को याद किया जाता है। उपलब्ध प्रलेखन एक संदर्भ के रूप में उपयोग करने के लिए काफी सुविधाजनक है, लेकिन केवल यह समझने के बाद कि यह या वह चीज़ कैसे काम करती है।
समुदाय। यहां चीजें बहुत खराब हैं, सामान्य रूप से रूसी इंटरनेट पर, हर कोई रूपरेखा के बारे में चुप है, वे अधिकतम उल्लेख करते हैं कि यह मौजूद है। अंग्रेजी में, मैंने पाया कि सभी विचारधारा के बारे में कहानियां थीं और यह कितना अच्छा था। कुछ समझदार विवरण, मैनुअल, लेख, आदि। मुझे नहीं मिला, सब कुछ केवल लेखक की साइट पर है मैं किसी भी तरह से इस तथ्य की व्याख्या नहीं कर सकता, रूपरेखा बहुत परिपक्व, दिलचस्प और "स्वादिष्ट" दिखती है, वास्तव में कोई विकल्प नहीं है, इसमें क्या गलत है, मुझे समझ में नहीं आता है।
वह लॉन्चपैड को होस्ट करता है, और अब लोकप्रिय गिटहब नहीं है, मुझे डर है कि यह तथ्य कई लोगों को अलग कर देगा जिनके पास कोड लिखने में लेखक की मदद करने की इच्छा और क्षमता है।

विकल्प

यदि आप अजगर में जीयूआई के परीक्षण के लिए विकल्पों को निर्दिष्ट नहीं करते हैं, तो यह विवरण अधूरा होगा, यहाँ हम क्या खोजने में कामयाब रहे:

रोबॉटफ्रैमवर्क इसके बारे में कुछ विशिष्ट कहना मुश्किल है , यह बहुत व्यापक है और आपको दस्तावेज़ीकरण को पढ़ने और इसे लंबे समय तक सोचने की कोशिश करने की आवश्यकता है। जाहिरा तौर पर, यह TextTest स्तर के परीक्षण के लिए एक क्रॉस-प्लेटफ़ॉर्म फ्रेमवर्क है और यह निश्चित रूप से हर किसी के लिए एक नज़र के लायक है जो एक उपकरण चुनता है।

ldtp अगला GUI परीक्षण उपकरण है। इसके तीन कार्यान्वयन हैं
लिनक्स / विंडोज / ओएस एक्स के लिए क्रमशः एलडीटीपी / कोबरा / पायमेट। यह भाषाओं के एक समूह (जावा / रूबी / सी #, आदि) का समर्थन करता है, जिसमें हमें अजगर की आवश्यकता है। मुझे प्रलेखन पसंद आया। सक्रिय रूप से विकसित करना।
मुझे केवल सिद्धांत पसंद नहीं था, परीक्षणों के विवरण से देखते हुए, वे किसी भी तरह इस तरह लिखे जाते हैं:

 selectmenuitem('frmUnsavedDocument1-gedit', 'mnuFile;mnuOpen') settextvalue('frmUnsavedDocument1-gedit', 'txt0', 'Testing editing') setcontext('Unsaved Document 1 - gedit', '*Unsaved Document 1 - gedit') verifytoggled('dlgOpenFile...', 'tbtnTypeafilename')

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

इसके बारे में pywinauto और एक हब पर आप कुछ शब्द पा सकते हैं। सिद्धांत एलडीटीपी में समान है - हम उस तत्व को ढूंढते हैं जिसकी हमें आवश्यकता है और इसके साथ कुछ करें। इसके अलावा, यह केवल विंडोज के तहत काम करता है।

विवरण को देखते हुए, डॉगटेल बहुत मजबूती से यूनिक्स से जुड़ा हुआ है, "GNOME 3, KDE4.8" और "गनोम 2" के लिए अलग-अलग संस्करण हैं, इसलिए ऐसा लगता है कि यह परीक्षण के लिए ग्राफिकल शेल एपीआई का उपयोग करता है, जिसका अर्थ है कि यह स्पष्ट रूप से क्रॉस-प्लेटफ़ॉर्म नहीं है। हालाँकि, यह अभी भी विकसित हो रहा है, इसलिए यदि कुछ को यूनिक्स के तहत परीक्षण करने की आवश्यकता है, तो इसकी दिशा में देखने लायक हो सकता है।

अजगर अनुप्रयोगों में मुख्य रूप से pyGTK के लिए GUIs के परीक्षण के लिए गिटार । अंतिम रिलीज की तारीख 11/13/2005 है। मुझे डर है कि इतने सालों के बाद विकास के बिना, वह भी नहीं कर पाई, जो कि आवश्यक Tkinter का उल्लेख नहीं करने के लिए pyGTK द्वारा घोषित आवेदनों का परीक्षण करने में सक्षम है। मैंने भी नहीं देखा।

pyAA एक और परित्यक्त परियोजना है, और 2005 के बाद से इसे छोड़ दिया गया है, इस तरह की परियोजनाओं में शामिल होने के लिए डरावना है, और यह केवल एक ही परियोजना के साथ है ...

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

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

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

TextTest GUIs और अधिक के परीक्षण के लिए एक क्रॉस-प्लेटफॉर्म पायथन फ्रेमवर्क है। भाग २