जब परीक्षण और ऑटोटेस्ट की आवश्यकता होती है, तो सुपरसिस्टेंस से एक नज़र

क्या मुझे ऑटो-परीक्षण की आवश्यकता है? इसकी आवश्यकता कब है? क्या मूल्य लाता है?

लेख इस बात पर चर्चा करता है कि परीक्षण कब और क्यों आवश्यक है और ऐसे मामलों में इसके स्वचालन की क्या आवश्यकता है।

क्लब में आयोजित इस मुद्दे पर उनसे चर्चा के दौरान। फ्रांसिस बेकन ("टेल्म में किफ़ब वेब-मीटिंग"), सहकर्मियों ने अनुभवों का आदान-प्रदान किया और अपने विचारों को लिखा।

यदि यह मूल्य लाता है तो परीक्षण स्वचालन की आवश्यकता है। कब परीक्षण स्वयं मूल्य लाता है? दो मामलों की पहचान की गई है।

यदि प्रक्रिया लड़ाई के लिए बिछाने से पहले सॉफ़्टवेयर में त्रुटियों को पकड़ती है

यदि नए संस्करण के परीक्षण में त्रुटियां सामने आईं जो बाद में तय की गईं, तो यह परीक्षण व्यर्थ नहीं था।

लेकिन क्या होगा अगर स्थिति उलट हो? यदि परीक्षण में त्रुटि नहीं मिली, लेकिन वे युद्ध में दिखाई दिए? यदि परीक्षण बेंच पर त्रुटियों का पता चला था (टेस्ट बेंच को लड़ाई में सबसे अधिक निकटता सहित)।

आरोप है कि इस मामले में परीक्षण खराब तरीके से किया गया था।

परीक्षण की गुणवत्ता को कैसे मापें? इस मामले के लिए, मीट्रिक उपयुक्त है = परीक्षण वातावरण पर त्रुटियों की संख्या / (परीक्षण + लड़ाकू वातावरण पर त्रुटियों की संख्या)। इस मामले में, त्रुटियों की संख्या को महत्वपूर्णता के स्तर से भारित किया जाता है।

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

यह कब संभव है? जब परीक्षण के तहत मॉड्यूल नहीं बदला। एक मॉड्यूल क्या बदल सकता है?

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

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

मुझे इस मामले में ऑटोटेस्ट लिखने की आवश्यकता कब है?

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

यदि आप कोड बनाने के बाद ऑटोटेस्ट लिखते हैं, तो इससे टाइम 2मार्केट में वृद्धि होगी (जिससे स्वचालित रूप से कनेक्टेड कैपिटल में वृद्धि होगी)। इसलिए, यदि ऑटोटैस्ट के साथ कोड को कवर करने का निर्णय लिया जाता है, तो आपको "टेस्टफ़र्स्ट" या "टीडीडी" के विकास प्रतिमान में, इन ऑटोटेस्ट को मुख्य कोड के समानांतर लिखना चाहिए।

परीक्षण स्वचालन द्वारा निर्मित मुख्य मूल्य नए संस्करण के तेजी से अपलोड होने के कारण time2market की कमी है।

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

इस तथ्य के बावजूद कि कार ने कभी आग नहीं पकड़ी है, इसमें आग बुझाने की मशीन की उपस्थिति बेकार नहीं है।

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

इसलिए, महत्वपूर्ण प्रक्रियाओं को उजागर करना आवश्यक है जो नियमित जांच में जाएंगे (जो किसी प्रकार का परिवर्तन होने पर करने योग्य हैं)। एसोसिएट होना चाहिए:

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

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

• विकास के तहत मॉड्यूल बहुत बड़ा नहीं है।
• स्थिर, अत्यधिक सक्षम टीम।
• एकीकरण परीक्षणों द्वारा बंद कर दिए जाते हैं या दूसरी तरफ कोई परिवर्तन नहीं होता है।

क्या परीक्षण करना संभव नहीं है?

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

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

जब परीक्षण स्वचालन की आवश्यकता नहीं है

यदि आपको बड़ी मात्रा में विरासत में मिला है तो बहुत उच्च गुणवत्ता वाला कोड नहीं। इस तरह की अराजकता के साथ ऑटोटेस्ट को कवर करना अराजकता को बढ़ा रहा है।

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

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

और अंत में - ऑटोटेस्ट्स के लिए कंपनी की तत्परता की एक चेकलिस्ट

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

चेकलिस्ट

1. कंपनी मुख्य व्यवसाय वितरण प्रक्रिया को आकर्षित करती है और आपको कहां स्थित है, इसकी समझ है।
2. कंपनी ने ग्राहकों को मूल्य देने की प्रक्रिया तैयार की है।
3. टास्क प्रबंधन की स्थापना की गई है, जिसका अर्थ है कि सभी शामिल कार्यों को वांछित स्थिति में ले जाते हैं। और कार्यों को टाइप किया जाता है।
4. कंपनी ने परीक्षण लक्ष्य तैयार किए हैं।
5. ट्रैकर में कार्यों के शीर्षक "कंघी" हैं, दूसरे शब्दों में, शीर्षक से आप समझ सकते हैं कि यह किस तरह का कार्य है।
6. कार्य रजिस्ट्री प्रबंधनीय है, किसी भी समय यह परियोजना / उत्पाद की वर्तमान स्थिति और नीति को दर्शाता है।
7. आवश्यकताओं की एक रजिस्ट्री है और यह प्रबंधनीय है।
8. कार्य आवश्यकताओं का पता लगाने की क्षमता है।
9. परीक्षण आवश्यकताओं का पता लगाने की क्षमता है। यह ज्ञात है कि क्या परीक्षण क्या आवश्यकताओं से आच्छादित हैं।
10. कार्य परीक्षणों की पता लगाने की क्षमता है। यह ज्ञात है कि यह पहले से ही परीक्षण किया गया है कि कहां और कैसे।
11. एक दूसरे पर घटकों के प्रभाव का एक मैट्रिक्स है।
12. घटकों को कार्य का पता लगाया जाता है।
13. सब कुछ संस्करण नियंत्रण पर है।
14. कौन, कैसे और क्यों की एक संस्करणित नीति है। इस बात की समझ है कि गिट फ्लो एक खराब मॉडल क्यों है।
15. मौजूदा मानक: कोडिंग और अन्य
16. एक ci है
17. एक रिलीज़ पॉलिसी है, जहां विशेष रूप से संस्करण बनाने के तरीके निर्धारित किए जाते हैं, जिसकी सभी आवश्यकता होती है।
18. कलाकृतियों के लिए एक भंडार है जहां से आप विशिष्ट रूप से स्थापना के लिए तैयार उत्पाद निकाल सकते हैं।
19. विभिन्न मानदंडों के अनुसार कलाकृतियों को चिह्नित करने के लिए एक नीति है। स्टेटिक कोड विश्लेषण को भुलाया नहीं जाता है।
20. उत्पाद स्वीप माध्यम उंगली के क्लिक पर उगता है। पर्यावरण भी संस्करण नियंत्रण पर है।
21. शुद्धता के लिए पर्यावरण पूरी तरह से स्वचालित है। पोर्ट, जावा संस्करण, ...
22. उत्पाद चेक के साथ क्लिक पर सामने आता है
23. आवश्यक कार्य के लिए उत्पाद पूरी तरह से स्वचालित रूप से कॉन्फ़िगर किया गया है। वैसे, यह व्यवसाय कॉन्फ़िगरेशन पर भी लागू होता है। और यह भी अपने आप जांचा जाता है।
24. आपके पास बार-बार और स्वचालित रूप से सभी आवश्यक परीक्षण डेटा उत्पन्न करने का एक तरीका है। जेनरेशन स्क्रिप्ट भी संस्करण नियंत्रण पर होती हैं और उत्पाद कलाकृतियों से जुड़ी होती हैं।
25. उपरोक्त सभी उत्पाद के किसी भी संस्करण के लिए काम करते हैं।
26. आपके पास रिलीज़ नीति के अंदर एक वितरण पाइपलाइन पंजीकृत है।

अंत में, चर्चा के लिए समूह के सदस्यों को धन्यवाद और लेख तैयार करने में मदद करें।