実行する65.000.000.000テスト
65.000.000.000個のテストのスイートを実行する方法について尋ねられましたが、このような膨大な量のテストを含むプロジェクトを作成するのは正常なことなのでしょうか。
あなたはこの特徴を持つプロジェクトで働いたことがありますか？
650億回のテストでは、考えられるすべての入力をテストするよう求められているようです。これは役に立ちません。コードが正しいことではなく、プロセッサが正しく機能することを本質的にテストすることになります。
代わりに equivalence classes をテストする必要があります。これにより、テスト入力の範囲が大幅に減少します。
システムをさらに細かく分割できるかどうかも検討してください。各部分を個別にテストする方が簡単です。その後、いくつかの統合テストを実行して、すべての部分を1つにまとめることができます。
これらの入力の組み合わせの一部が機能するという安心感が必要な場合は、おそらく ファズテスト を試すことができます。たくさんの異なる入力をテストすることでいくつかのメリットがありますが、650億のすべてを実行する必要はありません。
これが実際のテストスイートである場合、作業に近いところに行きたくありません。
テスターの全体の仕事は、「正しい」結果が得られると確信できるほど十分にテストすることと、妥当な時間内に実行できる十分な数のテストを作成することのバランスを取ることです。
多くのテストは「同等クラス」に抽象化できます。つまり、30億のテストを実行するのではなく1を実行すると、その同等クラスの他のすべてのテストが正常に実行されるという妥当なレベルの信頼性が得られます。それらを実行する時間。
650億のテストを実行することを考えている人には、テストを等価クラスに抽象化するためのより良い仕事をする必要があることを伝える必要があります。
おそらく、テスト対象システムへの入力のすべての可能な組み合わせを計算するか、循環的複雑度を計算し、これらの一意の実行パスごとにテストを作成する必要があると想定して、650億回のテストに到達しました。
他のポスターやコメンターが示したように、65 billionテストを実行するために必要な技術力は驚異的であるため、これは実際のテストの記述方法ではありません。これは、2つの32ビット値の可能なすべての順列をプラグインして結果をチェックすることにより、2つの整数を追加するメソッドを実行するテストを作成するようなものです。それは全く狂気です。線を引き、すべての可能なテストケースのサブセットを特定する必要があります。これらのテストケースの間で、システムは入力の範囲全体で期待どおりに動作することが保証されます。例えば。いくつかの「通常の」数値の追加をテストし、いくつかの負の数のシナリオをテストし、オーバーフローシナリオなどの技術的な制限をテストし、エラーが発生するシナリオをテストします。前述のように、これらのさまざまなタイプのテストは「同等クラス」を実行します。これらは、可能性のある入力の代表的なサンプルを既知の「異常値」とともに取得し、これらのシナリオが通過するため、これらに類似したすべてのシナリオが通過するという非常に高い確信を持って言うことができます。
基本的なコードカタの1つであるローマ数字ジェネレータを考えてみましょう。 「道場」スタイルでTDD技法を使用して実行されるタスクは、1から3000までの任意の数値を受け入れ、その数値に対応する正しいローマ数字を生成できる関数を作成することです。
この問題を解決するには、一度に3000の単体テストを作成し、それらを順番に渡します。それは狂気です。演習には通常1〜2時間かかります。個々の値を数日間テストするためにそこにいるでしょう。代わりに、あなたは賢くなります。最も単純な基本ケース（1 == "I"）から始め、「最小コード」戦略（_return "I";_）を使用してそれを実装し、次に、予想される別のシナリオでコードが正しく動作しないことを確認します。 （2 == "II"）。すすぎ、繰り返します。おそらく、最初の実装を、必要なだけ「I」文字を繰り返すもの（return new String('I',number);など）に置き換えました。それは明らかにIIIのテストに合格するので、気にする必要はありません。代わりに、4 == "IV"のテストを記述します。これは、現在の実装では正しく実行されないことがわかっています。
または、より分析的なスタイルで、コードによって行われた（または必要である）各条件付き決定を調べ、各決定の可能な結果ごとにコードを入力するように設計されたテストを記述します。 ifステートメントが5つあり（それぞれtrueとfalseの分岐がある）、それぞれが完全に独立している場合、32ではなく10のテストをコーディングします。各テストは、特定の可能な決定について2つのことを主張するように設計されます。最初に正しい決定が行われ、次にその条件を前提として入力されたコードが正しいことが示されます。あなたしないでください独立した決定の可能な順列ごとにテストをコーディングします。決定が依存している場合、それらを組み合わせてより多くテストする必要がありますが、一部の決定は別の決定が特定の結果を持っている場合にのみ行われるため、そのような組み合わせは少なくなります。
これは「普通」ですか、いいえ。 「通常」とは、平均的または典型的な体験として定義されます。そのようなプロジェクトに取り組む必要があったとは言えませんが、私は数百万ビットごとに1つが反転するプロジェクトに取り組んできました。それをテストすることは...挑戦でした。
潜在的に必要ですか？まあ、それはプロジェクトの保証と詳細に依存します。最初は理解するのは少し不思議ですが、あなたの質問は詳細については軽いです。
他の人（MichaelT）が指摘したように、シリアルテストでこのタスクを完了するには時間がかかるため、これは現実的ではありません。したがって、並列化が最初の検討事項になります。この問題にはいくつのテストシステムを投入できますか。また、これらの複数のシステムの結果を照合するためにどのようなサポートがありますか？
テストしているデバイスまたはアルゴリズムが確実に複製されていることをどのように保証していますか？ソフトウェアの複製はかなり信頼できますが、ハードウェアデバイス（特に第1世代）には製造上の問題がある可能性があります。その場合の誤ったテストの失敗は、不良なアルゴリズムか、デバイスが正しく組み立てられなかったことを示している可能性があります。これら2つのケースを区別する必要がありますか？
また、テストシステム自体を検証する方法も検討する必要があります。その多くのテストケースの正当な理由を想定すると、多くの自動化が必要になります。テストケースの生成でエラーが発生しないことを確認するには、その自動化を検査する必要があります。エラーのスポットチェックは、干し草の山から針を見つけることに相当します。
この arstechnicaリンク は、テストの考慮事項に関する洞察の一部である場合とそうでない場合があります。 GPUクラスターは、ブルートフォースクラッキングパスワードによく使用されます。記事で引用されているものはcan cycle through as many as 350 billion guesses per second、そういうわけであなたの65Bテストを見通しに入れます。おそらく別のドメインですが、さまざまな角度からタスクにアプローチすることで実行可能なソリューションがどのようにもたらされるかを示しています。
そもそもmaintain 6.5e + 10でテストするのは現実的ではないので、実行しても意味がないかもしれません。 Debianとそのすべてのパッケージのような最大のプロジェクトでさえ、合計で数億のSLOCしかありません。
しかし、とにかく膨大な数のテストを実行する必要がある場合は、いくつかの戦略があります。
それらすべてを実行しないでください。ほとんどの場合、すべてのテストがすべてのコードパスに依存するわけではありません。サブシステムとそのテストの間、およびテストスイートの間の依存関係を定義すると、特定の変更に関連する単体テストのみ、これらの単体テストに依存する統合テストなどを実行できます。
それらを並行して実行します。コードベースが非常に大きいため、おそらく大規模なビルドファームがあります（JetBrainsに戻って、比較的小さな操作ですが、IDEA継続的ビルド/統合ファームで40-50のビルドエージェントが実行されていました単体テストは独立しており、統合テストは既にビルドされたコードを再利用できるため、テストの並列化は比較的簡単です。
早く走らないで。特定のテストスイートが、その適切な機能が別のテストスイートの正確さに依存していることがわかっている場合は、1つのリンクに障害が発生したことを確認したら、チェーン全体を切断できます。
免責事項：私はプロのテストエンジニアではありません。塩の粒で上記を取る。
少数のテストでこっそりしようとする方法についていくつかの良い提案がここにありましたが、私はあなたのシステムが650億の入力の組み合わせしか持っていないことを真剣に疑っています。入力は36ビット未満です。上記のすべてのアドバイスをすでに受けていたとしましょう。
各テストの実行に約1ミリ秒かかり、テストを10プロセッサ（1つの通常のPC）のみに分散すると、テストは69日強で実行されます。それはしばらくですが、完全に不合理ではありません。 100個のプロセッサ（通常のPC 12台または妥当なサーバーPC 1台）に配布すると、テストは7日未満で完了します。これらを毎週実行して、リグレッションをチェックできます。