आपको क्या चाहिए बस कैसे टेस्ट करना है

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

इंस्ट्रुमेंटल कोड प्रोसेसिंग और टेस्ट इम्पैक्ट।

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

सब कुछ स्पष्ट करने के लिए एक विस्तृत परिदृश्य।

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


परीक्षण सेटिंग्स में, यह आवश्यक रूप से इंगित किया गया है कि परीक्षण चलाने के दौरान हम परीक्षण प्रभाव विश्लेषण करेंगे:


इसके अतिरिक्त, बिल्ड के बिल नियमों में एक ही विकल्प निर्दिष्ट करना सुनिश्चित करें:


हम बिल्ड इकट्ठा करते हैं और योजना के अनुसार हमारे आवेदन का परीक्षण शुरू करते हैं:

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


हमारे पास 4 परीक्षण, गुणन, विभाजन, घटाव और जोड़ हैं। परिणाम विंडो में, हम देखते हैं कि हमने अपने कैलकुलेटर की सभी विशेषताओं की जाँच की और योजना के सभी परीक्षण पास किए:

कोड में परिवर्तन करें

अब कल्पना करें कि हमारे समाधान के कोड के कुछ हिस्से में, प्रोग्रामर ने बदलाव किए। इन्हें गुणन और विभाजन के कार्य करने दें:


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


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


उसी समय, परीक्षक के पास निर्माण से अनुशंसित परीक्षणों का विश्लेषण करने का अवसर होता है:


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