Oyun geliştirmede otomatik testler ne kadar yaygındır? [kapalı]

Oyun geliştiricileri birim ve entegrasyon testleri yazmak için kullanıyor mu? Bulmaca geliştiricileri arasında ne kadar yaygındır? Ve MMORPG ve FPSes geliştiricileri arasında?

(Oyun geliştirme konusunda hiçbir geçmişim yok, onunla çalışmaktan da korkuyorum - bu sadece başıma gelen bir şüphe. O yüzden, zaten otomatikleştirilmiş testler yazmayı sevdiğim için bile beni onları yazmaya ikna etmeye çalışmak zorunda kalmayacağım . )

Genel olarak, oyunların birim ve entegrasyon testleri o kadar yaygın değildir. Bunun nedeni oyunların gerçeklenme yönünün genellikle oyun mekaniğinin geri kalanına yakından bağlı olmasından kaynaklanmaktadır.

Bununla birlikte, oyun geliştirmede birim testi yapılabilir ve kod bunun için ayarlanmışsa büyük yararı olabilir. Bununla birlikte, oyunlara otomatik testler yazmak, genellikle oyunu normal bir oynatıcıdan daha yüksek hızda etkili bir şekilde oynatabilen bir AI programı biçiminde yazmak daha yaygın olabilir. Bu testte otomatik testle ilgili olarak bunu yapan geliştiricilerin mükemmel hikayeleri var . Bu tür otomatik testler potansiyel olarak daha iyidir, çünkü ünite testleri render motorunda bir hata yakalamayabilir, ancak otomatik testlerin böyle bir sorunu ortaya çıkarması daha olasıdır.

Sonunda, yine de, tüm bunlar stüdyoya bağlı. Bazı stüdyolar bazı otomatik testler gerçekleştirirken, diğerleri yaz boyunca saatlerce oyun oynamak için yaz boyunca 20 lise çocuğunu tutabilirler.

Benim tecrübeme göre, çok yaygın değil.

Çoğunlukla ünite testi yapılmaz çünkü çoğu oyun geliştiricisi böyle şeylerin yaygınlaşmasından önce bir zaman ve kültürden gelir ve bu nedenle bu tür yöntemlerin gerekli olduğu iddiasını şimdi yapmak zordur. Bu, son yıllarda kullanıcının piyasaya sürüldükten sonra kendi yazılımını yamalayabileceği beklentisiyle daha da gerçek oldu.

Kısmen bunun nedeni oyun geliştirme endüstrisindeki baskın dilin C ++ olması ve ünite testlerinin diğer dillerden biraz daha hantal olmasını sağlamasıdır. Birim test çerçeveleri mevcuttur, ancak test durumlarının tespitini hızlandırmak için yansıma ve benzer püf noktalarını kullanabilen daha modern dillerde benzer sistemler kadar kullanımı kolay değildir.

Ayrıca, oyunlar genellikle kendilerini birim testlerine borç vermedikleri için - mantığın çoğu yarı deterministik kaynaklara (örn. Grafik donanımı, giriş zamanlamaları, kare hızı) bağlıdır, çıktının büyük kısmını ölçmek zordur (örn. Ekrandaki grafikler, ses efektleri) ve bazıları oyunun tam bağlamı dışında (örneğin, karmaşık reaktif AI, fizik simülasyonları) neredeyse anlamsız. İstisnalar var - çoğu, kodu bu şekilde yapmak için çok çalışıyorsanız - ancak tüm testlerde oyunlarda diğer yazılım türlerine göre daha pahalıdır ve bu nedenle maliyet / fayda oranı daha şüphelidir.

Entegrasyon testi gelince, oyun geliştirmede açıkça kullanıldığını açıkça duymadım ama birçok geliştirici mümkün olan tüm sistemin otomatik testlerini yaptı. Tahmin ediyorum, belki de 3 profesyonel geliştiriciden 1'i bunu yapmak isterim, çünkü her zaman kurulumu kolay değildir ve büyük olasılıkla her geliştiricinin (veya yayıncısının) bir QA'sına sahip olmasının faydaları azalır. manuel olarak benzer testleri yapacak olan departman. KG, genellikle geliştiricilere göre çok daha az ödenir; bu nedenle, üzerine fazladan kod zaman harcamak yerine, testlerden kendilerine ayrılmak ekonomik olabilir. (Kontrollü.)

Bir oyun yazmanın, testler kadarıyla herhangi bir yazılımdan ne kadar farklı olduğunu anlamıyorum. Yazılımın her bir bileşeni, ister zamanlanmış bir olayı tetiklediğini, ister oyun içi karaktere komut göndererek ya da menü düğmelerine basarak, uygun yürütme için test edilmelidir.

Oyunun tamamlanmasının mümkün olup olmadığını test etmek farklı bir konudur ve ünite veya entegrasyon testlerine girmez.

Genel olarak, kullanıcı arayüzü testini otomatikleştirmek (normal programlarda bile) normal otomasyondan daha zordur. Bu nedenle, oyunlarınız için birim testleri yazabilseniz de, asıl oyunu test etmek daha zordur. Çoğu şirket oyunu çalıştırmak insan test kullanmak zaman tekrar.

Örneğin İşte onlar küçük Game Studio (2 Devs) bu işler nasıl açıklayan bir makale. Okuduklarımdan itibaren doğrulamaları çok ayrıntılı gözükmüyor gibi görünüyor (otomasyon oyunu başlatıyor ve herhangi bir hatayı / iddiasını kaydediyor).

Bununla birlikte, bazı şirketler yarı otomasyon konusunda oldukça başarılıdır (Microsoft Test Studios gibi). Diğer bir deyişle, Geliştiriciler veya SDET'ler, oyunu test etmeyi çok kolaylaştıran araçlar oluşturur. Örneğin Crackdown'ı veya Fable'ı nasıl test ettiklerini tartıştıkları Gamefest konuşmaları yapıldı . Örneğin, hala her nesnenin olması gerektiği yerde olduğunu doğrulayan test ediciler kullanıyorlar, ancak bu konumun anlık görüntüsünü alan bir araç kullanıyorlar, böylece insanın yaptığı tümün oyunu oynamak zorunda kalmadan görsel olarak orada olduğunu doğrulıyor.

İşte , oyunları test etmek için ne tür araçlar geliştirdikleri / kullandıkları hakkında güzel bir konuşma. "Test Lider Mücevherleri: Oyunlarımızın Artan Karmaşıklığının Önüne Çıkmak"

Bununla birlikte, MMO ve çok oyunculu sunucu kodunun biraz daha sık test edildiğine bahse girerim.

En azından, otomatik regresyon testleri yaygındı. Bunları sunucunun başlatılması sırasında toplu akıl sağlığı kontrolleri olarak görmüştüm, örneğin yeni bir "bulut" sunucunun oyuncuları kabul etmeye başlamadan önce doğru bir şekilde yapılandırıldığından emin olmak için; Bu durumda, 3-4 yıldan fazla bir süredir inşa edilmiş oldukça iyi bir regresyon paketi, yaklaşık 4 saniye sürdü, sanal bir ana bilgisayarı (boş bir işletim sistemi görüntüsünden) getirmek neredeyse 10 dakika sürdü, bu yüzden zamana değdi. Aynı testleri Subversion depomuzdaki bir "tinderbox" (sürekli derleme sistemi) üzerinde de denedik, içine sürünmeyi seven bazı sinir bozucu, oldukça yaygın hataları kontrol etmek için. nesnelerin etrafından geçerken kopyalarını oluşturun: nesne başlatması, önbellekleme, ve ağ geçiş kodu% 100'e yakındı; Test edilebilecek her şeyi düşündüğümüzü düşünmeye devam ettik ve sonra da “eğlenceli” yeni bir vaka keşfetti.

Üzerinde çalıştığım bazı MMO'larda, ilk birim testini gerçekleştirmek için "saplama istemcileri" geliştirdik ve genellikle yeni özelliklerin geçici birim testini yapmak için "operatör" komutları verdik. Bu, istemci bundan yararlanmaya hazır olmadan önce sunucu kodunu çalıştırmamıza izin verir ve hata kurtarma işleyicilerinin iyi çalışmasını sağlamak için "imkansız" durumları (örneğin bir duvarın içine bir oyuncuyu ışınlamak) uygular. Sunucuda çevrimiçi olarak yeni bir özellik oluşturmak bazen bunun için müşteri desteğinden daha az gün alabilir; tersine, bazen bizden önce gelirlerse sahte ama iyi biçimlendirilmiş verileri döndüren müşteri için "sahte" bir sunucu yöntemi oluşturmak zorunda kalırdık.

Ancak, genel olarak MMO gelişimi, çevreyi yansıtabilecek bu tür sorunların çoğuna maruz kalmaktadır. Gömülü oyun sistemlerinde çalışırken, “test etme”, yeniden kullanılabilir bazı widget kodları (örn. Metin editörleri) dışında hiçbir şey için neredeyse hiç duyulmamış bir durumdu.

Otomatik testlerin Oyun Geliştirmede bu kadar yaygın olmamasının bir başka nedeni de, çoğu oyun için, oyun piyasaya sürüldüğünde Oyun Beta'ya katılımın bir "avantaj" olduğunu düşünen pek çok Beta testi gönüllüsü olmasıdır. Otomatik testler elbette kalite gereksinimlerinden değil, aynı zamanda bütçe kısıtlamalarından da çıkmıştır. Bu nedenle, oyunlarda ücretsiz olarak denemeye hazır çok sayıda deneyimli test cihazı bulunduğundan, belki de bu otomatik testlerin bu kadar yaygın olmamasının bir başka nedenidir.

GDC 2011'de otomatik testler hakkında bir yuvarlak masa toplantısına katıldım . IIRC, odada yaklaşık 60 kişi vardı. Bir noktada moderatör birim test kapsamı anketi yaptı. Orada bir kişi % 90 daha kod kapsama iddia etti. Diğer herkes, % 1 oranında bir kapsama alanına girme düşüncesiyle güldü . Eğer bu grup bir bütün olarak sektörün adil bir temsili ise, otomatikleştirilmiş testlerin genel olarak pek bir şey olmadığını söyleyebilirim.

Buradaki diğer cevaplar neden olarak iyi sebepler vermektedir. İlk elden hesap açmanın faydalı olacağını düşündüm.