रिपोर्ट का सारांश "सैकड़ों क्लाइंट संस्करणों के लिए मोनोलिथ" (HL2018, Badoo, व्लादिमीर यंत)

HL2018 के साथ सार की एक श्रृंखला जारी रखना। बुश (व्लादिमीर येंट्स के निवासी और निकोलाई क्रैपीवनी ) के दोस्तों ने मुझे इस संकलन की जाँच करने में मदद की, जिसके लिए उन्हें बहुत धन्यवाद। मुझे उम्मीद है कि रिपोर्ट के संदेश की गुणवत्ता पर इसका सकारात्मक प्रभाव पड़ेगा।

विकास प्रक्रिया की विशेषताएं:

डेवलपर की जिम्मेदारी बैकएंड की रिहाई के साथ समाप्त नहीं होती है। वह प्लेटफार्मों पर कार्यान्वयन से पहले जिम्मेदार है।



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

परीक्षण

यूनिट परीक्षण

फ़पुनिट में लिखा है।

एक छोटी इकाई का परीक्षण करें। वे डेटाबेस या सेवाओं पर नहीं जाते हैं (उन्हें किसी भी चीज़ के साथ बातचीत नहीं करनी चाहिए)।

विरासत में अभी भी परीक्षण प्रक्रिया है और जटिल है।

उन्होंने सॉफ्टक्स लाइब्रेरी विकसित की - इसमें सभी शामिल हैं / आवश्यकता होती है और इसे बदले हुए के साथ बदल देता है।

आप किसी भी तरीके को हवा दे सकते हैं: स्थिर, निजी, अंतिम।
पुस्तकालय खुले स्रोत में उपलब्ध है।

समस्या: सॉफ्टमॉक्स आराम करते हैं और आपको गैर-परीक्षण कोड लिखने की अनुमति देते हैं (और इसे परीक्षणों से कवर करते हैं)।

नियमों को स्वीकार किया:

• नया कोड फ़पुनिट का परीक्षण करने में आसान होना चाहिए
• सॉफ्टमोक्स - चरम स्थिति (पुराना कोड / लंबा / महंगा / जटिल)

हम इन नियमों के लिए कोड की समीक्षा को देखते हैं।

परीक्षण की गुणवत्ता

उत्परिवर्तन परीक्षण

• कोड ले लो
• कोड कवरेज लें
• हम कोड को पार्स करते हैं और म्यूटेशन लागू करते हैं (परिवर्तन + => -; सच्चा => असत्य, आदि)
• प्रत्येक उत्परिवर्तन के लिए, हम परीक्षणों का एक सूट (सेट) चलाते हैं।
• यदि परीक्षण विफल होते हैं, तो लगभग। यदि नहीं, तो वे पर्याप्त प्रभावी नहीं हैं। हम समझते हैं, परिवर्तन / परीक्षण जोड़ें।

तैयार समाधान (हंबग, संक्रमण) हैं, लेकिन वे फिट नहीं हुए (सॉफ्टमॉक्स के साथ संगत नहीं हैं, कोड कवरेज के साथ कठिनाइयां हैं)। इसलिए, उन्होंने अपना लिखा।

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

एकीकरण परीक्षण

संयोजन में कई घटकों के संचालन का परीक्षण; हम आधार और / या सेवाओं के साथ काम की जांच करते हैं।

डेटाबेस परीक्षण के लिए मानक दृष्टिकोण (DBUnit):

1. परीक्षण डेटाबेस उठाएँ
2. इसे भरें
3. परीक्षण चलाएं
4. हम डेटाबेस को साफ करते हैं

समस्याएं:

• डेटाटैबल्स और डेटासेट (डेटाबेस की सामग्री की प्रासंगिकता) का समर्थन करना आवश्यक है
• डेटाबेस तैयार करने में समय लगता है
• समानांतर लॉन्च परीक्षण को अस्थिर बनाते हैं और गतिरोध पैदा करते हैं

समाधान: DBMocks पुस्तकालय (स्वयं का समाधान)

काम सिद्धांत:

• DB ड्राइवर विधियों ने सेटअप परीक्षण पर सॉफ्टमैक्स का उपयोग करके अवरोधन किया
• अनुरोध से परसिम db + तालिका
• Tmpfs एक ही स्कीमा के साथ अस्थायी टेबल बनाता है
• सभी प्रश्न केवल अस्थायी तालिकाओं पर जाते हैं
• टियरडाउन पर, उन्हें हटा दिया जाता है।

पुस्तकालय छोटा है, लेकिन अभी तक खुले स्रोत में नहीं है।

परिणाम:

• परीक्षण मूल तालिकाओं में डेटा को दूषित नहीं कर सकते
• टेस्ट एक-दूसरे से अलग-थलग हैं (समानांतर में चलाए जा सकते हैं)
• MySQL संस्करण के साथ क्वेरी संगतता का परीक्षण करना

एपीआई परीक्षण

• ग्राहक सत्र का अनुकरण करें
• बैकएंड अनुरोध भेजने में सक्षम
• बैकएंड लगभग वास्तविक ग्राहक की तरह प्रतिक्रिया करता है

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

समाधान: हमने परीक्षण उपयोगकर्ताओं का एक पूल बनाया। उन्हें साफ करने का तरीका सीखा।



टेस्ट उपयोगकर्ता असली वाले वातावरण में हैं, क्योंकि डेवेल! = प्रोडक्ट। परीक्षण और लाइव उपयोगकर्ताओं को अलग करना आवश्यक है।

अलगाव के लिए, उपयोगकर्ता के लिए is_test_user ध्वज जोड़ा गया था। और इन उपयोगकर्ताओं को एनालिटिक्स और ए / बी परीक्षा परिणामों से भी बाहर रखा गया है।

यह परीक्षण उपयोगकर्ताओं को "अंटार्कटिका" भेजकर सस्ता बनाया जा सकता है, जहां कोई भी उन्हें नहीं देखेगा (पेंगुइन को छोड़कर)।

क्यूए एपीआई

एपीआई परीक्षणों में पर्यावरण तैयार करने का एक उपकरण, वास्तव में उपयोगकर्ता / पर्यावरण सेटिंग्स को जल्दी से बदलने के लिए बैकएंड में एक बैकडोर है।

• अच्छी तरह से प्रलेखित एपीआई तरीके
• डेटा को जल्दी और आसानी से प्रबंधित करें।
• डेवलपर्स बैकेंड लिखते हैं
• केवल परीक्षण उपयोगकर्ताओं के लिए लागू किया जा सकता है।

उपयोगकर्ता को अपरिवर्तनीय डेटा (उदाहरण के लिए, पंजीकरण दिनांक) बदलने की अनुमति देता है।

संरक्षण की आवश्यकता:

• नेटवर्क स्तर पर (केवल कार्यालय नेटवर्क से उपलब्ध)
• प्रत्येक अनुरोध के साथ एक रहस्य पारित किया जाता है, जिसकी वैधता की जाँच की जाती है
• तरीके केवल परीक्षण उपयोगकर्ताओं के साथ काम करते हैं।

HackerOne पर एक BugsBounty प्रोग्राम है। वे पाए जाने वाले कमजोरियों के लिए भुगतान करते हैं। क्यूए एपीआई के साथ एक कैंट इसका उपयोग करते हुए पाया गया था।

दूर की मटकी

दूरस्थ बैकेंड के लिए मोकी।

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

परीक्षण उदाहरण:



एपीआई परीक्षण बहुत सुविधाजनक हैं। यूनिट के बजाय उन्हें लिखना ललचा रहा है। लेकिन एपीआई परीक्षण बहुत धीमे हैं।

नियमों का एक सेट अपनाया:

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

उई परीक्षण

बैकएंड कमांड नहीं लिखता है।

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

टेस्ट रन

100,000 यूनिट परीक्षण। 6,000 एकीकरण, 14,000 एपीआई परीक्षण।
1 स्ट्रीम में, समय 40 मिनट / 90 मिनट / 10 घंटे है।

बनाया TestCloud - परीक्षण चलाने के लिए एक बादल।



धागे के बीच परीक्षण का वितरण:

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

समाधान:

• रन टाइम पर आंकड़ों का संग्रह।
• परीक्षणों का लेआउट ताकि चंक 30 सेकंड से अधिक नहीं चले

एपीआई परीक्षणों के साथ समस्या लंबे समय से है, बहुत सारे संसाधन हैं और दूसरों को निष्पादित करने की अनुमति नहीं देते हैं।

हल करने के लिए, हमने बादल को 2 भागों में विभाजित किया है:

1. केवल त्वरित परीक्षण चलाता है।
2. दोनों प्रकार के परीक्षण चलाता है।

परिणाम समय का एक त्वरण है:

• यूनिट - 1 मिनट
• एकीकरण - 5 मिनट
• एपीआई - 15 मिनट।

कोड कवरेज चलाते हैं

क्या परीक्षण करने के लिए? कोड कवरेज दिखाएगा।

1. हमें शाखा में अंतर मिलता है
2. संशोधित फ़ाइलों की एक सूची बनाएँ
3. इन फ़ाइलों के लिए परीक्षणों की एक सूची प्राप्त करें।
4. हम इन परीक्षणों से केवल सूट चलाते हैं।

मास्टर शाखा के लिए, दिन में एक बार, रात में कवरेज का गठन किया जाता है। परिणाम (अंतर) डेटाबेस में जोड़े जाते हैं।

पेशेवरों:

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

विपक्ष:

• बैकेंड दिन में 2 बार रिलीज होती है। दोपहर के भोजन के बाद, कवरेज कम प्रासंगिक है (लेकिन जब एक बीट को रोल आउट करते हैं, तो हम हमेशा एक पूर्ण सूट चलाते हैं)।
• एपि परीक्षण व्यापक कवरेज उत्पन्न करते हैं। उनके लिए, यह दृष्टिकोण बहुत बचत प्रदान नहीं करता है।

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

परिणाम

• सभी परीक्षण स्तरों की आवश्यकता है
• मात्रा! = गुण। कोड समीक्षा और उत्परिवर्तन परीक्षण करें
• असली लोगों से अलग उपयोगकर्ताओं का परीक्षण करें।
• बैकएंड में बैकएंड सरल और लेखन परीक्षण को गति देता है
• परीक्षणों पर आंकड़े एकत्र करें।

संदर्भ

• स्लाइड्स: bit.ly/yants-HL18
• हमारा प्रोटोकॉल: "हम ग्राहकों के 100 विभिन्न संस्करणों का समर्थन कैसे करते हैं" / यारोस्लाव गोलूब
• सॉफ्टमॉक्स: "सॉफ्टक्स: PHP 7 के लिए हमारा प्रतिस्थापन रनकिट" / यूरी नसेरेतिनोव , github.com/badoo/soft-mocks
• सगाई की बगिया
• UI परीक्षण: "क्रॉस प्लेटफ़ॉर्म मोबाइल टेस्ट ऑटोमेशन और कंटीन्यूअस डिलीवरी" / सतीश गोगिनेनी
• TestCloud: "4 मिनट में यूनिट परीक्षणों या 17000 परीक्षणों का इष्टतम समानांतर" / इल्या कुडिनोव
• QAAPI: बैरिकेड्स के दूसरी तरफ से परीक्षण पर एक नज़र। / लवक्यूए में दिमित्री मारुशेंको की रिपोर्ट
• बैकएंड: सगाई । सभी के बारे में मोबाइल एप्लिकेशन बैकएंड / निकोले क्रैपीवनी