खरोंच से परीक्षण स्वचालन। भाग 1

शुभ दोपहर, प्रिय पाठकों।

मैं परीक्षण स्वचालन प्रणाली के निर्माण के अनुभव के बारे में बात करना चाहता हूं जब परियोजना पर कोई परीक्षण नहीं होता है, या इसकी डिग्री न्यूनतम होती है।

मुझे आशा है कि लेख ऑटोट्रेस्टरों के लिए उपयोगी होगा।

• पहले भाग में, हम सामान्य दृष्टिकोण का पक्ष लेते हैं ।
• उदाहरणों के साथ दूसरे भाग ( भाग 1 ) में हम JAVA + पर ऑटोटेस्ट्स की एक परियोजना बनाएंगे। यह सिखाएंगे कि कैसे जल्दी से एपीआई का परीक्षण करें।
• तीसरे भाग में, हम UI परीक्षण के लिए परियोजना को पूरक करेंगे, हम समानांतर परीक्षण करेंगे।

ऑटोटेस्ट्स कब करें?

संक्षिप्त उत्तर जितना जल्दी हो सके।

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

क्यों?

क्योंकि ऑटोटेट:

1. प्रतिगमन के लिए परिदृश्यों को संचित करें
2. निष्पक्षता
3. शीघ्र

संचित परिदृश्य

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

यदि ऑटो परीक्षण सख्ती से पारित हुआ और किसी शाखा पर गिर गया, तो उन्होंने या तो आवश्यकताओं को बदल दिया, या एक बग, या बुनियादी ढांचा विफल हो गया।

निष्पक्षता

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

गति

यदि प्रत्येक परीक्षण थकाऊ स्थितियों को संतुष्ट करता है:

प्रीकंडिशन - टेस्ट - पोस्टकॉन्डिशन
ऐसे परीक्षणों को स्वचालित करना आसान है।

और फिर इसे समानांतर करना आसान है। क्योंकि वे स्वतंत्र हैं।

थ्रेड्स की संख्या - कितने परीक्षण सर्वरों का सामना कर सकते हैं और ताकि दूसरों को परेशान न करें।

दूसरा बिंदु स्वयं गति है। मैनुअल मोड में, उत्पाद के निर्माण पर क्लिक करें, इसकी खोज और ऑनलाइन स्टोर में खरीद 5 मिनट है। 4 ब्राउज़र। कुल 20 मिनट। सिर्फ एक छोटे से परिदृश्य में।

इस परिदृश्य में ऑटोटेस्ट को 1.5 मिनट लगते हैं। लेकिन 8 ब्राउज़रों पर। (प्रत्येक ब्राउज़र के नवीनतम और सुविधाजनक संस्करण)।

कहाँ से शुरू करें?

कस्टम स्क्रिप्टिंग के साथ।

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

क्यूए को उपयोगकर्ता कहानी से काम करना चाहिए। क्योंकि प्रोग्रामर आमतौर पर उसे नहीं जानता है, और जानना नहीं चाहता है।

तदनुसार, तर्क 1 परीक्षण - 1 उपयोगकर्ता मामला (व्यापार परिदृश्य) वास्तविकता के सबसे करीब है।

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

हां, कभी-कभी पूर्व-परीक्षाएं परीक्षण से अधिक समय लेती हैं, लेकिन स्क्रिप्ट का पुन: उपयोग करना मुश्किल नहीं है।

क्या स्क्रिप्ट स्वचालित करने के लिए

कम से कम अवधि में परिवर्तन के लिए अतिसंवेदनशील। स्वचालन के लिए कम से कम कुछ रहते थे।

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

वास्तव में क्या करते हैं?

आमतौर पर वहां की परियोजनाओं में

• बैकएंड
• दृश्यपटल
• मोबाइल ऐप
• लोहे के टुकड़े

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

इसलिए, मैं बैकएंड और फ्रंट से निपटने का प्रस्ताव करता हूं।

एक परिदृश्य चुनें

मान लीजिए कि हमारे पास एक ऑनलाइन स्टोर है।
एक व्यवस्थापक पैनल है, एक ग्राहक और व्यवस्थापक मोर्चा है।
एक एपीआई है जो यह सब कार्य करता है।

स्वचालन कहाँ से शुरू करें?

चलो देखते हैं।

ग्राहक हैं, कर्मचारी हैं।

ग्राहक का पहला मामला है - उत्पाद को देखना और खोजना, उसे टोकरी में जोड़ना, और डिज़ाइन करना।
कर्मचारी के पास सबसे आम मामला है - उत्पाद कार्ड जोड़ना।

कौन सा मामला पहले स्वचालित होगा? और कैसे?

स्टोर के लिए सबसे महत्वपूर्ण चीज बिक्री है।

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

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

अगला, उत्पाद कार्ड और उसके मोर्चे को संपादित करने वाले एपीआई पर जांच करें।

और क्लाइंट के पास वापस लौट आएं। इस स्तर पर, पहले से ही सबसे अधिक उपयोगकर्ता कार्यों और सबसे अक्सर ग्राहक पथ पर आँकड़े होंगे। हां, यांडेक्स मैट्रिक और वेबविस्टर भी परीक्षकों की मदद करते हैं।

यह जाँचने के लिए पहले चरण में कोई मतलब नहीं है कि उत्पन्न भुगतान प्रणाली के माध्यम से कंपनी के खाते में भुगतान का कार्य करता है यदि 0.5% आगंतुक इस फ़ंक्शन का उपयोग करते हैं। बेशक, आप प्रबंधक से एक सवाल पूछ सकते हैं कि यहां इसकी आवश्यकता क्यों है, लेकिन यह इस बारे में नहीं है।

मान लें कि हमारे पास साइट पर कार्ड के साथ भुगतान करने वाले 40%, नकद में 30%, डिलीवरी पर 20% नकद और अन्य सभी विधियों में 10% हैं।

हम पहले किस प्रकार के भुगतान की जाँच करेंगे? बेशक नक्शा।

यही है, हमें स्पष्ट रूप से समझना चाहिए कि वर्तमान में व्यवसाय के लिए कौन सा परिदृश्य सबसे महत्वपूर्ण है। और इसकी गुणवत्ता सबसे पहले और सबसे महत्वपूर्ण है।

Postconditions

हमने सब कुछ, सब कुछ परीक्षणों में बनाया। Namusorili। खुद के बाद सफाई करना आवश्यक होगा। अग्रिम में यह देखना आवश्यक है कि हम अपने आप को कौन से परीक्षणों में साफ करेंगे, और जिसमें - नहीं।

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

विषमताएं

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

यानी नया BIC अपडेट नहीं किया गया था। लेकिन नया बैंक सामान्य रूप से शुरू हुआ।

क्या यह इस परिदृश्य को स्वचालित करने के लिए समझ में आता है? यदि ठेकेदार हर दिन बदलते हैं - शायद। और फिर यह योजना में एक दोष था।

यदि यह वर्ष में 5-6 बार किया जाता है, तो क्या उच्च प्राथमिकता वाला कार्य करना बेहतर हो सकता है?

आगे क्या होगा?

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

मुझे आपको एक कीटनाशक के प्रभाव के बारे में याद दिलाना है, और इसे कम से कम कैसे चमकाना है।

प्रौद्योगिकियाँ: जावा + मावेन + टेस्टिंग + लुभाना + पुनर्स्थापना + चित्र।