ゲーム開発における自動テストはどのくらい一般的ですか？[閉まっている]

ゲーマーの開発者は単体テストと統合テストの作成に使用しますか？パズル開発者の間ではどれくらい一般的ですか？そして、MMORPGとFPSの開発者の間で？

（私はゲーム開発には、バックグラウンドを持っていないどちらも私はそれでの作業についてcogitatingています-それは私に起こっただけで疑問であるので、しようとしているの必要はありません。納得それらを書くために私は、私すでになどが自動化されたテストを書くことさえあるため。 ）

一般的に、ゲームの単体テストと統合テストはそれほど一般的ではありません。これは主に、ゲームのレンダリングの側面が他のゲームメカニクスと通常密接に結びついているためであり、実際に動作する単体テストを書くのは非常に難しい場合があります。

そうは言っても、ユニットテストはゲーム開発で発生する可能性があり、そのためのコードが設定されている場合、大きなメリットがあります。ただし、通常は通常のプレーヤーよりも高速でゲームを効果的にプレイできるAIプログラムの形式で、ゲームの自動テストを記述するのがはるかに一般的です。自動テストに関するこの質問には、まさにそれを行っている開発者の素晴らしい話があります。ユニットテストはレンダリングエンジンのバグをキャッチしない可能性があるため、この種の自動テストは潜在的に優れていますが、自動テストではこのような問題が発生する可能性が高くなります。

しかし、最終的には、これはすべてスタジオに依存します。一部のスタジオは何らかの自動テストを行いますが、他のスタジオでは夏に20人の高校生を雇って何時間もゲームを終わらせるかもしれません。

私の経験では、それはあまり一般的ではありません。

ほとんどのゲーム開発者は、そのようなものが普及する前の時代と文化から来ているため、ほとんどのユニットテストは発生しません。したがって、そのような方法が必要であるという議論をするのは困難です。これは、ユーザーがリリース後に自分のソフトウェアにパッチを適用できることを期待して、近年さらに真実になりました。

部分的には、ゲーム開発業界で主要な言語がC ++であるため、ユニットテストが他の言語よりも少し面倒になるからです。ユニットテストフレームワークは存在しますが、リフレクションや同様のトリックを使用してテストケースの検出を高速化できる、より現代的な言語の同様のシステムほど使いやすいものではありません。

また、ゲームは通常単体テストに役立たないためです-ロジックの多くは半決定的なソース（グラフィックハードウェア、入力タイミング、フレームレートなど）に依存し、出力の多くは測定が困難です（例：画面上のグラフィックス、サウンドエフェクト）、ゲームのコンテキスト作成以外ではほとんど意味がありません（複雑なリアクティブAI、物理シミュレーションなど）。例外があります-多くの場合、そのようにコードを作成するために一生懸命働く場合-しかし、テスト全体では、ゲームでは他のほとんどの種類のソフトウェアよりも高価であるため、コスト/メリット比はより疑わしいです。

統合テストに関しては、ゲーム開発でこの用語が明示的に使用されていることは聞いたことがありませんが、多くの開発者は可能な限りシステム全体の自動テストを実施しています。おそらく簡単に設定できるとは限らないため、プロの開発者の3人に1人がこれを行うと思います。これは、ほとんどすべての中規模から大規模の開発者（またはその発行元）がQAを持っているため、同様のテストを手動で実行する部門。通常、QAの費用は開発者よりもはるかに少ないため、テストに余分なコード時間をかけるのではなく、QAにテストを任せる方が経済的と考えられます。（議論の余地がある。）

テストを行う限り、ゲームの作成が他のソフトウェアとどのように異なるかはわかりません。時限イベントのトリガー、ゲーム内キャラクターへのコマンド送信、メニューボタンの押下など、ソフトウェアの各コンポーネントは、適切に実行されるかどうかをテストする必要があります。

ゲームを完了することができるかどうかをテストすることは別の問題であり、単体テストまたは統合テストにあまり該当しません。

一般に、UIテストの自動化は（通常のプログラムであっても）通常の自動化よりも困難です。したがって、ゲームの単体テストを作成できたとしても、実際のゲームのテストはより困難です。ほとんどの企業は、ゲーム時間を実行するヒューマンテスターを使用していますもう一度とします。

例えばここに、彼らは小さなゲームスタジオ（2つの開発者）でそれを行う方法を説明する記事です。私が読んだことから、彼らの検証はあまり詳細ではないようです（自動化はゲームを開始し、エラー/アサートを記録します）。

ただし、一部の企業は（Microsoft Test Studiosなど）半自動化で非常に成功しています。つまり、開発者またはSDETは、ゲームのテストをはるかに簡単にするツールを構築します。Gamefestの講演では、たとえば Crackdownのテスト方法について話し合いました。やFableの。たとえば、彼らはまだすべてのオブジェクトが本来あるべき場所にあることを確認するテスターを使用しますが、人間はその場所のスナップショットを取るツールを使用して、ゲームをプレイすることなく人間が視覚的にそれを確認するだけです。

ここで彼らはゲームをテストする/使用を構築するツールの種類どのように良い話です。「テストリードジェム：ゲームの複雑さの増大に直面する」と呼ばれています

ただし、MMOとマルチプレイヤーサーバーコードは、もう少し頻繁にテストされると思います。

少なくとも、自動回帰テストは一般的です。これらは、サーバーの起動時に大量の健全性チェックとして実装されるのを見てきました。たとえば、新しい「クラウド」サーバーがプレーヤーの受け入れを開始する前に正しく構成されていることを確認します。3〜4年かけて構築されたかなり良い回帰スイートは、その場合、約4秒で実行され、仮想ホスト（空のOSイメージから）の起動には10分近くかかったため、時間の価値がありました。Subversionリポジトリの "tinderbox"（継続的なビルドシステム）で同じテストを実行して、忍び寄るのが好きな厄介な、かなり一般的なエラーをチェックしました。特に、マルチサーバー機能には、渡されたオブジェクトの複製を作成します：オブジェクトのインスタンス化、キャッシュ、ネットワークを通過するコードはほぼ100％カバーされていました。テストできるものはすべて考えて、「楽しい」新しいエッジケースを発見したと考え続けました。

私が取り組んだいくつかのMMOでは、初期スタブテストを実行するための「スタブクライアント」を開発し、通常は新機能のアドホックユニットテストを行うための「演算子」コマンドを提供していました。これにより、クライアントがサーバーコードを利用する準備が整う前にサーバーコードを実行し、「不可能な」状況（たとえば、プレーヤーを壁の内側にテレポートする）を実行して、エラーリカバリハンドラーが適切に機能することを確認できます。サーバー上で新機能をオンラインにすると、クライアントがサポートするよりも数日かかる場合があります。逆に、クライアントのために「ダミー」のサーバーメソッドを作成し、偽造された整形式データが返される場合は、それらを作成する必要があります。

ただし、MMOの開発は一般に、環境を反映する可能性のあるこれらの種類の問題をはるかに多く受けます。私が組み込みゲームシステムで作業していたとき、「テスト」は、再利用可能なウィジェットコード（テキストエディターなど）を除いて、ほとんど前代未聞でした。

自動テストがゲーム開発でそれほど一般的ではないもう1つの理由は、ほとんどのゲームで、ゲームのリリース時に「ベータ版」としてゲームベータ参加を受け取るベータテストボランティアがたくさんいることです。自動テストは、当然のことながら、品質要件だけでなく、予算の制限からも発展しました。したがって、ゲームには無料でテストする準備ができている経験豊富なテスターがたくさんいるので、おそらくこれが自動テストがそれほど普及していない別の理由です。

GDC 2011での自動テストに関する円卓会議に参加しました。IIRC、部屋には約60人がいました。ある時点で、モデレーターは単体テストのカバレッジを調査しました。コードカバレッジが90％を超えると主張する人が1人いました。他の誰もが、1％のカバレッジに達するという考えを笑いました。そのグループが業界全体の公正な代表である場合、自動テストは一般にあまり起こらないと思います。

ここでの他の回答は、理由として十分な理由を示しています。直接アカウントを持っていると便利だと思いました。