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

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

परीक्षण मॉडल प्रबंधन एक ऐसी प्रक्रिया है जो परीक्षण मॉडल के कवरेज को नियंत्रित करती है, परिदृश्यों की गुणवत्ता जो परीक्षण मॉडल और उसके कार्यान्वयन का वर्णन करती है।

टेस्ट मॉडल प्रबंधन एक सतत प्रक्रिया है जीवन चक्रउत्पाद।

टेस्ट मॉडल कवरेज

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

स्क्रिप्ट की गुणवत्ता

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

परीक्षण मामलों का विवरण शुरू करने से पहले, प्रत्येक स्तर के विवरण के लिए आवश्यकताओं और परीक्षण मामलों के विवरण की गुणवत्ता के मानदंडों को परिभाषित करना आवश्यक है।

परीक्षण मामलों के विवरण के संभावित स्तर:

चौथे स्तर पर, ग्राहक के साथ समझौते को समझौते से बदला जा सकता है।

परीक्षण मामलों का वर्णन करने के लिए गुणवत्ता मानदंड निम्नानुसार हो सकते हैं:

• परीक्षण मामलों को आवश्यकताओं के अनुसार लिखा जाना चाहिए

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

• विस्तृत पूर्व शर्त का प्रयोग करें

परीक्षण मामलों पर समय कैसे बचाएं?

सभी परीक्षण मामलों के लिए स्वरूपण नियम सेट करें। तो किसी भी प्रोजेक्ट प्रतिभागी के लिए टेस्ट केस को समझना और पढ़ना आसान होगा। उदाहरण के लिए, किसी प्रोजेक्ट पर, आप निम्नलिखित नियम दर्ज कर सकते हैं:

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

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

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

स्क्रिप्ट गुणवत्ता नियंत्रण प्रक्रिया आयोजित की जा सकती है टेस्ट मॉडल नियंत्रण के साथ- विशेष रूप से तैयार टेम्पलेट।

परीक्षण मॉडल अद्यतन

आवश्यकताओं के अनुपालन के लिए परीक्षण मॉडल और परीक्षण मामलों को नियमित रूप से अद्यतन करना आवश्यक है, साथ ही परीक्षण मामलों की प्राथमिकताओं की समीक्षा करना भी आवश्यक है।

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

परीक्षण मॉडल नियंत्रण:

• टेस्ट रेल
• परीक्षण लिंक
• जीरा+ज़ेफिर
• माइक्रोसॉफ्ट टेस्ट मैनेजर (एमटीएम)
• एक्सेल

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

परीक्षण प्रक्रिया के लक्ष्य

परीक्षण का उद्देश्य गुणवत्ता का मूल्यांकन करना है सॉफ्टवेयर उत्पादके माध्यम से

• घटक इंटरैक्शन जांच;
• घटकों के सही एकीकरण की जाँच करना;
• सभी आवश्यकताओं के कार्यान्वयन की सटीकता की जाँच करना और दोषों की पहचान करना।

आरयूपी में परीक्षण प्रक्रिया की विशेषताएं

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

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

टेस्ट डेवलपरपरीक्षण की योजना, विकास और कार्यान्वयन के लिए जिम्मेदार। वह एक परीक्षण योजना और मॉडल बनाता है, परीक्षण प्रक्रियाएं (नीचे देखें) और परीक्षण के परिणामों का मूल्यांकन करता है।

परीक्षक (परीक्षक)सिस्टम परीक्षण करने के लिए जिम्मेदार। उनकी जिम्मेदारियों में परीक्षण स्थापित करना और निष्पादित करना, परीक्षण प्रदर्शन का मूल्यांकन करना, त्रुटियों से उबरना और पता लगाए गए दोषों को रिकॉर्ड करना शामिल है।

कलाकृतियों

परीक्षण के दौरान, निम्नलिखित दस्तावेज बनाए जाते हैं:

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

टेस्ट मॉडलक्या और कैसे परीक्षण किया जाएगा इसका एक प्रतिनिधित्व है। मॉडल में नियंत्रण कार्यों, परीक्षण विधियों, परीक्षण परिदृश्यों और अपेक्षित परिणाम (परीक्षण मामलों), परीक्षण स्क्रिप्ट और परीक्षण इंटरैक्शन के विवरण का एक सेट शामिल है।

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

परीक्षा के परिणामऔर परीक्षण के निष्पादन के दौरान प्राप्त डेटा।

वर्कलोड मॉडलअंतिम उपयोगकर्ताओं द्वारा किए गए बाहरी कार्यों, उन कार्यों के दायरे और उन कार्यों द्वारा उत्पन्न कार्यभार को मॉडल करने के लिए उपयोग किया जाता है। मॉडल लोड और/या तनाव परीक्षण करने के लिए अभिप्रेत है जो वास्तविक परिस्थितियों में सिस्टम के संचालन का अनुकरण करता है।

दोष के- ये परीक्षण के दौरान पाई गई आवश्यकताओं के साथ सिस्टम के गैर-अनुपालन के तथ्यों का विवरण हैं। वे एक प्रकार के परिवर्तन अनुरोध हैं।

सभी चरणों में प्रत्येक पुनरावृत्ति में परीक्षण कार्य किए जाते हैं, लेकिन परियोजना के विभिन्न चरणों में लक्ष्य और उद्देश्य काफी भिन्न होते हैं।

परियोजना में प्रवेश का चरण। इस चरण में, परीक्षण की तैयारी की जाती है। उसमे समाविष्ट हैं:

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

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

• परीक्षण परिदृश्यों का विकास।
• परीक्षण स्क्रिप्ट का निर्माण।
• नियंत्रण कार्यों का विकास।
• परीक्षण विधियों का विकास।
• वर्कलोड मॉडल का विकास।

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

• प्रत्येक पुनरावृत्ति के लिए एक परीक्षण योजना बनाएं।
• परीक्षण मॉडल का शोधन और परिवर्धन।
• परीक्षणों का निष्पादन।
• पाए गए दोषों का विवरण।
• परीक्षण के परिणामों का विवरण।
• परीक्षण के परिणामों का मूल्यांकन।

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

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

परीक्षण के परिणामों का मूल्यांकन परीक्षण मेट्रिक्स के आधार पर किया जाता है जो परीक्षण किए गए पीएस की गुणवत्ता और परीक्षण प्रक्रिया को स्वयं निर्धारित करने की अनुमति देता है।

वाद्य समर्थन

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

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

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

वाटरफॉल मॉडल (रैखिक अनुक्रमिक सॉफ्टवेयर जीवन चक्र मॉडल)

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

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

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

पिछले लेख से जलप्रपात मॉडल के बारे में अधिक जानें।.

वी-मॉडल (सत्यापन और सत्यापन मॉडल)

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

इस मॉडल की योजना कार्यों को दो भागों में विभाजित करने के सिद्धांत को दर्शाती है। डिजाइन और विकास से संबंधित लोगों को बाईं ओर रखा गया है। सॉफ़्टवेयर परीक्षण से संबंधित कार्य दाईं ओर स्थित हैं:

इस पद्धति के मुख्य चरण भिन्न हो सकते हैं, लेकिन आम तौर पर निम्नलिखित शामिल हैं:

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

माना परीक्षण पद्धति का एकमात्र दोष तैयार किए गए समाधानों की कमी है जिसे परीक्षण चरण के दौरान पाए गए सॉफ़्टवेयर दोषों से छुटकारा पाने के लिए लागू किया जा सकता है।

वृद्धिशील मॉडल

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

1. आकार और विकास
2. परिक्षण
3. कार्यान्वयन।

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

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

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

सर्पिल मॉडल

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

1. योजना
2. संकट विश्लेषण
3. विकास
4. श्रेणी

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

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

पिछले ब्लॉग पोस्ट में सर्पिल मॉडल के बारे में और पढ़ें।.

फुर्तीला

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

Agile . के बारे में और जानें(नोट - लेख अंग्रेजी में).

एक्सट्रीम प्रोग्रामिंग (एक्सपी, एक्सट्रीम प्रोग्रामिंग)

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

इस पद्धति के मुख्य लाभ निरंतर परीक्षण और लघु रिलीज हैं, जो सुनिश्चित करने में मदद करता है उच्च गुणवत्ताकोड।

जमघट

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

• स्क्रम योजना में भागीदारी
• यूनिट परीक्षण समर्थन
• उपयोगकर्ता कहानी परीक्षण
• स्वीकृति मानदंड निर्धारित करने के लिए ग्राहक और उत्पाद स्वामी के साथ सहयोग करें
• स्वचालित परीक्षण प्रदान करना

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

उसी समय, स्क्रम में फुर्तीली कार्यप्रणाली के सिद्धांत विशिष्ट विशेषताओं के उद्भव की ओर ले जाते हैं:

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

पिछले लेख से स्क्रम पद्धति के बारे में और जानें।.

निष्कर्ष

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

चाहे आपको सॉफ़्टवेयर विकास या परीक्षण में सहायता की आवश्यकता हो, डेवलपर्स और QA इंजीनियरों की एक समर्पित टीम जाने के लिए तैयार है।

वेब सेवा परीक्षण

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

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

मूल्यांकन क्यों?

कोई भी मूल्यांकन मेट्रिक्स समय की बर्बादी है। इस समय, आप परीक्षण कर सकते हैं, बग शुरू कर सकते हैं, ऑटोटेस्ट तैयार कर सकते हैं। परीक्षण कवरेज मेट्रिक्स से परीक्षण समय का त्याग करने के लिए हमें क्या जादुई लाभ मिलता है?

1. अपने कमजोर क्षेत्रों का पता लगाना।स्वाभाविक रूप से, हमें इसकी आवश्यकता है? केवल शोक करने के लिए नहीं, बल्कि यह जानने के लिए कि सुधार की आवश्यकता कहाँ है। कौन से कार्यात्मक क्षेत्र परीक्षणों द्वारा कवर नहीं किए जाते हैं? हमने क्या जाँच नहीं की? गुम त्रुटियों के सबसे बड़े जोखिम कहां हैं?
2. शायद ही हमें मूल्यांकन परिणामों से 100% कवरेज मिलता है। क्या सुधारना है? कहाँ जाना है? अभी प्रतिशत क्या है? हम इसे किसी भी कार्य से कैसे बढ़ा सकते हैं? हम कितनी तेजी से 100 तक पहुंच सकते हैं? ये सभी प्रश्न हमारी प्रक्रिया में पारदर्शिता और स्पष्टता लाते हैं।, और उनके उत्तर कवरेज अनुमान द्वारा दिए गए हैं।
3. ध्यान का फोकस।मान लें कि हमारे उत्पाद में लगभग 50 विभिन्न कार्यात्मक क्षेत्र हैं। बाहर आ रहा है एक नया संस्करण, और हम उनमें से 1 का परीक्षण करना शुरू करते हैं, और वहां टाइपोस ढूंढते हैं, और बटन जो कुछ पिक्सेल, और अन्य ट्राइफल्स को स्थानांतरित कर चुके हैं ... और अब परीक्षण का समय समाप्त हो गया है, और इस कार्यक्षमता का विस्तार से परीक्षण किया गया है .. और शेष 50? कवरेज मूल्यांकन हमें वर्तमान वास्तविकताओं और समय सीमा के आधार पर कार्यों को प्राथमिकता देने की अनुमति देता है।

मूल्यांकन कैसे करें?

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

परीक्षणों द्वारा आवश्यकताओं के कवरेज का आकलन

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

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

समस्या: आवश्यकताएँ परमाणु नहीं हैं।

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

इस प्रकार, एक आवश्यकता परीक्षण होने से हमें कुछ भी गारंटी नहीं मिलती है! इस मामले में हमारे कवरेज आँकड़ों का क्या अर्थ है? लगभग कुछ नहीं! हमें फैसला करना होगा!

1. इस मामले में, परीक्षण द्वारा कवरेज आवश्यकताओं की स्वचालित गणना को हटाया जा सकता है - यह अभी भी एक अर्थ भार नहीं लेता है।
2. प्रत्येक आवश्यकता के लिए, सर्वोच्च प्राथमिकता से शुरू करते हुए, हम परीक्षण तैयार करते हैं। तैयारी करते समय, हम विश्लेषण करते हैं कि इस आवश्यकता के लिए किन परीक्षणों की आवश्यकता होगी, कितने पर्याप्त होंगे? हम एक पूर्ण परीक्षण विश्लेषण करते हैं, और "एक परीक्षण है, लेकिन ठीक है" को दरकिनार नहीं करते हैं।
3. उपयोग की गई प्रणाली के आधार पर, हम मांग पर परीक्षण निर्यात/अपलोड करते हैं और… हम इन परीक्षणों का परीक्षण करते हैं! क्या वे पर्याप्त हैं? आदर्श रूप से, निश्चित रूप से, इस तरह के परीक्षण को एक विश्लेषक और इस कार्यक्षमता के डेवलपर के साथ किया जाना चाहिए। परीक्षणों को प्रिंट करें, अपने सहयोगियों को बैठक कक्ष में बंद करें, और जब तक वे कहते हैं कि "हाँ, ये परीक्षण पर्याप्त हैं" (यह केवल लिखित समझौते के साथ होता है, जब ये शब्द सदस्यता समाप्त करने के लिए बोले जाते हैं, यहां तक ​​​​कि परीक्षणों का विश्लेषण किए बिना भी। एक मौखिक चर्चा के दौरान, आपके सहकर्मी एक टब आलोचना, छूटे हुए परीक्षण, गलत समझी जाने वाली आवश्यकताओं आदि को बाहर निकाल देंगे - यह हमेशा सुखद नहीं होता है, लेकिन यह परीक्षण के लिए बहुत उपयोगी है!)
4. मांग पर परीक्षणों को अंतिम रूप देने और उनकी पूर्णता पर सहमत होने के बाद, सिस्टम में इस आवश्यकता को "परीक्षणों द्वारा कवर" स्थिति के साथ चिह्नित किया जा सकता है। इस जानकारी का अर्थ "यहां कम से कम 1 परीक्षण है" से कहीं अधिक होगा।

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

समस्या: बिल्कुल कोई आवश्यकता नहीं है।

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

1. एक फीचर सूची बनाएं। सामी! Google-टैबलेट के रूप में, TFS में PBI प्रारूप में - कोई भी चुनें, जब तक कि वह पाठ स्वरूप न हो। हमें अभी भी स्थितियाँ एकत्र करने की आवश्यकता है! हम इस सूची में उत्पाद के सभी कार्यात्मक क्षेत्रों को शामिल करते हैं, और अपघटन के एक सामान्य स्तर को चुनने का प्रयास करते हैं (आप सॉफ़्टवेयर ऑब्जेक्ट, या उपयोगकर्ता स्क्रिप्ट, या मॉड्यूल, या वेब पेज, या API विधियाँ, या स्क्रीन फ़ॉर्म लिख सकते हैं .. ।) - लेकिन यह सब एक बार में नहीं! एक अपघटन प्रारूप जो आपके लिए महत्वपूर्ण चीजों को याद नहीं करना आसान और स्पष्ट कर देगा।
2. हम अपनी टीम के भीतर विश्लेषकों, डेवलपर्स, व्यवसाय के साथ इस सूची की पूर्णता का समन्वय करते हैं ... सब कुछ करने की कोशिश करें ताकि उत्पाद के महत्वपूर्ण हिस्सों को न खोएं! विश्लेषण करना कितना गहरा है, यह आप पर निर्भर है। मेरे व्यवहार में, केवल कुछ उत्पाद थे जिनके लिए हमने तालिका में 100 से अधिक पृष्ठ बनाए, और ये विशाल उत्पाद थे। सबसे अधिक बार, 30-50 लाइनें आगे की सावधानीपूर्वक प्रसंस्करण के लिए एक प्राप्त परिणाम है। समर्पित परीक्षण विश्लेषकों के बिना एक छोटी टीम में अधिकफिकेलिस्टा तत्वों को बनाए रखना बहुत मुश्किल होगा।
3. उसके बाद, हम प्राथमिकताओं के माध्यम से जाते हैं, और फ़िशलिस्ट की प्रत्येक पंक्ति को ऊपर वर्णित आवश्यकता अनुभाग के अनुसार संसाधित करते हैं। हम परीक्षण लिखते हैं, चर्चा करते हैं, पर्याप्तता पर सहमत होते हैं। हम उन स्थितियों को चिह्नित करते हैं जिनके लिए पर्याप्त परीक्षण हैं। हमें टीम के साथ संचार के माध्यम से स्थिति, प्रगति और परीक्षणों का विस्तार मिलता है। सब खुश हैं!

लेकिन... क्या होगा यदि आवश्यकताओं को बनाए रखा जाता है, लेकिन ट्रेस करने योग्य प्रारूप में नहीं?

समस्या: आवश्यकताएँ पता लगाने योग्य नहीं हैं।

परियोजना पर प्रलेखन की एक बड़ी मात्रा है, विश्लेषक प्रति मिनट 400 वर्णों की गति से टाइप करते हैं, आपके पास विनिर्देश, तकनीकी विनिर्देश, निर्देश, संदर्भ हैं (अक्सर यह ग्राहक के अनुरोध पर होता है), और यह सब इस प्रकार कार्य करता है आवश्यकताओं, और सब कुछ लंबे समय से परियोजना पर रहा है उलझन में है कि किस जानकारी को कहां देखना है?
पिछले खंड को दोहराते हुए, पूरी टीम को साफ करने में मदद करता है!

1. हम एक फीचरलिस्ट बनाते हैं (ऊपर देखें), लेकिन आवश्यकताओं के विस्तृत विवरण के बिना।
2. प्रत्येक सुविधा के लिए, हम तकनीकी विशिष्टताओं, विशिष्टताओं, निर्देशों और अन्य दस्तावेज़ों के लिंक एक साथ एकत्रित करते हैं।
3. हम प्राथमिकताओं से चलते हैं, परीक्षण तैयार करते हैं, और उनकी पूर्णता पर सहमत होते हैं। सब कुछ समान है, केवल एक प्लेट में सभी दस्तावेजों के संयोजन के लिए धन्यवाद, हम उन तक पहुंच में आसानी, पारदर्शी स्थिति और परीक्षणों की स्थिरता को बढ़ाते हैं। अंत में, सब कुछ सुपर है, और हर कोई खुश है!

लेकिन… लंबे समय के लिए नहीं… ऐसा लगता है कि पिछले सप्ताह में, विश्लेषकों ने ग्राहकों के अनुरोधों के आधार पर 4 अलग-अलग विशिष्टताओं को अपडेट किया है!!!

समस्या: आवश्यकताएँ हर समय बदलती रहती हैं।

बेशक, कुछ निश्चित प्रणाली का परीक्षण करना अच्छा होगा, लेकिन हमारे उत्पाद आमतौर पर लाइव होते हैं। ग्राहक ने कुछ मांगा, हमारे उत्पाद के बाहर कानून में कुछ बदल गया, और कहीं विश्लेषकों ने पिछले साल से पहले की विश्लेषण त्रुटि पाई ... आवश्यकताएँ अपना जीवन जीते हैं! क्या करें?

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

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

समस्या: दस्तावेजों के परीक्षण के लिए पर्याप्त समय नहीं है।

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

1. आपको अभी भी पूर्ण आवश्यकताओं के रूप में या एक फीचर सूची के रूप में आवश्यकताओं की आवश्यकता है, इसलिए उपरोक्त अनुभागों में से एक, परियोजना पर विश्लेषकों के काम के आधार पर, अभी भी आवश्यक होगा। एक आवश्यकता/सुविधा सूची मिली?
2. हम विशिष्ट परीक्षणों का दस्तावेजीकरण किए बिना, एक छोटी परीक्षण रणनीति का वर्णन करते हैं और मौखिक रूप से सहमत होते हैं! यह रणनीति तालिका कॉलम में, विकी पेज पर, या आरएमएस में एक आवश्यकता में निर्दिष्ट की जा सकती है, और फिर से सहमत होना चाहिए। इस रणनीति के हिस्से के रूप में, समीक्षा अलग-अलग तरीकों से की जाएगी, लेकिन आपको पता चल जाएगा: यह कब है पिछली बारपरीक्षण किया और किस रणनीति के साथ? और यह, आप देखते हैं, यह भी बुरा नहीं है! और सभी खुश रहेंगे।

परंतु… और क्या "लेकिन"? कौन सा???

कहो, हम सब कुछ करेंगे, और उच्च गुणवत्ता वाले उत्पाद हमारे साथ हो सकते हैं!

| स्कूल वर्ष के लिए पाठ योजना | मॉडलिंग के मुख्य चरण

पाठ 2
मॉडलिंग के मुख्य चरण

इस विषय का अध्ययन करके आप सीखेंगे:

मॉडलिंग क्या है;
- मॉडलिंग के लिए एक प्रोटोटाइप के रूप में क्या काम कर सकता है;
- मानव गतिविधि में मॉडलिंग का क्या स्थान है;
- मॉडलिंग के मुख्य चरण क्या हैं;
- कंप्यूटर मॉडल क्या है;
कंप्यूटर प्रयोग क्या है।

कंप्यूटर प्रयोग

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

स्कूल में, आप जीव विज्ञान, रसायन विज्ञान, भौतिकी, भूगोल के पाठों में प्रयोग करते हैं।

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

प्रयोगशाला और पूर्ण पैमाने के प्रयोगों के लिए बड़ी सामग्री लागत और समय की आवश्यकता होती है, लेकिन उनका महत्व, फिर भी, बहुत बड़ा है।

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

प्रयोग योजना

प्रयोग योजना को मॉडल के साथ काम के क्रम को स्पष्ट रूप से प्रतिबिंबित करना चाहिए। ऐसी योजना में पहला कदम हमेशा मॉडल का परीक्षण करना होता है।

परीक्षण निर्मित मॉडल की शुद्धता की जांच करने की प्रक्रिया है।

परीक्षण - प्रारंभिक डेटा का एक सेट जो आपको मॉडल के निर्माण की शुद्धता निर्धारित करने की अनुमति देता है।

प्राप्त मॉडलिंग परिणामों की शुद्धता के बारे में सुनिश्चित करने के लिए, यह आवश्यक है: मॉडल के निर्माण के लिए विकसित एल्गोरिथम की जांच करने के लिए; ♦ सुनिश्चित करें कि निर्मित मॉडल मूल के गुणों को सही ढंग से दर्शाता है, जिन्हें सिमुलेशन में ध्यान में रखा गया था।

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

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

यह सुनिश्चित करने के लिए कि निर्मित मॉडल मूल के गुणों को दर्शाता है, जिन्हें सिमुलेशन में ध्यान में रखा गया था, वास्तविक स्रोत डेटा के साथ एक परीक्षण उदाहरण का चयन करना आवश्यक है।

अनुसंधान का संचालन

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

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

कंप्यूटर प्रयोग तैयार करने और संचालित करने की योजना चित्र 11.7 में दिखाई गई है।

चावल। 11.7 कंप्यूटर प्रयोग की योजना

सिमुलेशन परिणामों का विश्लेषण

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

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

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

ओह, हमारे पास कितनी अद्भुत खोजें हैं
आत्मज्ञान की भावना तैयार करें
और अनुभव, कठिन गलतियों का बेटा,
और प्रतिभाशाली, विरोधाभास मित्र,
और मौका, भगवान आविष्कारक है...

प्रश्नों और कार्यों को नियंत्रित करें

1. मॉडलिंग समस्या कथन के दो मुख्य प्रकार क्या हैं?

2. जी. ओस्टर की प्रसिद्ध "समस्या पुस्तक" में निम्नलिखित समस्या है:

दुष्ट चुड़ैल, अथक परिश्रम करते हुए, एक दिन में 30 राजकुमारियों को कैटरपिलर में बदल देती है। 810 राजकुमारियों को कैटरपिलर में बदलने में उसे कितने दिन लगेंगे? 15 दिनों में काम पूरा करने के लिए एक दिन में कितनी राजकुमारियों को कैटरपिलर में बदलना होगा?
"क्या होगा अगर ..." के प्रकार के लिए किस प्रश्न को जिम्मेदार ठहराया जा सकता है, और कौन सा - "ऐसा कैसे करें ..." के प्रकार के लिए?

3. मॉडलिंग के सबसे प्रसिद्ध लक्ष्यों की सूची बनाएं।

4. जी। ओस्टर की "समस्या पुस्तक" से चंचल समस्या को औपचारिक रूप दें:

एक दूसरे से 27 किमी की दूरी पर स्थित दो बूथों से एक ही समय में दो उग्र कुत्ते एक दूसरे की ओर कूद पड़े। पहला 4 किमी / घंटा की गति से चलता है, और दूसरा - 5 किमी / घंटा।
लड़ाई कब तक शुरू होगी?

5. "जूते की जोड़ी" वस्तु की जितनी हो सके उतनी विशेषताओं को नाम दें। विभिन्न उद्देश्यों के लिए किसी वस्तु का सूचना मॉडल तैयार करें:
लंबी पैदल यात्रा के लिए जूते का चुनाव;
एक उपयुक्त जूता बॉक्स का चयन;
शू केयर क्रीम की खरीद।

6. एक पेशा चुनने की सिफारिश के लिए किशोरी की कौन सी विशेषताएँ आवश्यक हैं?

7. सिमुलेशन में कंप्यूटर का व्यापक रूप से उपयोग क्यों किया जाता है?

8. कंप्यूटर मॉडलिंग के उन उपकरणों के नाम बताइए जिन्हें आप जानते हैं।

9. कंप्यूटर प्रयोग क्या है? एक उदाहरण दें।

10. मॉडल परीक्षण क्या है?

11. मॉडलिंग प्रक्रिया में क्या त्रुटियां आती हैं? त्रुटि पाए जाने पर क्या करना चाहिए?

12. सिमुलेशन परिणामों का विश्लेषण क्या है? आमतौर पर कौन से निष्कर्ष निकाले जाते हैं?