लाभ:
- सीआई/सीडी के संदर्भ में विचार से लेकर रिलीज तक एंड-टू-एंड क्यूए प्रवाह में कृत्रिम बुद्धिमत्ता और मानव अनुमोदन बिंदुओं की भूमिका को डिजाइन करने की क्षमता
- सीआई/सीडी में, एआई को परीक्षण को स्वचालित रूप से 'पास' करने के लिए अधिकृत नहीं किया जा रहा है, बल्कि गोपनीय डेटा और कुंजियों की सुरक्षा के लिए सीमाएं लागू की जा रही हैं
- प्राधिकरण के भीतर और रक्षात्मक उद्देश्यों के लिए सुरक्षा परीक्षण करने की क्षमता, और जिम्मेदार प्रकटीकरण और नैतिक पारदर्शिता सिद्धांतों को अपनाने की क्षमता।
पिछली दस इकाइयों में, हमने व्यक्तिगत कार्यों में एआई का उपयोग किया: परिदृश्य निर्माण, स्वचालन कोड, बग रिपोर्टिंग, कवरेज विश्लेषण, उत्परिवर्तन परीक्षण। यह अंतिम इकाई उन सभी को एक जिम्मेदार वर्कफ़्लो में जोड़ती है। आधुनिक QA कोई ऐसा काम नहीं है जो एक व्यक्ति के डेस्क पर समाप्त हो जाए; यह एक प्रक्रिया है जो सीआई/सीडी (कंटीन्यूअस इंटीग्रेशन/कंटीन्यूअस डिलीवरी - पाइपलाइन जहां कोड लगातार संयुक्त होता है, स्वचालित रूप से परीक्षण किया जाता है और बार-बार और सुरक्षित रूप से प्रकाशन के लिए तैयार किया जाता है) के भीतर रहता है। एआई इस प्रक्रिया के हर चरण को छू सकता है। लेकिन जैसे-जैसे एआई की शक्ति बढ़ती है, वैसे-वैसे इसे जिम्मेदारी से उपयोग करने का महत्व भी बढ़ता है: गोपनीयता, सुरक्षा परीक्षण में अधिकार, नैतिकता, और सबसे महत्वपूर्ण बात, गुणवत्ता निर्णय को मानव तक बनाए रखना। इस इकाई में, आप अंत-से-अंत प्रवाह और सीमाएँ सीखेंगे।
एंड-टू-एंड एआई-संचालित क्यूए प्रवाह
किसी फीचर की विचार से रिलीज़ तक की यात्रा में एआई की भूमिका:
1. आवश्यकताएँ विश्लेषण। एआई आवश्यकताओं और अनुपलब्ध स्वीकृति मानदंडों में अस्पष्टताओं को चिह्नित करता है ("यह नियम यह नहीं बताता है कि पासवर्ड में न्यूनतम कितने अक्षर हैं")।
2. परीक्षण डिजाइन. परिदृश्य और केस ड्राफ्ट (यूनिट 2), एज केस (यूनिट 3) स्वीकृति मानदंडों में से हैं।
3. स्वचालन. यूनिट (6), एपीआई (5) और यूआई (4) परीक्षण कोड ड्राफ्ट; प्रत्येक की पुष्टि उत्परिवर्तन (10) द्वारा की जाती है।
4. सीआई/सीडी एकीकरण। प्रत्येक कोड मर्ज के साथ परीक्षण स्वचालित रूप से चलते हैं। एआई ड्राफ्ट पाइपलाइन कॉन्फ़िगरेशन (वाईएएमएल), विफल परीक्षणों के लॉग का सारांश देता है, संभावित मूल कारण सुझाता है।
5. रिहाई का निर्णय. जोखिम विश्लेषण (8) और प्रतिगमन (9) परिणाम एकत्र किए जाते हैं - लेकिन विशेषज्ञ तय करता है कि यह सफल हो सकता है या नहीं।
6. उत्पादन निगरानी और प्रतिक्रिया। लाइव में त्रुटियाँ भविष्य की परीक्षाएँ बन जाती हैं; एआई विनिर्माण दोष से प्रतिगमन मामले का प्रस्ताव करता है।
युक्ति: एआई को सीआई/सीडी में एक परत के रूप में स्थापित करें जो "परीक्षण लिखने और निर्णय लेने" के बजाय "मानव-समीक्षित ड्राफ्ट को तेज करता है"। किसी भी स्वचालित रूप से उत्पन्न परीक्षण को मानव समीक्षा और अनुमोदन के बिना पाइपलाइन में प्रवेश नहीं करना चाहिए।
सीआई/सीडी में एआई: कहां हां, कहां नहीं
मंच
एआई फिट
मानव आवश्यक है
टेस्ट कोड ड्राफ्ट
हाँ
संशोधन + उत्परिवर्तन
पाइपलाइन YAML ड्राफ्ट
हाँ
प्रमाणीकरण + गुप्त कुंजी जाँच
विफल लॉग सारांश
हाँ
मूल कारण की पुष्टि
नाजुक परीक्षण निदान
हाँ
स्थाई समाधान का निर्णय
"क्या इसका कोई संस्करण हो सकता है?"
नहीं
विशेषज्ञ निर्णय और जिम्मेदारी
परीक्षण को स्वचालित रूप से "पास" करें
कभी नहीं
—
सावधानी: सीआई/सीडी में एआई को कभी भी "असफल परीक्षा पास करने के लिए इसे ठीक करें" जैसा आदेश न दें। इससे परीक्षण का उद्देश्य विफल हो जाता है और स्वचालित रूप से त्रुटियाँ छिप जाती हैं। एआई त्रुटि की व्याख्या कर सकता है, सुधार का सुझाव दे सकता है; लेकिन "परीक्षण को हरा रंगना" एक व्यक्ति का सचेत, तर्कसंगत निर्णय होना चाहिए।
गोपनीयता, डेटा और सुरक्षा: अपरिवर्तनीय सीमाएँ
गोपनीयता. परीक्षण परिवेश में, वास्तविक ग्राहक डेटा, उत्पादन डेटाबेस प्रतियां, एपीआई कुंजी और आंतरिक सिस्टम जानकारी संवेदनशील होती हैं। इन्हें सार्वजनिक AI टूल को न दें। व्यक्तिगत डेटा KVKK और समान नियमों के अधीन है; मास्क लॉग और स्क्रीनशॉट। जहां भी संभव हो सिंथेटिक (काल्पनिक) परीक्षण डेटा का उपयोग करें।
सुरक्षा परीक्षण - रक्षात्मक और अधिकृत। इस मॉड्यूल में सीखे गए सुरक्षा परीक्षण (प्राधिकरण/आईडीओआर परीक्षण, फ़ाइल अपलोड सीमाएं, इनपुट सत्यापन) केवल लिखित प्राधिकरण और परिभाषित दायरे के भीतर आपके अपने उत्पाद का परीक्षण करने के लिए हैं। बिना अनुमति के किसी और के सिस्टम तक पहुंचने के लिए एआई का उपयोग करना, वास्तविक कमजोरियों को हथियार बनाना, या दायरे से बाहर परीक्षण करना अनैतिक और अवैध दोनों है। जब आपको कोई सुरक्षा भेद्यता मिलती है, तो जिम्मेदार प्रकटीकरण के सिद्धांत का पालन करें - भेद्यता को गोपनीय रखें और संबंधित पक्ष को इसकी रिपोर्ट करें ताकि इसे ठीक किया जा सके।
नैतिकता और पारदर्शिता. एआई द्वारा उत्पादित परीक्षणों को अपने काम के रूप में प्रस्तुत न करें; यह कहना कि आप टीम के भीतर एआई का उपयोग कर रहे हैं, पारदर्शिता है। एआई-निर्मित आउटपुट की अशुद्धि के लिए आप जिम्मेदार हैं - "एआई ने इसे लिखा है" कोई बहाना नहीं है।
कमजोर संकेत/मजबूत संकेत
कमजोर: "सीआई के लिए परीक्षण पाइपलाइन स्थापित करें।"
मजबूत: "गिटहब क्रियाओं के लिए एक सीआई वर्कफ़्लो वाईएएमएल का मसौदा तैयार करें: प्रत्येक पीआर पर यूनिट + एपीआई परीक्षण चलाएं, कवरेज रिपोर्ट तैयार करें, उत्परिवर्तन परीक्षण (स्ट्राइकर) साप्ताहिक चलाएं। कोड में रहस्यों को एम्बेड न करें; केवल रहस्य संदर्भ का उपयोग करें। यदि परीक्षण लाल हैं तो मर्ज को ब्लॉक करें। यह एक ड्राफ्ट है; मैं गुप्त कुंजी प्रबंधन और सत्यापन चरणों की समीक्षा और संपादन करूंगा। एक स्वचालित परीक्षण 'फिक्स' या 'माइग्रेट' चरण न जोड़ें।"
शक्तिशाली संकेत; यह गोपनीयता, मानवीय समीक्षा और "कोई स्वचालित परीक्षण नहीं" पर सीमाएं लगाता है।
चार प्रतिलिपि योग्य टेम्पलेट
1) एंड-टू-एंड परीक्षण योजना:
आपकी भूमिका: वरिष्ठ क्यूए नेता। निम्नलिखित सुविधा के लिए विचार से रिलीज तक एक एंड-टू-एंड परीक्षण योजना का मसौदा तैयार करें: [सुविधा + स्वीकृति मानदंड]। चरण: आवश्यकताओं का विश्लेषण (अनिश्चितताएं), परीक्षण डिजाइन, स्वचालन परतें (यूनिट/एपीआई/यूआई), सीआई/सीडी एकीकरण, रिलीज निर्णय मानदंड, उत्पादन ट्रैकिंग। प्रत्येक चरण में AI और HUMAN अनुमोदन बिंदुओं की भूमिका अलग से निर्दिष्ट करें।
2) सीआई/सीडी पाइपलाइन रूपरेखा:
[GitHub Actions/GitLab CI/Azure पाइपलाइन] के लिए CI YAML ड्राफ्ट:- यूनिट + एपीआई टेस्ट + पीआर में स्कोप- रेड टेस्ट में मर्ज को रोकें- केवल रहस्यों के साथ गुप्त मान; कोड में एम्बेड करना यह एक ड्राफ्ट है; मैं प्रमुख प्रबंधन और अनुमोदन चरणों की समीक्षा करूंगा। एक स्वत: सुधार/पास परीक्षण चरण जोड़ा जा रहा है।
3) असफल परीक्षण लॉग विश्लेषण:
उस सीआई प्रिंटआउट में, परीक्षण लाल हैं। लॉग की जांच करें; विफलताओं को समूहित करें, संभावित मूल कारण को अलग करें और कौन सा वास्तविक विफलता हो सकता है और कौन सा एक नाजुक परीक्षण/पर्यावरण मुद्दा हो सकता है। यदि व्यक्तिगत डेटा है, तो उसे छिपाएँ। निर्णय और सुधार मेरा होगा. लॉग: [चिपकाएँ]
4) सुरक्षा/गोपनीयता की पूर्व जांच:
इससे पहले कि यह परीक्षण डेटा/लॉग एआई टूल पर भेजा जाए, जांचें: क्या इसमें व्यक्तिगत डेटा, एपीआई कुंजी, आंतरिक सिस्टम पता, उत्पादन डेटा शामिल है? सूचीबद्ध करें कि किन क्षेत्रों को, यदि कोई हो, ढकने/हटाने की आवश्यकता है। जैसा है वैसा ही प्रसंस्करण। सामग्री: [चिपकाएं]
तीन मिनी मामले
केस 1 - एंड-टू-एंड प्रवाह की गति। एक टीम ने एआई-पावर्ड एंड-टू-एंड फ्लो के साथ एक नई "सदस्यता नवीनीकरण" सुविधा का सामना किया: आवश्यकता अनिश्चितताओं को सामने लाया गया, तीन-परत परीक्षणों का मसौदा तैयार किया गया और उत्परिवर्तन-सत्यापित किया गया, जो सीआई से जुड़ा हुआ था। सुविधा ने परीक्षण चक्र को कम कर दिया, जिसमें पारंपरिक प्रक्रिया में 5 दिन लगते थे, 2 दिन तक; लेकिन हर चरण में मानवीय अनुमोदन को संरक्षित रखा गया था, और आवश्यकताओं की अनिश्चितता (रीफ्रेश विफल होने पर क्या होगा) को प्री-लाइव बंद कर दिया गया था।
केस 2 - कुंजी लीक से वापसी। एक डेवलपर के पास AI जेनरेट CI YAML था, और AI ने उदाहरण के तौर पर YAML में एक वास्तविक दिखने वाली API कुंजी को एम्बेड किया था। "सुरक्षा/गोपनीयता प्रीचेक" चरण ने इसे पकड़ लिया; कुंजी को रहस्य संदर्भ में परिवर्तित किया गया। ऑडिट चरण के बिना, कुंजी संस्करण नियंत्रण (गिट इतिहास) में लीक हो जाएगी।
केस 3 - अधिकार की सीमा। टीम का एक सदस्य "मैं उत्सुक था" से सीखे गए आईडीओआर परीक्षण को एक बिजनेस पार्टनर के लाइव सिस्टम पर लागू करना चाहता था। क्यूए नेता ने रोक दिया: लिखित प्राधिकरण और परिभाषित दायरे के बिना किसी अन्य सिस्टम पर सुरक्षा परीक्षण करना अवैध है। परीक्षण केवल उनके अपने उत्पादों के परीक्षण वातावरण में, अधिकार के साथ किया गया था; खुले जिम्मेदार पक्ष को संबंधित टीम को सूचित किया गया।
सामान्य गलतियाँ
- एआई को रिलीज संबंधी निर्णय लेना। प्रश्न पूछना "क्या इसे जारी किया जा सकता है?" एआई को और हस्ताक्षर के स्थान पर उत्तर डालना।
- स्वचालित परीक्षण "उत्तीर्ण"। सीआई में, एआई द्वारा परीक्षण को हरा रंग देना; गलतियों को छुपाना.
- वाहन को गोपनीय डेटा/चाबी देना। पर्यवेक्षण के बिना उत्पादन डेटा, व्यक्तिगत डेटा या एपीआई कुंजी साझा करना।
- अनधिकृत सुरक्षा परीक्षण. हमलावर बिना दायरे और अनुमति के किसी अन्य सिस्टम पर परीक्षण कर रहा है।
- समीक्षा के बिना पाइपलाइन में परीक्षण प्रस्तुत करना। मानव अनुमोदन के बिना एआई स्केच को स्वचालित रूप से चलाएं।
- एआई पर दोष मढ़ना। "एआई ने इसे लिखा है" कहकर गलत आउटपुट का बचाव किया।
सारांश
एंड-टू-एंड क्यूए एक ऐसी प्रक्रिया है जो आवश्यकताओं से लेकर उत्पादन ट्रैकिंग तक फैली हुई है और सीआई/सीडी के भीतर रहती है; हर चरण में, एआई ड्राफ्ट तैयार करता है, लॉग का सारांश देता है, और मूल कारण सुझाता है। लेकिन सीमाएँ अपरिवर्तनीय हैं: मनुष्य परीक्षण संबंधी निर्णय लेते हैं और अनुमोदन जारी करते हैं; एआई को कभी भी परीक्षण को स्वचालित रूप से "पास" करने का अधिकार नहीं दिया जाता है; गोपनीय डेटा और चाबियाँ वाहन में प्रवेश नहीं करतीं; सुरक्षा परीक्षण केवल आपके अपने उत्पाद पर, लिखित प्राधिकरण और परिभाषित दायरे के भीतर, रक्षात्मक उद्देश्यों के लिए किया जाता है, और निष्कर्षों को जिम्मेदार प्रकटीकरण के साथ रिपोर्ट किया जाता है। जब आप एआई का उपयोग करें तो पारदर्शी रहें; आउटपुट की सटीकता के लिए आप जिम्मेदार हैं। एआई में तेजी आती है; आप गुणवत्ता और नैतिकता की प्रतिज्ञा करते हैं।
आवेदन कार्य
अपने स्वयं के प्रोजेक्ट की एक सुविधा के लिए "एंड-टू-एंड टेस्ट प्लान" टेम्पलेट के साथ विचार से जारी करने तक की योजना का मसौदा तैयार करें; प्रत्येक चरण में एआई की भूमिका और मानव अनुमोदन बिंदुओं को अलग-अलग चिह्नित करें। फिर "CI/CD पाइपलाइन रूपरेखा" के साथ एक YAML उत्पन्न करें और एम्बेडेड कुंजी/गुप्त डेटा की जांच के लिए इस YAML पर "सुरक्षा/गोपनीयता प्रीचेक" लागू करें। अंत में, अपनी योजना में सभी "मानवीय निर्णय" बिंदुओं को सूचीबद्ध करें और एक वाक्य में बताएं कि इन निर्णयों को एआई को क्यों नहीं सौंपा जा सकता है।
चेकलिस्ट
- [ ] मैं रिलीज़ और परीक्षण निर्णयों का श्रेय मानवीय अनुमोदन को देता हूँ; मैंने इसे एआई को नहीं सौंपा।
- [ ] सीआई/सीडी में मैंने एआई को परीक्षण को स्वचालित रूप से "पास/सही" करने की अनुमति नहीं दी।
- [ ] मैंने वाहन में भेजने से पहले गोपनीय डेटा, व्यक्तिगत डेटा और चाबियों की जांच की और उन्हें छिपा दिया।
- [ ] मैंने केवल लिखित प्राधिकरण और दायरे के भीतर, अपने उत्पाद पर सुरक्षा परीक्षण पर विचार किया है।
- [ ] मैंने जिम्मेदार प्रकटीकरण के सिद्धांत के साथ पाई गई कमजोरियों को संबोधित किया।
- [ ] मैंने पारदर्शी रूप से कहा कि मैंने एआई का उपयोग किया और आउटपुट की सटीकता के लिए खुद को जिम्मेदार ठहराया।
मॉड्यूल परीक्षा
1. क्यूए संदर्भ में 'गलत पास' को सबसे सटीक रूप से कैसे परिभाषित किया गया है?
- ए) यद्यपि परीक्षण हरा हो जाता है, यह वास्तव में किसी भी व्यवहार की पुष्टि नहीं करता है; ✔कोड खराब होने पर भी लाल नहीं होता
- बी) परीक्षण बहुत धीमी गति से चलता है और समय समाप्त हो जाता है।
- सी) परीक्षण एक वास्तविक त्रुटि का पता लगाता है और लाल हो जाता है
- डी) परीक्षण केवल उत्पादन परिवेश में चलता है
स्पष्टीकरण: छद्म पास तब होता है जब कोई परीक्षण 'पास' कहता है लेकिन वास्तव में किसी भी सार्थक बात की पुष्टि नहीं करता है; परीक्षण हरा है, लेकिन सॉफ़्टवेयर दोषपूर्ण होने पर भी यह इसे पकड़ नहीं पाएगा। यह क्यूए में एआई का नंबर एक जोखिम है क्योंकि एआई ऐसे परीक्षण तैयार करता है जो साफ-सुथरे दिखते हैं लेकिन खोखले होते हैं।
2. परीक्षण और QA प्रक्रिया में कृत्रिम बुद्धिमत्ता की सबसे सटीक स्थिति क्या है?
- ए) आर्टिफिशियल इंटेलिजेंस यह तय कर सकता है कि संस्करण को मानव अनुमोदन के बिना जारी किया जा सकता है या नहीं
- बी) कृत्रिम बुद्धिमत्ता एक सहायक है जो ड्राफ्ट और विचार उत्पन्न करती है; 'क्या यह प्रकाशन के लिए तैयार है' का निर्णय और जिम्मेदारी विशेषज्ञ ✔ की है
- सी) आर्टिफिशियल इंटेलिजेंस केवल पाठ लिखता है और परीक्षण कोड से बिल्कुल भी निपट नहीं सकता है
- डी) कृत्रिम बुद्धिमत्ता हमेशा मानव की तुलना में सही परीक्षण लिखती है, इसलिए समीक्षा अनावश्यक है
विवरण: आर्टिफिशियल इंटेलिजेंस एक परीक्षण सहायक, ड्राफ्ट जनरेटर और विचार गुणक है; परीक्षण परिदृश्य, स्वचालन कोड और रिपोर्ट ड्राफ्ट तैयार करता है। हालाँकि, 'क्या यह सॉफ़्टवेयर प्रकाशन के लिए तैयार है' या 'क्या यह परीक्षण उत्तीर्ण हुआ है' जैसे गुणवत्ता निर्णयों की ज़िम्मेदारी और अंतिम अनुमोदन सक्षम विशेषज्ञ का है।
3. इस तथ्य के आधार पर कि त्रुटियां अधिकतर सीमा मूल्यों पर होती हैं, 18 आयु सीमा के लिए 17, 18 और 19 को अलग-अलग परीक्षण करने के लिए कौन सी परीक्षण डिजाइन तकनीक है?
- ए) राज्य संक्रमण परीक्षण
- बी) निर्णय तालिका
- सी) सीमा मूल्य विश्लेषण ✔
- डी) खोजपूर्ण परीक्षण
स्पष्टीकरण: सीमा मूल्य विश्लेषण इस अवलोकन पर आधारित है कि त्रुटियां सबसे अधिक बार सीमाओं पर होती हैं और थ्रेशोल्ड मानों (सीमा के ठीक नीचे, ठीक ऊपर और सीमा के ठीक ऊपर) का अलग-अलग परीक्षण किया जाता है। यह एक शक्तिशाली तकनीक है जो समतुल्य वर्गों का पूरक है।
4. कृत्रिम बुद्धिमत्ता से निर्मित यूआई परीक्षण स्वचालन कोड में नाजुकता को कम करने के लिए तत्व चयन में किस दृष्टिकोण को प्राथमिकता दी जानी चाहिए?
- ए) संभव सबसे लंबे XPath पथ का उपयोग करना
- बी) स्क्रीन पर उसकी पिक्सेल स्थिति के अनुसार तत्व का चयन करना
- सी) सीएसएस वर्ग नामों के आधार पर चयनकर्ताओं का उपयोग करना
- डी) परीक्षण के लिए जोड़ी गई स्थिर विशेषताओं (डेटा-टेस्टिड) का उपयोग करना ✔
स्पष्टीकरण: लंबे XPath पथ और CSS वर्ग के नाम पृष्ठ संरचना और डिज़ाइन पर अत्यधिक निर्भर हैं; यह थोड़े से इंटरफ़ेस परिवर्तन पर टूट जाता है। परीक्षण के लिए विशेष रूप से जोड़े गए स्थिर गुण (उदाहरण के लिए डेटा-टेस्टिड) डिज़ाइन परिवर्तनों से प्रभावित नहीं होते हैं और परीक्षणों को मजबूत बनाते हैं।
5. एपीआई परीक्षण के लिए केवल HTTP स्थिति कोड (जैसे 200) की जांच करना अपर्याप्त क्यों है?
- ए) क्योंकि सही स्थिति कोड वाला मुख्य डेटा दूषित हो सकता है और अकेले स्थिति जांच से यह (छद्म-विश्वास) पकड़ में नहीं आएगा ✔
- बी) क्योंकि एपीआई परीक्षणों में स्थिति कोड बिल्कुल भी विश्वसनीय नहीं होते हैं
- सी) क्योंकि स्टेटस कोड जांचने से परीक्षण बहुत धीमा हो जाता है
- डी) क्योंकि एपीआई परीक्षणों में स्टेटस कोड कभी वापस नहीं आता है
स्पष्टीकरण: जबकि सर्वर सही स्थिति कोड लौटाता है, यह मुख्य भाग में दूषित डेटा (गलत प्रकार, गायब फ़ील्ड, गलत गणना मूल्य) लौटा सकता है। जो परीक्षण केवल स्थिति को देखता है वह इसे नहीं देख सकता और झूठा विश्वास देता है। इसलिए स्कीमा/अनुबंध और व्यावसायिक नियम सत्यापन भी जोड़ा जाना चाहिए।
6. मुद्रण इकाई परीक्षण करते समय एआई को 'स्वीकृति नियम के अनुसार अपेक्षित मूल्य की मैन्युअल रूप से गणना करने, फ़ंक्शन के वर्तमान आउटपुट का संदर्भ न देने' के लिए कहना महत्वपूर्ण क्यों है?
- ए) क्योंकि मैनुअल गणना तेजी से परीक्षण चलाती है
- बी) क्योंकि अन्यथा परीक्षण कोड के वर्तमान (शायद छोटी गाड़ी) व्यवहार को 'सही' के रूप में स्वीकार करता है और बग की पुष्टि करता है ✔
- C) क्योंकि कृत्रिम बुद्धिमत्ता दशमलव संख्याओं की गणना ही नहीं कर सकती
- डी) क्योंकि परीक्षणों में स्वीकृति नियमों का कभी भी उपयोग नहीं किया जाता है
स्पष्टीकरण: यदि एआई परीक्षण के तहत फ़ंक्शन के आउटपुट से अपेक्षित मूल्य प्राप्त करता है, तो यह फ़ंक्शन दोषपूर्ण होने पर भी परीक्षण को 'पास' कर देगा; अर्थात्, कोड जो भी उत्पन्न करता है, परीक्षण सत्य माना जाता है। स्वीकृति नियम से स्वतंत्र रूप से अपेक्षित मूल्य की गणना यह सुनिश्चित करती है कि परीक्षण नियम का द्वारपाल है, कोड का दर्पण नहीं।
7. निम्नलिखित में से कौन सी एक अच्छी बग रिपोर्ट की सबसे विशिष्ट विशेषता है?
- ए) यथासंभव लंबा और तकनीकी होना
- बी) कृत्रिम बुद्धि द्वारा लिखित
- सी) इसमें नियतात्मक पुनरुत्पादन चरण शामिल हैं जिनका डेवलपर स्वतंत्र रूप से पालन कर सकता है और त्रुटि ✔ उत्पन्न कर सकता है
- डी) यह सिर्फ एक स्क्रीनशॉट है
स्पष्टीकरण: बग रिपोर्ट का वास्तविक मूल्य यह है कि डेवलपर आपकी मदद के बिना बग को पुन: उत्पन्न कर सकता है। शुरुआत से ही नियतात्मक, पता लगाने योग्य पुनरुत्पादन चरण इसे सुनिश्चित करते हैं; यदि ये चरण गायब हैं, तो रिपोर्ट अक्सर 'उत्पादन नहीं किया जा सका' के रूप में बंद हो जाती है।
8. होम पेज पर कंपनी के नाम की गलत वर्तनी की त्रुटि में गंभीरता और प्राथमिकता के बीच संबंध के लिए सबसे सटीक अभिव्यक्ति कौन सी है?
- ए) तीव्रता और प्राथमिकता का मूल्य हमेशा समान होना चाहिए
- बी) इस त्रुटि की गंभीरता और प्राथमिकता दोनों निश्चित रूप से कम हैं
- सी) गंभीरता और प्राथमिकता एक ही अवधारणा हैं, एक लेबल पर्याप्त है
- डी) तकनीकी तीव्रता कम हो सकती है लेकिन व्यावसायिक प्राथमिकता (प्रतिष्ठा) अधिक हो सकती है; दोनों का मूल्यांकन अलग-अलग किया जाता है ✔
स्पष्टीकरण: गंभीरता त्रुटि का तकनीकी प्रभाव है (टाइपो तकनीकी रूप से कम है), प्राथमिकता यह है कि इसे कितनी तत्काल ठीक करने की आवश्यकता है (उच्च क्योंकि यह एक प्रतिष्ठा तत्व है जिसे प्रत्येक आगंतुक देखता है)। दोनों हमेशा एक ही दिशा में नहीं जाते; यह उदाहरण कम गंभीरता-उच्च प्राथमिकता वाली स्थिति है।
9. 90% लाइन कवरेज वाले परीक्षण सूट की सबसे सटीक व्याख्या कौन सी है?
- ए) यह दर्शाता है कि लाइनें निष्पादित हैं लेकिन यह साबित नहीं करती हैं कि वे सही ढंग से व्यवहार करती हैं; ✔उच्च कवरेज झूठा आत्मविश्वास दे सकता है
- बी) निर्णायक रूप से साबित करता है कि 90% सॉफ्टवेयर बग-मुक्त है
- सी) यह उत्कृष्ट परीक्षण गुणवत्ता का एक निश्चित उपाय है।
- डी) इंगित करता है कि अब कोई अतिरिक्त परीक्षण लिखने की आवश्यकता नहीं है
स्पष्टीकरण: पंक्ति कवरेज इंगित करता है कि केवल पंक्तियों को निष्पादित किया गया था; इससे यह सिद्ध नहीं होता कि यह सही परिणाम देता है। यहां तक कि बिना दावे वाले परीक्षणों से भी 90% कवरेज हासिल किया जा सकता है। स्कोप एक 'कभी भी कहाँ नहीं देखा' मानचित्र है, न कि 'हर चीज़ का परीक्षण किया गया है' आश्वासन; वास्तविक सुरक्षा उत्परिवर्तन परीक्षण द्वारा मापी जाती है।
10. जोखिम-आधारित परीक्षण में, सीमित परीक्षण प्रयास को निर्देशित करने के लिए किसी सुविधा के जोखिम की गणना कैसे की जाती है?
- ए) केवल कोड की पंक्तियों की संख्या से
- बी) विफलता की संभावना और इसके टूटने पर होने वाले प्रभाव को गुणा करके ✔
- सी) केवल उसी क्रम में जिसमें सुविधा विकसित की गई थी
- डी) केवल उस सुविधा को प्राथमिकता देना जिसके लिए परीक्षण लिखना सबसे आसान है
स्पष्टीकरण: जोखिम-आधारित परीक्षण में, जोखिम का मूल्यांकन संभाव्यता = संभाव्यता (टूटने की संभावना) × प्रभाव (टूटे होने पर क्षति) के रूप में किया जाता है। उच्च संभावना और उच्च प्रभाव वाले डोमेन (भुगतान, प्रमाणीकरण) सबसे गहन परीक्षण के पात्र हैं, जबकि निम्न×निम्न डोमेन को हल्का परीक्षण प्राप्त होता है।
11. किसी परीक्षण में पुनः प्रयास जोड़ने का मुख्य जोखिम क्या है जो कभी-कभी पास हो जाता है और कभी-कभी विफल हो जाता है (भंगुर/परतदार) भले ही कोड नहीं बदला हो?
- ए) परीक्षण के चलने के समय को छोटा करना
- बी) कवरेज प्रतिशत कम हो जाता है
- सी) एक वास्तविक समवर्ती त्रुटि या मूल कारण को छिपाना और लक्षण को दबाना ✔
- डी) परीक्षण का नाम बदलना
स्पष्टीकरण: पुनः प्रयास एक निदान उपकरण है, उपचार नहीं। अनिर्णय अक्सर वास्तविक नस्ल की स्थिति या लत से आता है; पुनः प्रयास करके परीक्षण को 'पास' करने से यह वास्तविक त्रुटि छिप जाती है और इससे जीवन में गंभीर समस्याएं पैदा हो सकती हैं। सबसे पहले मूल कारण खोजा जाना चाहिए।
12. उत्परिवर्तन परीक्षण, यह मापने का सबसे ईमानदार तरीका कि परीक्षण सूट वास्तव में सुरक्षा करता है या नहीं, कैसे काम करता है?
- ए) परीक्षणों की चलने की गति को मापकर
- बी) कोड की कितनी पंक्तियाँ लिखी गईं, इसकी गिनती करके
- सी) विभिन्न क्रमों में परीक्षण चलाकर
- डी) जानबूझकर कोड में छोटे-छोटे ब्रेक बनाकर और यह मापकर कि क्या परीक्षण उन्हें पकड़ पाते हैं ✔
विवरण: उत्परिवर्तन परीक्षण स्रोत कोड में छोटी जानबूझकर विकृतियाँ (उत्परिवर्तन) उत्पन्न करता है; एक अच्छे परीक्षण सूट को इन विकृतियों को पकड़ना चाहिए और लाल हो जाना चाहिए। उत्परिवर्तन जो पकड़े नहीं गए (बचे हुए) संकेत देते हैं कि परीक्षण उस व्यवहार को संरक्षित नहीं करते हैं। म्यूटेशन स्कोर प्रतिशत कवरेज की तुलना में गुणवत्ता का कहीं अधिक ईमानदार माप है।
13. सुरक्षा परीक्षण (जैसे प्राधिकरण/आईडीओआर परीक्षण) करते समय पालन की जाने वाली मुख्य सीमा क्या है?
- ए) इसे केवल अपने उत्पाद पर, लिखित प्राधिकरण और परिभाषित दायरे के भीतर, रक्षात्मक उद्देश्यों के लिए किया जाना चाहिए ✔
- बी) इसे रुचि की किसी भी प्रणाली पर स्वतंत्र रूप से लागू किया जा सकता है
- C) इसे बिना अनुमति के बिजनेस पार्टनर्स के लाइव सिस्टम पर आज़माया जा सकता है
- डी) पाई गई किसी भी कमज़ोरी को तुरंत सार्वजनिक रूप से प्रकाशित किया जाना चाहिए।
विवरण: इस मॉड्यूल में सीखे गए सुरक्षा परीक्षण केवल लिखित प्राधिकरण और परिभाषित दायरे के भीतर रक्षात्मक उद्देश्यों के लिए आपके स्वयं के उत्पाद का परीक्षण करने के लिए हैं। बिना अनुमति के किसी और के सिस्टम तक पहुँचना या दायरे से बाहर परीक्षण करना अनैतिक और अवैध दोनों है; पाई गई किसी भी कमज़ोरी को जिम्मेदार प्रकटीकरण के माध्यम से रिपोर्ट किया जाता है।
14. सीआई/सीडी पाइपलाइन में एआई को कौन सा अधिकार कभी नहीं दिया जाना चाहिए?
- ए) असफल परीक्षण लॉग का सारांश
- बी) असफल (लाल) परीक्षण को स्वचालित रूप से 'पास' करने या उसे हरे रंग में रंगने का अधिकार ✔
- सी) एक परीक्षण कोड ड्राफ्ट का सुझाव देना
- डी) पाइपलाइन वाईएएमएल फ़ाइल प्रारूपण
विवरण: AI परीक्षण कोड रूपरेखा, पाइपलाइन YAML और CI/CD में लॉग सारांश तैयार कर सकता है; हालाँकि, किसी असफल परीक्षा को स्वचालित रूप से 'पास/ठीक' करने की क्षमता कभी नहीं दी जानी चाहिए। इससे परीक्षण का उद्देश्य विफल हो जाता है और स्वचालित रूप से त्रुटियाँ छिप जाती हैं। परीक्षण को हरे रंग से रंगना एक व्यक्ति का सचेत और तर्कसंगत निर्णय होना चाहिए।