इकाइयाँ
1. खेल विकास में कृत्रिम बुद्धिमत्ता का परिचय: भूमिकाएँ, सीमाएँ, सत्यापन, कॉपीराइट और नैतिकता 2. प्रोटोटाइप और मैकेनिकल डिज़ाइन: आइडिया से प्लेएबल कोर तक तीव्र पुनरावृत्ति 3. एनपीसी व्यवहार और संवाद प्रणाली: कृत्रिम बुद्धिमत्ता जो चरित्र को जीवंत बनाती है 4. प्रक्रियात्मक सामग्री निर्माण (पीसीजी): स्तर, मानचित्र, खोज और कथा 5. संपत्ति और दृश्य उत्पादन: संकल्पना कला, 2डी/3डी और बनावट 6. ध्वनि, संगीत और प्रभाव उत्पादन: खेल की हर्ड दुनिया 7. कोड जनरेशन और इंजन एकीकरण: एकता (सी#) और अवास्तविक (ब्लूप्रिंट/सी++) 8. खेल संतुलन, सिमुलेशन और अर्थव्यवस्था: संख्याओं के साथ एक उचित खेल 9. गुणवत्ता आश्वासन (क्यूए), डिबगिंग और स्वचालित परीक्षण 10. कॉपीराइट, मौलिकता, लाइसेंस और नैतिकता: प्रकाशन योग्य और जिम्मेदार सामग्री 11. एंड-टू-एंड वर्कफ़्लो, प्रोडक्शन लाइन इंटीग्रेशन, गवर्नेंस और लाइव सर्विस
इकाई 9 / 11

गुणवत्ता आश्वासन (क्यूए), डिबगिंग और स्वचालित परीक्षण

लाभ:

  • कार्यात्मक, प्रतिगमन, एज केस और क्रैश टेस्ट परतों को समझने और कृत्रिम बुद्धिमत्ता के साथ परीक्षण परिदृश्य और एज केस सूची तैयार करने की क्षमता
  • कृत्रिम बुद्धिमत्ता के साथ स्वचालित परीक्षण कोड लिखकर और लॉग और क्रैश विश्लेषण में पैटर्न निकालकर डिबगिंग में तेजी लाने की क्षमता
  • यह समझने में सक्षम होने के नाते कि कृत्रिम बुद्धिमत्ता का त्रुटि निदान साक्ष्य नहीं बल्कि परिकल्पना है, इसका कारण लॉग और पुनरुत्पादन के साथ सिद्ध होना चाहिए, और त्रुटि रिपोर्ट के पुनरुत्पादन का महत्व।

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

इस इकाई में आप सीखेंगे कि QA और डिबगिंग में AI का उपयोग कैसे करें; आप परीक्षण परिदृश्य डिज़ाइन, लॉग विश्लेषण, स्वचालित परीक्षण लेखन और त्रुटि रिपोर्टिंग अनुशासन सीखेंगे।

QA की परतें और AI का स्थान

QA बहुस्तरीय है. कार्यात्मक परीक्षण: क्या सुविधा काम करती है (क्या दरवाज़ा खुलता है, क्या रिकॉर्डिंग लोड होती है)। प्रतिगमन परीक्षण: क्या नए परिवर्तन ने पहले जो काम कर रहा था उसे तोड़ दिया? एज केस परीक्षण: असामान्य इनपुट (इन्वेंट्री रीसेट करें, एक साथ दो कुंजी, बॉर्डरलाइन मान)। प्रदर्शन/क्रैश परीक्षण: क्या खेल स्थिर है। गेमप्ले/अनुभव परीक्षण: मज़ेदार, सहज ज्ञान युक्त। एआई पहले चार में मजबूत है: परिदृश्य तैयार करना, किनारे के मामलों को सूचीबद्ध करना, परीक्षण कोड लिखना, लॉग का विश्लेषण करना। अंतिम—अनुभव—मनुष्य का है।

QA प्रवाह चरण दर चरण:

  1. परीक्षण मामले (एआई के साथ कार्यात्मक और एज केस सूची) उत्पन्न करें।
  2. स्वचालित परीक्षण लिखें (दोहराए गए जाँचों के लिए कोड)।
  3. चलाएँ और एकत्र करें (लॉग त्रुटियाँ, लॉग, क्रैश)।
  4. विश्लेषण करें (एआई के साथ लॉग और त्रुटि पैटर्न की जांच करें)।
  5. रिपोर्ट करें और सत्यापित करें (स्पष्ट, प्रतिलिपि प्रस्तुत करने योग्य बग रिपोर्ट; परीक्षण सुधार)।
संकेत: एज केस ढूँढना कठिन है क्योंकि डिज़ाइनर अपना गेम "सही" खेलता है। एआई से पूछें "यदि कोई खिलाड़ी इस प्रणाली को तोड़ना चाहे तो वह क्या प्रयास करेगा?" कारनामों और किनारे के मामलों की सूची बनाएं।

स्वचालित परीक्षण: दोहराव को मशीन पर छोड़ दें

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

सावधानी: डिबगिंग में, एआई कभी-कभी "संभावित कारण" (मतिभ्रम) के रूप में एक मनगढ़ंत स्पष्टीकरण प्रस्तुत करता है। बग के कारण को सिर्फ इसलिए स्वीकार न करें क्योंकि एआई ने आपको ऐसा बताया है; लॉगिंग, पुनरुत्पादन और परीक्षण द्वारा कारण सिद्ध करें। गलत निदान से सही निदान खोजने में देरी होती है।

पुनरुत्पादन: डिबगिंग का मूल

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

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

तीन मिनी मामले

केस 1 - एज केस शिकार। एक आरपीजी में, टीम ने "सामान्य" गेमप्ले में इन्वेंट्री सिस्टम का परीक्षण किया और सोचा कि यह ठोस था। उन्होंने एआई से कहा था कि "इस इन्वेंट्री को क्रैक करने का प्रयास करें" और 30 एज केस परिदृश्य उत्पन्न किए; इनमें से 4 सही त्रुटियां थीं (0 वज़न आइटम का विभाजन, एक साथ डिस्पोजेबल)। प्रकाशन से पहले ठीक किया गया.

केस 2 - लॉग विश्लेषण ने दुर्घटना का समाधान किया। एक गेम बेतरतीब ढंग से क्रैश हो रहा था; क्रैश लॉग में सैकड़ों लाइनें थीं। जब एआई को लॉग दिए गए और पैटर्न के बारे में पूछा गया, तो पता चला कि दुर्घटना हमेशा एक विशिष्ट दृश्य संक्रमण और कम मेमोरी पर होती थी। इस सुराग के साथ, प्रोग्रामर को मेमोरी लीक का पता चला; दुर्घटना दर शून्य हो गई.

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

चार प्रतिलिपि योग्य टेम्पलेट

1) एज केस/शोषण परिदृश्य निर्माण:

आपकी भूमिका: दुर्भावनापूर्ण QA परीक्षक। मैं निम्नलिखित प्रणाली का वर्णन करता हूं: [प्रणाली, नियम]। कार्य: 20 प्रमुख परिदृश्यों की सूची बनाएं जो इस प्रणाली को तोड़ने, शोषण करने या अप्रत्याशित स्थिति में डालने का प्रयास करेंगे। प्रत्येक के लिए: क्या प्रयास करें, अपेक्षित परिणाम, संभावित त्रुटि।

2) स्वचालित परीक्षण लेखन:

इंजन: [एकता 2022.3 / अवास्तविक 5.3]। टेस्ट फ्रेमवर्क: [निर्दिष्ट करें]। निम्नलिखित फ़ंक्शन/सिस्टम के लिए स्वचालित परीक्षण लिखें: [विवरण/कोड]। सामान्य केस, लिमिट केस और दोषपूर्ण इनपुट शामिल करें। सुनिश्चित करें कि प्रत्येक परीक्षण वास्तव में कुछ सार्थक सत्यापित करता है; खाली/अर्थहीन परीक्षण लिखना।

3) लॉग/क्रैश विश्लेषण:

नीचे गेम के क्रैश/त्रुटि लॉग हैं: [लॉग]। कार्य: आवर्ती पैटर्न, सामान्य स्थितियों (दृश्य, स्मृति, समय) और संभावित मूल कारणों को चिह्नित करें। प्रत्येक कारण को "सिद्ध होने वाली परिकल्पना" के रूप में प्रस्तुत करें; स्पष्ट रूप से बोलो। मुझे यह भी बताएं कि सत्यापन कैसे करें।

4) बग रिपोर्ट स्पष्टीकरण:

निम्नलिखित अस्पष्ट त्रुटि रिपोर्ट को स्पष्ट और प्रतिलिपि प्रस्तुत करने योग्य बनाएं: [कच्ची रिपोर्ट]। आउटपुट: शीर्षक, चरण-दर-चरण पुनरुत्पादन, अपेक्षित परिणाम, वास्तविक परिणाम, आवृत्ति, वातावरण। यदि कोई जानकारी गायब है, तो सूचीबद्ध करें कि कौन सी जानकारी आवश्यक है।

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

कमजोर संकेत:

मेरे गेम में एक बग है, इसे ठीक करें।

कोई संदर्भ नहीं, कोई लॉग नहीं, कोई पुनरुत्पादन नहीं; एआई पूर्वानुमानित है और मतिभ्रम का जोखिम अधिक है।

शक्तिशाली संकेत:

मेरे यूनिटी 2022.3 गेम में एक बग है: जब खिलाड़ी त्वरित सेव-लोड करता है तो इन्वेंट्री कभी-कभी दोगुनी हो जाती है। पुनरुत्पादन: [चरण]। संबंधित कोड: [पेस्ट करें]। लॉग: [पेस्ट करें]। कार्य: सिद्ध की जाने वाली परिकल्पनाओं के रूप में संभावित मूल कारणों की सूची बनाएं, सत्यापित करने का तरीका बताएं और प्रत्येक के लिए संभावित समाधान बताएं। एक गैर-मौजूद कारण बनाएं; यदि आप निश्चित नहीं हैं तो मुझे बताएं।

पुनरुत्पादन, कोड, लॉग और "परिकल्पना के रूप में प्रस्तुत करें" अनुरोध निदान को विश्वसनीय बनाते हैं।

QA परत तालिका

परत

यह क्या परीक्षण करता है?

एआई योगदान

मानव हिस्सा

कार्यात्मक

क्या सुविधा काम करती है?

स्क्रिप्ट, परीक्षण कोड

प्रवेश निर्णय

प्रतिगमन

क्या पुरानी चीज़ टूट गयी है?

स्वचालित परीक्षण

कार्यक्षेत्र निर्णय

चरम मामला

असामान्य इनपुट

स्क्रिप्ट निर्माण

प्राथमिकता

क्रैश/प्रदर्शन

दृढ़ संकल्प

लॉग विश्लेषण

मूल कारण की पुष्टि

अनुभव

मनोरंजन, अंतर्ज्ञान

सीमित

पूरी तरह से मानव

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

  • बस "सामान्य" गेमप्ले का परीक्षण कर रहा हूँ। रिलीज के बाद एज केस का विस्फोट हो गया।
  • एआई निदान को प्रमाण समझना। लॉग और परीक्षण द्वारा सिद्ध क्यों किया गया है।
  • खाली स्वचालित परीक्षण लिखना. निरर्थक परीक्षण आत्मविश्वास का भ्रम पैदा करता है।
  • अस्पष्ट बग रिपोर्ट. एक गैर-पुनरुत्पादन योग्य त्रुटि को ठीक नहीं किया जा सकता है।
  • प्रतिगमन परीक्षण छोड़ना। प्रत्येक सुधार के कारण नई त्रुटियाँ हो सकती हैं।

संक्षेप में

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

आवेदन कार्य

अपने गेम से एक सिस्टम चुनें. "एज केस/शोषण परिदृश्य निर्माण" टेम्पलेट के साथ 20 परिदृश्य तैयार करें और वास्तव में 5 सबसे जोखिम भरे का परीक्षण करें। "बग रिपोर्ट परिशोधन" टेम्पलेट के साथ पाए जाने वाले बग के लिए एक प्रतिलिपि प्रस्तुत करने योग्य रिपोर्ट बनाएं।

जांच सूची

  • [ ] मैंने "इसे कौन तोड़ सकता है और कैसे?" के साथ एक एज केस बनाया।
  • [ ] आवर्ती जांच के लिए स्वचालित परीक्षण लिखा और समीक्षा की।
  • [ ] मैंने एआई निदान को एक परिकल्पना माना और इसे लॉग/टेस्ट के साथ साबित किया।
  • [ ] मैंने पुनरुत्पादित रूप से त्रुटियों की सूचना दी।
  • [ ] मैंने प्रतिगमन के लिए प्रत्येक सुधार का पुनः परीक्षण किया।