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

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

स्वचालन की डिग्री के अनुसार, परीक्षण में विभाजित हैं:

1. मैनुअल।
2. स्वचालित।
3. स्वचालित (मानव हस्तक्षेप के बिना, इस समय - वास्तविकता की तुलना में एक मिथक)।

सीधे परीक्षण के अनुकूलन का दृष्टिकोण स्वचालन की डिग्री पर निर्भर करता है।

सभी प्रकार के परीक्षणों पर लागू अनुकूलन

परीक्षण में निम्न चरण शामिल हैं:

• परीक्षण प्रणाली की तैयारी
• इनपुट डेटा की तैयारी
• परीक्षण (मैन्युअल या स्वचालित रूप से, हम नीचे विचार करेंगे),
• परिणामों का संग्रह और विश्लेषण।

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

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

समस्याएं:

1. परीक्षण प्रणाली की लंबी तैयारी

अनुकूलन को लागू करने से पहले पूछे जाने वाले प्रश्न:

• लंबे समय के बारे में क्या?
• इस प्रशिक्षण में कौन शामिल है (परीक्षक, प्रोग्रामर ...)?
• एक कार्य दिवस के दौरान आप कितनी बार एक परीक्षण प्रणाली तैयार कर सकते हैं? क्या इस संख्या में परीक्षण की आवश्यकता है?
• तैयारी में सबसे लंबा चरण क्या है और क्यों?

इस समस्या का कारण खोजने के लिए, सही प्रश्न पूछना महत्वपूर्ण है।
निम्नलिखित उदाहरणों पर विचार करें:

सभी सिस्टम मॉड्यूल का लंबा संकलन
सही सवाल है : क्या सभी मॉड्यूल को संकलन की आवश्यकता है?
समाधान : सभी सिस्टम मॉड्यूल को संकलित करने के लिए, लेकिन केवल वे जो कार्य में प्रभावित हुए थे, और जो रिलीज में भाग लेंगे।

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

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

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

2. लंबे संग्रह और परिणामों का विश्लेषण

अनुकूलन को लागू करने से पहले पूछे जाने वाले प्रश्न:

• लंबे समय के बारे में क्या?
• परिणाम एकत्र करने और विश्लेषण करने की प्रक्रिया के चरण क्या हैं? कौन सा चरण सबसे लंबा है और क्यों?
• परिणामों का विश्लेषण कौन करता है?
• कौन रिहाई और किस आधार पर फैसला करता है? निर्णय लेने में कितना समय लगता है?

उदाहरण के लिए :
परीक्षण के परिणाम टेम्प्लेट के अनुसार जारी किए जाते हैं, टेम्प्लेट के अनुसार पंजीकरण परीक्षण के दौरान अधिकांश समय लेता है।

समाधान (धन्यवाद, कैप!) : टेम्पलेट के परिणामों को भरने से इंकार करें या भरने के लिए एक आसान टेम्पलेट बनाएं। टीम के साथ एक समझौते पर आना और इन परिणामों को पढ़ने वालों से यह पता लगाना आवश्यक होगा (और क्या वे इसे पढ़ते हैं?), क्या वास्तव में इस तरह के टेम्पलेट की आवश्यकता है (जोखिम "मेज पर" परीक्षा परिणाम लिखने के लिए है)।

मैनुअल परीक्षण के लिए लागू अनुकूलन

इन परीक्षणों को दो बड़े वर्गों में विभाजित किया जा सकता है:

1. नियमित रूप से आयोजित किया जाता है, उदाहरण के लिए, रिलीज से पहले (प्रतिगमन परीक्षण पर विचार करें),
2. नई कार्यक्षमता का परीक्षण करने के लिए शायद ही कभी और आयोजित किया गया।

यदि प्रतिगमन अक्सर और मैनुअल होता है, तो यह स्वचालन के बारे में सोचने और स्वचालन के भुगतान के बारे में सोचता है, लेकिन इस लेख में हम स्वचालन रॉय पर विचार नहीं करेंगे।

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

मैनुअल परीक्षण के लिए, सबसे पहले, आपको नियमित कार्यों (कार्यों, परीक्षण नहीं!) की तलाश करनी होगी, और पहले से ही उन्हें अनुकूलित करना होगा (स्वचालन का उपयोग करना या मानव संसाधनों का पुनर्वितरण करना)।

उदाहरण के लिए, परीक्षणों के लिए दिनचर्या परीक्षण डेटा तैयार करना है। इसकी बहुत तैयारी के लिए अलग-अलग तरीके हैं:

1. यूआई के माध्यम से मैन्युअल रूप से,
2. एपीआई के माध्यम से मैन्युअल रूप से,
3. ऑटोटेस्ट चलाने से, फिर डेटा इन परीक्षणों का एक दुष्प्रभाव होगा,
4. एपीआई या यूआई के माध्यम से स्क्रिप्ट / उपयोगिताओं / कस्टम टूल के माध्यम से स्वचालित।

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

स्वचालित परीक्षणों पर लागू अनुकूलन

मैन्युअल परीक्षण की तुलना में यहां परीक्षण डेटा तैयार करने की समस्या अधिक गंभीर है। परीक्षण डेटा की तैयारी होनी चाहिए:

1. तेजी से,
2. डिजाइन / लेआउट परिवर्तन के लिए प्रतिरोधी,
3. संभव समानांतर परीक्षण रन के लिए प्रतिरोधी,
4. प्रणाली की आंतरिक वास्तुकला में परिवर्तन के लिए प्रतिरोधी।

यह वांछनीय है कि डेटा की तैयारी को समाधान के कार्यान्वयन में अतिरिक्त कौशल और समय की आवश्यकता नहीं है।

परीक्षण डेटा स्वचालित रूप से तैयार किया जा सकता है:

1. UI के माध्यम से,
2. एपीआई या HTTP अनुरोधों के माध्यम से,
3. डेटाबेस प्रश्नों के माध्यम से।

इन दृष्टिकोणों के पक्ष और विपक्ष के बारे में तालिका में अधिक विस्तार से विचार करें:

एपीआई और HTTP के माध्यम से प्लस और माइनस के संयोजन के लिए परीक्षण डेटा की तैयारी सबसे इष्टतम है।

स्वचालित परीक्षण पर लागू होने वाले सबसे आम अनुकूलन हैं:

समानता का परीक्षण करें

यदि परीक्षणों की समस्याओं में से एक उनके पारित होने का समय ठीक है, जबकि कम्प्यूटेशनल संसाधन हैं, तो आप उन्हें तीन समानांतर मोड में से एक में समानांतर और निष्पादित कर सकते हैं:

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

पुराने परीक्षणों को हटाना

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

टेस्ट केस सेट का अनुकूलन करने के लिए टेस्ट डिज़ाइन तकनीकों का उपयोग करना

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

मौजूदा परीक्षणों और सत्यापन को दूसरे स्तर पर स्थानांतरित करना

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

"मॉड्यूलर - एकीकरण - प्रणाली" के स्तरों पर परीक्षणों का सही अपघटन

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

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

वेब अनुप्रयोगों के स्वचालित परीक्षण के लिए परीक्षण और परीक्षण प्रणालियों की एक लोकप्रिय कनेक्शन योजना:

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

सादगी के लिए, कुछ इंटरैक्शन का अनुकूलन करने पर विचार करें:

1) सहभागिता "परीक्षण-मामलों - ब्राउज़र - डेटाबेस"
एपीआई का उपयोग न केवल परीक्षण के लिए डेटा तैयार करने के लिए, बल्कि परीक्षण में कई कदम उठाने के लिए भी किया जाता है।

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

2) इंटरैक्शन "टेस्ट-केस - सेलेनियमवेबड्राइवर - ब्राउज़र"।

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

निष्कर्ष में

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

और एक बार फिर मैं दोहराना चाहूंगा: नियमित परीक्षणों की तलाश न करें, नियमित कार्यों की तलाश करें और उन्हें स्वचालित करें!

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