🤵 🧑🏽‍🤝‍🧑🏼 🔎 IOS पर परीक्षण भुगतान सेवाओं का स्वचालन 👩🏾‍🌾 👨🏽‍💼 🤽🏽

जो लोग iOS पर स्वचालन के विषय में रुचि रखते हैं, उनके लिए मेरे पास दो समाचार हैं - अच्छा और बुरा। अच्छा: सशुल्क सेवाओं के लिए iOS एप्लिकेशन में, केवल एक एकीकरण बिंदु का उपयोग किया जाता है - इन-ऐप खरीदारी (एप्लिकेशन में अंतर्निहित खरीद )। खराब: एप्पल परीक्षण खरीद को स्वचालित करने के लिए कोई उपकरण प्रदान नहीं करता है।

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

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

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

आइए हमारे शोध के सामान्य विवरण से शुरू करें:

समस्या की परिभाषा
समस्या का बयान
समाधान नंबर 1। Apple सैंडबॉक्स
निर्णय संख्या 2। नकली विधि और एक नकली वस्तु का उपयोग करना
निर्णय का आकलन: मुख्य जोखिम
परिणाम
निष्कर्ष

समस्या की परिभाषा

प्राकृतिक आवश्यकता उत्पन्न होने पर स्वचालन की आवश्यकता होती है। यह क्षण हमारे साथ कब आया?

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

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

हम जल्द से जल्द परीक्षा परिणाम प्राप्त करना चाहते थे। और वे एक समस्या में भाग गए: तेजी से और स्थिर परिणाम प्राप्त करने के लिए सस्ते में हमारे iOS अनुप्रयोगों में भुगतान सेवाओं के प्रतिगमन परीक्षण का आयोजन कैसे करें?

समस्या का बयान

इसलिए, अंतिम उत्पाद के वितरण की हमारी प्रक्रिया और टीम के आकार की बारीकियों को ध्यान में रखते हुए, हम चाहते हैं:

ग्राहक आवेदन (एक-बार भुगतान और सदस्यता) के भीतर किसी भी खरीद का परीक्षण करें;

दिन में 10-20 बार परीक्षण की पुनरावृत्तियों को दोहराएं;
आधे घंटे से कम समय में परीक्षण के परिणाम ~ 150 परीक्षण स्क्रिप्ट प्राप्त करें;
शोर से छुटकारा;
अन्य कोड के परिणामों की परवाह किए बिना, डेवलपर कोड की एक विशिष्ट शाखा पर परीक्षण चलाने में सक्षम हो।

अब जब हमने कार्य को तैयार कर लिया है, यह इंजीनियरों की अद्भुत दुनिया और उनके समाधान में यात्रा शुरू करने का समय है।

समाधान नंबर 1। Apple सैंडबॉक्स

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

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

लेकिन जब हमने इस सैंडबॉक्स का उपयोग करके ऑटोटेस्ट्स को लागू किया, तो हम पूर्ण रूप से पी गए। आइए जल्दी से मुख्य समस्याओं पर जाएं।

1. परीक्षण उपयोगकर्ताओं का पूल

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

सदस्यता खरीद के केवल एक ऑटो-खरीद को चलाने के लिए, हमें चाहिए:

सैंडबॉक्स में प्राधिकरण के लिए एक नया उपयोगकर्ता ले लो;
सिम्युलेटर पर वर्तमान लिंक की गई Apple ID;
Badoo से Badoo से जुड़ें
सदस्यता खरीद की स्क्रीन पर जाएं और उत्पाद का चयन करें;
खरीद की पुष्टि करें और Apple ID के माध्यम से लॉग इन करें;
सुनिश्चित करें कि खरीद सफल रही थी;
सफाई के लिए उपयोगकर्ता भेजें;
सदस्यता से सैंडबॉक्स के उपयोगकर्ता को साफ़ करें।

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

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

और अब चलो कल्पना करते हैं कि हम दो एजेंटों पर सेल्फ-टेस्ट रन कर रहे हैं, जिनमें से प्रत्येक उन्हें 100 थ्रेड में चला सकता है। इस मामले में, हमें कम से कम 200 उपयोगकर्ताओं की आवश्यकता है!

2. "बुरा" सूचनाएं

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

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

यह सब परीक्षण धीमा कर दिया:

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

3. क्या कोई टेस्ट था?

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

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

निर्णय संख्या 2। नकली विधि और एक नकली वस्तु का उपयोग करना

इसलिए, हमने Apple के सैंडबॉक्स में स्वचालन के साथ समस्याओं को पिया। लेकिन ऐसा मत सोचो कि मोबाइल की दुनिया में सब कुछ पूरी तरह से खराब है। एंड्रॉइड पर, सैंडबॉक्स बहुत अधिक स्थिर है - आप वहां ऑटोटेस्ट चला सकते हैं।

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

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

1. मोचा और नकली का परिचय

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

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

किसी अन्य के लिए एक फ़ंक्शन का प्रतिस्थापन जो वांछित परिणाम लौटाता है, चलो फ़ंक्शन को मॉक कहें, या केवल मॉक करें। इन कार्यों में एक ही हस्ताक्षर हो सकते हैं, लेकिन ये दो अलग-अलग कार्य हैं।

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

इसे समाप्त करने के लिए, आइए नकली कार्यों और नकली वस्तुओं के उपयोग की कुछ विशेषताओं पर जोर दें:

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

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

2. वास्तविक खरीद कैसे होती है

इससे पहले कि हम सिस्टम के सभी हिस्सों की बातचीत का वर्णन करना शुरू करें, आइए मुख्य अभिनेताओं पर प्रकाश डालें:

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

आइए देखें कि खरीद कैसे होती है। पूरी प्रक्रिया को आरेख में देखा जा सकता है:

चित्र 1. ऐप स्टोर पर भुगतान योजना

हम एक्टर्स की मुख्य क्रियाओं को चरण दर चरण बताएंगे।

1. शुरुआती बिंदु उत्पादों की सूची के साथ स्क्रीन खोलने से पहले सभी अभिनेताओं की स्थिति है।

यह स्क्रीन क्या है और हम इसे कैसे प्राप्त करते हैं?

मान लीजिए कि एक उपयोगकर्ता को एक दिलचस्प व्यक्ति मिला, उसने अपना प्रोफ़ाइल खोला, एक संदेश लिखा और एक उपहार भेजना चाहा। एक उपहार भेजना एक भुगतान सेवा है। उपयोगकर्ता उपहार भेजने के लिए अनुभाग में प्रोफ़ाइल स्क्रॉल कर सकता है या तुरंत चैट से उपहार का चयन कर सकता है।

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

2. उत्पादों की सूची खोलना।

हम शुरुआती बिंदु पर हैं, उदाहरण के लिए, उपहार सूची पर। उपयोगकर्ता अनुप्रयोग में उपहारों में से एक का चयन करता है। आवेदन संभव सर्वर आईडी ऋण पैकेज (100, 550, 2000, 5000) की एक सूची प्राप्त करने के लिए हमारे सर्वर से अनुरोध करता है। सर्वर इस सूची को एप्लिकेशन को वापस कर देता है।

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

3. उत्पाद चयन और प्राप्ति पीढ़ी।

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

4. Badoo सर्वर पर जाँच की जाँच करना।

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

5. सर्वर से पुश नोटिफिकेशन (पुश नोटिफिकेशन) भेजना।

ऐप्पल द्वारा सत्यापन के बाद द ब्रेट सर्वर फिर से प्राप्त सूचनाओं को संसाधित करता है और एप्लिकेशन को एक पुश नोटिफिकेशन के साथ प्रतिक्रिया भेजता है।

6. आवेदन में अधिसूचना धक्का।

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

3. निर्भरता और परीक्षण लूप का निर्धारण

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

बाहरी निर्भरता

बाहरी निर्भरता से हमारा मतलब किसी भी घटक के साथ बातचीत से है, जो हमारे लिए एक "ब्लैक बॉक्स" है। इस स्थिति में, ऐप स्टोर iOS सिस्टम फ्रेमवर्क (StoreKit) के रूप में एक ऐसे घटक के रूप में कार्य करता है, जिसके साथ हमारा iOS एप्लिकेशन काम करता है, और एक Apple सर्वर, जहां सत्यापन अनुरोध चलते हैं।

वास्तविक स्थितियों में इन निर्भरताओं को प्रबंधित करना असंभव है, एप्लिकेशन को ब्लैक बॉक्स से आउटपुट सिग्नल का जवाब देने के लिए मजबूर किया जाता है (देखें। 2)।

हमारे पास तीन बाहरी निर्भरताएं हैं:

StoreKit उत्पादों की जाँच करना।
खरीद रसीद प्राप्त करना और बदलना।
Badoo सर्वर पर जाँच की जा रही है।

चित्रा 2. बाहरी निर्भरता

परीक्षण सर्किट

टेस्टिंग सर्किट - ये उस पथ के भाग होते हैं, जिसे हम परीक्षण प्रक्रिया के दौरान जाँचेंगे।

चित्रा 3. टेस्ट लूप

निर्भरता को खत्म करने पर हमारे काम का लक्ष्य एक परीक्षण सर्किट का निर्माण करना है जो वास्तविक पथ के जितना करीब हो सके और आपको सभी बाहरी निर्भरता को बाहर करने और नियंत्रण को अपने पक्ष में स्थानांतरित करने की अनुमति देता है।

हम प्रत्येक निर्भरता को अनुक्रम में मानते हैं।

4. निर्भरता का अलगाव: तकनीकी कार्यान्वयन

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

तैयार वह विधि है जो उत्पादों की जांच के लिए जिम्मेदार है;
makePayment एक ऐसा तरीका है जो इन-ऐप खरीदारी की प्रक्रिया करता है।

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

निर्भरता नं। १। StoreKit उत्पादों की जाँच करना

उत्पादों की सूची की जांच करने के लिए, तैयार फ़ंक्शन का उपयोग करें, जो चेक किए गए उत्पादों की सूची लौटाता है। हम उस मॉक का उपयोग कर सकते हैं जिसमें हम चेक को बंद कर देते हैं और उत्पादों की आने वाली सूची को पूरी तरह से सत्यापित करके वापस कर देते हैं। इस प्रकार, निर्भरता समाप्त हो जाएगी।

चित्रा 4. पहली निर्भरता उन्मूलन योजना

हमारे आवेदन में वास्तुकला के शीर्ष पर भुगतान प्रदाता है। यह एप्लिकेशन में संभावित प्रदाता के इंटरफ़ेस को दर्शाता है। मॉक को लागू करने का कोड मॉक पेमेंट प्रोवाइडर वर्ग में पाया जा सकता है।

public class MockPaymentProvider: PaymentProvider { public static var receipt: String? public static var storeKitTransactionID: String? public func prepare(products: [BMProduct]) -> [BMProduct] { return products } ... }

लिस्टिंग 1. नकली ग्राहक की जाँच करें

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

 public func prepare(products: [BMProduct]) -> [BMProduct] { let validatedProducts = self.productsSource.validate(products: products) return validatedProducts }

लिस्टिंग 2. रियल स्टोर भुगतान प्रदाता

निर्भरता नं। २। खरीद रसीद प्राप्त करना और बदलना

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

चित्र 5. भुगतान करते समय एक प्राधिकरण फ़ॉर्म को हटाना

यह चेक के साथ इतना आसान नहीं है। कई सवाल हैं:

अग्रिम में सही उत्पाद के लिए रसीद कैसे प्राप्त करें?
यदि हमने चेक प्राप्त किया है, तो आवेदन के अंदर कब और कैसे संलग्न करें?

यहां अभिनेता "उपयोगकर्ता" की एक नई भूमिका है - क्यूए। जब हम परीक्षण चलाते हैं, तो हम न केवल इंटरफ़ेस पर बटनों पर क्लिक कर सकते हैं, बल्कि परीक्षण ढांचे के एपीआई तरीकों (उपयोगकर्ता क्रियाओं को अनुकरण करने वाले तरीके) और REST एपीआई सेवाओं (आंतरिक आंतरिक सेवा से जादू कर सकने वाले तरीके) को भी कॉल कर सकते हैं। हम बुश में एक बहुत शक्तिशाली क्यूए एपीआई टूल का उपयोग करते हैं (आप इसकी सभी क्षमताओं को लिंक पर पा सकते हैं: https://vimeo.com/116941200 )। यह वह है जो हमें परीक्षण में मदद करता है और सर्वर की ओर से सही उत्पाद के लिए चेक देता है। चेक को जेनरेट करने के लिए ब्रेट सर्वर सबसे अच्छी जगह है: चेक का एन्क्रिप्शन और डिक्रिप्शन है, इसलिए सर्वर इस डेटा संरचना के बारे में सब कुछ जानता है।

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

चित्र 6. प्राप्ति की योजना

यह तकनीकी रूप से कैसे संभव हुआ?

1. आवेदन में एक नकली चेक सेट करने के लिए, हम एक पिछले दरवाजे का उपयोग करने में सक्षम थे जो रसीद में नकली चेक को सहेजता था MockPaymentProvider फ़ील्ड:

 #if BUILD_FOR_AUTOMATION @objc extension BadooAppDelegate { @objc func setMockPurchaseReceipt(_ receipt: String?) { PaymentProvidersFactory.useMockPaymentProviderForITunesPayments = true MockPaymentProvider.receipt = receipt } ... } #endif

लिस्टिंग 3. नकली चेक बैकडोर

2. आवेदन हमारे चेक को MockPaymentProvider के लिए धन्यवाद देने में सक्षम था, जिसमें हमने MakePayment मॉक और MockPaymentProvider.receipt में सहेजे गए चेक का उपयोग किया था:

 public class MockPaymentProvider: PaymentProvider { ... public func makePayment(_ transaction: BPDPaymentTransactionContext) { ... if let receiptData = MockPaymentProvider.receipt?.data(using: .utf8) { let request = BPDPurchaseReceiptRequest(...) self.networkService.send(request, completion: { [weak self] (_) in guard let sSelf = self else { return } if let receipt = request.responsePayload() { sSelf.delegate?.paymentProvider(sSelf, didReceiveReceipt: receipt) } }) } else { self.delegate?.paymentProvider(self, didFailTransaction: transaction) } } }

लिस्टिंग 4. एक नकली जाँच के साथ एक खरीद प्रसंस्करण मोका कॉलिंग

3. नकली चेक प्राप्त करना

एक नकली जांच प्राप्त करने के लिए, हमने सर्वर पर विधि का उपयोग किया (देखें सूची 5)। यह चेक डेटा उत्पन्न करने के लिए डेटा के साथ एक डिफ़ॉल्ट सरणी लेता है और उस डेटा को जोड़ता है जो किसी विशेष उत्पाद के लिए आवश्यक है।

 $new_receipt_model = array_replace_recursive( //       $this->getDefaultModel(), //       //,      $this->enrichModelUsingSubscription($nr), //        $this->enrichModelUsingInput($input) ); //  $new_receipt = $this->signReceipt( json_encode($new_receipt_model, true), $new_receipt_model );

लिस्टिंग 5. चेक पीढ़ी का सर्वर हिस्सा

वास्तविक चेक की संरचना को दोहराने के लिए, एप्लिकेशन द्वारा भेजे गए कस्टम चेक को एक प्रमाण पत्र का उपयोग करके एन्क्रिप्ट किया जाना चाहिए। हम अपने काम के प्रमाण पत्र का उपयोग Apple प्रमाण पत्र के बजाय करते हैं।

 function signReceipt($receipt, $response)  { //     base64 $receipt = 'Subject: ' . base64_encode(json_encode($response)) . PHP_EOL . PHP_EOL . $receipt; file_put_contents($receipt_file, $receipt); ... //    $sign_result = openssl_pkcs7_sign( $receipt_file, $signed_receipt_file, 'file://'.$path_cert, 'file://'.$path_key, [], PKCS7_BINARY); ... //  $signed_content_with_headers = file_get_contents($signed_receipt_file); list($headers, $signed_content) = explode(PHP_EOL . PHP_EOL, $signed_content_with_headers); //  return str_replace(["\r\n", "\r", "\n"], '', $signed_content); }

लिस्टिंग 6. एक प्रमाण पत्र के साथ एक चेक पर हस्ताक्षर करने के लिए विधि

4. परिणामस्वरूप, हमें प्राप्त होने वाली परीक्षा में:

 (/       "((\d+) |  (\d+) ?/) do |service_type| #    service_details = parse_options(service_type) #  QA API (  Badoo) receipt = QaApi::Billing.order_get_app_store_receipt(service_details) #   Backdoors.set_fake_receipt(receipt) end

लिस्टिंग 7. खीरे की रूपरेखा के लिए गेरकिन परीक्षण कदम

निर्भरता नंबर 3। Badoo सर्वर पर जाँच की जा रही है

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

चित्र 7. सर्वर सत्यापन हटाना

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

 class EngineTest extends Engine function verifyReceiptByCert($receipt)  { $result = parent::verifyReceiptByCert($receipt); if ($result === -1 || empty($result)) { $result = $this->verifyReceiptByLocalCert($receipt); } return $result; } function verifyReceiptByLocalCert($receipt) { $receipt_file = tempnam(sys_get_temp_dir(), 'rcp'); file_put_contents($receipt_file, base64_decode($receipt)); $result = openssl_pkcs7_verify($receipt_file, PKCS7_BINARY, '/dev/null', [$DIR]); if ($result) { $this->addLocallyVerifiedReceipt($receipt, base64_decode($response)); } unlink($receipt_file); return $result; } class Engine function verifyReceiptByCert($receipt) { $receipt_file = tempnam(sys_get_temp_dir(), 'rcp'); file_put_contents($receipt_file, base64_decode($receipt)); $result = openssl_pkcs7_verify($receipt_file, PKCS7_BINARY, '/dev/null', [$DIR]); unlink($receipt_file); return $result; }

लिस्टिंग 8. प्रारंभिक सत्यापन

द्वितीयक सत्यापन (वेरिफिकेशन) के दौरान, हमें getLocallyVerifiedReceipt चाइल्ड क्लास के local_receipt फ़ील्ड का मान मिलता है। यदि यह खाली नहीं है, तो हम सत्यापन के परिणामस्वरूप इसके मूल्य का उपयोग करते हैं।

यदि फ़ील्ड खाली है, तो हम माता-पिता वर्ग ( माता-पिता :: VerReceipt) से द्वितीयक सत्यापन कहते हैं। वहाँ हम App Store से इसके पक्ष में सत्यापन के लिए अनुरोध करते हैं। दोनों मामलों में सत्यापन परिणाम एक डिक्रिप्टेड चेक है।

 class EngineTest extends Engine function verifyReceipt($receipt_encoded, $shared_secret, $env) { $response = $this->getLocallyVerifiedReceipt($receipt_encoded); if (!empty($response)) { return json_decode($response, true); } return parent::verifyReceipt($receipt_encoded, $shared_secret, $env); } class Engine function verifyReceipt($receipt_encoded, $shared_secret, $env) { $response = $this->_sendRequest($receipt_encoded, $shared_secret, $env); return $response; }

लिस्टिंग 9. माध्यमिक सत्यापन

5. वीडियो टेस्ट रन: ऋण और सदस्यता खरीद

टेस्ट नंबर 1। सदस्यता खरीद

जब	मैं एक फोटो के साथ नए उपयोगकर्ता के रूप में एप्लिकेशन में लॉग इन करता हूं
और	मैं एक नया एक महीने का सब्सक्रिप्शन बिलिंग चेक जनरेट करता हूं
और	मैं अपनी प्रोफाइल पर जाता हूं
	मुझे यकीन है कि सदस्यता अक्षम है
जब	मैं उत्पाद सूची खोलता हूं
और	मैं एक महीने का सब्सक्रिप्शन पैकेज खरीदता हूं
	मैं सफल खरीद अधिसूचना की जांच करता हूं
और	मुझे यकीन है कि सदस्यता सक्रिय है

टेस्ट रन वीडियो:

टेस्ट नंबर 2 ऋण खरीदना और उपहार भेजना

जब	मैं एक फोटो के साथ नए उपयोगकर्ता के रूप में एप्लिकेशन में लॉग इन करता हूं
और	मैं अपनी प्रोफ़ाइल में दस क्रेडिट जोड़ता हूं
और	मैं 550 क्रेडिट के लिए एक नया क्रेडिट चेक उत्पन्न करता हूं
और	मैं एक नई उपयोगकर्ता लीला बनाता हूं
और	लीला ने मुझे वोट दिया
और	मैं लोगों के पास जाता हूं और एक लीला प्रोफ़ाइल खोलता हूं
और	मैं लीला के लिए "हां" वोट देता हूं
	मैं मैच का पेज चेक करता हूं
जब	मैं एक नियमित उपहार भेजने का चयन करता हूं
	मैं पैकेज की सूची के साथ भुगतान स्क्रीन की जांच करता हूं
जब	मैं 550 क्रेडिट खरीदने का विकल्प चुनता हूं
	मैं सफल खरीद अधिसूचना की जांच करता हूं
और	मुझे यकीन है कि लीला को एक चैट उपहार मिला

टेस्ट रन वीडियो:

निर्णय का आकलन: मुख्य जोखिम

बाहरी निर्भरता को हटाने से कुछ जोखिम होते हैं।

1. गलत कॉन्फ़िगरेशन।

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

2. सीमावर्ती मामले।

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

3. नकली या धोखेबाज।

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

4. चेक का प्रारूप बदलें।

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

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

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

परिणाम

मुख्य लाभों पर विचार करें जो हम मोकी विधि और नकली वस्तु को लागू करने के परिणामस्वरूप प्राप्त करने में सक्षम थे।

आईओएस पर सशुल्क सेवाओं की सस्ती, तेज और स्थिर स्वचालन

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

समानांतरकरण के लिए धन्यवाद, हम iOS क्लाइंट डेवलपर या बिलिंग सर्वर डेवलपर की किसी भी शाखा पर केवल 15-20 मिनट में परिणाम प्राप्त कर सकते हैं। स्वचालन से पहले, एक व्यक्ति द्वारा इस क्षेत्र के मैनुअल परीक्षण में आठ घंटे लगते थे।

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

नई सुविधाओं के विकास में कार्यात्मक प्रतिगमन

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

भुगतान रिफैक्टरिंग में कार्यात्मक प्रतिगमन

शायद सबसे सफल और कुशल स्वचालन संभव है जो कोड रीफैक्टरिंग के क्षेत्र में होता है। इस मामले में, केवल आंतरिक कार्यान्वयन में परिवर्तन होता है - ऑटोटेस्ट कोड को बदलने की कोई आवश्यकता नहीं है। यूआई किसी भी तरह से नहीं बदलता है, और ऑटोटेस्ट को कुशलता से संचालित किया जा सकता है।

एप्पल से प्रयोगात्मक सुविधाओं का परीक्षण करना: अनुग्रह अवधि

एक समान प्रणाली पूरी तरह से विनिमेय है जब आप नए एकीकरण का परीक्षण करते हैं जो अभी तक सैंडबॉक्स में लागू नहीं होते हैं। तो यह अनुग्रह अवधि के साथ था। यह कार्यक्षमता सैंडबॉक्स में नहीं है। Apple पर अनुग्रह अवधि अभी तक सभी के लिए उपलब्ध नहीं है। यह एक पायलट प्रोजेक्ट है, जिसे Apple के साथ मिलकर कार्यान्वित किया जा रहा है। एक ग्रेस पीरियड के साथ जाँच करने के लिए, हमें यहाँ JSON कोड का एक ऐसा टुकड़ा जोड़ना होगा:

 pending_renewal_info:[ { expiration_intent: 2 grace_period_expires_date: 2019-04-25 15:50:57 Etc/GMT auto_renew_product_id: badoo.productId original_transaction_id: 560000361869085 is_in_billing_retry_period: 1 grace_period_expires_date_pst: 2019-04-25 08:50:57 America/Los_Angeles product_id: badoo.productId grace_period_expires_date_ms: 1556207457000 auto_renew_status: 1 }]

लिस्टिंग 10. एक सदस्यता के लिए अनुग्रह अवधि

हमने यह कुछ ही सेकंड में बड़ी आसानी से कर दिया। हमारी प्रणाली में, हम एक नई सुविधा के लिए अपनी प्रतिक्रिया का परीक्षण करने में सक्षम थे। अब हम इस कार्यक्षमता को ठेस पर चला रहे हैं।

संरचना विधियों में उत्पाद की गुणवत्ता परीक्षण

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

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

निष्कर्ष

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

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

अंत तक पढ़े हुए सभी को बहुत-बहुत धन्यवाद। इस परियोजना में मदद करने वाले और भाग लेने वाले सभी को बहुत-बहुत धन्यवाद। इन लोगों को विशेष धन्यवाद:

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

IOS पर परीक्षण भुगतान सेवाओं का स्वचालन