परीक्षण उत्पादन और गुणवत्ता आश्वासन

लाभ:

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

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

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

परीक्षण के दो पक्ष: व्यवहार को ठीक करना बनाम सत्यापित करना

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

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

सावधानी: यदि एआई परीक्षण पास कर लेता है, तो इसका मतलब यह नहीं है कि कोड "काम कर रहा है"; इसका सीधा सा अर्थ है "यह वैसा ही व्यवहार करता है जैसा AI अपेक्षा करता है"। आप स्पेसिफिकेशन देखकर तय करते हैं कि अपेक्षा सही है या नहीं।

चरण दर चरण: एआई के साथ मजबूत टेस्ट लिखना

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

तीन मिनी मामले

केस 1 - 52% से 85% तक कवरेज। एक सेवा मॉड्यूल का परीक्षण कवरेज 52% था। टीम ने एआई को मौजूदा परीक्षण दिए, परीक्षण न की गई शाखाओं की सूची बनाई और उनके लिए परीक्षण तैयार किए। मानव समीक्षा के साथ, कवरेज बढ़कर 85% हो गया; इस प्रक्रिया में, एआई ने एक बग शाखा में एक वास्तविक बग (एक पथ जो गलत त्रुटि कोड लौटाता है) का खुलासा किया, जिसका पहले कभी परीक्षण नहीं किया गया था।

केस 2 - झूठी उम्मीद निर्धारण जाल। मनी राउंडिंग फ़ंक्शन वास्तव में गलत था; 2.675 से 2.67 के बजाय 2.68 के बजाय 2.67 का चक्कर लगा रहा था। एआई ने कोड को देखा और एस्टर राउंड_मनी(2.675) == 2.67 लिखा - त्रुटि को "सही" के रूप में फ्रीज कर दिया। जब डेवलपर ने विनिर्देश पढ़ा, तो उसने अपेक्षा को सही किया और वास्तविक बग को पकड़ लिया। कोड का नहीं, नियम का परीक्षण करने से फर्क पड़ा।

केस 3 - एज स्टेट विस्फोट। दिनांक सीमा फ़ंक्शन के लिए केवल "एज केस" के लिए AI से पूछते समय; इसने 8 मामले प्रस्तुत किए जैसे प्रारंभ=अंत, विपरीत अंतराल, लीप वर्ष 29 फरवरी, विभिन्न समय क्षेत्र और शून्य अंतराल। इनमें से दो (रिवर्स स्पेसिंग और लीप वर्ष) वास्तव में त्रुटि का कारण बन रहे थे। इन मामलों पर मैन्युअल रूप से विचार करना अक्सर छोड़ दिया जाता है; एआई यहां "एज-केस ब्रेनस्टॉर्मिंग" भागीदार बन गया।

चार प्रतिलिपि योग्य टेम्पलेट

विशिष्टता-आधारित परीक्षण पीढ़ी:

भूमिका: एक डेवलपर जो परीक्षण लिखता है। फ़्रेमवर्क: {{pytest/JUnit/Jest...}}.फ़ंक्शन को क्या करना चाहिए (विनिर्देश): {{नियम}}निम्नलिखित फ़ंक्शन के लिए परीक्षण लिखें। अपेक्षाओं को विनिर्देश के अनुसार लिखें, कोड के वर्तमान आउटपुट के अनुसार नहीं। शुभ पथ + कम से कम 4 किनारे वाले मामले जोड़ें। प्रत्येक परीक्षण को एक चीज़ का परीक्षण करने दें, वर्णनात्मक नाम का उपयोग करें। {{फ़ंक्शन}}

एज केस पर मंथन:

किनारे/विफलता के मामलों की सूची बनाएं जिन्हें इस फ़ंक्शन के परीक्षण में आजमाया जाना चाहिए (शून्य, शून्य, ब्रेकप्वाइंट, खराब प्रारूप, समवर्ती, बाहरी त्रुटि)। प्रत्येक मामले के लिए: इनपुट, अपेक्षित व्यवहार। अभी तक कोड न लिखें, केवल सूची बनाएं।

कवरेज अंतर विश्लेषण:

नीचे फ़ंक्शन और उपलब्ध परीक्षण दिए गए हैं। किन शाखाओं, स्थितियों और मामलों का परीक्षण नहीं किया गया है? कमियों को सूचीबद्ध करें और कमियों के लिए ही नए परीक्षण लिखें। मौजूदा को न दोहराएँ. फ़ंक्शन:{{फ़ंक्शन}}परीक्षण:{{मौजूदा_परीक्षण}}

परीक्षण डेटा/नकली वस्तु निर्माण:

{{फ़ंक्शन/सेवा}} परीक्षणों के लिए यथार्थवादी परीक्षण डेटा उत्पन्न करें: वैध नमूने, सीमा नमूने और अमान्य नमूने अलग से। बाहरी निर्भरता {{X}} के लिए एक सरल नकली व्यवहार का सुझाव दें। सच्चे गोपनीय डेटा/पीआईआई का उपयोग करना; नकली डेटा उत्पन्न करें.

कमजोर संकेत/मजबूत संकेत

कमज़ोर: "इस फ़ंक्शन के लिए एक परीक्षण लिखें।"

मजबूत: "पाइटेस्ट के साथ। फ़ंक्शन अप्लाई_डिस्काउंट (कुल, प्रतिशत) - नियम: छूट 0% -30% होनी चाहिए, सीमा से बाहर वैल्यूएरर फेंकना चाहिए, परिणाम 2 दशमलव तक पूर्णांकित होना चाहिए। इस नियम द्वारा अपेक्षाएं लिखें (कोड द्वारा नहीं)। हैप्पी पथ + ये किनारे के मामले: 0%, 30%, 31% (त्रुटि), नकारात्मक, कुल = 0। [कोड]"

वह सशक्त रिलीज़ नियम देते हैं और कहते हैं, "अपेक्षा को नियम के अनुसार लिखें, कोड के अनुसार नहीं"; यह एकल वाक्य एआई फिक्सिंग दुर्व्यवहार के जाल को बंद कर देता है।

परीक्षण प्रकार

एआई योगदान

मानव नियंत्रण

शुभ सड़क इकाई परीक्षण

तेज़ कंकाल

क्या अपेक्षा सही है?

किनारे के मामले

गहन मंथन

अप्रासंगिक को हटा दें

स्कोप गैप फिलिंग

छूटी हुई शाखाएँ ढूँढ़ता है

महत्व की पुष्टि करें

परीक्षण डेटा/मॉक

यथार्थवादी नमूना तैयार करता है

कोई पीआईआई नहीं, यथार्थवाद नियंत्रण

परीक्षण गुणवत्ता का प्रबंधन करते हैं, इसकी गारंटी नहीं

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

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

सामान्य गलतियाँ

• बिना नियम बताए टेस्ट की मांग कर रहे हैं। मॉडल वर्तमान व्यवहार को स्थिर कर देता है; त्रुटि को "सत्य" के रूप में ठीक करता है।
• अपेक्षाओं को बिना पढ़े स्वीकार करना। यदि आप यह जांच नहीं करते कि दावे सही मान की जांच कर रहे हैं तो परीक्षण भ्रामक है।
• बस सुखी पथ का परीक्षण कर रहा हूँ। वास्तविक त्रुटियाँ हाशिये पर रहती हैं; किनारे के मामलों के लिए स्पष्ट रूप से पूछें।
• उद्देश्य के दायरे को गलत समझना। उच्च प्रतिशत सही व्यवहार की कोई गारंटी नहीं है।
• वास्तविक/छिपे हुए डेटा को परीक्षण डेटा के रूप में बनाना। ग्राहक डेटा या रहस्यों को परीक्षण और भंडारण में प्रवेश नहीं करना चाहिए; सिंथेटिक डेटा उत्पन्न करें.

संक्षेप में

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

आवेदन कार्य

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

चेकलिस्ट

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