⚾️ 👨‍👧‍👧 🧕🏽 यूनिवर्सल ऑटोटेस्ट, या हमने नैनोसीएडी में मैनुअल एपीआई परीक्षणों को कैसे स्वचालित किया 🛵 👨🏽‍🏭 👩🏼‍🤝‍👩🏻

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

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

एसक्यूए डेज़ -12 सम्मेलन में रिपोर्ट के आधार पर।

नैनोसीएडी के परीक्षण के कार्यों को दो मुख्य समूहों में विभाजित किया जा सकता है। पहला नैनो-पैड एक डिजाइनर उपकरण के रूप में परीक्षण कर रहा है, जहां मुख्य सवाल यह है: "क्या डिजाइनर आकर्षित कर सकता है जो आवश्यक है?"। दूसरा समूह एपीआई परीक्षण है, यहां हम एक और प्रश्न के उत्तर की तलाश कर रहे हैं: "क्या वे एप्लिकेशन जो काम करना चाहिए?"।

कार्यक्रम के मैनुअल परीक्षणों के साथ जिसमें उपयोगकर्ता काम करता है, सब कुछ स्पष्ट है। तो एक मैनुअल एपीआई परीक्षण क्या है? और एपीआई का परीक्षण करने के लिए नियमित इकाई परीक्षणों का उपयोग क्यों नहीं किया जाता है?

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

एपीआई मैनुअल परीक्षण योजना इस प्रकार है:

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

: GetAngleTest     UnitTest.dwg   ,  : 0,0,0  : 100,100,0   .  Esc: <Esc>    0.  0: 0     0.  0: 0    .     0.  0: 1     .  Enter  : <Enter>     .  Enter  : <Space>     .  Enter  : 1    .  Enter  : <Enter>   .   : #sqadays12     .  Enter <135>: <Space>     .    [/-/]:        .  Enter   <135>  [/-/]: <Enter>

परीक्षण के मामले के पूरा होने पर, लॉग फ़ाइल का विश्लेषण किया जाता है।

स्वचालन के साथ शुरुआत करते हुए, हमने "लाल बटन" दबाकर शुरुआत की और एक स्क्रिप्ट दर्ज की। एक चमत्कार नहीं हुआ, सभी बिंदुओं, जैसा कि अपेक्षित था, स्क्रीन निर्देशांक में दर्ज किए गए थे।

 Window.MouseClick(100, 200); //

क्या करें? स्क्रीन समन्वय प्रणाली उपयुक्त नहीं है, क्योंकि स्क्रीन पर ड्राइंग तत्वों की स्थिति बदल सकती है, और एक विश्वसनीय ऑटोटेस्ट को इस पर निर्भर नहीं होना चाहिए:

आकार और अनुप्रयोग विंडो और उसके नियंत्रण पैनलों की स्थिति,
OS की शैलियों से, OS के विभिन्न संस्करणों में नियंत्रण प्रदर्शित करता है,
मल्टी-मॉनिटर कॉन्फ़िगरेशन,
और भी बहुत कुछ ...

उत्तर स्पष्ट था: आपको ड्राइंग की समन्वय प्रणाली में अंक संग्रहीत करने की आवश्यकता है।

लेकिन परीक्षण के दौरान ड्राइंग के निर्देशांक को स्क्रीन निर्देशांक में कैसे परिवर्तित किया जाए?

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

हमने COM मॉडल को स्क्रीन से ड्राइंग और इसके विपरीत में परिवर्तन के साथ पूरक किया:

 nanoCAD.Utility.CoordFromPixelToWorld() nanoCAD.Utility.CoordFromWorldToPixel()

और परीक्षण सर्किट में परीक्षक को एक स्वचालित परीक्षण प्रणाली से बदल दिया गया है:

अब हमारा स्वचालित परीक्षण इस तरह दिखता है:

 x_drawing = 3.14; //  :   y_drawing = 159265; //     FromWorldToPixel(x_drawing, y_drawing, x_screen, y_screen); Window.MouseClick(x_screen, y_screen); //    100, 200, //      .

इस दृष्टिकोण की कमियों में से एक ऐसी स्क्रिप्ट को स्वचालित रूप से लिखने में असमर्थता है - जब रिकॉर्डिंग, स्क्रीन निर्देशांक को गतिशील रूप से ड्राइंग के निर्देशांक में परिवर्तित किया जाना चाहिए। यदि कोई पूर्ण एडाप्टर था, तो यह समस्या हल हो सकती है।

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

हमने इस खामी को खत्म करने और यह सुनिश्चित करने का निर्णय लिया कि परीक्षण का पूरा तर्क एक मॉड्यूल में हो। दो विकल्पों पर विचार किया गया:

परीक्षण का तर्क स्वचालित परीक्षण प्रणाली में स्थित है, एक सार्वभौमिक परीक्षण नैनो कार्ड में लोड किया गया है, जो अग्रणी ऑटोटेस्ट से स्थानांतरित की गई क्रियाओं को करता है
परीक्षण का तर्क नैनोकाड में स्थित है, एक सार्वभौमिक ऑटोटेस्ट को स्वचालित परीक्षण प्रणाली में लोड किया जाता है, मेजबान परीक्षण से स्थानांतरित की गई क्रियाओं को निष्पादित करता है।

पहला विकल्प उपयुक्त नहीं है, क्योंकि यह हमें परीक्षण को मैन्युअल रूप से चलाने के अवसर से वंचित करता है। हमने दूसरा विकल्प चुना, पुस्तकालय जो प्रत्येक सार्वभौमिक ऑटो-टेस्ट का उपयोग करता है, हमने "सार्वभौमिक खिलाड़ी" कहा।

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

यह सब व्यवहार में कैसे दिखता है? आइए हम उदाहरण पर लौटते हैं - गेटएंगल () फ़ंक्शन का परीक्षण, जिसका उल्लेख लेख की शुरुआत में किया गया था।

 : GetAngleTest ...   ,  : 0,0,0  : 100,100,0 ...

NanoCAD में लोड GetAngleTest कमांड को मैन्युअल रूप से या स्वचालित रूप से चलाया जा सकता है।

 [CommandMethod("GetAngleTest")] public void GetAngleTest() { //   UI       testRunner.AddAction(new ActionClickDocument(0, 0, 0)); testRunner.AddAction(new ActionClickDocument(100, 100, 0)); testRunner.SendActions(); //  EditorInput.Editor.GetAngle() PromptAngleOptions opts = new PromptAngleOptions("  "); PromptDoubleResult pr = this.ed.GetAngle(opts); //      thisAssert.IsTrue((pr.Status == PromptStatus.OK) && (pr.Value > 0), "  . " + pr.ToString()); }

RunGetAngleTest स्वचालित परीक्षण केवल उन कार्रवाइयों को करता है जो इसे GetAngleTest कमांड से भेजे गए थे।

 [TestMethod] public void RunGetAngleTest() { //   'GETANGLETEST' Keyboard.SendKeys(uICommandLineEdit, "GETANGLETEST{Enter}", ModifierKeys.None); //   UI this.ProcessUIActions(context); }

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

वैसे, क्या आपने देखा कि हमारी कंपनी ने परीक्षकों के लिए रिक्त पद भरे हैं ?

लेख की चर्चा हमारे मंच पर भी उपलब्ध है: forum.nanocad.ru/index.php?showtopic=6513 ।

यूनिवर्सल ऑटोटेस्ट, या हमने नैनोसीएडी में मैनुअल एपीआई परीक्षणों को कैसे स्वचालित किया

More articles: