ゲーム開発を扱っている場合、ソフトウェアテストは異なりますか？
私が読んでいたのは この論文 一般的なソフトウェア開発とゲーム開発の違いについてであり、著者はソフトウェアテストに関していくつかの良い点を指摘しました。
...ゲーム開発者は、自動化されたテストの使用をためらっています。なぜなら、これらのテストは、ゲームデザイナーの創造的な欲求の変化に直面して急速に陳腐化しているためです。
それで、この読書は私に、ゲームを扱っている/テストしているとき、ソフトウェアテストの他のどのような側面を異なるまたは特定のものとして考慮すべきかを考えさせましたか？誰かがこれについての経験がありますか、それについて誰かが何か聞いたことはありますか？
現代のゲームは、実際には社内または独自のゲームエンジンを使用して開発された大量のクリエイティブアートコンテンツです。エンジン自体は、ほとんどの部分（レンダリング、ジオメトリ、物理、AIモジュールなど）の単体テストが可能です。同様に、開発されたコンテンツの個々の部分に簡単なテストを添付することもできます。これは、ユニットとホワイトボックスのテストが実際に実行可能で成功していることを意味します。
「全体としての製品」に関する限り、ゲームはシミュレーションです。単純なビジネスプログラムよりも生成が複雑になる可能性があります。無限の、ユニークな、手続き型の生成された世界と、数えきれないほど計画された動作を持つエンタープライズリソースプランナーとを考えてください。簡単に言えば、ゲームのコンテキストで何かを行うための可能なユニークな方法の数は、数学的には非常に大きくなる可能性があります。実際には、ゲームのセールスポイントと見なされます。
これに加えて、最終出力は純粋にオーディオビジュアルであり、そのような出力の絶対的な正確さの確定的な基準はありません。 GPUチップは実際には正確な計算を実行する必要はありません。正確でない場合でも、大量の計算を実行する必要があります。
そして最後に、主な目標はEntertainmentです。ゲーマーは、60以上のFPSを実行し、見栄えが良く、何時間にもわたる面白いコンテンツがあれば、グリッチで問題ありません。
これは単に、ゲームに適用される場合、従来の自動化されたブラックボックステストのアイデアを「それほど具体的ではなく価値がある」領域に配置するだけです。
ただし、 NNをトレーニングしてゲームをプレイする の試みが最近行われています。これは、事実上、探索的で自己学習型のサルのテストの形式です。
Gamedevを作成してから何年も経ちましたが、Niceの回答に加えて、追加したいことがいくつかあります。
最初にすでに述べたように、出力は厳密な「FPSクリティカル」制約と計算/メモリバジェットに対して視覚的および聴覚的であるだけです。質問が次のようなものである場合、正確さのアイデアはぼやけます"それは見栄えがいいですか？それは途切れることなくスムーズに実行されますか？それは素晴らしい音ですか？"開発者がデザイナー/開発者のコラボレーションは、すべての迅速な反復で見た目や音が少し異なることにつながります。
もう1つは、テスターが素晴らしいということです。ソフトウェアをテストするためのwantであるため、他のドメインでより専用のテスターグループを見つけたことはありません。彼らは楽しんでいます。ゲームの隅々まで探索している間、彼らは中毒になってコンピューターの隣で寝ています。実際にソフトウェアに夢中になっている間にソフトウェアの隅々まで徹底的にテストする人々が実際に楽しまれるとき、あいまいなグリッチさえ発見することはかなり簡単になります。私の現在の業界では、テスターの多くはソフトウェアに生計を結び付けている専門家であり、作業を完了するために少数の機能に依存しているため、テスターは作業が少し難しいです。いつも隅から隅まで。当然、人間のテスターに大きく依存することができない場合は、さらに自動化されたテストが必要です。
さらにもう1つは、ゲームのコードベースは通常、何年も維持および変更されず、拡張されないことです。これは、6502アセンブリで最初に開発したスーパーマリオの開発者が、ゲームが出荷された後も元のコードに似たものを維持する必要があったのとは異なります。 Doom 3はおそらくDoom 1のコード行をゼロ（またはクローズ）にします。フランチャイズが継続している場合、新しいゲームは「アップグレード」ではなく「続編」に似ています。ほとんどのゲームは出荷され、おそらくいくつかのパッチ、DLCをリリースするだけで、コードが完成します。これは、何十年も移植され維持されてきたAmigaの時代にさかのぼるコードの維持に取り組んできた私のVFX業界とは非常に対照的です。通常、ゲームには30年前のコードベースがなく、10年前のコードベースが現在も維持されており、積極的に変更されています。
ゲームコードベースのこの短命な性質の理由の1つは、ハードウェアに非常に結びついていることです。それらを最先端の性質とFPSクリティカルな要件と組み合わせると、ハードウェアの詳細を抽象化する方法で開発することはできません。彼らはしばしばハードウェアのターゲット世代のために非常に特別に書かれており、PS3がPS4に置き換わってからPS3が廃止されてPS5に置き換わる、などということになるのはそれほど速くありません。ハードウェア機能はゲームの設計と開発において極めて重要な役割を果たしているため、PS4用に記述されたものと同じコードの多くをPS4用に維持することは一般的には価値がありません。何世代にもわたって続くほとんどのゲームフランチャイズは、大部分が最新のハードウェア用にゼロから開発された次世代エンジンを今でも書いています。
存続期間の短いコードベースでは、メンテナンス時間が制限されます（つまり、コードを変更する必要がある時間が制限されます）。アップグレードするたびにエンジンの規模がどんどん大きくなるため、コードが変更される期間は限られており、ゲームがミッションクリティカルに近づいていないという事実と相まって、そのような絶対的なものはありません最も徹底的なユニットと統合テストを適用する重要な必要性。将来の変更が行われない場合に、将来の変更の整合性を確保することでそれを行うメリットはありません。最初に「レガシー」がない場合、レガシーコードベースのユニットテストとリファクタリングの側面は当然無関係です。
常に関連があるとは限らないもう1つの小さな問題は、ゲームがデスクトップポートなしで非常に狭い範囲のハードウェアのみをターゲットにする可能性があることです。これらの場合、これらの状況での予測できないグリッチの巨大な原因、つまり根本的に異なるハードウェアとドライバーでソフトウェアを実行しているユーザーが排除されます。
とはいえ、最高/最も粗いレベルでの統合テストはすぐに役立つ傾向があります。たとえば、多くのゲームでは、「リプレイ」のためにゲームの状態が時間の経過とともにどのように変化するかを記録する方法を利用する場合があります。このようなリプレイ機能は、ゲームが確定的であることを保証し、他の誰かが以前に記録したゲームセッションをリプレイするためのテストツールの形式として使用することもできます。
小さなスタジオでゲーム開発者がボットを作成してゲームを最高速度でプレイし、そのシミュレーションを実行させたところ、最初は1日か2日後にあいまいなクラッシュが発生し、その後修正しました。シミュレーションを再度実行し、何週間も実行した後でも、表示を停止するクラッシュがなくなるまで繰り返しました。したがって、ゲーム開発者がソフトウェアをテストするために私が見たような、実用的なアプローチには興味深い種類がありますが、多くの場合、最も粗いレベルの統合テストに似ており、プレイヤーが実際にゲームを操作する方法に非常に近いものをシミュレートします。
最後に、これらの大きなAAAゲームエンジンはまったく異なる種類の獣に似始めています。長寿命で、ハードウェアの抽象化に成功し、コードベースが大きくなり、メンテナンススパンが長くなり、レベルエディターが本格的な開発環境に似始めています。特にそれらのコードが維持される時間が大幅に拡大する場合、これらの大きなエンジンはおそらくより徹底的なテスト手順を必要とするでしょう。それでも、多くのゲームスタジオは巨大なAAAゲームエンジンを作成していません。ライセンスを付与するか、範囲がかなり狭く、何年も維持されない小さな独自のエンジンを開発しています。