نگران نیستیم! در حاشیه انتشار کاریکاتور منتسب به خبرگزاری تسنیم

پوریا احمدی

۱۳۹۶/۱۰/۲۳

CBO
b

مدلسازی با Raymarching و میادین فاصله در یونیتی

سید مرتضی کمالی

۱۳۹۶/۱۱/۲۷

راهنمای ارسال مقالات برای گیمولوژی

علیرضا محمدی

۱۳۹۷/۰۱/۲۷

سردبیر
b

شیدر نویسی در یونیتی (بخش دوم)

سید مرتضی کمالی

۱۳۹۶/۰۸/۱۳

چالش‌های بازگشت بازیکنان به بازی

سمیرا دولت‌آبادی

۱۳۹۶/۰۸/۰۲

عضو تحریریه
b

شیدرنویسی در یونیتی (بخش اول)

سید مرتضی کمالی

۱۳۹۶/۰۷/۲۶

مارکتینگ بازی: طراحی برنامه

سمیرا دولت‌آبادی

۱۳۹۶/۰۷/۲۰

عضو تحریریه
b

باز‌ی سازان بزرگ چطور شما را گول می‌زنند؟

فرناز حقیقت

۱۳۹۶/۰۶/۱۶

روابط عمومی
b

قابلیت‌های آنلاین در بازی‌های تک نفره

رهام سجادی

۱۳۹۶/۰۷/۱۵

عضو تحریریه
b

پرونده تست بازی: روش‌ها و حوزه‌های مختلف تست

*** قسمت اول این پرونده را از اینجا مطالعه نمایید***

1- محدوده و تعاریف

این آزمون در نگاهی ساده برای شناسایی باگ های موجود در نرم‌افزار است تا بتوان آن‌ها را رفع کرد. شیوه‌های مختلفی از آزمون‌ها و روش‌های آزمایش کردن وجود دارند که می‌توان آن‌ها را به عنوان روش «Black Box» و روش «Clear Box» دسته‌بندی کرد. (روش Clear Box در صنعت طراحی نرم‌افزار با نام «White Box» هم شناخته می‌شود)

2- فلسفه تست

این امتحان کردن‌ها در واقع نه کار یک نفره است و نه مسئولیت تیم تست بازی و نرم‌افزار. هر کسی که عضوی از تیم طراحی بازی و یا نرم‌افزار است باید این نکته را در ذهن داشته باشد و هر عضو گروه مسئول کیفیت و کمیت کاری است که در حال انجام آن است. این شیوه آزمایش کردن تنها روش موجود نیست و هرگز نباید در انزوا انجام شود.

برنامه‌ریزی آزمون و نیازمندی‌هایش

1- مشخص کردن نیازمندی‌ها

نیازمندی آزمون یکی از اهدافی است که حتماً باید مشخص شود. تستر حتماً باید نیازمندی‌های یک بازی را بداند و آن‌ها را تبدیل به شرایط عملکردی کند(برای مثل، چه چیزهایی باید سنجیده شوند، چه چیزهایی قابل سنجش هستند، اهداف و هدف‌گیری‌ها و ...) تا طراحی و پیاده‌سازی جزییات به طراحان سپرده شود.

2- مشخص کردن محدوده‌های زمانی

وقتی یک پروژه بازی‌سازی برای یک بازه زمانی خاص برنامه‌ریزی شده است؛ ما باید یک نقطه شروع برای پروژه در نظر بگیریم تا زمان کافی برای تستر ها فراهم شود تا فعالیت‌هایی نظیر: تکرار تست برای به‌روزرسانی و یا ویژگی‌های تازه بازی، چرخه کامل آزمون پسرفت برای هر نسخه، آزمون پسرفت کافی برای مشکلات قبلی، باگ های بسته‌شده و یک آزمون پسرفت کامل برای بخش‌های اتفاقات، دنیا و محیط انجام‌شده تا بازی برای نسخه آلفا، بتا و نسخه نهایی آماده شود. این نقطه آغازین با توجه به بازی تحت ساخت متفاوت خواهد بود و تستر ها باید نیازمندی‌های روش «Bare Bone» را شناخته و با مدیر پروژه همگام شوند.

تست بازی و روش‌های تست

اسناد اولیه تست بازی برخی از ویژگی‌ها و وجوه آزمایش بازی را به خوبی توضیح می‌دهند. این بخش شامل بررسی تست سیستماتیک است و توضیح می‌دهد چگونه می‌توان بخش‌های مختلف بازی را به کوچک‌ترین بخش‌های قابل تست تقسیم بندی کرد:

1- اجزای بازی و ریز کردن ساختار

تست بازی به معنا امتحان کردن تمامی بخش‌های بازی است. این قسمت شامل:

·         منو و عملیات‌های آن

·         طراحی هنری (مدل شخصیت‌ها، بافت، زمین یا دنیا، جمعیت، اشیاء و ...)

·         انیمیشن (حس و حال تحرک، واقعی بودن، نرخ فریم و ...)

·         صدا و افکت‌های صوتی ( در گرو بخش انیمیشن : هماهنگی صدا با حرکت لب و زمان‌بندی انیمیشن)

·         موسیقی

·         دوربین ( منظره سینمایی، زوم بیرون یا داخل، بازبینی)

·         جریان بازی و منطق

·         دنیا، مرحله و سکانس

·         ویژگی‌های بازیکن

·         ویژگی‌های اکشن

·         شرایط رسیدن به مرحله بعدی (قوانین رسیدن به مرحله بعدی چیست؟)

·         استفاده از اشیاء محیطی

·         راه‌اندازی اتفاقات و یا اشیاء

·         سیستم امتیازدهی

·         پیشرفت درجه سختی

·         منطق هوش مصنوعی (هم برای بازی دفاعی و هم برای بازی تهاجمی، حرکت بازیکن و نحوه قرارگیری)

·         آمار (قبل و بعد از بازی؛ برای مثال آمار بازی و بالاترین امتیازها)

·         صفحه آغازین

·         NIS (سکانس های غیر تعاملی)

·         SFX ( جلوه‌های ویژه صوتی)

·         هر گونه کلیپ تصویری

·         استفاده از دسته بازی

·         استفاده از دستورهای چند دکمه‌ای (در اصطلاح همان فشار دادن چندین دکمه همزمان)

·         اسانی در استفاده از دکمه‌ها

·         شوک و یا لرز موجود در دسته بازی

·         استفاده از حالت دیجیتال و آنالوگ

·         فرم های قانونی

·         گزینه‌های بازی ( شروع بازی یا انتخاب منو، راهنماها، توقف بازی، منو توقف بازی و گردش بین منو های مختلف در روی صفحه)

2- تکنیک های تست بازی (نکات و روش‌ها)

در بخش جزییات و تکنیک های مختلف تست ذکرشده‌اند:

·         حتماً باید کل صفحه بررسی شود نه یک بخش کوچک از آن

·         آشنایی با قوانین بازی و قوانین تست گیم پلی و روی به روی هم قرار دادن این قوانین

·         تست برای مختصر کردن (برای این که دو یا پند پولیگان یا پولیگان اشیاء  را باهم بپوشانیم یا آن‌ها را باهم خنثی کنیم)

·         بررسی همپوشانی (در جایی که یک شی نیمه شفاف بر روی یک شی جامد رنگ تر و یا پیش‌زمینه قرار می‌گیرد) و اینکه همپوشانی در اندازه و جای مناسب انجام شده است تا هدف و اطلاعات مورد نیاز آن فراهم شود.

·         تست برای یافتن برخوردهای صحیح و غیر صحیح (شرایطی که در آن دو شی باید باهم برخورد داشته باشند). تصور کنید که دو ماشین در حال برخورد به هم هستند. این دو ماشین باید در بخورد دچار آسیب شوند. در مورد فیزیک هم برخورد زمانی انجام می‌شود که دو شی با جرم همسان به همان میزان و در جهت مخالف تکانه ایجاد کنند. به این ترتیب وقتی یک هواپیما با زمین برخورد می‌کند این هواپیماست که باید تأثیرات برخورد را نشان بدهد زیرا هواپیما در مقایسه با زمین از جرم کمتری برخوردار است.

·         شخصیت قابل بازی را از میان تمام اشیا و مراحل عبور داده و تغییراتش را مورد مطالعه قرار دهید (ممکن است باعث برخورد، رخداد شی و یا رخداد یک اتفاق شود)

·         تست Grayed Out (برای وقتی که یک گزینه و یا ایکون قابل انتخاب نباشد)

·         تست بارگذاری و ذخیره کردن بازی توسط دستگاه ذخیره‌سازی ( دیسک سخت و یا کرات ذخیره‌سازی) و مطمئن شدن از نمایش پیغام‌های صحیح روی صفحه

·         مطمئن شدن از پیغام صحیح بارگذاری و نشان‌دهنده‌های عملیات بارگذاری (خط بارگذاری) روی صفحه نمایش

·         مطمئن شدن از مدت زمان مناسب برای بارگذاری (هیچ کس دوست ندارد بیشتر از بیست ثانیه صبر کند)

·         گشتن دنبال توقف‌های کوچکی که ممکن است در بازی به وجود بیایند اما به صورت کامل باعث ثابت و به هم ریختن بازی نمی‌شوند. این اتفاق به عنوان مانعی برای گیم پلی به حساب می‌آید.

·         تست برای بخش چندنفره (بازی چندنفره روی یک دستگاه و بازی آفلاین) وقتی که دو و یا چند بازیکن بر روی یک دستگاه بازی می‌کنند.

·         تست بازی برای پیدا کردن نشت حافظه و پر شدن حافظه به هنگام اجرای بازی

·         تست محدوده‌های بازی (همان طور با نام انتها و یا لبه دنیا شناخته می‌شود). بازی نباید به بازیکن اجازه بدهد تا از حریم‌های بازی عبور کند زیرا بازی در این صورت ناپایدار می‌شود. (برای مثال  کرش کردن، از بین رفتن باف ها، گیر کردن شخصیت بازی در بخش‌های خاصی از نقشه)

·         تست برای سازگاری با پلتفرم. پلتفرم مورد نیاز برای تست بازی نیاز به تلاش‌های فراوانی برای تست بازی‌های PC و بازی‌های آنلاین دارد:

برای یک بازی PC آزمایش سیستم‌عامل‌هایی چون ویندوز 95 ،97 ،98، 2000 و NT (این بخش شامل نصب، حذف نصب و گیم‌پلی بازی می‌شود). همچنین آزمایش کارت‌های صدا و گرافیک و لوازم جانبی مختلف موجود در بازار (بررسی مدل های مختلف لوازم جانبی با مدیر بخش فنی)

·         تست قابلیت شبکه بازی با سرعت‌های مختلف مودم و اینترنت (عمق و پوشش برای آزمایش شبکه بازی بزرگ‌تر خواهد شد اگر بازی برای انجام به سرور متکی باشد و از بازی چندنفره استفاده کند)

·         اگر بازی قرار است برای کشورهای اروپایی عرضه شود تبدیل PAL را هم بررسی کنید ( بازی‌های ما امروزه برای آمریکای شمالی عرضه می‌شود و ما از NTSC استفاده می‌کنیم)

·         تست برای بومی‌سازی (نیاز به زبان‌های خارجی) اگر مورد نیاز بود. این لیستی از تکنیک های معمول برای تست بازی است. با این حال این یک لیست کامل نیست. اگر از یک تستر باسابقه سوال کنید او به شما پیشنهاد خواهد کرد تا از ذهن خود استفاده کنید تا در هر کجا که نیاز شد خلاقیت را مورد استفاده قرار دهید.

3- نکات قابل‌توجه برای تست بازی

قبل از این که کارمان تمام شود باید از هشداری هم راجع به Crack Bugها و جایگزین‌ها بدهم زیرا در اکثر موارد با باگ های واقعی اشتباه گرفته می‌شوند:

Crack Bugها: (برای مثال: باگی که در اصل باگ نیست و توسط یکی از طراحان بازی ساخته شده است)

جایگزین‌ها: (برای مثال لقتی مثل Dummy-up روی صفحه نمایش برای زمانی است که بخواهیم تا آماده شدن ویدیو، بافت، موسیقی و یا شی خاص از آن استفاده کنیم)

توسعه برنامه تست بازی

دو حالت مختلف از شرایط تست وجود دارند:

یکی از این  انواع تست مربوط به قابل‌اجرا بودن یک محصول است که در صنعت با نام Positive testing شناخته می‌شود.

 نوع دیگر آزمون دوام و سطح تحمل و مقاومت بازی است که با نام Negative Testing شناخته می‌شود (همان طور با نام‌های Stress Test و یا Load Test هم شناخته می‌شود). نوع Negative این آزمون برای خرد کرد جزییات بازی در ذهن استفاده می‌شوند تا آزمون برای شرایط خاص و برخورد با این شرایط آماده باشد. مثال‌های این شرایط خاص به شرح زیر است:

-          بارگذاری بازی بدون کارت حافظه یا خرج کردن کارت حافظه در حال بارگذاری.

-          اجرا کردن بازی بیشتر از 48 ساعت تا میزان استفاده از حافظه و مدیریت آن را بررسی کرد.

-          وقتی اجزای مختلف بازی به درست از حافظه استفاده نمی‌کنند و بازی را غیرقابل بازی می‌کنند (برای مثال منجمد شدن بازی بعد از مدت زیادی بازی کردن)

-          برای آزمون قابل بازی بودن فکر کنید یک سناریو برای حالت Head-To-Head ورزش Snowboarding در اختیاردارید. ما یک بازیکن 1 داریم که به سرعت در حال حرکت است و زورتر از نفر دوم مسابقه را تمام می‌کند که بسیار کند حرکت می‌کند. از نظر ما بازی باید بتواند این موقعیت‌های حساس را به درستی انجام دهد. (بدون انجماد، کرش، ادامه پیدا کردن امتیازدهی همان طور که باید) تا بازیکن دوم بازی‌اش را تمام کند.

تست برنامه و تکنیک های تست

1-    پروسه تست یک نرم‌افزار

این بخش از مطلب شامل بررسی تست نرم‌افزار است. پروسه‌هایی که معمولا برای تست نرم‌افزار انجام می‌شوند نکات زیر را شامل می‌شوند:

-          بررسی کد: کد منبع و منطق ساختار اصلی آن با توجه به استانداردهای موجود نظیر استفاده از کامنت، تکامل مستندات و یا معانی برنامه بررسی شود.

-          تست تمرکز افزایشی: بررسی بخش و یا اجزای کد با خوراندن آن به مذل های منزوی تر و بررسی حد وسط این نتایج. معمولا تأسیسات اجرایی، ابزار اشکال‌زدایی و یک Dummy Front-End مورد استفاده قرار می‌گیرد تا بررسی توسط اشیا مربوطه انجام شوند.

-          آنالیز اطلاعات: بررسی اطلاعات در پایگاه اطلاعات؛ یا آنالیز یک بخش خاص از سیستم که بخشی از اطلاعات را بهبود می‌بخشد. با دنبال کردن رد آیتم‌های اطلاعاتی در گیم‌پلی تیتر می‌تواند استفاده از داده،تفسیر و دست‌کاری اطلاعات توسط مدل و یا اشیاء را تأیید کند.

-          آزمایش مسیر و جریان: تایید اینکه بخش صحیح اشیاء و یا قطعات برای یک مسیر پایان به پایان استفاده می‌شوند.

-          تست الگوریتم محور: آزمایش یک بازی سناریو خاص بازی و یا تنظیمات خاص (و افزایش سرعت)متغیرها و مقادیر داده به کد و اجرای آن‌ها در تأسیسات اجرایی. با توجه تفاوت‌های تست تمرکز افزایشی، این آزمایش برای تصحیح کد هایست که یک بخش مهمی از بازی را تشکیل می‌دهند.

-          آنالیز هوش مصنوعی: تولید یک نسخه استاتیک و قابل برنامه‌ریزی که از قدرت هوش مصنوعی استفاده می‌کند. این نتایج برای تایید حرکت‌های از قبل طراحی‌شده (مثل گرفتن یک لبه در Snowboard) و یا بازی (جکی چان و ترکیب مشت و لگد در جهت‌های مختلف) استفاده می‌شوند. و در نهایت  تایید اینکه منطق هوش مصنوعی صحیح و منطقی است ( برای مثال در یک بازی بسکتبال اگر امتیاز گیری با دانک 90 درصد باشد و امتیازگیری با پرش 10 درصد داده‌ها منطقی نیست).

2- تکنیک های تست نرم‌افزار (نکات و روش‌ها)

بخش زیر شامل خلاصه‌ای از وظایف و تکنیک های یک تیتر نرم‌افزار می‌شود و هر تستری به هنگام کار بر روی یک پروژه بازی باید از آن‌ها اطلاع داشته باشد.

-          ساختار فایل: هر تستر نرم‌افزاری باید با ساختار فایل رادیکال آشنا باشد. در این زمینه فایل های مکتوب خوبی در زمینه بازی و فن آوری پایه اسناد تکنیکی هم وجود دارند. هدف یادگیری هم صرفاً یادگیری بازی‌های رایانه‌ای و چگونگی جریان آن است تا با نیازمندی‌های فایلی یک بازی آشنا شوید. وقتی که در حال بررسی یک مدل هستید دانستن متود تست بازی و بخش‌های درونی که به آن وابسته‌اند ضروریست. همین موضوع به شما و سرعت باگ یابی شما کمک می‌کند و پروسه آنالیز شما را بهبود می‌بخشد.

-          ساختن فایل: یکی تستر نرم‌افزار مسئولیت ساخت نسخه‌های شبانه را دارد. هر شب یک نسخه با آخرین مدل ها ساخته می‌شود تا فردا صبح همه بتوانند بر روی کد به‌روزرسانی شده کار کنند. گاها اتفاقی غیر منتظره برای نسخه شبانه می‌افتد پس بهتر است نسخه‌ای ساخته شود تا در صورت خراب شدن نسخه شبانه بخش مخرب شناسایی شود. شما می‌توانید از این فایل برای بررسی‌های آینده خود استفاده کنید. معمولا امکان دارد بخشی از کد با بخش‌های دیگر همخوانی نداشته باشند. اینجا وظیفه تستر است مسئولیت به عهده گرفته و مدل ها خراب را بررسی کند و در صورت امکان آن‌ها را تصحیح کند. اگر تصحیح کردن آن‌ها خیلی سخت است بهتر است فردی که مسئولیت نوشتن کد را بر عهده داشته است را خبر کنید. وقتی که مشکل حل شد این نسخه باید دوباره ساخته‌شده و تایید شود. شماره هر نسخه هم باید به صورت خودکار اصلاح شود تا نشانگری برای نسخه روزانه باشد. این شماره‌ها به شما اجازه می‌دهند تا بتوانید رد باگ ها را گرفته و آن‌ها را در نسخه‌ای خاص شناسایی کنید. برای مثال: ممکن است کسی با یک باگ از نسخه‌های اولین نزد شما بیایید. اگر شما بتوانید نسخه درخواستی را شناسایی کنید و بدانیم کدام نسخه تکمیل شده است می‌تواند تبدیل به ترمیم ساده تبدیل‌شده و یک نسخه ترمیم‌شده از آن بسازیم. همین طور ممکن است ایده خوبی باشد تا یک ایمیل فرستاده و آن‌ها را از نسخه جدید مطلع کنیم. نکته دیگری که در ساخت نسخه‌ها مهم است نشان‌گذاری تاریخ عرضه است زیرا ممکن است مشکلی به وجود امده فقط مختص به یک نسخه خاص باشد. متود تست بازی‌های رایانه باعث می‌شود تا از بارگذاری اطلاعات در مکان صحیح مطمئن شویم. در شرایط خاص تر می‌توانید همیشه پایگاه اطلاعات را بررسی کرده و از نبودن ارور اطلاع حاصل کنیم. تکنیک خوب دیگر شانسی سازی بررسی بر روی آمار هر کاربر است تا بدانیم اطلاعات بدست آمده صحیح است.

-          پوشش: حتماً مطمئن شوید که پوشش به صورت کامل بارگذاری شود. یک تستر ممکن است برنامه‌ای برای تأیید پوشش‌ها بنویسد و پس از شناسایی مطمئن شود که فرد دیگری از آن استفاده نمی‌کند.

-          Front End: بیشتر صفحات Front End می‌تواند به آمار متصل شود (که می‌دانید در پایگاه داده موجود است). بهترین کار نگاه کردن به Text Bible است، برای مثال تناسب متن، نام‌گذاری و بررسی آن‌ها بر اساس استانداردهای تولیدکنندگان و نیازهایشان و حتی حجی کردن.

-          نرم‌افزارهای شناسایی باگ: تستر نرم‌افزار باید طریقه کار با PVCS را بداند تا بتواند باگ ها را شناسایی کرده و دنبال کند. همچنین باید طریقه کار با قالب‌های استاندارد را دانسته تا  نقص پایگاه داده را برای پروژه‌های جدید بر طرف کند. این موضوع ممکن است به عنوان حقوق مدیریت شناخته شود و بقیه کاربران را با اکانت مجهز کرده و پایگاه داده را مدیریت کند (ID ورودی کاربران جدید، زمینه‌ها و اطلاعات) .

دیدگاه‌ها

پاسخ
٠
٠

مرتضی کارگر   |   ۱۳۹۶/۰۵/۰۶   |   ۰۴:۱۰

مقاله پر باری بود...ممنون