चौखटे का परिचय (भाग 2)

भाग 1

फ्रेमवर्क की दूसरी पीढ़ी

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

कार्यात्मक अपघटन

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

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

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

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

कार्यात्मक अपघटन के लाभ

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

कार्यात्मक अपघटन के नुकसान

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

डेटा ओरिएंटेशन

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

1. इनपुट "जॉन" यूजरनेम टेक्स्टबॉक्स में
2. पासवर्ड टेक्स्ट बॉक्स में "JPass" इनपुट करें
3. लॉगिन बटन पर क्लिक करें
4. अगर "वेलकम स्क्रीन" मौजूद है
5. टेस्ट पास करें
6. अन्यथा
7. परीक्षण विफल
8. यदि समाप्त हो

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

NameParameter	PasswordParameter
जॉन	JPass
नालिश करना	Spaß
भिखारिन	RPass
ट्रीना	TPass

ऊपर दिखाए गए डेटा अभिविन्यास के साथ ऊपर संशोधित रैखिक स्क्रिप्ट का संस्करण निम्नानुसार लग सकता है:

1. डेटा तालिका खोलें
2. इनपुट <NameParameter> उपयोगकर्ता नाम टेक्स्टबॉक्स में
3. इनपुट <PasswordParameter> पासवर्ड टेक्स्टबॉक्स में
4. लॉगिन बटन पर क्लिक करें
5. अगर "वेलकम स्क्रीन" मौजूद है
6. टेस्ट पास करें
7. अन्यथा
8. परीक्षण विफल
9. यदि समाप्त हो
10. डेटा टेबल बंद करें

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

डेटा ओरिएंटेशन के लाभ

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

डेटा ओरिएंटेशन नुकसान

इस दृष्टिकोण के नुकसान में रेखीय लिपियों से विरासत में निम्नलिखित पहलू शामिल हैं (देखें भाग 1 ):

• अतिरेक।
• एक आयामी स्वरूप।
• पढ़ने में कठिनाई।
• समर्थन के लिए उच्च स्तर के ज्ञान की आवश्यकता होती है।