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