खेल विकास में स्वचालित परीक्षण कितना आम है? [बन्द है]

Question

गेमर्स डेवलपर्स यूनिट और इंटीग्रेशन टेस्ट लिखने के लिए उपयोग करते हैं? पहेली डेवलपर्स के बीच यह कितना सामान्य है? और MMORPGs और FPSes के डेवलपर्स के बीच?

(खेल विकास में मेरी कोई पृष्ठभूमि नहीं है और न ही मैं इसके साथ काम करने के बारे में कह रहा हूं - यह सिर्फ एक संदेह है जो मेरे साथ हुआ है। इसलिए, मुझे उन्हें लिखने के लिए समझाने की कोशिश करने की कोई आवश्यकता नहीं है, यहां तक ​​कि क्योंकि मैं पहले से ही स्वचालित परीक्षण लिखना पसंद करता हूं। )

Comments

स्टैक एक्सचेंज पर स्वचालित प्रश्न कितने सामान्य हैं?

— MichaelHouse

गेम्स

— बम्ज़ैक

सिर्फ इसलिए कि वे खेल उद्योग में आम नहीं हैं, इसका मतलब यह नहीं है कि आपको उन्हें लिखना जारी रखने का प्रयास नहीं करना चाहिए। वैसे भी आप इस समस्या को हल करने के लिए क्या समस्या है?

— तेतराड 3

@ टेट्राद बस सवाल पढ़ें। दूसरा पैराग्राफ सभी को समझाता है।

— ब्रांडीज़ी

Answer 1

सामान्य तौर पर, यूनिट और गेम्स का एकीकरण परीक्षण आम नहीं है। यह ज्यादातर इसलिए है क्योंकि खेलों के प्रतिपादन का पहलू आमतौर पर बाकी खेल यांत्रिकी से निकटता से जुड़ा होता है कि यह वास्तव में इकाई परीक्षण लिखने के लिए बहुत कठिन हो सकता है जो काम करते हैं।

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

हालांकि, अंत में, यह सब स्टूडियो पर निर्भर करता है। कुछ स्टूडियो कुछ प्रकार के स्वचालित परीक्षण करेंगे, जबकि अन्य शायद गर्मियों में 20 उच्च विद्यालय के बच्चों को अपने खेल को अंत तक खेलने के लिए रख सकते हैं।

Comments

+1 केवल इसलिए कि हम सभी चाहते हैं कि हम इन बच्चों में से एक थे। :(

— बॉबी

@ बॉबी अपने लिए बोलें। बग्गी और अधूरे गेम को बार-बार खेलने के लिए मजबूर किया जाना एक भयावह सोच है, भले ही आप अंत में नवीनतम बार्नी द डायनासौर गेम जैसी किसी चीज़ का परीक्षण करने के लिए असाइन नहीं किए गए हों।

— दान नीली

@ बॉबी, मैं लगभग 3-4 वर्षों से क्यूए था, यह बहुत अच्छा काम है अगर आपको सॉफ्टवेयर को तोड़ना और उस उद्योग में काम करना पसंद है, लेकिन ऐसा न करें क्योंकि 'आप पूरे दिन खेल खेलना पसंद करते हैं' :)

— JuniorDeveloper1208

मैं लगभग छह महीने तक क्यूए में था। नौकरी पर अपने दूसरे दिन के अंत में अपनी कार पर जाते समय, मैं खुद को सोच समझकर याद करता हूं, "मैं खुद को इस नौकरी से नफरत करते हुए देख सकता हूं।" और मेरे तीसरे दिन के अंत में, "मुझे वास्तव में इस नौकरी से नफरत है।" अच्छे क्यूए परीक्षक जो नौकरी की मांगों का सामना कर सकते हैं, वे सोने में अपने वजन के लायक हैं, और यह एक अपराध है कि वे मूल्यवान नहीं हैं और उनकी तुलना में अधिक उच्च मुआवजा दिया है।

— ट्रेवर पॉवेल

Answer 2

मेरे अनुभव में, यह बहुत आम नहीं है।

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

आंशिक रूप से यह इसलिए है क्योंकि खेल विकास उद्योग में प्रमुख भाषा C ++ है और यह इकाई परीक्षण को अन्य भाषाओं की तुलना में थोड़ा अधिक बोझिल बनाता है। यूनिट टेस्टिंग फ्रेमवर्क मौजूद हैं, लेकिन वे अधिक आधुनिक भाषाओं में समान प्रणालियों के रूप में उपयोग करना आसान नहीं हैं जो परीक्षण मामलों का पता लगाने में तेजी लाने के लिए प्रतिबिंब और समान चाल का उपयोग कर सकते हैं।

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

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

Comments

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

— झटके लगाना

Answer 3

मैं यह नहीं देखता कि किसी गेम को सॉफ्टवेयर के किसी अन्य टुकड़े से अलग कैसे लिखा जाता है। सॉफ्टवेयर के प्रत्येक घटक, चाहे वह एक समयबद्ध घटना को ट्रिगर कर रहा हो, एक इन-गेम चरित्र को कमांड भेज रहा हो, या मेनू बटन दबा रहा हो, उचित निष्पादन के लिए परीक्षण किया जाना चाहिए।

परीक्षण कि क्या खेल को पूरा करना संभव है, एक अलग मामला है और इकाई या एकीकरण परीक्षण के तहत नहीं आता है।

Answer 4

सामान्य स्वचालित यूआई परीक्षण में (नियमित कार्यक्रमों में भी) नियमित स्वचालन की तुलना में कठिन है। तो भले ही आप अपने खेल के लिए इकाई परीक्षण लिख सकते हैं, वास्तविक खेल का परीक्षण कठिन है। ज्यादातर कंपनियां मानव परीक्षकों का उपयोग करती हैं जो खेल को बार -बार चलाते हैं ।

उदाहरण के लिए यहां एक लेख बताया गया है कि वे इसे एक छोटे गेम स्टूडियो (2 देव) में कैसे करते हैं। मैंने जो पढ़ा है, ऐसा लगता है कि उनका सत्यापन बहुत विस्तृत नहीं है (स्वचालन खेल शुरू करता है और किसी भी त्रुटि / दावे को लॉग करता है)।

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

यहाँ उपकरणों की तरह वे खेल का परीक्षण करने / उपयोग निर्माण क्या पर एक अच्छी बात है। इसे "टेस्ट लीड रत्न: हमारे खेलों की बढ़ती जटिलता के सामने लाना" कहा जाता है

Answer 5

मैं चाहता हूँ कि MMO और मल्टीप्लेयर सर्वर कोड, हालांकि, थोड़ा अधिक बार परीक्षण किया जाता है।

बहुत कम से कम, स्वचालित प्रतिगमन परीक्षण सामान्य रहे हैं। मैंने इन्हें सर्वर स्टार्ट-अप के दौरान बड़े पैमाने पर विवेक-जांच के रूप में लागू किया है, उदाहरण के लिए यह सुनिश्चित करने के लिए कि खिलाड़ियों को स्वीकार करने से पहले एक नया "क्लाउड" सर्वर सही ढंग से कॉन्फ़िगर किया गया था; 3-4 वर्षों में निर्मित एक काफी अच्छा प्रतिगमन सूट, उस मामले में, लगभग 4 सेकंड में भाग गया, जबकि एक आभासी मेजबान (एक खाली ओएस छवि से) को लाने में लगभग 10 मिनट लगे, इसलिए यह समय के लायक था। हमने अपने सबवर्सन रिपॉजिटरी पर एक "टिंडरबॉक्स" (निरंतर निर्माण प्रणाली) पर एक ही परीक्षण चलाया, कुछ कष्टप्रद, काफी सामान्य त्रुटियों की जांच करने के लिए जो कि वापस रेंगना पसंद करते थे। विशेष रूप से, बहु-सर्वर कार्यक्षमता के लिए प्रयास करने की एक बुरी आदत थी। ऑब्जेक्ट के डुप्लिकेट बनाएं जैसे कि वे आसपास पारित किए गए थे: ऑब्जेक्ट इंस्टेंटेशन, कैशिंग, और नेटवर्क-पासिंग कोड 100% कवर के करीब था; हम सोचते रहे कि हम हर उस चीज़ के बारे में सोचेंगे जिसका परीक्षण किया जा सकता है, और फिर कुछ "मज़ेदार" नए किनारे का मामला खोज सकते हैं।

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

हालांकि, सामान्य रूप से MMO का विकास इस प्रकार की समस्याओं के बहुत अधिक के अधीन है, जो पर्यावरण को प्रतिबिंबित कर सकता है। जब मैं एम्बेडेड गेम सिस्टम पर काम कर रहा था, तो कुछ पुन: प्रयोज्य विजेट कोड (जैसे पाठ संपादकों) को छोड़कर "परीक्षण" व्यावहारिक रूप से अनसुना था।

Answer 6

एक और कारण है कि स्वचालित परीक्षण गेम डेवलपमेंट में इतना सामान्य नहीं है कि माना जा सकता है कि अधिकांश गेम के लिए बहुत सारे बीटा परीक्षण स्वयंसेवक हैं जो गेम रिलीज होने पर गेम की "बढ़त" के रूप में बीटा भागीदारी का शिकार करते हैं। स्वचालित परीक्षण निश्चित रूप से गुणवत्ता आवश्यकताओं से बाहर हो गया है, लेकिन बजट प्रतिबंधों से भी बाहर है। इसलिए, चूंकि गेमिंग में बहुत सारे अनुभवी परीक्षक हैं जो मुफ्त में परीक्षण करने के लिए तैयार हैं, शायद यह एक और कारण है कि स्वचालित परीक्षण व्यापक नहीं हैं।

Answer 7

मैंने जीडीसी 2011 में स्वचालित परीक्षण के बारे में एक गोलमेज चर्चा में भाग लिया । IIRC, कमरे में लगभग 60 लोग थे। एक बिंदु पर मॉडरेटर ने यूनिट टेस्ट कवरेज का एक सर्वेक्षण लिया। एक व्यक्ति था जिसने 90% से अधिक कोड कवरेज का दावा किया था । बाकी सभी ने कभी भी 1% कवरेज तक पहुंचने के बारे में सोचा । अगर वह समूह संपूर्ण रूप से उद्योग का एक उचित प्रतिनिधित्व है, तो मैं कहूंगा कि स्वचालित परीक्षण आम तौर पर बहुत अधिक नहीं होता है, यदि सभी।

यहाँ अन्य जवाब क्यों के रूप में अच्छे कारण देते हैं। मैंने सोचा था कि पहले खाते के लिए उपयोगी होगा।

Comments

मुझे आश्चर्य है कि आंकड़ा इतना कम है (हालांकि मैं अपने परीक्षण में इस तरह के परीक्षणों का उपयोग करने के लिए एक तिहाई से अधिक gamedevs की उम्मीद नहीं करूंगा, जैसा कि मैंने अपने उत्तर में किया है।) कुछ व्यक्तिगत उपाख्यानात्मक साक्ष्य जोड़ने के लिए, सर्वर सॉफ्टवेयर मैं काम कर रहा हूं। 70% से अधिक यूनिट परीक्षण कवरेज है। मैं शायद इसे थोड़ी मेहनत के साथ 85% तक पहुंचा सकता हूं, लेकिन अंतिम 15% में विभिन्न निर्भरता इंजेक्शन गर्भनिरोधक शामिल होंगे जो मैं बनाने के लिए तैयार नहीं हूं। तुलना करके, क्लाइंट सॉफ्टवेयर यूनिट परीक्षण के लिए लगभग असंभव है इसलिए हम मैन्युअल परीक्षण पर ध्यान केंद्रित करते हैं।

— काइलोटन

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

— hsandt