1 सी पर परीक्षण: एंटरप्राइज 8 प्लेटफॉर्म

परिचय।

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

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

आवेदन।

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

विवरण।

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

• इकाई परीक्षण;
• कार्यात्मक परीक्षण;
• प्रतिगमन परीक्षण *;
• एकीकरण परीक्षण;

* प्रतिगमन को ध्यान में नहीं लाया जाता है, परीक्षण की शुरुआत और अंत के टाइमस्टैम्प हैं, इन निशानों के अंतर में परिवर्तन पर कोई सामान्य रिपोर्ट नहीं है।

डिवाइस।

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

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

काम का रूप इस तरह दिखता है:

1. वर्तमान परियोजना
2. परीक्षण प्रणाली का उपयोगकर्ता नाम
3. परीक्षणों को समूहों में विभाजित किया जा सकता है, यह स्वचालित परीक्षण स्थापित करते समय सुविधाजनक है और आपको स्वयं परीक्षणों की संरचना करने की अनुमति देता है।
4. 400 के कोड के साथ एक परीक्षण का चयन किया जाता है, परीक्षण का नाम इंगित किया गया है, परीक्षण विधि अंतर्निहित ट्रांसलेटर "ट्रांसलेटर" के रूप में है, अंतिम कॉलम परीक्षण किए गए विधि के नाम को प्रदर्शित करता है।
5. परीक्षण किए गए तरीके का पूरा हस्ताक्षर यहां डाला गया है, जो स्वचालित रूप से पार्स किया जाता है (बटन 8 दबाकर) आने वाले मापदंडों पर - 6 और परिणाम - 7।
6. यहां आप आदिम और संदर्भ प्रकारों के इनपुट मापदंडों को दर्ज करते हैं, यदि आप फ़ाइल चेक बॉक्स का चयन करते हैं, तो आप फ़ाइल का पथ भी निर्दिष्ट कर सकते हैं।
7. चयनित परीक्षण में केवल एक फ़ंक्शन रिटर्न वैल्यू है; _ReturnRem नाम इसके लिए पूर्वनिर्धारित है।
8. आने वाले मापदंडों और वापसी परिणामों में विधि हस्ताक्षर को पार्स करें।

आगे के कथन को समझने के लिए, आपको फ़ील्ड 5 से विचलित होने की ज़रूरत है, जहाँ कुछ और टैब हैं।
निष्पादित करने से पहले :

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

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

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

9. परीक्षण चलाएं। निष्पादन योग्य कोड टैब पर दिखाई देने वाले कोड को निष्पादित किया जाता है । फ़ील्ड 7 निष्पादित कोड के परिणामों के साथ आबादी है।
10. बटन को 9 संदर्भ के रूप में दबाने के बाद प्राप्त परिणामों को बचाने के लिए बटन।
11. परीक्षण चलाएं और पहले से सहेजे गए मानक के साथ परिणामों की तुलना करें।
12. सहेजे गए संदर्भ मान देखें।

एक उदाहरण है।

यह वही है जो एक इंटरैक्टिव संदेश दिखता है कि परीक्षण विफल हुआ:

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

कुल।

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

सिस्टम बिक्री के लिए नहीं बनाया गया था, सिस्टम को कई जगहों पर ध्यान में नहीं लाया गया है, लेकिन यहां तक ​​कि जो पहले से मौजूद है वह श्रृंखला से कम से कम बेवकूफ गलतियों से बचने में मदद करता है - एक स्थान पर सही, तीन अन्य में गिर गया ।