গেম ডেভলপমেন্টে অটোমেটেড টেস্টিং কত সাধারণ? [বন্ধ]

Question

গেমার বিকাশকারীরা ইউনিট এবং ইন্টিগ্রেশন টেস্ট লিখতে ব্যবহার করেন? ধাঁধা বিকাশকারীদের মধ্যে এটি কতটা সাধারণ? এবং এমএমওআরপিজি এবং এফপিএসগুলির বিকাশকারীদের মধ্যে?

(গেমের বিকাশের আমার কোনও পটভূমি নেই এবং আমি এটি নিয়ে কাজ করার বিষয়ে কৌতূহল রাখছি না - এটি আমার কাছে ঘটে যাওয়া একটি সন্দেহ মাত্র So তাই, আমাকে এগুলি লিখতে রাজি করার চেষ্টা করার প্রয়োজন নেই , যদিও আমি ইতিমধ্যে স্বয়ংক্রিয় পরীক্ষাগুলি লিখতে পছন্দ করি। )

Comments

স্ট্যাক এক্সচেঞ্জে স্বয়ংক্রিয় প্রশ্নগুলি কতটা সাধারণ?

— মাইকেলহাউস

গেমগুলির অটোমেটেড পরীক্ষার

— বামমজ্যাক

গেমস ইন্ডাস্ট্রিতে এগুলি সাধারণ না হওয়ার অর্থ এই নয় যে আপনি তাদের লেখার চেষ্টা চালিয়ে যাওয়া উচিত নয়। আপনি যেভাবেই এই প্রশ্নটি সমাধান করার চেষ্টা করছেন?

— টেট্রাড

@ টেট্রাড শুধু প্রশ্নটি পড়ুন। দ্বিতীয় অনুচ্ছেদ সমস্ত ব্যাখ্যা।

— ব্র্যান্ডজিজি

Answer 1

সাধারণভাবে, গেমগুলির ইউনিট এবং ইন্টিগ্রেশন টেস্টিং সাধারণ নয়। এটি বেশিরভাগ কারণ হ'ল গেমগুলির রেন্ডারিং দিকটি সাধারণত গেমের বাকী বাকী অংশগুলির সাথে খুব বেশি ঘনিষ্ঠভাবে আবদ্ধ থাকে যা কাজ করে এমন ইউনিট পরীক্ষাগুলি লিখতে খুব কঠিন হতে পারে।

এটি বলেছিল, গেম বিকাশে ইউনিট টেস্টিং ঘটতে পারে এবং যদি কোডটির জন্য সেট আপ করা হয় তবে এটি খুব বেশি উপকৃত হতে পারে। তবে গেমসের জন্য স্বয়ংক্রিয় পরীক্ষাগুলি লিখতে অনেক বেশি সাধারণ হতে পারে, সাধারণত একটি এআই প্রোগ্রাম আকারে যা কার্যকরভাবে কোনও খেলোয়াড়ের চেয়ে বেশি গতিতে গেমটি খেলতে পারে। স্বয়ংক্রিয় পরীক্ষার বিষয়ে এই প্রশ্নে বিকাশকারীদের কিছু দুর্দান্ত গল্প রয়েছে । এই ধরণের স্বয়ংক্রিয় পরীক্ষার সম্ভাব্যতর উন্নতি, যেহেতু ইউনিট টেস্টিং রেন্ডারিং ইঞ্জিনে কোনও বাগ ধরতে পারে না, তবে একটি স্বয়ংক্রিয় পরীক্ষার ফলে এ জাতীয় সমস্যা প্রকাশের সম্ভাবনা বেশি।

শেষ পর্যন্ত, যদিও এটি স্টুডিওর উপর নির্ভর করে। কিছু স্টুডিও কিছু প্রকারের স্বয়ংক্রিয় পরীক্ষামূলক কাজ করবে, অন্যরা গ্রীষ্মে 20 টি উচ্চ বিদ্যালয়ের বাচ্চাদের কয়েক ঘন্টা খেলা শেষ করতে খেলতে পারে।

Comments

+1 কেবল কারণ আমরা সকলেই আশা করি আমরা এই বাচ্চাদের একজন হয়ে থাকি। :(

— ববি

@ ববি নিজের জন্য কথা বলুন। আপনি বারে বারে বগি এবং অসম্পূর্ণ গেমস খেলতে বাধ্য করা একটি ভয়ঙ্কর চিন্তাভাবনা, এমনকি যদি আপনি সর্বশেষ বার্নি ডায়নোসর গেমের মতো কিছু পরীক্ষা করার জন্য নির্ধারিত না হন তবেও।

— ড্যান নীলি

@ ববি, আমি প্রায় ৩-৪ বছর কিউএ ছিলাম, আপনি যদি সফ্টওয়্যার ভাঙতে এবং সেই শিল্পে কাজ করতে পছন্দ করেন তবে এটি দুর্দান্ত কাজ, তবে এটি করবেন না কারণ 'আপনি সারাদিন গেমস খেলতে পছন্দ করেন' :)

— জুনিয়র ডেভেলপার ১208

আমি প্রায় ছয় মাস কিউএ ছিলাম। চাকরিতে দ্বিতীয় দিন শেষে আমার গাড়িতে হাঁটতে গিয়ে আমি স্পষ্টভাবে মনে মনে ভেবেছিলাম, "আমি নিজেকে শেষ পর্যন্ত এই কাজটিকে ঘৃণা করতে দেখি" " এবং আমার তৃতীয় দিন শেষে "আমি সত্যিই এই কাজটিকে ঘৃণা করি।" ভাল কিউএ পরীক্ষার্থীরা যারা কাজের দাবিগুলি মোকাবেলা করতে পারে তাদের সোনার জন্য তাদের ওজন মূল্যবান এবং এটি এমন একটি অপরাধ যে তাদের মূল্য দেওয়া হয় না এবং তাদের চেয়ে বেশি ক্ষতিপূরণ দেওয়া হয়।

— ট্রেভর পাওয়েল

Answer 2

আমার অভিজ্ঞতায় এটি খুব সাধারণ কিছু নয়।

বেশিরভাগ ইউনিট টেস্টিং ঘটে না কারণ বেশিরভাগ গেম বিকাশকারী সময় এবং সংস্কৃতি থেকে আগত এমন জিনিসগুলি আগে ব্যাপকভাবে আসে এবং তাই এখন এই জাতীয় পদ্ধতিগুলি প্রয়োজনীয় বলে যুক্তিটি তৈরি করা শক্ত। এটি সাম্প্রতিক বছরগুলিতে প্রত্যাশার সাথে আরও সত্য হয়ে উঠেছে যে ব্যবহারকারী মুক্তির পরে তার নিজের সফ্টওয়্যারটি প্যাচ করতে সক্ষম হবে।

আংশিকভাবে এটি কারণ গেম ডেভলপমেন্ট ইন্ডাস্ট্রির প্রভাবশালী ভাষা সি ++ এবং এটি ইউনিট টেস্টিংকে অন্যান্য ভাষার চেয়ে কিছুটা জটিল করে তোলে। ইউনিট টেস্টিং ফ্রেমওয়ার্কগুলি বিদ্যমান তবে এগুলি আরও আধুনিক ভাষায় অনুরূপ সিস্টেমের মতো ব্যবহার করা সহজ নয় যা পরীক্ষার কেস সনাক্তকরণের গতি বাড়ানোর জন্য প্রতিবিম্ব এবং অনুরূপ কৌশল ব্যবহার করতে পারে।

এছাড়াও, কারণ গেমস সাধারণত ইউনিট টেস্টিংয়ে নিজেকে ঘৃণা করে না - যুক্তির বেশিরভাগ অংশ আধা-নির্ধারক উত্সগুলিতে নির্ভর করে (যেমন, গ্রাফিক্স হার্ডওয়্যার, ইনপুট টাইমিংস, ফ্রেম রেট), আউটপুটটির বেশিরভাগ পরিমাপ করা কঠিন (যেমন। অন-স্ক্রিন গ্রাফিক্স, সাউন্ড এফেক্টস) এবং কিছু সম্পূর্ণ গেমের প্রসঙ্গ তৈরির (যেমন। জটিল প্রতিক্রিয়াশীল এআই, পদার্থবিজ্ঞানের সিমুলেশন) এর বাইরে প্রায় অর্থহীন। ব্যতিক্রমগুলি রয়েছে - অনেকগুলি, আপনি যদি কোডটি তৈরির জন্য কঠোর পরিশ্রম করেন তবে - তবে সম্পূর্ণ পরীক্ষায় অন্যান্য সফ্টওয়্যারগুলির তুলনায় গেমগুলিতে আরও ব্যয়বহুল এবং তাই ব্যয় / উপকারের অনুপাতটি আরও সন্দেহজনক।

ইন্টিগ্রেশন টেস্টিংয়ের কথা, আমি কখনই শব্দটি গেম ডেভেলপমেন্টে স্পষ্টভাবে ব্যবহৃত হচ্ছে শুনিনি তবে অনেক বিকাশকারী যেখানে সম্ভব সেখানে পুরো সিস্টেমটির স্বয়ংক্রিয় পরীক্ষা চালায়। একটি অনুমানের মধ্যে আমি বলব যে সম্ভবত 3 টির মধ্যে 1 জন প্রো বিকাশকারী এটি করুন, কারণ এটি স্থাপন করা সবসময় সহজ নয় এবং কারণ সুবিধার পরিমাণ হ্রাস হওয়ায় প্রতিটি মাধ্যম থেকে বড় বিকাশকারী (বা তাদের প্রকাশক) এর কিউএ রয়েছে ম্যানুয়ালি অনুরূপ পরীক্ষা করা হবে যে বিভাগ। কিউএ সাধারণত বিকাশকারীদের তুলনায় অনেক কম দেওয়া হয় সুতরাং এটিতে অতিরিক্ত কোড সময় বিনিয়োগ না করে তাদের কাছে পরীক্ষা ছেড়ে দেওয়া অর্থনৈতিক হিসাবে বিবেচিত হতে পারে। (বিতর্কিত।)

Comments

আউটপুট পরিমাপ করা কঠিন হচ্ছে সম্পর্কে দুর্দান্ত পয়েন্ট। এটি সহজেই যাচাই করা সহজ যে কোনও শ্রেণি ছিটকে যায়, বলুন, JSON কে সঠিকভাবে সংশোধন করুন, তবে যখন শটটি আসলে গেমটি খেলতে হয় তখন আপনার রাগডলগুলি নিয়ন্ত্রণের বাইরে চলে না যায় তা নিশ্চিত করার একমাত্র উপায়। সবচেয়ে খারাপ দিকটি এটি পার্শ্ব প্রতিক্রিয়াগুলি লক্ষ্য করা সত্যিই কঠিন করে তোলে (যেমন আপনি কোনও বাগ ঠিক করেন, তবে এখন গেমের আরও কিছু প্রত্যন্ত অংশ অন্যরকম আচরণ করে))

— 22:31

Answer 3

আমি দেখতে পাই না যে কোনও গেম লেখার জন্য সফ্টওয়্যারটির অন্য কোনও অংশে পরীক্ষা করা যতটা আলাদা। সফ্টওয়্যারটির প্রতিটি উপাদান, এটি কোনও সময়সাপেক্ষ ইভেন্টটিকে ট্রিগার করে, কোনও গেমের চরিত্রের জন্য কমান্ড প্রেরণ করে, বা মেনু বোতামগুলি টিপছে কিনা তা সঠিকভাবে সম্পাদনের জন্য পরীক্ষা করা উচিত।

গেমটি সম্পন্ন করা সম্ভব কিনা তা পরীক্ষা করা আলাদা বিষয় এবং ইউনিট বা ইন্টিগ্রেশন পরীক্ষার এতটা পড়ে না।

Answer 4

সাধারণ স্বয়ংক্রিয়তা ইউআই পরীক্ষায় (এমনকি নিয়মিত প্রোগ্রামগুলিতেও) নিয়মিত অটোমেশনের চেয়ে শক্ত। যদিও আপনি আপনার গেমগুলির জন্য ইউনিট পরীক্ষা লিখতে পারেন, প্রকৃত গেমটি পরীক্ষা করা আরও শক্ত। সর্বাধিক কোম্পানি মানব পরীক্ষকগণ খেলা চালানো ব্যবহার সময় এবং আবার।

উদাহরণস্বরূপ এখানে একটি নিবন্ধ এখানে একটি ছোট গেম স্টুডিওতে (2 দেব) এটি কীভাবে তা ব্যাখ্যা করে dev আমি যা পড়েছি তা দেখে মনে হচ্ছে তাদের বৈধতা খুব বিস্তারিত নয় (অটোমেশন গেমটি শুরু করে এবং কোনও ত্রুটি / দৃ as়তা লগ করে)।

তবে কিছু সংস্থা আধা অটোমেশন (যেমন মাইক্রোসফ্ট টেস্ট স্টুডিওগুলি) দিয়ে খুব সফল। এটি হ'ল ডেভেলপাররা বা এসডিইটিগুলি এমন সরঞ্জাম তৈরি করে যা গেমটি পরীক্ষা করা আরও সহজ করে তোলে। গেম ফেস্টের আলোচনা হয়েছে যেখানে তারা আলোচনা করেছেন যে তারা কীভাবে উদাহরণস্বরূপ বা কল্পিতভাবে ক্র্যাকডাউন পরীক্ষা করেছিল । উদাহরণস্বরূপ, তারা এখনও পরীক্ষকগণ ব্যবহার করে যাচাই করে যাচাই করে যে প্রতিটি বস্তু যেখানে এটি অনুমান করা উচিত সেখানে কিন্তু তারা এমন একটি সরঞ্জাম ব্যবহার করে যা সেই অবস্থানের স্ন্যাপশট নেয় যাতে মানুষের যা কিছু ঘটে তা গেমটি না খেলেই সেখানে উপস্থিত রয়েছে ually

গেমগুলি পরীক্ষা করতে তারা কী ধরণের সরঞ্জাম তৈরি করে / ব্যবহার করে সে সম্পর্কে এখানে একটি ভাল আলোচনা is একে বলা হয় "টেস্ট লিড রত্ন: আমাদের গেমসের ক্রমবর্ধমান জটিলতার সামনে বেরিয়ে আসা"

Answer 5

আমি বাজিয়ে দেব যে এমএমও এবং মাল্টিপ্লেয়ার সার্ভার কোডটি অবশ্য আরও প্রায়ই পরীক্ষিত হয়।

খুব কমপক্ষে, স্বয়ংক্রিয় রিগ্রেশন টেস্টগুলি সাধারণ ছিল। আমি এগুলি সার্ভার শুরুর সময় জনসাধারণের কাছে যাচাই-বাছাই হিসাবে প্রয়োগ করা দেখেছি, উদাহরণস্বরূপ নিশ্চিত করুন যে কোনও নতুন "ক্লাউড" সার্ভারটি খেলোয়াড়দের গ্রহণ করা শুরু করার আগে সঠিকভাবে কনফিগার করা হয়েছে; ভার্চুয়াল হোস্ট আনার সময় (ফাঁকা ওএস ইমেজ থেকে) প্রায় 10 মিনিট সময় নেয়, এই ক্ষেত্রে 3-4 বছরেরও বেশি সময় ধরে নির্মিত একটি মোটামুটি ভাল রিগ্রেশন স্যুট প্রায় 4 সেকেন্ডের মধ্যে দৌড়েছিল, তাই এটি সময়টির পক্ষে খুব ভাল ছিল। কিছু বিরক্তিকর, মোটামুটি সাধারণ ত্রুটিগুলি যা পিছন দিকে ভেঙে যেতে পছন্দ করেছে তা পরীক্ষা করার জন্য আমরা আমাদের সাবভার্সন রিপোজিটরিতে একটি "টেন্ডারবক্স" (ক্রমাগত বিল্ড সিস্টেম) তে একই পরীক্ষা চালিয়েছি particular বিশেষত, মাল্টি-সার্ভার কার্যকারিতাটি চেষ্টা করার অভ্যাস করার অভ্যাস ছিল চারপাশে পাস করার সাথে সাথে নকল তৈরি করুন: অবজেক্ট ইনস্ট্যান্টেশন, ক্যাশে, এবং নেটওয়ার্ক-পাসিং কোডটি প্রায় 100% আচ্ছাদিত ছিল; আমরা ভাবতে থাকি যে আমরা পরীক্ষা করা যায় এমন সমস্ত কিছু নিয়ে চিন্তা করব এবং তারপরে কিছু "মজাদার", নতুন প্রান্তের কেস আবিষ্কার করব।

আমি কাজ করেছি এমন বেশ কয়েকটি এমএমও-তে আমরা প্রাথমিক ইউনিট-টেস্টিং করতে "স্টাব ক্লায়েন্ট" বিকাশ করব এবং সাধারণত নতুন বৈশিষ্ট্যগুলির অ্যাড-হক ইউনিট পরীক্ষার জন্য "অপারেটর" কমান্ড সরবরাহ করতাম। ক্লায়েন্টটি এর সদ্ব্যবহারের জন্য প্রস্তুত হওয়ার আগে এটি সার্ভার কোডটি কার্যকর করুক এবং ত্রুটি পুনরুদ্ধারের হ্যান্ডলারগুলি ভালভাবে কাজ করবে কিনা তা নিশ্চিত করতে "অসম্ভব" পরিস্থিতিগুলি (যেমন কোনও প্রাচীরের অভ্যন্তরে কোনও খেলোয়াড়কে টেলিপোর্ট করা) অনুশীলন করুন। সার্ভারে অনলাইনে একটি নতুন বৈশিষ্ট্য আনতে কখনও কখনও এটির ক্লায়েন্ট সমর্থনের চেয়ে অনেক দিন কম সময় লাগে; বিপরীতভাবে, আমাদের মাঝে মাঝে ক্লায়েন্টের জন্য একটি "ডামি" সার্ভার পদ্ধতি তৈরি করতে হবে, যদি তারা আমাদের থেকে এগিয়ে যায় তবে জাল-কিন্তু-সুসংহত ডেটা ফিরিয়ে দেয়।

যাইহোক, সাধারণভাবে এমএমও বিকাশ এই ধরণের সমস্যাগুলির অনেক বেশি, যা পরিবেশকে প্রতিফলিত করে। যখন আমি এমবেডেড গেম সিস্টেমগুলিতে কাজ করছিলাম তখন কিছু পুনরায় ব্যবহারযোগ্য উইজেট কোড (যেমন টেক্সট সম্পাদক) ব্যতীত অন্য কোনও কিছুর জন্য "টেস্টিং" কার্যত অজ্ঞাত ছিল।

Answer 6

গেম ডেভেলপমেন্টে স্বয়ংক্রিয় পরীক্ষার বিষয়টি সাধারণ হিসাবে বিবেচিত হতে পারে না এর কারণ হ'ল বেশিরভাগ গেমের জন্য প্রচুর বিটা পরীক্ষার স্বেচ্ছাসেবীরা রয়েছেন যারা গেমটি প্রকাশিত হওয়ার পরে গেম বিটাতে একটি "প্রান্ত" হিসাবে অংশীদার হন। অটোমেটেড টেস্টিং অবশ্যই মানের প্রয়োজনীয়তার বাইরে বেড়েছে, তবে বাজেটের সীমাবদ্ধতার বাইরেও রয়েছে। সুতরাং, যেহেতু গেমিংয়ে প্রচুর অভিজ্ঞ পরীক্ষার্থী রয়েছে যারা নিখরচায় পরীক্ষার জন্য প্রস্তুত, সম্ভবত এটি অন্য কারণ যা স্বয়ংক্রিয় পরীক্ষাগুলি এত ব্যাপক নয়।

Answer 7

আমি জিডিসি ২০১১ এ স্বয়ংক্রিয় পরীক্ষার বিষয়ে একটি গোলটেবিল আলোচনায় অংশ নিয়েছি । আইআইআরসি, ঘরে প্রায় 60 জন লোক ছিল। এক পর্যায়ে মডারেটর ইউনিট পরীক্ষার কভারেজের সমীক্ষা নেন। এমন এক ব্যক্তি ছিলেন যিনি 90% এরও বেশি কোড কভারেজের দাবি করেছেন। অন্যরা সকলেই সর্বদা 1% কভারেজ পৌঁছানোর কথা ভেবে হাসত। যদি সেই গোষ্ঠীটি সামগ্রিকভাবে শিল্পের সুষ্ঠু উপস্থাপনা হয় তবে আমি বলতে পারি যে স্বয়ংক্রিয়ভাবে পরীক্ষা সাধারণত খুব বেশি ঘটে না, যদি তা না হয়।

অন্যান্য উত্তর এখানে কেন কারণ হিসাবে ভাল কারণ দেয়। আমি কেবল ভেবেছিলাম প্রথম হাতে থাকা অ্যাকাউন্টটি ব্যবহার করা কার্যকর হবে।

Comments

আমি বিস্মিত হয়েছি যে চিত্রটি এত কম (যদিও আমি আমার উত্তরে বলেছি যে গেমদেবদের এক তৃতীয়াংশেরও বেশি এই জাতীয় পরীক্ষা করা হবে বলে আশা করি না)) কিছু ব্যক্তিগত কাহিনী প্রমাণ প্রমাণের জন্য, আমি যে সার্ভার সফটওয়্যারটিতে কাজ করছি 70% এর বেশি ইউনিট পরীক্ষার কভারেজ রয়েছে। আমি সম্ভবত এটি কঠোর পরিশ্রমের সাথে 85% এ পেয়েছি, তবে শেষ 15% বিভিন্ন নির্ভরতা ইনজেকশন সংকোচনের সাথে জড়িত যা আমি তৈরি করতে রাজি নই। তুলনা করে ক্লায়েন্ট সফ্টওয়্যারটি ইউনিট টেস্টে প্রায় অসম্ভব তাই আমরা ম্যানুয়াল পরীক্ষায় মনোনিবেশ করি।

— কাইলোটন

একটি লুয়া প্রকল্পে, স্ট্যাবিং এবং বিদ্রূপের স্বাচ্ছন্দ্যের জন্য ধন্যবাদ, আমি উন্নয়নের সময় 100% কভারেজ রাখতে সক্ষম হয়েছি। তবে, আমি লক্ষ্য করেছি যে অনেকগুলি পরীক্ষাগুলি উদ্বেগজনক ছিল (যেমন ইউআইয়ের সঠিক স্থান নির্ধারণের পরীক্ষা করা, বা ডেটা-চালিত হওয়া উচিত তবে কোডে সত্যই সম্পন্ন হওয়া উচিত)। জিনিসগুলিকে আরও পরিষ্কার রাখার জন্য, আমি "ইঞ্জিন" (পুনরায় ব্যবহারযোগ্য) এবং গেম-নির্দিষ্টের মধ্যে কোডটি বিভক্ত করেছিলাম এবং কেবলমাত্র সমস্ত ইঞ্জিন কোডটি কভার করার বিষয়টি নিশ্চিত করেছিলাম, যখন গেমের কোডের জন্য কভারেজটি ওঠানামা করে (আমি এখনও নিম্ন-স্তরের শ্রেণিগুলি পরীক্ষা করা সহজ করি কারণ কর এবং কাস্টম পদার্থবিজ্ঞানের সাথে জগাখিচু করা সহজ; তবে উচ্চ-স্তরের ইউআই / রেন্ডারিং নয়)।

— hsandt