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