🈵 🥂 🧑🏾‍🤝‍🧑🏻 परतदार परीक्षण 🐬 😼 📺

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

नतीजतन, दर्शकों ने रिपोर्ट की सराहना की, और हमने न केवल वीडियो प्रकाशित करने का फैसला किया, बल्कि हैबर को रिपोर्ट का एक पाठ संस्करण बनाने के लिए भी कहा।

मेरी राय में, स्वचालन की दुनिया में परतदार परीक्षण सबसे अधिक प्रासंगिक विषय हैं। क्योंकि सवाल "दुनिया में क्या हो रहा है, आप स्वचालन के साथ कैसे कर रहे हैं?" सभी उत्तर: “कोई स्थिरता नहीं है! हमारे परीक्षण समय-समय पर गिरते हैं। ”

आपने अपने स्थान पर एक परीक्षण चलाया, यह हरा है, एक और दो दिन हरा है, और फिर एक बार और अचानक जेनकिंस पर गिर गया। आप इसे दोहराने की कोशिश करते हैं, इसे शुरू करते हैं, और यह फिर से हरा होता है। और अंत में, आप कभी नहीं जानते: क्या यह एक बग है या यह सिर्फ एक ग्लूकोन परीक्षण है? और हर बार आपको समझने की जरूरत है।

अक्सर, जेनकिंस पर परीक्षणों की एक रात की शुरूआत के बाद, परीक्षक पहली बार देखता है "30 परीक्षण गिर गए हैं, आपको अध्ययन करने की आवश्यकता है", लेकिन हर कोई जानता है कि आगे क्या होता है ...

आप निश्चित रूप से अनुमान लगाते हैं कि कौन सा अभद्र शब्द प्रच्छन्न है: "मैं पुनः आरंभ करूंगा।" जैसे, "आज समझने में कोई हिचक नहीं है ..." यह आमतौर पर ऐसा होता है, और यह एक वास्तविक आपदा है।

कोई सटीक आंकड़े नहीं हैं, लेकिन मैंने अक्सर विभिन्न लोगों से सुना है कि उनके पास लगभग 30% परीक्षण हैं - परतदार। मोटे तौर पर, वे एक हजार लॉन्च करते हैं, जिनमें से 300 समय-समय पर लाल होते हैं, और फिर वे अपने हाथों से जांचते हैं कि क्या वे वास्तव में गिर गए थे।

Google ने कुछ वर्षों में एक लेख प्रकाशित किया: यह कहता है कि उनके पास 1.5% प्रतिशत परतदार परीक्षण हैं, और बताता है कि वे अपनी संख्या को कम करने के लिए कैसे लड़ते हैं। मैं थोड़ा डींग मार सकता हूं और कहता हूं कि कोडबोर्न में मेरा प्रोजेक्ट अब 0.1% है। लेकिन वास्तव में, यह सब बुरा है, यहां तक कि 0.1% भी। क्यों?

1.5% लें, यह संख्या छोटी लगती है, लेकिन व्यवहार में इसका क्या मतलब है? मान लीजिए कि एक परियोजना में एक हजार परीक्षण हैं। इसका मतलब यह हो सकता है कि 15 परीक्षण एक बिल्ड में गिर गए, अगले 12, फिर 18। और यह बहुत बुरा है, क्योंकि इस मामले में लगभग सभी बिल्ड लाल हैं, और आपको अपने हाथों से लगातार जांचने की ज़रूरत है कि यह सच है या नहीं।

और यहां तक कि हमारे एक पीपीएम (0.1%) अभी भी खराब है। मान लीजिए हमारे पास 1000 परीक्षण हैं, तो 0.1% का मतलब है कि नियमित रूप से दस में से एक निर्माण 1-2 लाल परीक्षणों के साथ होता है। यहाँ हमारे जेनकींस से वास्तविक तस्वीर है, और यह पता चला है: एक रन के साथ, एक परतदार परीक्षण गिर गया, एक और शुरुआत के साथ।

यह पता चला है कि हमारे पास एक दिन नहीं है बिना लाल बिल्ड के। चूंकि बहुत हरा है, सब कुछ ठीक लग रहा है, लेकिन ग्राहक को हमसे पूछने का अधिकार है: "दोस्तों, हम आपको पैसे देते हैं, और आप हमेशा हमें लाल रंग की आपूर्ति करते हैं!" क्या कर रहे हो?

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

योजना यह है:

अस्थिर परीक्षणों का मेरा संग्रह (मेरे अभ्यास से, बिल्कुल वास्तविक मामले, जटिल और दिलचस्प जासूसी कहानियाँ)
अस्थिरता के कारण (कुछ शोध में भी वर्षों लगे)
उनसे कैसे निपटें? (उम्मीद है कि यह सबसे उपयोगी हिस्सा होगा)

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

उदाहरण 1: क्लासिक

बीज के लिए - क्लासिक सेलेनियम स्क्रिप्ट:

driver.navigate().to("https://www.google.com/"); driver.findElement(By.name("q")).sendKeys("selenide"); driver.findElement(By.name("btnK")).click(); assertEquals(9, driver.findElements(By.cssSelector("#ires .g")).size());

हम वेबड्राइवर खोलते हैं;
तत्व q खोजें, वहां सर्च करने के लिए शब्द में ड्राइव करें;
"बटन" तत्व ढूंढें और क्लिक करें;
जांच लें कि उत्तर नौ परिणाम है।

सवाल: यहां कौन सी लाइन टूट सकती है?

यह सही है, हम सभी अच्छी तरह से जानते हैं कि कोई भी! पूरी तरह से अलग कारणों से कोई भी रेखा टूट सकती है:

पहली पंक्ति धीमी इंटरनेट है, दुर्घटनाग्रस्त हो गई सेवा, कुछ को कॉन्फ़िगर नहीं करती है।

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

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

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

इस उदाहरण में, मैं कहना चाहता हूं कि, मेरे अनुभव में, ९ ०% परतदार परीक्षण उन्हीं कारणों पर आधारित हैं:

अजाक्स अनुरोध गति: कभी-कभी वे धीमी गति से चलते हैं, कभी-कभी तेज;
अजाक्स अनुरोधों का क्रम;
स्पीड जे.एस.

सौभाग्य से, इन कारणों का एक इलाज है! सेलेनाइड इन समस्याओं को हल करता है। यह कैसे तय करता है? हम सेलेनाइड पर अपने Google परीक्षण को फिर से लिखते हैं - लगभग सब कुछ ऐसा दिखता है, केवल $ संकेतों का उपयोग किया जाता है:

 @Test public void userCanLogin() { open(“http://localhost:8080/login”); $(By.name(“username”).setValue(“john”); $(“#submit”).click(); $(“.menu”).shouldHave(text(“Hello, John!”)); }

यह परीक्षा हमेशा गुजरती है। इस तथ्य के कारण कि सेटवैल्यू (), क्लिक () और हैथवे () विधियां स्मार्ट हैं: यदि किसी चीज पर पेंट करने का समय नहीं है, तो वे थोड़ा इंतजार करते हैं और फिर से प्रयास करते हैं (इसे "स्मार्ट अपेक्षाएं" कहा जाता है)।

यदि आप विस्तार से थोड़ा और देखें, तो इन सभी तरीकों को स्मार्ट होना चाहिए:

यदि आवश्यक हो तो वे इंतजार कर सकते हैं। डिफ़ॉल्ट रूप से, वे 4 सेकंड तक प्रतीक्षा करते हैं, और यह टाइमआउट, निश्चित रूप से, विन्यास योग्य है, आप किसी अन्य को निर्दिष्ट कर सकते हैं। उदाहरण के लिए, इस तरह: mvn -Dselenide.timeout = 8000।

उदाहरण 2: nbob

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

हमने कियोस्क में लॉगिन के लिए कीबोर्ड एप्लिकेशन का परीक्षण किया। परीक्षण उपयोगकर्ता "बॉब" के रूप में लॉग इन करना चाहता था, अर्थात, "लॉगिन" फ़ील्ड में तीन अक्षर दर्ज करें: बॉब। ऐसा करने के लिए, स्क्रीन पर बटन का उपयोग किया गया था। एक नियम के रूप में, यह काम करता है, लेकिन कभी-कभी परीक्षण दुर्घटनाग्रस्त हो जाता है, और "nbob" मान "लॉगिन" फ़ील्ड में रहता है:

स्वाभाविक रूप से, आप उस कोड द्वारा खोज करने के लिए संघर्ष कर रहे हैं जहां हम "nbob" लिख सकते हैं - लेकिन पूरी परियोजना में यह बिल्कुल भी नहीं है (न तो डेटाबेस में, न ही कोड में, और ना ही एक्सेल फाइलों में भी)। यह कैसे संभव है?

हम कोड को और अधिक विस्तार से देखते हैं - ऐसा लगेगा कि सब कुछ सरल है, कोई पहेलियां नहीं:

 @Test public void loginKiosk() { open(“http://localhost:9000/kiosk”); $(“body”).click(); $(By.name(“username”)).sendKeys(“bob”); $(“#login”).click(); }

हम आगे कदम से कदम बढ़ाने के लिए बहस करने लगे, और इस पद्धति के साथ हम समझने में कामयाब रहे: यह त्रुटि कभी-कभी लाइन $ ("बॉडी") के बाद दिखाई देती है। क्लिक करें ()। यही है, इस चरण में, "एन" "लॉगिन" फ़ील्ड में दिखाई देता है, फिर बाद के चरणों में "बॉब" जोड़ा जाता है। किसने पहले ही अनुमान लगा लिया है कि "n" कहाँ से आता है?

ऐसा हुआ कि पत्र एन स्क्रीन के बीच में था, और क्रोम में कम से कम क्लिक () फ़ंक्शन इस तरह से काम करता है: यह एक तत्व के केंद्रीय समन्वय की गणना करता है और उस पर क्लिक करता है। चूंकि शरीर एक बड़ा तत्व है, उसने पूरी स्क्रीन के केंद्र में क्लिक किया।

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

आपके पास शायद एक सवाल है: किसी ने $ ("शरीर") क्यों बनाया? क्लिक करें ()? मैं अंत तक नहीं जानता, लेकिन मुझे लगता है कि क्षेत्र से ध्यान हटाने के लिए। सेलेनियम में ऐसी समस्या है जो क्लिक () है, लेकिन अशुद्ध () नहीं है। यदि क्षेत्र में ध्यान केंद्रित है, तो इसे वहां से हटाया नहीं जा सकता है, आप केवल किसी अन्य तत्व पर क्लिक कर सकते हैं। और चूंकि कोई अन्य उचित तत्व नहीं थे, इसलिए उन्होंने शरीर पर क्लिक किया, और ऐसा प्रभाव मिला।

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

परिणामस्वरूप, हम अस्थिर परीक्षणों के कारणों की सूची का विस्तार करते हैं:

अजाक्स अनुरोध की गति;
अजाक्स अनुरोधों का क्रम;
स्पीड जेएस;
ब्राउज़र विंडो का आकार;
वैनिटी!

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

उदाहरण 3: प्रेत खाते

एक उदाहरण इस बात में दिलचस्प है कि सबकुछ केवल संयोग से हो सकता है।

एक परीक्षण था जिसने जांच की थी कि इस स्क्रीन पर 5 खाते होने चाहिए।

एक नियम के रूप में, यह हरा था, लेकिन कभी-कभी यह स्पष्ट नहीं था कि यह किन परिस्थितियों में गिर गया और कहा गया कि स्क्रीन पर पांच नहीं, बल्कि छह मायने थे।

मैंने शोध करना शुरू किया कि अतिरिक्त बिल कहां से आता है। बिलकुल नासमझी है। सवाल उठता है: शायद हमारे पास एक और परीक्षण है, जो परीक्षण के दौरान एक नया खाता बनाता है? यह पता चला कि हां, इस तरह का एक लोनटेस्ट है। और इसके और गिरते हुए खातों के बीच (जो पांच खातों की उम्मीद करता है) कुछ अन्य परीक्षणों का एक मिलियन हो सकता है।

हम यह समझने की कोशिश कर रहे हैं कि यह कैसे है: क्या LoanTest, जो खाता नहीं बनाता है, उसे अंत में हटा दें? हम इसके कोड को देखते हैं - हां, इसे समाप्त करना चाहिए, इसके बाद एक फ़ंक्शन है। फिर, सिद्धांत रूप में, सब कुछ ठीक होना चाहिए, समस्या क्या है?

हो सकता है कि परीक्षण इसे हटा दे, लेकिन यह कहीं न कहीं छाया हुआ है? हम खातों को लोड करने वाले उत्पादन कोड को देखते हैं - इसमें वास्तव में @ कैशेफ़ोर एनोटेशन है, यह खातों को पांच मिनट के लिए कैश करता है।

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

किसी ने पहले से ही देखा, है ना? यह सही है: बच्चे और माता-पिता वर्ग में एक ही नाम के साथ एक विधि है, और यह सुपर नहीं कहता है।

और Java में यह करना बहुत आसान है: आप IntelliJ IDEA या Eclipse में Alt + Enter या Ctrl + Insert दबाएं, डिफ़ॉल्ट रूप से यह आपके लिए सेटअप () विधि बनाता है, और आप ध्यान नहीं देते हैं कि यह सुपरक्लास में विधि को ओवरराइड करता है। यही है, कैश अभी भी नहीं बुलाया गया था। जब मैंने यह देखा तो मैं बेतहाशा गुस्से में था। यह अब मेरे लिए खुशी की बात है।

इसलिए नैतिक:

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

इस घटना के बाद, मैंने आईडीईए में इस तरह के एक निरीक्षण को पाया, डिफ़ॉल्ट रूप से बंद कर दिया, वह जाँच करता है: यदि विधि कहीं से ओवरराइड की जाती है, लेकिन कोई @ ओवरराइड एनोटेशन नहीं है, तो यह इसे एक त्रुटि के रूप में चिह्नित करता है। अब मैं हमेशा इस बॉक्स की हिस्टीरिक जांच करता हूं।

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

हम सूची का विस्तार करते हैं कि परीक्षण अस्थिर क्यों हो सकते हैं:

अजाक्स अनुरोध की गति;
अजाक्स अनुरोधों का क्रम;
स्पीड जेएस;
ब्राउज़र विंडो का आकार;
आवेदन कैश;
पिछले परीक्षणों से डेटा;
समय।

उदाहरण 4: जावा समय

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

 assert payment.time <= new Date();

हम कोड में देखते हैं, अचानक, कुछ शर्तों के तहत, क्या हम भविष्य में एक तिथि निर्धारित कर सकते हैं? हम नहीं कर सकते: केवल उसी स्थान पर जहां भुगतान का समय आरंभिक है, नई तिथि () का उपयोग किया जाता है, और यह हमेशा वर्तमान समय होता है (चरम मामलों में, यह अतीत में हो सकता है यदि परीक्षण बहुत धीमा था)। यह कैसे भी संभव है? वे लंबे समय तक अपना सिर पीटते रहे, वे समझ नहीं पाए।

और एक बार उन्होंने एप्लीकेशन लॉग में देखा। इसलिए पहला नैतिक - आवेदन के लॉग में देखने के लिए परीक्षणों की जांच करते समय यह बहुत उपयोगी है। अपने हाथ उठाओ, जो करता है। सामान्य तौर पर, बहुमत नहीं, अफसोस। और उपयोगी जानकारी है: उदाहरण के लिए, अनुरोध लॉग, ऐसे-और-ऐसे URL को ऐसे समय में निष्पादित किया गया था, इस तरह के और इस तरह के जवाब दिए।

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

तो: 34 सेकंड, 35, 36, 37, 35, 39 ... यह अच्छा है कि हमने इसे पाया, लेकिन यह कैसे संभव है? सिद्धांत फिर से समाप्त हो गए, एक और दो दिन उनके सिर को खरोंच कर रहे थे। यह वास्तव में मामला है जब मैट्रिक्स आपके साथ मजाक कर रहा है, है ना?

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

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

वैसे, मैंने उसी समय जावा के एक दिलचस्प बारीकियों को सीखा, जो इससे पहले, मेरे कई वर्षों के अनुभव के बावजूद नहीं जानता था। जावा में सबसे बुनियादी तरीकों में से एक को System.currentTimeMillis () कहा जाता है, जिसकी मदद से आमतौर पर किसी चीज को कॉल करने के लिए समयबद्ध किया जाता है, कई ने ऐसे कोड लिखे:

 long start = System.currentTimeMillis(); // ... long end = System.currentTimeMillis(); log.info("Loaded in {} ms", end-start);

ऐसा कोड Apache Commons, Guava पुस्तकालयों में है। यही है, अगर आपको यह पता लगाने की आवश्यकता है कि किसी चीज को कॉल करने के लिए कितने मिलीसेकंड लगे, तो वे आमतौर पर ऐसा करते हैं। और बहुतों ने शायद सुना है कि ऐसा नहीं किया जाना चाहिए। मैंने भी सुना, लेकिन न जाने क्यों, और समझने के लिए बहुत आलसी भी। मैंने सोचा था कि सवाल ठीक था क्योंकि System.nanoTime () जावा के कुछ संस्करण में दिखाई दिया - यह अधिक सटीक है, यह नैनोसेकंड का उत्पादन करता है जो एक मिलियन गुना अधिक सटीक हैं। और चूंकि, एक नियम के रूप में, मेरी कॉल एक दूसरे या आधे सेकंड तक चलती है, यह सटीकता मेरे लिए महत्वपूर्ण नहीं है, और मैंने System.currentTimeMillis () का उपयोग करना जारी रखा, जिसे हमने लॉग में देखा जहां यह -3 सेकंड था। तो, वास्तव में, सही तरीका यह है, और अब मुझे पता चला क्यों:

 long start = System.nanoTime(); // ... long end = System.nanoTime(); log.info("Loaded in {} ms", (end-start)/1000000);

दरअसल, यह तरीकों के प्रलेखन में लिखा गया है, लेकिन मैंने इसे कभी नहीं पढ़ा। मैंने अपना सारा जीवन सोचा है कि System.currentTimeMillis () और System.nanoTime () एक ही बात है, केवल एक लाख गुना अंतर के साथ। लेकिन यह पता चला कि ये मौलिक रूप से अलग चीजें हैं।

System.currentTimeMillis () वास्तविक वर्तमान तिथि लौटाता है - 1 जनवरी, 1970 से अब तक कितने मिलीसेकंड हैं। और System.nanoTime () एक प्रकार का सार काउंटर है जो वास्तविक समय से बंधा नहीं है: हाँ, यह प्रति यूनिट हर नैनोसेकंड बढ़ने की गारंटी है, लेकिन यह वर्तमान समय से जुड़ा नहीं है, यह नकारात्मक भी हो सकता है। जेवीएम की शुरुआत में, समय का एक बिंदु किसी तरह बेतरतीब ढंग से चुना जाता है, और यह बढ़ने लगता है। यह मेरे लिए आश्चर्य की बात थी। आपके लिए भी? खैर, यह व्यर्थ नहीं है कि वह पहुंचे।

उदाहरण 5: हरे बटन का अभिशाप

यहां, हमारा परीक्षण एक निश्चित फॉर्म भरता है, हरे रंग की पुष्टि बटन पर क्लिक करता है, और कभी-कभी यह आगे नहीं बढ़ता है। क्यों नहीं जाता है यह समझ से बाहर है।

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

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

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

उदाहरण 6: क्रोम फ्रीज क्यों होता है?

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

हमने वह सब कुछ करने की कोशिश की जो केवल दिमाग में आ सके:

ब्राउज़र को खोलने / बंद करने के लिए टाइमआउट कॉन्फ़िगर करें (यदि आप 15 सेकंड में ब्राउज़र को खोल / बंद नहीं कर सके, तो 15 सेकंड के बाद पुन: प्रयास करें, तीन प्रयासों तक)। ब्राउज़र को एक अलग थ्रेड में खोलें और बंद करें। परिणाम: तीनों प्रयास एक ही तरह से लटकाए गए।
पुराने Chrome प्रक्रियाओं को मारें। उन्होंने जेनकिंस की 'किल-क्रोम' में एक अलग नौकरी बनाई, उदाहरण के लिए, इस तरह, आप एक घंटे से अधिक पुरानी सभी प्रक्रियाओं को "मार" सकते हैं:

किलॉल - फोल्डर-से १ एच क्रोमेड्रिवर
Killall - फ़ोल्डर-से 1h क्रोम

यह कम से कम स्मृति को मुक्त कर दिया, लेकिन "क्या हो रहा है?" सवाल का जवाब नहीं दिया। वास्तव में, इस बात ने हमें निर्णय के क्षण में देरी कर दी।
डिबग एप्लिकेशन लॉग सक्षम करें।
WebDriver डीबग लॉग सक्षम करें।
हर 20 परीक्षणों के बाद ब्राउज़र को फिर से खोलें। यह हास्यास्पद लग सकता है, लेकिन यह सोचा गया था: "क्या होगा अगर क्रोम जमा देता है क्योंकि यह थका हुआ है?" खैर, एक मेमोरी लीक या कुछ और।

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

हम समस्या को दोहराने की कोशिश कर रहे हैं: हम 1 से 1000 तक एक चक्र लिखते हैं, जिस चक्र में हम केवल ब्राउज़र खोलते हैं, और हमारे आवेदन में पहला पृष्ठ बंद करते हैं। हमने ऐसा चक्र लिखा, और ... बिंगो! परिणाम: समस्या लगभग (हालांकि लगभग हर 80 पुनरावृत्तियों) को दोहराना शुरू कर दिया! कूल! सच है, इस उपलब्धि ने लंबे समय तक कुछ भी नहीं दिया। आपने इसे शुरू किया, 80 वें पुनरावृत्ति की प्रतीक्षा की, क्रोम दुर्घटनाग्रस्त हो गया ... और फिर क्या करना है? आप स्टैक के निशान, डंप, लॉग को देखते हैं - वहां कुछ भी उपयोगी नहीं है। Chrome में डेवलपर टूल मदद कर सकते हैं, लेकिन सितंबर 2017 तक ये उपकरण सेलेनियम के साथ काम नहीं करते (पोर्ट संघर्ष में थे: आप क्रोम को सेलेनियम से लॉन्च करते हैं और DevTools नहीं खुलते हैं)। लंबे समय तक मैं सोच नहीं पाया कि क्या करूं।

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

क्या करें, उदास रूप से कंप्यूटर छोड़ दिया, क्यूब्स खेलने चला गया ... और अचानक, लगभग 20 मिनट के बाद, मैं गलती से स्क्रीन पर नज़र डालता हूं, और मुझे पूरी तरह से अप्रत्याशित तस्वीर दिखाई देती है:

क्या होता है: एक उलटी गिनती होती है, कितने मिनट के बाद सत्र समाप्त होता है, और मैं क्यूब्स का एक टॉवर बनाता हूं, दो बने रहते हैं, एक ... सत्र समाप्त हो रहा है, परीक्षण जारी है, अंत तक चलता है और गिरता है (अब कोई तत्व नहीं है, सत्र समाप्त हो गया है)।

क्या होता है: क्रोम वास्तव में फ्रीज नहीं करता है, जैसा कि हमने सोचा था कि इस समय, यह सब कुछ इस समय की प्रतीक्षा कर रहा है। जब सत्र समाप्त हो गया, इंतजार किया, पर चला गया। वास्तव में क्रोम क्या उम्मीद कर रहा था - यह समझने के लिए यह पूरी तरह से समझ से बाहर है, मुझे बाइनरी सर्च विधि का उपयोग करके सभी कोड को फावड़ा करना पड़ा: जावास्क्रिप्ट और एचटीएमएल का आधा बाहर फेंक दें, फिर से 80 पुनरावृत्तियों को दोहराने का प्रयास करें - यह लटका नहीं था, ओह, इसका मतलब है कि कहीं बाहर ... सामान्य तौर पर, हमने प्रयोगात्मक रूप से समझा। यह समस्या यहाँ है:

 var timeout = setTimeout(sessionWatcher);

JavaScript — , , . , JavaScript- , : , <script> . , , , , . JavaScript — jQuery, $, function , :

 var timeout; $(function() { timeout = setTimeout(...); });

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

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

, flaky- , , , . , — , , ( ). , . , : ?

Chrome flaky-: -, , , .

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

. , , , . , , , , Docker.

, - , . :

Ajax-;
Ajax-;
JS;
;
;
;
;
;
UI-;
( ).

flaky- , . , -, : , .

. «» . , flaky- , ID, flaky- . .

, : , , .

, flaky- usability, -, flaky- . .

, , … , , , flaky- security-, . , !

, , flaky-:

;
Selenide;
;
.

— . flaky- , unit- , UI-? , ( ), , flaky.

Selenide .

. (, / ). , « ?». , , . , .

, . , , , , . : « », , (10 , 20 , — , — ). , flaky - .

, flaky- :

;
;
वीडियो।

« » , , , : - . «», «» , : flaky-, , flaky. , , . . , Jenkins pipeline, Jenkins :

 finally { stage("Reports") { junit 'build/test-results/**/*.xml' artifacts = 'build./reports/**/*,build/test-results/**/*,logs/**/*' archiveArtifacts artifacts: artifacts } }

finally , . : - - . Jenkins , . , Jenkins , . , .

(Selenide , ). flaky-. , Video Recorder , : video — , !

, Docker: TestContainers ( Heisenbug ). Rule , — Docker , , . .

 @Rule public BrowserWebDriverContainer chrome = new BrowserWebDriverContainer() .withRecordingMode(RECORD_ALL, new File("build")) .withDesiredCapabilities(chrome());

.

. , , , , , . flaky- .

, ! , :) . , « , , », , .

— , , , , - . — , … ! :) flaky- — : !

, : 6-7 Heisenbug . , , . (, , ) .