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

लाभ:

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

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

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

अवधारणाएँ: इकाई परीक्षण: किसी एकल फ़ंक्शन/वर्ग का अलगाव में परीक्षण करता है। एकीकरण परीक्षण: परीक्षण करता है कि कई हिस्से एक साथ सही ढंग से काम करते हैं। दावा: एक कथन जो जाँचता है कि परिणाम अपेक्षित के बराबर है; यह परीक्षण का हृदय है. कवरेज: परीक्षण द्वारा कितना कोड चलाया जाता है; उच्च कवरेज गुणवत्ता की गारंटी नहीं देता.

सार्थक परीक्षण का निर्माण

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

1. परीक्षण किए जाने वाले व्यवहार को परिभाषित करें। “क्या सही माना जाएगा?” प्रश्न का स्पष्ट उत्तर दीजिए.
2. परिदृश्य प्रकार के लिए पूछें. सामान्य, सीमा, नकारात्मक, त्रुटि स्थिति।
3. सार्थक अभिकथन आयात करें. इसने केवल "त्रुटि नहीं दी", इसने "सही मान लौटाया"।
4. परीक्षण की सटीकता की जाँच करें. जब आप जानबूझकर कोड तोड़ते हैं तो क्या परीक्षण लाल हो जाता है?

व्यापक परीक्षण पीढ़ी संकेत: "निम्नलिखित 'लागू छूट (राशि, कूपन)' फ़ंक्शन के लिए इकाई परीक्षण लिखें। निम्नलिखित श्रेणियों में कम से कम एक परिदृश्य रखें: (1) सामान्य वैध कूपन, (2) ब्रेकप्वाइंट (0 राशि, 100% छूट), (3) नकारात्मक (अमान्य कूपन, नकारात्मक राशि), (4) त्रुटि मामला (शून्य कूपन)। प्रत्येक परीक्षण में ठोस अपेक्षित मूल्य पर जोर दें (सिर्फ 'काम नहीं किया')। पढ़ने योग्य परीक्षणों का नाम बताएं। कोड: [कोड]"

सीमा मूल्य निष्कर्षण संकेत: "इस फ़ंक्शन के इनपुट के लिए एक सीमा मूल्य विश्लेषण करें। प्रत्येक पैरामीटर के लिए, एक तालिका के रूप में 'सीमा पर', 'सीमा के ठीक नीचे', 'सीमा के ठीक ऊपर' मान निकालें। फिर इन सीमाओं को कवर करने वाले परीक्षण परिदृश्यों को सूचीबद्ध करें। अभी तक कोड न लिखें, केवल विश्लेषण और परिदृश्य सूची। फ़ंक्शन: [हस्ताक्षर]"

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

स्वयं परीक्षण का परीक्षण: उत्परिवर्तन का तर्क

यह समझने का सबसे व्यावहारिक तरीका है कि एआई-जनरेटेड परीक्षण वास्तव में काम करता है या नहीं, जानबूझकर कोड (उत्परिवर्तन परीक्षण तर्क) को तोड़ना है। किसी शर्त को उलट दें, + चिह्न बनाएं -; यदि कोई भी परीक्षण लाल नहीं होता है, तो आपके परीक्षण वास्तव में उस व्यवहार को बनाए नहीं रख रहे हैं।

परीक्षण भेद्यता शिकार संकेत: "मुझे बताएं कि इस कोड में कौन से संभावित बग निम्नलिखित परीक्षण नहीं पकड़ सकते हैं। 5 छोटे उत्परिवर्तन सुझाएं जो कोड में किए जा सकते हैं (उदाहरण के लिए >= के बजाय, - + के बजाय) और प्रत्येक के लिए इंगित करें कि क्या मौजूदा परीक्षण इसे पकड़ पाएंगे। जो नहीं पकड़े गए हैं, उनके लिए परीक्षण का सुझाव दें जिन्हें जोड़ा जाना चाहिए। कोड: [कोड] परीक्षण: [परीक्षण]"

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

कमजोर: "इस फ़ंक्शन के लिए एक परीक्षण लिखें।" (परिणाम: आमतौर पर एक सुखद परिदृश्य, कमजोर जोर; त्रुटियां छूट जाती हैं।) मजबूत: "इस 'पासवर्डस्ट्रॉन्ग' फ़ंक्शन के लिए एक परीक्षण लिखें। नियम: कम से कम 8 अक्षर, 1 अपरकेस अक्षर, 1 अंक आवश्यक। निम्नलिखित परिदृश्यों को अलग-अलग परीक्षणों के रूप में कवर करें: बिल्कुल 8 अक्षर (सीमा), 7 अक्षर (सीमा से नीचे), कोई बड़ा अक्षर नहीं, कोई अंक नहीं, खाली स्ट्रिंग, केवल रिक्त स्थान, बहुत लंबा (1000 अक्षर) स्पष्ट रूप से अपेक्षित पर जोर दें प्रत्येक परीक्षण में सही/गलत मान और परीक्षण को उसकी जाँच के अनुसार नाम दें।"

शक्तिशाली संकेत नियम और पूर्ण सीमा परिदृश्य देता है। सीमा युग्म जैसे "बिल्कुल 8/7 अक्षर" गलतियाँ करने के लिए सबसे आम स्थान हैं (भ्रमित > के साथ >=)। कमजोर प्रॉम्प्ट इन सीमाओं को दरकिनार कर देता है और त्रुटि को उत्पादन तक ले जाता है।

परीक्षण के प्रकार और कहां उपयोग करें

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

यह क्या पुष्टि करता है?

एआई योगदान

ध्यान दें

इकाई

एकल फ़ंक्शन/वर्ग

तेजी से बहु-परिदृश्य उत्पन्न करता है

सार्थक दावे की आवश्यकता है

एकीकरण

हिस्से एक साथ काम कर रहे हैं

परिदृश्य और मॉक डेटा ड्राफ्ट

सच्चा व्यसनी व्यवहार

समाप्त/स्वीकार करें

संपूर्ण उपयोगकर्ता प्रवाह

चरण सूची और अपेक्षा

भंगुरता की संभावना

प्रतिगमन

पुरानी त्रुटि वापस नहीं आ रही

दोष विशिष्ट परीक्षण

प्रत्येक सुधार में जोड़ा जाना चाहिए

मिनी मामले

केस 1 - वह परीक्षा जो हमेशा उत्तीर्ण होती है। एआई एक फ़ंक्शन के लिए 12 परीक्षण लिखता है और वे सभी पास हो जाते हैं। इंजीनियर को संदेह हो जाता है और वह जानबूझकर फ़ंक्शन के रिटर्न मान को विकृत कर देता है; केवल 3 परीक्षण ही लाल हुए। अन्य 9 परीक्षणों में सार्थक दावे नहीं हैं। उत्परिवर्तन शिकार द्वारा परीक्षण को मजबूत किया जाता है; वास्तविक सुरक्षा 9 परिदृश्यों में प्राप्त होती है।

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

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

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

• निरर्थक दावा. "कोई त्रुटि नहीं हुई" पर्याप्त नहीं है; सही मान सत्यापित किया जाना चाहिए.
• गुणवत्ता के साथ भ्रमित करने वाला दायरा। उच्च कवरेज सटीक परिणामों की कोई गारंटी नहीं है।
• कोड द्वारा परीक्षण प्रिंट करना। वर्तमान त्रुटि को "सही" पर ठीक करता है; परीक्षण अपेक्षा से प्राप्त होने चाहिए।
• सीमा मान छोड़ना। > के साथ >= को भ्रमित करना सबसे आम गलती है; सीमा युग्मों का परीक्षण किया जाना चाहिए।
• परीक्षण का ऑडिट ही नहीं किया जा रहा है। ऐसा परीक्षण जो कोड तोड़ने पर लाल नहीं होता, सुरक्षा प्रदान नहीं करता।

संक्षेप में

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

आवेदन कार्य

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

चेकलिस्ट

• [ ] मैंने परीक्षणों को अपेक्षित/सही व्यवहार के आधार पर मुद्रित किया, कोड के आधार पर नहीं।
• [ ] मैंने सामान्य, सीमा, नकारात्मक और त्रुटि परिदृश्यों को कवर किया।
• [ ] मैंने प्रत्येक परीक्षण में ठोस अपेक्षित मूल्य पर जोर दिया।
• [ ] मैंने बॉर्डर जोड़े का परीक्षण किया (ठीक ऊपर-नीचे / ठीक ऊपर-नीचे)।
• [ ] जानबूझकर कोड तोड़कर, मैंने पुष्टि की कि परीक्षण लाल हो गए।
• [ ] मैंने अज्ञात उत्परिवर्तनों के लिए एक नया परीक्षण जोड़ा है।