हर कोई स्व-लिखित परीक्षा के ढांचे को डांटता है। और हम अपने साथ खुश हैं

मेरा नाम ऐलेना रस्तोगुएवा है, मैं एचएफएलएब्स में फैक्टर उत्पाद के लिए जिम्मेदार हूं । कारक एक जटिल जटिल एल्गोरिथम उद्यम है, यह एक औद्योगिक पैमाने पर डेटा को संसाधित करता है।

लेख में, मैं आपको बताऊंगा कि हमने फैक्टर का परीक्षण कैसे शुरू किया, हमने ऑटो-टेस्ट कैसे विकसित किए और हम स्व-लिखित रूपरेखाओं में क्यों आए।

यह किस प्रकार का उत्पाद है - "कारक"

"फैक्टर" लाखों ग्राहकों के साथ डेटाबेस में डेटा को साफ करता है: नाम, फोन और ईमेल में टाइपोस को हटा देता है, पासपोर्ट की जांच करता है, बहुत कुछ करता है। सबसे मुश्किल बात मेलिंग पतों को सही करना है।


_{पते सैकड़ों तरीकों से लिखे गए हैं, इसलिए फैक्टर में हुड के नीचे एक मजबूत एल्गोरिदम तंत्र है}

"फैक्टर" एक सेवा के रूप में काम करता है: इनपुट डेटा - आउटपुट डेटा।

यह एक सांविधिक प्रणाली है जहां प्रत्येक कॉल पिछले वाले से स्वतंत्र है। स्टेटलेस परीक्षक के जीवन को बहुत सरल करता है। जब किसी क्रिया का क्रम महत्वपूर्ण होता है, तो किसी राज्य प्रणाली का परीक्षण करना अधिक कठिन होता है।

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

ऑटोटेस्ट्स की विश्वसनीयता आवश्यकताओं के कारण, हमने विकास की शुरुआत से लिखा था। कार्य की तत्परता के लिए एक मापदंड "जोड़ा गया ऑटोटेस्ट" है।

मैनुअल चेक और ऑटोटेस्ट से शुरू हुआ

हमने 2005 में फैक्टर लॉन्च किया और सबसे पहले अपने हाथों से इसका परीक्षण किया। सुबह, परीक्षक ने मामलों के साथ एक फ़ाइल पर ऑटो-परीक्षण चलाए और पिछले दिन के परिणाम के साथ डेटा प्रसंस्करण के परिणाम की तुलना की: कल के कोड कमिट के बाद क्या बदल गया।

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

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


_{एसएनआईएलएस प्रारूप की जाँच के लिए इकाई परीक्षण}

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

अपना ढांचा बनाएं

पारंपरिक इकाई परीक्षणों में, डेटा और कोड को मिलाया जाता है, सही भागों को खोजना मुश्किल होता है।

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

मामलों को एक एक्सेल-फ़ाइल से लोड किया गया था, वे "रॉ डेटा" और "अपेक्षित परिणाम" कॉलम में थे। डीडीटी एक सफलता थी: "एक्सलनिक" में अपडेट होने वाले मामले अनुभवहीन रूप से सरल हैं।

थोड़ा-थोड़ा करके, हमने एक दृष्टिकोण विकसित किया और अपना स्वयं का परीक्षण ढांचा विकसित किया। यह पाठ फ़ाइलों को इनपुट के रूप में प्राप्त करता है, उनके अंदर स्रोत डेटा और अपेक्षित परिणाम हैं।


_{हमने भंडारण के रूप में एक्सेल-फाइलों से इनकार कर दिया: पाठ फाइलें तेजी से खुलती हैं, सामग्री को नहीं बदलते हैं, उनसे डेटा एकत्र करना आसान है}

फ्रेमवर्क को मानक उपकरणों द्वारा मदद की जाती है:

• टीमसिटी हर रात अपने आप टेस्ट चलाती है;
• testNG अपेक्षित और वास्तविक परिणामों की तुलना करता है।

_{यदि परिणाम अपेक्षा से अलग है, तो टीमसिटी में परीक्षण की पुष्टि होती है। यदि सब कुछ जैसा होना चाहिए, परीक्षण हरा है}

अपने लिए रूपरेखा को संशोधित किया

तब से 12 साल बीत चुके हैं। इस समय के दौरान, फ्रेमवर्क उन क्षमताओं से आगे निकल गया है जो मानक समाधानों में नहीं हैं।

जीरा में कार्य की स्थिति का लेखा-जोखा। HFLabs परीक्षण प्रेरित विकास का पालन ​​करता है: पहले हम एक परीक्षण लिखते हैं या नए व्यवहार के लिए परीक्षण मामलों को जोड़ते हैं, और उसके बाद ही कार्यक्षमता को बदलते हैं।

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

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

इसलिए, हमने डिस्कनेक्ट किए गए मामलों में एक कार्य संख्या जोड़ दी और थोड़ा सा स्वचालन कर दिया। अब सब कुछ इस तरह काम करता है:

• परीक्षण का मामला जीरा में एक खुले कार्य के साथ मिलान करके अक्षम किया गया है;
  
  
  _{किसी कार्य को केस संलग्न करने के लिए, उसके सामने # और कार्य संख्या लिखें}
  
• फ्रेमवर्क अक्षम मामलों पर भी परीक्षण चलाता है। जीरा में टास्क खुला होने के बावजूद क्रैश को नजरअंदाज किया जाता है;
• जैसे ही कार्य बंद हो जाता है, परीक्षण इससे जुड़े मामलों पर पड़ना शुरू हो जाता है। यह एक संकेत है: उन्होंने कार्य पारित कर दिया, लेकिन मामलों को चालू करना भूल गए;
• यदि अचानक डिस्कनेक्ट किए गए मामले के लिए परीक्षण एक खुले कार्य के साथ पारित होने लगा, तो फ्रेमवर्क इस बारे में भी सूचित करेगा। शायद यह मामले को चालू करने या इसके साथ संलग्न कार्य को बंद करने का समय है (प्लस अपडेट नोट जारी करें और ग्राहकों को सूचित करें)।
  
  
  _{ढांचा कहता है कि डिस्कनेक्ट किया गया मामला गुजर रहा है। शायद किसी ने दूसरे कार्य के हिस्से के रूप में कोड को सही किया, और अब सब कुछ काम करता है}
  

इसलिए हमने परीक्षण मामलों को प्रबंधित करते समय टीडीडी को बचाया और भूलने की बीमारी को हराया।


_{हमने परीक्षण के मामलों और संबंधित कार्यों की स्थिति के साथ सभी विकल्पों का दस्तावेजीकरण किया, ताकि भूल न जाएं}

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

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

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


_{एक जीता-जागता उदाहरण: हमने फोन नंबर के द्वारा किसी देश का निर्धारण करने के लिए "कारक" सिखाया, TeamCity में परीक्षण गिर गए। एक नया बेंचमार्क वास्तविक परिणाम से लिया जा सकता है, लेकिन इसमें लंबा समय लगता है}

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


_{पहली फ़ाइल एक नया बेंचमार्क है जिसमें रूपरेखा ने अपेक्षित परिणाम अपडेट किए हैं। शेष फाइलें इनपुट डेटा, पुराने मानक और गिराए गए मामलों के लिए वास्तविक डेटा हैं।}

नए बेंचमार्क के साथ, परीक्षक तीन चरणों में मामलों को अपडेट करता है।

1. जनरेट की गई फ़ाइल डाउनलोड करें।
2. किसी भी विलय उपकरण के माध्यम से जांचता है कि नए बेंचमार्क में क्या परिवर्तन हैं। केवल आवश्यक छोड़ देता है।
3. करता है।

_{परीक्षक यह जांचता है कि क्या नए मानक में अपडेट सही हैं और क्या वे प्रतिबद्ध हैं}

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

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

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

जब हमने महसूस किया कि हम अपने समय को बर्बाद कर रहे हैं तो महत्वहीन परिणाम का विश्लेषण करते हुए हमने अपेक्षित परिणाम में स्टब्स को जोड़ा।

जब क्षेत्र को बिल्कुल भी जांचने की आवश्यकता नहीं होती है, तो परीक्षक अपेक्षित परिणाम में प्रतीक लिखता है: $$ DNV $$ । जब फ़ील्ड भरा जाना चाहिए, लेकिन मूल्य स्वयं महत्वपूर्ण नहीं है: $ $ NE $ $ ।


_{FIAS ID हमेशा पते में होती है, इसलिए हम इसे सभी परीक्षणों पर जाँचते हैं। यदि मैदान खाली है, तो कुछ गलत है। लेकिन सूचकांक नहीं हो सकता है, इसलिए, FIAS ID की जाँच करते समय, हम सूचकांक की उपेक्षा करते हैं}

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

एक स्व-लिखित रूपरेखा अधिक सुविधाजनक है

इसलिए, मैं अपने ढांचे को बेवकूफ बनाने के लिए बिल्कुल भी विचार नहीं करता। यदि हमने अपना स्वयं का उपकरण नहीं बनाया है, तो हमें इतने नए अवसर और ऐसा लचीलापन नहीं मिला है।

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

यदि आप उद्यम में जटिल चीजें करना पसंद करते हैं, तो हमारे पास आएं। अब हम एक जावा डेवलपर की तलाश कर रहे हैं , व्यक्तिगत आयकर के बिना 135 000 a से वेतन।