एकीकरण के माध्यम से स्वचालन। प्रोमो संस्करण। युपीडी

अद्यतन : जोड़ा गया त्वचा शॉट्स।

सॉफ्टवेयर इंजीनियरिंग फोरम 2011 का आयोजन 19-20 मई को मिन्स्क में किया गया था। हमने एक रिपोर्ट "टेस्ट ऑटोमेशन का एक नया स्तर", या एक वैकल्पिक लंबा संस्करण बनाया - टेस्ट टूल्स के एकीकरण के माध्यम से स्वचालित परीक्षण का "प्री-ऑटोमेशन"। इसमें, हमने तीन मुख्य प्रश्नों का खुलासा किया:

1. संगठन में परीक्षण स्वचालन के स्तर।
2. मुख्य बिंदु जो आपको स्वचालन परीक्षण करते समय ध्यान देना चाहिए (अपने स्वयं के अनुभव और सहकर्मियों के अनुभव, साथ ही सर्वेक्षण के परिणामों के आधार पर)।
3. स्वचालित परीक्षण (ऑक्टोपस आंतरिक विकास पर आधारित) के प्रबंधन के लिए एक समाधान का एक प्रोटोटाइप।

कटौती के तहत - रिपोर्ट की सामग्री, ऑक्टोपस के प्रचार संस्करण का एक लिंक। लंबी पोस्ट।

1. परीक्षण स्वचालन के स्तर

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

उत्पत्ति के चरण (I)

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

स्टेज के लक्षण

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

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

बी। चेतना चरण (I + II)

परीक्षणों के स्वचालन के साथ-साथ, प्रक्रिया का कुछ हिस्सा स्वचालित है।

स्टेज के लक्षण

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

यह सबसे लोकप्रिय चरणों में से एक है। यह उन कंपनियों के लिए विशिष्ट है जिन्होंने परीक्षण प्रक्रिया को इस तरह स्थापित किया है और मध्यम अवधि और दीर्घकालिक परियोजनाओं पर काम कर रहे हैं। यानी हम उन संगठनों के बारे में बात कर रहे हैं जिन्हें उत्पाद के प्रतिगमन परीक्षण का संचालन करने की आवश्यकता है।

C. उन्नत स्तर (I + II + III)

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

स्टेज के लक्षण

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

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

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

कुछ गीत, या प्रतिगमन परीक्षण के साथ कठिनाइयों

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

2. टेस्ट ऑटोमेशन में समस्या

A. अधूरा स्वचालन

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


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

(*) माप निम्नलिखित परिस्थितियों में किए गए:
1. दोष नियंत्रण प्रणाली - एमएस टीएफएस, मेंटिस, बुगज़िला।
2. प्रयोगकर्ता: 4 वर्ष के अनुभव के साथ 2 परीक्षक।
प्रयोग के दौरान, 10 कीड़े निम्नलिखित आवश्यक क्षेत्रों के साथ बनाए गए थे:
एमएस टीएफएस: टाइटल, एसाइग्न्टो, इटरेशन, एरिया, टेस्टर, फाउंडइन, सेवेरिटी।
मंटिस: श्रेणी, सारांश, विवरण, मंच, ओएस, गंभीरता।
बुगज़िला: घटक, संस्करण, सारांश, विवरण, गंभीरता, कार्य।
बीटीएस खोलने का समय भी ध्यान में रखा गया था।

B. एक सुविधाजनक और लचीले परीक्षण प्रबंधन उपकरण का अभाव

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

C. वास्तुकला की व्यापकता और मापनीयता

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

D. एक ही प्रारूप में संचयी रिपोर्टिंग का अभाव

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

सभी परीक्षणों के लिए एक सामान्य HTML रिपोर्ट का एक उदाहरण

ई। प्रक्रिया निरंतरता

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

F. अपर्याप्त सिस्टम लॉगिंग

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

3. स्वचालित परीक्षण के प्रबंधन के लिए समाधान

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

स्क्रीनशॉट उदाहरण
टैब बनाता है


मशीनें टैब


कतार टैब

ऑक्टोपस नियंत्रण प्रणाली की मुख्य विशेषताएं

1. वर्चुअल मशीन (VMs) शुरू करता है अगर परीक्षण के दौरान वर्चुअलाइजेशन का उपयोग किया जाता है।
2. एक परीक्षण वातावरण तैयार करता है: परीक्षण के लिए मशीन में कॉन्फ़िगरेशन फ़ाइलों और ऑटोटेस्ट की प्रतिलिपि बनाता है, उत्पाद स्थापित करता है।
3. सफलतापूर्वक एकत्र की गई जगह बिल्ड प्राथमिकता के अनुसार परीक्षण कतार में बनाता है।
4. एक अनुसूची या एक सफल बिल्ड रिलीज की घटना पर स्वचालित परीक्षण / परीक्षण समूह चलाता है।
5. "स्वच्छ" वीएम, कुछ स्नैपशॉट और भौतिक मशीनों पर टेस्ट।
6. बीटीएस में पाई गई त्रुटियों को लॉग करता है, परीक्षक द्वारा निर्दिष्ट क्षेत्रों में भरता है (उदाहरण के लिए, शीर्षक, असाइन किया गया, राज्य, विवरण, में पाया गया, समीक्षक / परीक्षक, गंभीरता, आदि)।
7. ऑपरेटर द्वारा अनुमति दिए जाने पर, फिक्स्ड बग को बंद कर देता है।
8. HTML में सभी उत्तीर्ण परीक्षणों पर एक सामान्य रिपोर्ट बनाता है।
परीक्षक स्वचालित परीक्षणों को एकीकृत प्रणाली के डेटाबेस में लोड करता है, एक बार एक विशिष्ट परियोजना के लिए इसकी सेटिंग्स सेट करता है, और यह स्वतंत्र रूप से उत्पाद के हर नए निर्माण को रोक देता है।
यह वीडियो (3 मिनट।) दिखाता है कि सिस्टम कैसे असेंबली बिल्ड का परीक्षण करना शुरू कर देता है।

ऑक्टोपस सिस्टम संरचना

समाधान में तीन मॉड्यूल होते हैं:
स्वचालित परीक्षण प्रबंधक एक सर्वर घटक है जो संपूर्ण प्रणाली के संचालन को नियंत्रित करता है।
कार्यान्वयन तकनीक: .NET फ्रेमवर्क v3.5 के लिए C # में Windows सेवा।
संसाधन की खपत:
CPU: वस्तुतः कोई भार नहीं
रैम: ~ 50 एमबी
नेटवर्क: कार्यों की शुरुआत और पूरा होने पर यह पूरी तरह से कब्जा कर लिया जाता है - पर्यावरण को वर्चुअल मशीन में डाउनलोड किया जाता है और परिणाम प्राप्त किए जाते हैं

स्वचालित परीक्षण लॉन्च एजेंट - एक मॉड्यूल जो परीक्षण के लिए एक आभासी या भौतिक मशीन पर सीधे परीक्षण चलाता है, पर्यावरण को कॉन्फ़िगर करता है, एक फ़ाइल को परीक्षण परिणामों के साथ स्वचालित परीक्षण प्रबंधक में स्थानांतरित करता है।
कार्यान्वयन प्रौद्योगिकी: C ++ कंसोल एप्लिकेशन।
संसाधन की खपत:
सीपीयू: परीक्षण निष्पादन के दौरान उपयोग नहीं किया जाता है
रैम: ~ 7 एमबी

ऑटोमैटिक टेस्टिंग कंट्रोल पैनल क्लाइंट पार्ट है जो ऑक्टोपस यूजर इंटरफेस प्रदान करता है। इसके माध्यम से, आप परीक्षण निष्पादन की व्यापक ट्यूनिंग कर सकते हैं, संसाधनों (वर्चुअल मशीन) का प्रबंधन कर सकते हैं, परीक्षण निष्पादन की वर्तमान स्थिति और इवेंट लॉग देख सकते हैं, और यदि आवश्यक हो, तो मैन्युअल रूप से परीक्षण शुरू और रोक सकते हैं।
कार्यान्वयन प्रौद्योगिकी: Microsoft सिल्वरलाइट प्लेटफ़ॉर्म के लिए C # डेस्कटॉप और वेब अनुप्रयोग।
संसाधन की खपत:
आकार: ~ 0.5 एमबी
रैम: ~ 30 एमबी

सिस्टम आवश्यकताओं

ओएस: विंडोज एक्सपी / विस्टा / 7, विंडोज सर्वर 2003/2008
CPU: 1.0 GHz
रैम: 512 एमबी
हार्ड ड्राइव: 4 एमबी

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

वर्तमान में, सूची इस प्रकार है:

वर्चुअलाइजेशन सिस्टम: VMware सर्वर 2.0 *, हाइपर- V।
बिल्ड सिस्टम: क्रूज़कंट्रोल.नेट *, माइक्रोसॉफ्ट टीम फाउंडेशन सर्वर 2008/2010।
संस्करण नियंत्रण प्रणाली: एसवीएन *, माइक्रोसॉफ्ट टीम फाउंडेशन सर्वर 2008/2010।
त्रुटि नियंत्रण प्रणाली: मेंटिस बग ट्रैकर *, बुग्जिला *, माइक्रोसॉफ्ट टीम फाउंडेशन सर्वर 2008/2010।
विकास के वातावरण का परीक्षण करें: AutoIt *, Microsoft Visual Studio, HP QTP।
(*) - मुफ्त सॉफ्टवेयर।

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

मुफ्त प्रोमो संस्करण

हमने मुफ्त सॉफ्टवेयर के आधार पर ऑक्टोपस एप्लिकेशन का एक मुफ्त प्रचार संस्करण बनाया। हमने फ्रीवेयर चुना, ताकि अगर वांछित हो, तो हर कोई इसे कार्रवाई में आज़मा सके।
इस पृष्ठ पर अधिक जानकारी: www.appsys.net/Octopus/Download/Ru
आपके सवालों और टिप्पणियों का इंतजार रहेगा।