टीसीएस बैंक में परीक्षण इंटरफेस का रहस्य

मैं सामान्य शब्दों में यह बताने की कोशिश करूंगा कि टीसीएस बैंक में इंटरफेस के परीक्षण की प्रक्रिया कैसी दिखती है।

अस्पष्ट अतीत

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

आकर्षक उपस्थित

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

कोड परीक्षण

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

परीक्षण के माध्यम से विकास के लिए विभिन्न दृष्टिकोण हैं: टीडीडी, बीडीडी, आदि। हम यह नहीं समझ पाएंगे कि वे एक दूसरे से कैसे भिन्न हैं, लेकिन उनकी परीक्षण प्रक्रिया पर ध्यान केंद्रित करते हैं।

ग्रंट स्टैटिक्स के निर्माण और परीक्षण चलाने के लिए जिम्मेदार है। हम ग्रन्ट + कर्मा + फैंटमजस + जैस्मीन + सिनोन + कॉफीस्क्रिप्ट का एक गुच्छा उपयोग करते हैं। हां, आपने कॉफीस्क्रिप्ट के बारे में सही सुना है।

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

जैस्मीन - सादगी के लिए चुनी गई, सिनॉन - एपीआई अनुरोधों का अनुकरण करने के लिए, कर्म - बस एक शांत परीक्षण धावक, और फैंटम जेएस - टीम सिटी से ऑटोटेस्ट्स चलाने के लिए।

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

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

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

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

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

परीक्षण दो प्रकार के होते हैं:

• मैन्युअल रूप से
• ऑटो परीक्षण

पहले विकल्प के साथ, सब कुछ स्पष्ट है, हम तब तक क्लिक करते हैं जब तक कि माउस टूट न जाए, और बटन कीबोर्ड से बाहर निकल जाते हैं। दूसरे के साथ - थोड़ा और अधिक जटिल ...

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

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

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

परीक्षण वातावरण के अलावा, हमारे पास मुकाबला पर्यावरण के लिए धुएं के परीक्षण हैं, वे कम कई हैं और अप्रत्याशित विफलताओं के मामले में केवल महत्वपूर्ण कार्यक्षमता को कवर करते हैं।

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