रोबोट एसएपी ईआरपी का परीक्षण करता है

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

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

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

बड़े झटके

विवरणों में जाने और पाठकों को खोने का खतरा है, मैं ऐसा नहीं करने की कोशिश करूंगा (एक लेखक के रूप में, मैं सभी विवरण जानता हूं)।

यह सब SAP, हमारे सहयोगियों और श्री Google के साथ अध्ययन, संचार के साथ शुरू हुआ।

इस संचार का परिणाम इस प्रकार था:

• SAP में परीक्षण स्वचालन के लिए उपकरण हैं (हमने eCATT को देखा, SAP CBTA को बारीकी से देखा)
• उन्हें पर्याप्त विसर्जन की आवश्यकता होती है (विशेषकर SAP CBTA)
• प्रतिबंध आवश्यक हो सकते हैं, यदि आवश्यक हो, एसएपी की सीमाओं से परे जाएं (वह हमारे साथ "वैक्यूम" में नहीं है)
• तीसरे पक्ष के उत्पाद हैं (उदाहरण के लिए, एचपी), लेकिन हमारे पास उनके लिए योग्यताएं नहीं हैं, जैसे हमने लाइसेंस खरीदे हैं
• बाहर से एसएपी को "प्रबंधित" करने का एक तरीका है (कॉनिस्टा कंपनी ने मुझे यह विचार बताया, इसके लिए बहुत बहुत धन्यवाद)

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

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

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

आर्किटेक्चर

(हां मुझे इस शब्द का उपयोग करने दें)

यह कैसे काम करता है:

• स्क्रिप्ट को सर्वर पर निष्पादित किया जाता है (शब्द "सर्वर" का उपयोग इस अर्थ में किया जाता है कि यह कंप्यूटर हमारे परीक्षण अनुरोधों को पूरा करता है। इस विशेष स्थिति में, "क्लाइंट" शब्द का उपयोग करना अधिक सही है क्योंकि यह स्क्रिप्ट है जो परीक्षण प्रक्रिया को नियंत्रित करता है)
• रोबोट रिमोट के मानक तंत्र के माध्यम से, स्क्रिप्ट SUT पर चलने वाले रोबोट के सर्वर घटक के साथ इंटरैक्ट करता है (सिस्टम अंडर टेस्ट)
• यह सर्वर घटक SAP प्रबंधन लाइब्रेरी के तरीकों को कहता है
• SAP GUI इन अनुरोधों को संसाधित करता है (समकालिक रूप से, यह महत्वपूर्ण है)
• प्रश्नों के निष्पादन के परिणाम या "बीट" को स्क्रिप्ट में "सर्वर" पर लौटा दिया जाता है, जहां वे परीक्षण प्रक्रिया में उपयोग किए जाते हैं

तकनीकी रूप से

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

क्या अद्भुत है?

दरअसल, लाइसेंस के बोझ की कमी को छोड़कर हमें क्या मिला?

बहुत सी बातें, अगर संक्षेप में और मुख्य बात के बारे में:

रूसी भाषा

स्क्रिप्ट कुछ इस तरह दिखती है:

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

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

कुल और कुल नियंत्रण और एक्स्टेंसिबिलिटी

मुझे पता है कि परीक्षण प्रक्रिया के दौरान वास्तव में क्या होता है। कोई जादू नहीं है - सब कुछ बेहद स्पष्ट है। मुझे नहीं पता कि कोई कैसे, मुझे वह पसंद है।

एक्स्टेंसिबिलिटी के बारे में - कार्यक्षमता को किसी भी दिशा में विकसित किया जा सकता है, जिसका हमने सक्रिय रूप से उपयोग किया है:

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

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

प्रवेश में आसानी

एक नियम के रूप में, परीक्षकों को एसएपी बुनियादी ढांचे और विशेष रूप से एसएपी प्रोग्रामिंग का ज्ञान नहीं है। वे कुछ हफ़्ते में रोबोट और हमारे सुधारों को मास्टर करने का प्रबंधन करते हैं।

उपयोगकर्ता निर्देश

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

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

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

रोबोट फ्रेमवर्क के बारे में थोड़ा सा

फिर भी, रोबोट के बारे में कुछ भी नहीं कहा जा सकता है - यह समझ से बाहर और सतही रूप से बदल जाएगा। मैं संक्षेप में कोशिश करूंगा।

इस ढांचे का मुख्य विचार अपनी खुद की परीक्षण भाषा (रोबोट की शब्दावली में, निष्पादन योग्य इकाई कीवर्ड - कीवर्ड) बनाने की क्षमता है। ढांचा प्रदान करता है

• इस भाषा में कार्यक्रम का निष्पादन वातावरण (प्रोग्रामर - नाराज न हों)
• कार्यात्मक रूप से समृद्ध पुस्तकालय (स्ट्रिंग और सूचियों के साथ काम करने के लिए ssh और सेलेनियम के लिए)
• रिपोर्टिंग (उपयोग की प्रक्रिया में, किसी भी तरह की रिपोर्ट लिखने का विचार भी नहीं था)
• कीवर्ड से एक प्रोग्राम बनाने का एक सरल प्रतिमान (थोड़ा अजीब है, लेकिन आप इसकी आदत डाल सकते हैं), चर, पैरामीटर और "कॉल" (कीवर्ड) के परिणाम जैसी चीजें हैं
• सरल और शक्तिशाली एक्स्टेंसिबिलिटी - अजगर में अपनी खुद की लाइब्रेरी बनाना बहुत आसान है (उदाहरण के लिए, हमने एक्सेल के साथ इस तरह से काम किया), दोनों स्थानीय (यानी परीक्षण कोड के रूप में एक ही स्थान पर निष्पादित) और रिमोट (उदाहरण के लिए) जो SAP GUI को नियंत्रित करता है)

परीक्षण बनाने की प्रक्रिया काफी सरल है

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

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

परीक्षण के तहत प्रणाली के साथ सहभागिता

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

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

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

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

def get_ctrl_attr ( self, uid, attr ): """     (  )   (  )  exception =  (   log) """ ctrl = self._get_ctrl(uid) try: retText = getattr( ctrl, attr ) except: raise AssertionError("  {1}   {0}".decode("utf-8").format(attr,uid)) return retText 

कोड पर कुछ टिप्पणियां

• एसएपी जीयूआई प्रबंधन पुस्तकालय का टुकड़ा
• एक पुस्तकालय एक वस्तु है, परीक्षण (कीवर्ड में) में विधियां सीधे उपलब्ध हैं, उदाहरण के लिए, उपरोक्त विधि को इस तरह से कहा जा सकता है: "res = get ctrl attr $ {UID} पाठ" (रोबोट संकेतन का उपयोग करके)
• त्रुटि के मामले में, अपवाद पाठ रोबोट के लॉग में दिखाई देगा (आपको इसके लिए कुछ भी करने की आवश्यकता नहीं है - सिर्फ "मार" अपवाद

कोड बहुत सरल है, यह प्रसन्न करता है।

परीक्षण चल रहा है

रोबोट के तर्क के बाद, व्यक्तिगत परीक्षण हमारी परियोजनाओं में संयुक्त हैं। वेब इंटरफ़ेस से मैन्युअल रूप से एक परीक्षण या परियोजना शुरू की जा सकती है। प्रतिगमन परीक्षण प्रक्रिया भी एसएपी परिवहन प्रणाली में एकीकृत है:

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

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

ओम नहीं ओम

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

• परीक्षण अभी भी लिनक्स वर्चुअल मशीन पर काम करते हैं (एक ही पर - एसएपी परीक्षण और एसएपी परीक्षण एक ही "उदाहरण" में नहीं रहते हैं)
• परीक्षक के कार्यस्थल पर ब्राउज़र "ब्लिंक" करता है (किसी भी चाल के बिना पूर्ण दृश्य नियंत्रण)
• मानक रिपोर्ट, परिचित उपकरण

इस प्रणाली के परीक्षणों में, मैं आगे बढ़ गया (ATDD की ओर) - दृष्टिगोचर तत्व (लेबल और प्लेसहोल्डर) का परीक्षण में शुरू में गठन किया गया था, वहाँ वे व्यापार से सहमत हुए और वहाँ से सिस्टम के स्रोत कोड में "गिर गया" (यह थोड़ा DRY है) - आप नहीं कर सकते पहले टेस्ट लिखे बिना कोड लिखें। कूल?

बेशक, वेब एप्लिकेशन के लिए बहुत सारे उपकरण विकसित किए गए हैं, लेकिन मैं यह नहीं कह सकता कि मैंने काम के दौरान किसी भी असुविधा का अनुभव किया। यह यहाँ अच्छी तरह से निकला ...

संक्षेप में देना

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

और, एक बार फिर, प्रोग्रामिंग में सब कुछ संभव है, सवाल केवल समय और पैसा (प्रेरणा) है।