BFT - स्ट्रीमिंग परीक्षण

शुभ दोपहर, गृहणियों!

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

• BFT - व्यवसाय प्रवाह परीक्षण, यह क्या है?
• मैं आपको सरल उदाहरणों के साथ इसका उपयोग करने का तरीका दिखाता हूँ।
• इस दृष्टिकोण के क्या लाभ हैं?
• मैं इसे कहां लागू कर सकता हूं
• और आगे क्या होगा

स्ट्रीम परीक्षण (BFT - BusinessFlowTesting)

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

• विविध इनपुट व्यवसाय डेटा का एक सेट
• व्यावसायिक संस्थाओं के परीक्षण के लिए महत्वपूर्ण प्रणाली टूट गई, जिसे सत्यापित करने की आवश्यकता है
• राज्य संक्रमण नियम

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

Bft फ्रेमवर्क

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

व्यावसायिक संस्थाएँ:

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

आदेश की स्थिति:

• बनाया गया (बनाया गया)
• स्वीकृत (पंजीकृत)
• भुगतान किया गया (भुगतान किया गया)
• वितरित (देते)
• वितरित (वितरित)
• वितरण अस्वीकृत (अस्वीकृत किया गया)
• पुरालेख में (पुरालेख में)

उत्पाद आंदोलन ग्राफ



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

• चेक। इस अवस्था में क्या जाँच करें
• संक्रमण। इस राज्य से कहाँ और कैसे जाना है

PS दोनों चेक और ट्रांज़ेक्शन कॉन्टेक्ट का एक फ़ंक्शन है, अर्थात वह डेटा सेट जो राज्य में आया है और यात्रा का पथ (वैकल्पिक)

प्रत्येक परीक्षण इस ग्राफ में एक रेखीय पथ है, जो इनपुट डेटा की विशेषता है।



इनपुट डेटा कई प्रकार के हो सकते हैं:

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

लेखन परीक्षण

मूल सरल परीक्षण

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



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

परीक्षण स्वयं कुछ इस तरह दिखाई देगा:

var SimpleScenario = BusinessGraph.GetScenario(CorrectSimpleData, DefaultControllData);BFTFramework.Run(SimpleScenario, CorrectSimpleData);

BusinessGraph इनपुट डेटा CorrectSimpleData का उपयोग करेगा रेखीय स्क्रिप्ट पथ (Default DefaultControllData) को आउटपुट ग्राफ में जो हम SimpleScenario प्राप्त करते हैं।
BFTFramework इस स्क्रिप्ट को CorrectSimpleData इनपुट के साथ निष्पादित करेगा।

अन्य परीक्षण

अब, यदि हम बहुत सारे सकारात्मक डेटा का परीक्षण करना चाहते हैं, तो हम केवल CorrectOtherData के अन्य सेटों को स्थानांतरित करते हैं।

यदि हमें नकारात्मक परीक्षण (उदाहरण के लिए, खरीदारी की वापसी) को जोड़ना, कहना है:

• हम BusinessGraph में एक नया अस्वीकृत डिलीवरिंग स्टेट जोड़ते हैं (इस राज्य में स्विच करते समय किए जाने वाले चेक, और यदि आवश्यक हो, तो इससे संभव पथ)
  
  
  
  
• अन्य राज्यों से इस नए राज्य में संक्रमण पथ जोड़ें (हमारे मामले में, यह तीर वितरित कर रहा है -> अस्वीकृत वितरण)
• हम अपने परीक्षण में गलत डेटा डिलीवररेडक्टाटा का एक सेट पास करते हैं

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

कुल:

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

आवेदन का क्षेत्र

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

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

आई-फ्री विभागों में से एक में, हमने इस दृष्टिकोण को सफलतापूर्वक लागू किया है, मुझे उम्मीद है कि यह आपको सुंदर, आसानी से समर्थित, लॉग इन और विज़ुअल टेस्ट करने में भी मदद करेगा।
आगे क्या है?

निम्नलिखित लेखों में:

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