Seberapa umum pengujian otomatis dalam pengembangan game? [Tutup]

Apakah gamer pengembang gunakan untuk menulis unit dan tes integrasi? Seberapa umumkah itu di antara para pengembang puzzle? Dan di antara pengembang MMORPG dan FPSes?

(Saya tidak memiliki latar belakang dalam pengembangan game, saya juga tidak tertarik untuk bekerja dengannya - itu hanya keraguan yang terpikir oleh saya. Jadi, tidak perlu mencoba meyakinkan saya untuk menulisnya, bahkan karena saya sudah suka menulis tes otomatis. )

Secara umum, pengujian unit dan integrasi gim tidak umum. Ini sebagian besar karena aspek rendering permainan biasanya terkait erat dengan mekanik permainan lainnya sehingga sangat sulit untuk benar-benar menulis unit test yang berfungsi.

Yang mengatakan, pengujian unit dapat terjadi dalam pengembangan game, dan jika kode diatur untuk itu, itu bisa sangat bermanfaat. Namun, bisa jauh lebih umum untuk menulis tes otomatis untuk gim, biasanya dalam bentuk program AI yang secara efektif dapat memainkan gim dengan kecepatan lebih tinggi daripada pemain normal. Ada beberapa kisah luar biasa dari pengembang yang melakukan hal itu dalam pertanyaan tentang pengujian otomatis ini . Pengujian otomatis semacam ini berpotensi lebih baik, karena pengujian unit mungkin tidak menangkap bug di mesin render, tetapi pengujian otomatis lebih mungkin untuk mengekspos masalah seperti itu.

Pada akhirnya, ini semua tergantung pada studio. Beberapa studio akan melakukan semacam pengujian otomatis, sementara yang lain mungkin hanya mempekerjakan 20 anak sekolah menengah selama musim panas untuk bermain game mereka selama berjam-jam.

Dalam pengalaman saya, itu tidak terlalu umum.

Sebagian besar pengujian unit tidak terjadi karena sebagian besar pengembang game berasal dari waktu dan budaya sebelum hal-hal seperti itu tersebar luas, dan karena itu sulit untuk membuat argumen sekarang karena metode seperti itu diperlukan. Ini menjadi lebih benar dalam beberapa tahun terakhir dengan harapan bahwa pengguna dapat menambal perangkat lunaknya sendiri setelah rilis.

Sebagian karena bahasa yang dominan di industri pengembangan game adalah C ++ dan itu membuat pengujian unit sedikit lebih rumit daripada bahasa lain. Kerangka kerja pengujian unit ada tetapi tidak semudah menggunakan sistem serupa dalam bahasa yang lebih modern yang dapat menggunakan refleksi dan trik serupa untuk mempercepat deteksi kasus uji.

Juga, itu karena permainan umumnya tidak cocok untuk pengujian unit - banyak dari logika tergantung pada sumber semi-deterministik (misalnya perangkat keras grafis, timing input, frame rate), sebagian besar output sulit diukur (misalnya. pada layar grafis, efek suara) dan beberapa hampir tidak berarti di luar pembuatan konteks permainan penuh (mis. AI reaktif kompleks, simulasi fisika). Ada pengecualian - banyak, jika Anda bekerja keras untuk membuat kode seperti itu - tetapi secara keseluruhan pengujian lebih mahal dalam game daripada di sebagian besar jenis perangkat lunak lain dan karenanya rasio biaya / manfaat lebih meragukan.

Sedangkan untuk pengujian integrasi, saya belum pernah mendengar istilah yang secara eksplisit digunakan dalam pengembangan game tetapi banyak pengembang melakukan tes otomatis dari seluruh sistem jika memungkinkan. Pada tebakan saya akan mengatakan mungkin 1 dari 3 pengembang pro melakukan ini, karena tidak selalu mudah untuk mengatur, dan karena manfaatnya berkurang oleh fakta bahwa hampir setiap pengembang menengah ke besar (atau penerbit mereka) memiliki QA departemen yang secara manual akan melakukan tes serupa. QA biasanya dibayar jauh lebih sedikit daripada pengembang sehingga dianggap ekonomis untuk menyerahkan pengujian kepada mereka, daripada menginvestasikan waktu kode tambahan untuknya. (Kontroversial.)

Saya tidak melihat bagaimana menulis permainan berbeda dengan perangkat lunak lain sejauh pengujian berlangsung. Setiap komponen perangkat lunak, apakah itu memicu peristiwa waktunya, mengirim perintah ke karakter dalam game, atau menekan tombol menu, harus diuji untuk eksekusi yang tepat.

Menguji apakah permainan bisa diselesaikan adalah masalah yang berbeda dan tidak termasuk dalam unit atau pengujian integrasi.

Secara umum pengujian UI otomatis (bahkan dalam program reguler) lebih sulit daripada otomatisasi biasa. Jadi meskipun Anda bisa menulis unit test untuk gim Anda, menguji gim yang sebenarnya lebih sulit. Sebagian besar perusahaan menggunakan penguji manusia yang menjalankan game berkali -kali.

Sebagai contoh, Berikut adalah artikel yang menjelaskan bagaimana mereka melakukannya di Game Studio kecil (2 devs). Dari apa yang saya baca sepertinya validasi mereka tidak terlalu detail (otomatisasi memulai permainan dan mencatat kesalahan / pernyataan).

Namun beberapa perusahaan sangat sukses dengan semi otomatisasi (Seperti Microsoft Test Studios). Artinya, Pengembang atau SDET membangun alat yang membuat pengujian game lebih mudah. Ada pembicaraan Gamefest di mana mereka membahas bagaimana mereka menguji Crackdown misalnya atau Fable. Misalnya, mereka masih menggunakan penguji yang memverifikasi bahwa setiap objek berada di tempat yang seharusnya tetapi mereka menggunakan alat yang mengambil snapshot dari lokasi itu sehingga semua yang dilakukan manusia secara visual memverifikasi itu ada di sana tanpa harus bermain game.

Berikut ini adalah pembicaraan yang baik tentang alat apa yang mereka bangun / gunakan untuk menguji permainan. Ini disebut "Test Lead Gems: Keluar di Depan Kompleksitas yang Meningkat dari Permainan Kami"

Saya ingin bertaruh bahwa MMO dan kode server multipemain, sedikit lebih sering diuji.

Paling tidak, tes regresi otomatis sudah biasa dilakukan. Saya telah melihat ini diimplementasikan sebagai pemeriksaan kewarasan massal selama server start-up, misalnya memastikan bahwa server "cloud" baru dikonfigurasi dengan benar sebelum mulai menerima pemain; suite regresi yang cukup bagus yang dibangun selama 3-4 tahun, dalam hal ini, berlari dalam waktu sekitar 4 detik, sementara membawa host virtual (dari gambar OS kosong) membutuhkan waktu hampir 10 menit, jadi itu layak waktu. Kami menjalankan tes yang sama pada "tinderbox" (sistem pembangunan berkelanjutan) pada repositori Subversion kami untuk memeriksa beberapa kesalahan yang cukup umum dan menyebalkan yang suka menyusup kembali. Secara khusus, fungsi multi-server memiliki kebiasaan buruk dalam mencoba untuk membuat duplikat objek saat mereka diedarkan: objek objek, caching, dan kode kelulusan jaringan mendekati 100% tercakup; kami terus berpikir bahwa kami telah memikirkan segala hal yang dapat diuji, dan kemudian menemukan beberapa "menyenangkan," kasus tepi baru.

Di beberapa MMO yang telah saya kerjakan, kami juga akan mengembangkan "rintisan klien" untuk melakukan pengujian unit awal, dan biasanya memberikan perintah "operator" untuk melakukan pengujian unit ad-hoc fitur baru. Ini memungkinkan kami mengeksekusi kode server sebelum klien siap untuk mengambil keuntungan darinya, dan melakukan situasi yang "tidak mungkin" (misalnya memindahkan pemain di dalam dinding) untuk memastikan bahwa penangan pemulihan kesalahan akan bekerja dengan baik. Membawa fitur baru secara online di server terkadang membutuhkan waktu berhari-hari kurang dari dukungan klien untuk itu; sebaliknya, kadang-kadang kita harus membuat metode server "dummy" untuk klien, mengembalikan data palsu tapi terbentuk dengan baik, jika mereka mendahului kita.

Namun, pengembangan MMO secara umum lebih banyak mengalami masalah seperti ini, yang mungkin mencerminkan lingkungan. Ketika saya sedang bekerja pada sistem permainan tertanam, "pengujian" praktis tidak pernah terdengar untuk apa pun kecuali beberapa kode widget yang dapat digunakan kembali (misalnya editor teks).

Alasan lain mengapa pengujian otomatis tidak umum dalam Pengembangan Game yang dapat dipertimbangkan adalah bahwa untuk sebagian besar game ada banyak sukarelawan pengujian Beta yang menganggap partisipasi Game Beta sebagai "ujung" ketika game dirilis. Pengujian otomatis tentu saja tumbuh dari persyaratan kualitas, tetapi juga di luar batasan anggaran. Oleh karena itu, karena dalam permainan ada banyak penguji berpengalaman yang siap untuk menguji secara gratis, mungkin inilah alasan lain mengapa tes otomatis tidak tersebar luas.

Saya berpartisipasi dalam diskusi meja bundar tentang pengujian otomatis di GDC 2011 . IIRC, ada sekitar 60 orang di ruangan itu. Pada satu titik, moderator mengambil survei cakupan unit test. Ada satu orang yang mengklaim cakupan kode lebih dari 90%. Semua orang menertawakan membayangkan akan mencapai 1% pertanggungan. Jika grup itu adalah representasi industri yang adil secara keseluruhan, saya akan mengatakan pengujian otomatis umumnya tidak banyak terjadi, jika tidak sama sekali.

Jawaban lain di sini memberikan alasan yang bagus mengapa. Saya hanya berpikir akan bermanfaat jika memiliki akun tangan pertama.