実行する65.000.000.000テスト

65.000.000.000テストのスイートを実行する方法について尋ねられたので、このような膨大なテストを含むプロジェクトがあるのは普通かと思います。

この特性を持つプロジェクトで働いたことはありますか？

650億回のテストでは、考えられるすべての入力をテストするように求められているようです。これは役に立ちません。コードが正しいことではなく、プロセッサが正しく機能していることを本質的にテストすることになります。

代わりに、同等クラスをテストする必要があります。これにより、テスト入力の範囲が大幅に減少します。

また、システムをさらに細かく分割できるかどうかも検討してください。各ピースは個別にテストする方が簡単です。その後、すべてのピースを統合する統合テストを実行できます。

それでも、これらの入力の組み合わせの一部が機能するという安心感が必要な場合は、ファズテストを試してみてください。多くの異なる入力をテストすることの利点の一部を得ることができますが、それらのすべてを650億回実行する必要はありません。

これが実際のテストスイートである場合、それに取り組んでいるところの近くには行きたくないでしょう。

テスターの仕事は、「正しい」結果が得られると確信できるほど十分に徹底的にテストすることと、妥当な時間で実行できる十分なテストを書くこととのバランスを取ることです。

多くのテストは「等価クラス」に抽象化できます。つまり、30億テストを実行するのではなく、1を実行すると、その等価クラスの他のすべてのテストが無駄になった場合に正常に実行されるという合理的なレベルの信頼が得られますそれらを実行する時間。

650億個のテストを実行することを考えている人は誰でも、テストを同等クラスに抽象化するより良い仕事をする必要があることを伝える必要があります。

おそらく、テスト対象システムへの入力の可能なすべての組み合わせを計算するか、循環的複雑度を計算し、これらの一意の実行パスごとにテストを記述する必要があると仮定することで、650億テストという数字に到達しました。

これは実際のテストがどのように書かれているかではありません。他のポスターやコメンターが示しているように、650 億を実行するために必要な技術力テストは驚異的です。これは、2つの32ビット値のすべての可能な順列をプラグインし、結果をチェックすることにより、2つの整数を追加するメソッドを実行するテストを作成するようなものです。それはまったく狂気です。線を引き、考えられるすべてのテストケースのサブセットを特定する必要があります。これらのテストケースの間で、システムは入力の範囲全体で期待どおりに動作します。例えば。いくつかの「通常の」番号の追加をテストし、いくつかの負の数のシナリオをテストし、オーバーフローシナリオなどの技術的な制限をテストし、エラーが発生するはずのシナリオをテストします。前述のように、これらのさまざまなタイプのテストは「等価クラス」を実行します。既知の「外れ値」とともに、可能な入力の代表的なサンプルを取得できます。

基本的なコード型の1つであるローマ数字ジェネレーターを検討してください。「dojo」スタイルでTDD技術を使用して実行するタスクは、1〜3000の任意の数値を受け入れ、その数値に対して正しいローマ数字を生成できる関数を記述することです。

3000個のユニットテストを一度に1つずつ作成し、順番に渡すことでこの問題を解決することはできません。それは狂気です。エクササイズは通常1〜2時間かかり、個々の値をテストするために数日間そこにいます。代わりに、賢くなります。最も単純な基本ケース（1 == "I"）から始め、 "最小コード"戦略（return "I";）を使用して実装し、次に、予想される別のシナリオ（2 == " II "）。すすぎ、繰り返します。おそらく、最初の実装を必要なだけ「I」文字を繰り返すもの（たとえばreturn new String('I',number);）に置き換えました。これは明らかにIIIのテストに合格するため、気にする必要はありません。代わりに、4 == "IV"のテストを記述します。これにより、現在の実装が確認されます。

または、より分析的なスタイルで、コードによって行われた（またはその必要がある）各条件付き決定を調べ、各決定の結果ごとにコードを入力するように設計されたテストを作成します。5つのifステートメント（それぞれtrueとfalseの分岐がある）があり、それぞれが完全に独立している場合、32個ではなく10個のテストをコーディングします。最初に正しい決定が行われ、次にその条件が正しいと入力されたコードが入力されたこと。あなたはしていない独立した意思決定のそれぞれの可能な順列のためのテストをコーディングします。決定が依存している場合は、より多くの組み合わせをテストする必要がありますが、一部の決定は別の決定が特定の結果になったときにのみ行われるため、そのような組み合わせは少なくなります。

これは「正常」ですか？いいえ。「通常」は、平均または典型的な経験として定義されます。そのようなプロジェクトに取り組んだことがあるとは言えませんが、数百万ビットごとに1つが反転するプロジェクトに取り組んできました。それをテストすることは...挑戦でした。

潜在的に必要ですか？まあ、それはプロジェクトの保証と詳細に依存します。最初は理解するのは少し信じられませんが、あなたの質問は詳細に光を当てています。

他の人（MichaelT）が指摘したように、シリアルテストでこのタスクを完了する時間は、これを非実用的にします。したがって、並列化が最初の考慮事項になります。この問題に対していくつのテストシステムを投げることができますか？また、それらの複数のシステムの結果を照合するためにどのようなサポートがありますか？

テストしているデバイスまたはアルゴリズムが確実に複製されるという保証はありますか？ソフトウェアは複製においてかなり信頼できますが、ハードウェアデバイス（特に第一世代）には製造上の問題があります。その場合の誤ったテストの失敗は、不正なアルゴリズムか、デバイスが正しくアセンブルされていないことを示している可能性があります。これら2つのケースを区別する必要がありますか？

また、テストシステム自体を検証する方法を検討する必要があります。多くのテストケースの正当な理由を推測すると、多くの自動化が必要になります。その自動化は、テストケースの生成でエラーが発生しないことを確認するために検査する必要があります。エラーのスポットチェックは、実際に干し草の山で針を見つけることと同等です。

このarstechnicaリンクは、テストに関する考慮事項に関する洞察を提供する場合としない場合があります。GPUクラスターは、ブルートフォースクラッキングパスワードによく使用されます。記事で引用されてcan cycle through as many as 350 billion guesses per secondいるものはcan であるため、その種の65Bテストを展望することができます。おそらく異なるドメインですが、異なる角度からタスクにアプローチすることで実行可能なソリューションがどのように得られるかを示しています。

そもそも6.5e + 10のテストを維持することは現実的ではないと思うので、それらを実行することは無意味かもしれません。Debianのようなすべてのパッケージを含む最大のプロジェクトでさえ、合計で数億のSLOCしかありません。

ただし、とにかく膨大な数のテストを実行する必要がある場合は、いくつかの戦略があります。

• それらをすべて実行しないでください。ほとんどの場合、すべてのテストがすべてのコードパスに依存するわけではありません。サブシステムとそのテスト間、およびテストスイート間の依存関係を定義すると、特定の変更に関連する単体テストのみ、これらの単体テストに依存する統合テストのみを実行できます。

• それらを並行して実行します。巨大なコードベースで、おそらく大規模なビルドファームがあります（JetBrainsに戻ると、比較的小規模な操作で、以前はIDEAの継続的なビルド/統合ファームだけで40〜50のビルドエージェントを実行していました）。単体テストは独立しており、統合テストは既にビルドされたコードを再利用できるため、テストは比較的簡単に並列化できます。

• 早く実行を停止します。特定のテストスイートが別のテストスイートの正当性に依存する合理的な機能に依存していることがわかっている場合は、1つのリンクが失敗するとチェーン全体を切断できます。

免責事項：私はプロのテストエンジニアではありません。塩の粒で上記を取ります。

ここでは、より少ないテストでこっそりしようとする方法についていくつかの良い提案がありましたが、あなたのシステムにはたった650億の入力の組み合わせしかないと思います。これは入力の36ビット未満です。上記のすべてのアドバイスをすでに受けていると仮定しましょう。

各テストの実行に約1ミリ秒かかり、テストを10個のプロセッサ（1つの通常のPC）のみに分散した場合、テストは69日強で実行されます。それはしばらくですが、完全に不合理ではありません。100個のプロセッサ（1ダースの通常のPCまたは1台の妥当なサーバーPC）に分散すると、テストは7日以内に完了します。これらを毎週実行して、回帰をチェックできます。