परीक्षण परिदृश्य र परीक्षण केस जेनेरेसन: आवश्यकता देखि व्यापक नियन्त्रण सम्म — सफ्टवेयर परीक्षण र QA मा कृत्रिम बुद्धिमत्ता

लाभ:

आवश्यकता र स्वीकृति मापदण्डलाई आर्टिफिसियल इन्टेलिजेन्सको सहयोगमा इक्विभेलेन्स क्लासहरू, सीमा मूल्य विश्लेषण र निर्णय तालिकाहरू जस्ता प्रविधिहरूको साथ व्यापक परीक्षण केसहरूमा रूपान्तरण गर्ने क्षमता।
सकारात्मक, नकारात्मक र किनारा केस परिदृश्यहरू अलग-अलग उत्पादन गर्ने क्षमता र उत्पादन जानकारीको साथ कृत्रिम बुद्धिमत्ता द्वारा छुटेको किनारा केसहरू पूरा गर्ने क्षमता।
स्वीकृति मापदण्डमा परीक्षण केसहरू जोडेर ट्रेसेबिलिटी स्थापना गर्ने र कभरेज अन्तर र अनावश्यक ब्लोट हटाउने क्षमता

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

यस एकाईमा, तपाईंले एआई समर्थनको साथ आवश्यकतालाई व्यापक तर अव्यवस्थित परीक्षण सुइटमा कसरी परिवर्तन गर्ने भनेर चरण-दर-चरण सिक्नुहुनेछ।

चरण द्वारा चरण: आवश्यकता देखि परीक्षण सेट सम्म

चरण 1 - आवश्यकता स्पष्ट गर्नुहोस्। AI लाई कच्चा आवश्यकता दिनु अघि स्वीकृति मापदण्डहरू (कामलाई "सम्पन्न" मानिने शर्तहरू पूरा गर्नुपर्छ) सङ्कलन गर्नुहोस्। "पासवर्ड रिसेटयोग्य हुनुपर्छ" पर्याप्त छैन; "रिसेट लिङ्क ३० मिनेटको लागि मान्य छ", "उही पासवर्ड पुन: प्रयोग गर्न सकिँदैन" जस्ता नियमहरू वास्तविक परीक्षणको स्रोत हुन्।

चरण 2 - परीक्षण प्रविधिहरू लागू गर्नुहोस्। AI को बारेमा "स्क्रिप्ट लेख्नुहोस्" मात्र नभन्नुहोस्; नामद्वारा क्लासिक परीक्षण डिजाइन प्रविधिहरूको लागि सोध्नुहोस्:

समानता वर्गहरू (समानता विभाजन): समान व्यवहार उत्पादन गर्ने अपेक्षा गरिएका समूहहरूमा इनपुटहरू विभाजन गर्दै। उदाहरण को लागी, उमेर क्षेत्र को लागी, "वैध दायरा", "धेरै सानो", र "धेरै ठूलो" वर्गहरू हुन्; प्रत्येक कक्षाबाट एउटा उदाहरणको परीक्षण पर्याप्त छ।
सीमा मूल्य विश्लेषण: सीमाहरूमा त्रुटिहरू प्रायः हुन्छन् भन्ने तथ्यमा आधारित थ्रेसहोल्ड मानहरूको परीक्षण। यो 18 उमेर सीमा को लागी 17, 18, 19 अलग-अलग परीक्षण जस्तै हो।
निर्णय तालिका: धेरै सर्तहरूको तालिका संयोजन र प्रत्येक संयोजनको अपेक्षित परिणाम।
राज्य संक्रमण: राज्यबाट राज्यमा प्रणालीको संक्रमण परीक्षण गर्दै (उदाहरणका लागि, अर्डर: सिर्जना गरिएको → भुक्तान गरिएको → पठाइएको) र अवैध संक्रमणहरू।

चरण 3 - सकारात्मक, नकारात्मक, र किनारा राज्यहरू अलग गर्नुहोस्। सकारात्मक परीक्षणको लागि सोध्नुहोस् (सही इनपुटको साथ अपेक्षित परिणाम), नकारात्मक परीक्षण (अमान्य इनपुटको साथ उचित त्रुटि), र किनारा केस — सीमा रेखा वा असामान्य केसहरू। AI ले सामान्यतया सकारात्मकलाई जोड दिन्छ; तपाईंले स्पष्ट रूपमा अनुरोध नगरेसम्म नकारात्मक र किनारा केसहरू अपूर्ण छन्।

चरण 4 - प्राथमिकता दिनुहोस् र छाँट्नुहोस्। AI ले 60 परिदृश्यहरू उत्पन्न गर्न सक्छ; तिनीहरू सबै समान मूल्य होइनन्। उच्च जोखिम (पैसा, सुरक्षा, डाटा हानि) भएकाहरूलाई प्राथमिकता दिनुहोस् र नक्कलहरू मिलाउनुहोस्।

सुझाव: AI लाई "यस आवश्यकताबाट 5 अकल्पनीय किनारा केसहरू उत्पन्न गर्नुहोस्" भन्दै छुट्टै अनुरोध पठाउनुहोस्। AI को सबैभन्दा मूल्यवान योगदान यो हो कि यसले तपाईंलाई अक्सर बेवास्ता गरेको असाधारण परिस्थितिहरूको सम्झना गराउँछ।

कमजोर प्रम्प्ट / बलियो प्रम्प्ट

कमजोर: "पासवर्ड रिसेटको लागि परीक्षण केसहरू लेख्नुहोस्।"

बलियो: "निम्न स्वीकृति मापदण्डको साथ 'पासवर्ड रिसेट' सुविधाको लागि परीक्षण केसहरू उत्पन्न गर्नुहोस्: लिङ्क 30 मिनेटको लागि मान्य, एकल प्रयोग, अन्तिम 3 पासवर्डहरू पुन: प्रयोग गर्न सकिँदैन, 5 गलत प्रयासहरू पछि 15 मिनेटको लागि खाता लक गरियो। समानता वर्गहरू र सीमा मूल्य विश्लेषण लागू गर्नुहोस्। प्रत्येक सकारात्मक, नकारात्मक र पूर्व हेडिङ केसहरूमा अलग-अलग आईडी दिनुहोस्। चरणहरू, परीक्षण डेटा, अपेक्षित नतिजा, सम्बद्ध स्वीकृति मापदण्डहरू हाइलाइट सुरक्षा/लक परिदृश्यहरूले यसलाई लिन्छन्।"

शक्तिशाली प्रम्प्ट; यसले नियम, प्रविधि, आउटपुट ढाँचा र प्राथमिकता क्रम दिन्छ। यसरी, AI ले कार्यान्वयनयोग्य र ट्रेस गर्न मिल्ने परीक्षण केसहरू उत्पादन गर्छ, सजावटी होइन।

परीक्षण केस आउटपुट ढाँचा

एउटा संरचित ढाँचाको लागि सोध्नुहोस् जुन सिधै तपाईंको टोलीको परीक्षण व्यवस्थापन उपकरणमा आयात गर्न सकिन्छ (जस्तै TestRail, Zephyr, Xray)। निम्न तालिकाले राम्रो परीक्षण केसको घटकहरू देखाउँछ:

क्षेत्र

विवरण

उदाहरण

अद्वितीय आईडी

TC-PWD-014

शीर्षक

संक्षिप्त उद्देश्य

म्याद सकिएको लिङ्क अस्वीकार गरिनेछ

पूर्व शर्त

परीक्षण अघि शर्त आवश्यक छ

रिसेट लिङ्क 31 मिनेट पहिले उत्पन्न भएको थियो

चरणहरू

क्रमिक कार्यहरू

1. लिङ्कमा क्लिक गर्नुहोस् 2. नयाँ पासवर्ड प्रविष्ट गर्नुहोस्

परीक्षण डाटा

कंक्रीट मानहरू प्रयोग गरियो

पुरानो लिङ्क, नयाँ पासवर्ड "Abc! 2345"

अपेक्षित परिणाम

व्यवहार प्रमाणित गर्नुपर्छ

"लिङ्कको म्याद सकियो" त्रुटि, पासवर्ड परिवर्तन हुँदैन

स्वीकृति मापदण्ड

ट्रेसिबिलिटी लिंक

AK-3: लिङ्क ३० मिनेटको लागि मान्य छ

प्राथमिकता

जोखिम स्तर

उच्च

चार प्रतिलिपि गर्न मिल्ने टेम्प्लेटहरू

1) प्राविधिक आधारित परिदृश्य उत्पादन:

तपाईंको भूमिका: वरिष्ठ परीक्षण डिजाइनर।विशेषताका लागि परीक्षण केसहरू उत्पन्न गर्नुहोस्: [सुविधा र स्वीकृति मापदण्ड]।लागू गर्नुहोस्: समानता वर्गहरू, ब्रेकपोइन्ट विश्लेषण, निर्णय तालिका। 3 समूहहरूमा आउटपुट प्रदान गर्नुहोस्: सकारात्मक / नकारात्मक / किनारा केस। प्रत्येक केस: आईडी, पूर्व शर्त, चरणहरू, परीक्षण डेटा, अपेक्षित परिणाम, सम्बद्ध स्वीकृति मापदण्ड (LowM/L)।

2) किनारा केस शिकारी:

निम्न सुविधाका लागि 10 सामान्यतया बेवास्ता गरिएका किनारा केसहरू सूचीबद्ध गर्नुहोस्: [सुविधा]। एक वाक्यमा लेख्नुहोस् किन यो प्रत्येकको लागि जोखिमपूर्ण छ। खाली/नल, इनपुट धेरै लामो, कन्कर्रेन्सी, टाइमआउट, ढाँचा त्रुटिहरू, युनिकोड/इमोजी, नकारात्मक/शून्य, नेटवर्क आउटेज जस्ता अक्षहरूको बारेमा सोच्नुहोस्।

3) निर्णय तालिका उत्पादन:

निम्न व्यापार नियमको लागि निर्णय तालिका बनाउनुहोस्: [नियम]। स्तम्भहरू: अवस्था संयोजन; पङ्क्तिहरू: प्रत्येक अवस्था र अपेक्षित कार्य। फ्ल्याग गर्न नसकिने वा विवादित संयोजनहरू। त्यसपछि प्रत्येक संयोजनको लागि परीक्षण केस प्रस्ताव गर्नुहोस्।

4) ट्रेसबिलिटी नियन्त्रण:

स्वीकृति मापदण्ड र निम्न परीक्षण केसहरूको निम्न सूची दिइएको छ: [मापदण्ड] / [केसहरू]। कुन स्वीकृति मापदण्डहरू NO परीक्षण केसहरू (कभरेज ग्याप) द्वारा पूरा हुन्छन् र कुन मामिलाहरू कुनै पनि मापदण्ड (रिडन्डन्ट केस) द्वारा पूरा हुँदैनन् भनेर तालिकामा देखाउनुहोस्।

तीन मिनी केसहरू

केस १ — किनारा अवस्थाहरूको मान। फिनटेक टोलीका एक विशेषज्ञले पैसा हस्तान्तरण सुविधाको लागि 18 स्क्रिप्टहरू लेखेका थिए। उसले AI मा "एज केस हन्टर" टेम्प्लेट लागू गर्यो; एआईले "एकै समयमा दुई यन्त्रहरूबाट एउटै ब्यालेन्स स्थानान्तरण" (समस्या) को स्थितिलाई सम्झायो। जब यो परिदृश्य परीक्षण गरियो, दोहोरो खर्च जोखिम भेटियो र लाइभ हुनु अघि बन्द भयो। एकल फ्रिङ्ग अवस्थाले सम्भावित छ-अङ्कको हानिलाई रोक्यो।

केस 2 - बल्ज काट्दै। एउटा टोलीले एआईले सदस्यता फारमको लागि स्क्रिप्ट तयार गरेको थियो र 74 केसहरू आए। ट्रेसेबिलिटी टेम्प्लेट चलाउँदा 74 केसहरूले मात्र 9 स्वीकृति मापदण्डहरू पूरा गरेको फेला पर्यो, धेरैले समान समानता वर्गको पुन: परीक्षण गर्दै। सेट 74 बाट 23 महत्त्वपूर्ण केसहरूमा घटाइएको थियो; रन टाइम ६८% ले घट्यो, कभरेज घटेको छैन।

केस 3 - गलत धारणा। AI ले मिति फिल्डको लागि "फेब्रुअरी 31st" जस्ता अवैध मितिहरू परीक्षण गर्न सुझाव दियो, तर टोलीले प्रयोग गरिरहेको क्यालेन्डर कम्पोनेन्टले यसलाई पहिले नै अवरुद्ध गरेको थाहा थिएन। विज्ञले उत्पादनको सन्दर्भमा अनावश्यक रूपमा AI द्वारा उत्पादित 6 मिति परिदृश्यहरू मध्ये 4 मेटाए। AI ले सम्भावनाहरू उत्पन्न गर्यो; उत्पादन जानकारी चयन गरे।

सामान्य गल्तीहरू

स्वीकृति मापदण्ड नदिई स्क्रिप्ट अनुरोध गर्दै। सत्य के हो थाहा नदिई, AI ले सतही परिदृश्यहरू उत्पादन गर्छ जसले प्रायः वास्तविक जोखिमलाई गुमाउँछ।
सकारात्मक परीक्षणको लागि बसोबास गर्दै। स्पष्ट रूपमा नकारात्मक र किनारा केसहरू चाहँदैनन्। गल्तीहरू प्रायः यहीँ हुन्छ।
जे उत्पादन हुन्छ त्यसैलाई स्वीकार गर्ने । AI लाई उत्पादनको सन्दर्भ थाहा छैन भनेर बिर्सनु र सेटमा अनावश्यक वा असम्भव परिदृश्यहरू छोड्दै।
ट्रेसिबिलिटी बाइपास गर्दै। स्वीकृति मापदण्डमा केसहरू लिङ्क नगर्ने; नतिजाको रूपमा, कुन मापदण्डको परीक्षण गरिएको छैन (कभरेज ग्याप)।
मात्रा भ्रम। "६० पटक स्क्रिप्ट रिलिज भइसकेकाले" खुसी छु। मान संख्यामा होइन, तर जोखिम कभर गर्ने दायरामा हुन्छ।

संक्षेपमा

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

आवेदन कार्य

तपाईंको आफ्नै परियोजनाबाट एक सुविधा छान्नुहोस् र स्वीकृति मापदण्ड लेख्नुहोस्। एआईसँग "प्रविधि-आधारित परिदृश्य जेनेरेसन" टेम्प्लेटको साथ परीक्षण केसहरू उत्पन्न गर्नुहोस्। त्यसपछि "एज केस हन्टर" र "ट्रेसेबिलिटी चेक" टेम्प्लेटहरू लागू गर्नुहोस्। नतिजाको रूपमा: (१) कम्तिमा 3 किनारा केसहरू थप्नुहोस् जुन AI ले छोड्छ, (2) कुनै पनि स्वीकृति मापदण्डमा जडान नगर्ने केसहरू काट्नुहोस्, (3) कुनै स्वीकृति मापदण्ड परीक्षण नगरी बाँकी छ भने नयाँ केसहरू लेख्नुहोस्। अन्तिम सेटलाई स्प्रेडसिटमा हाल्नुहोस्।

चेकलिस्ट

[] स्क्रिप्ट अनुरोध गर्नु अघि, मैले स्वीकृति मापदण्ड स्पष्ट गरें।
[ ] मैले YZ लाई नामद्वारा समतुल्यता वर्ग र सीमा मूल्य विश्लेषणको लागि सोधें।
[] मैले सकारात्मक, नकारात्मक र किनारा राज्यहरू अलग-अलग उत्पन्न गरें।
[] मैले प्रत्येक परीक्षण केसलाई स्वीकृति मापदण्ड (ट्रेसेबिलिटी) मा जोडेको छु।
[] मैले तालिकाको साथ स्कोप ग्याप र अनावश्यक केसहरू जाँच गरें।
[ ] मैले जोखिमलाई प्राथमिकता दिएँ र सुन्निएको सेट छाँटें।