4

OK、それで、テストに関する情報、さまざまなテストライブラリなどについて調べてみました。

人々は常に、これらのテストの違いを、一方が高レベルで他方が低レベルであると明確に定義しているように私には思えます。また、適切にテストされたアプリケーションには、スタイル テストと統合テストなどの両方が含まれます。

しかし、テストの種類に関するすべての記事は、「実際には、違いが実際に何であるかを理解するのは難しいかもしれない」のようなもので終わっているようです. あらゆる種類の完全なコード カバレッジに到達するために両方のテストが必要であると同時に、それぞれがどのように見えるかについての良い情報/例を持っていないほど、人々が非常に説教しているように見えるのは奇妙だと思います。

私が質問しているのは、私が過去に行ったことよりもはるかに大きく、より関与することを約束する新しいプロジェクトを開始しているためです. 私は自分のテストで適切なワークフローを維持し、進行中にテストでギャップを作成しないようにしたいと考えています (過去のプロジェクトは小規模であり、発生した可能性のあるギャップが大きな問題を引き起こすことはないようです)単純ではなかった実稼働中の t0 正しい)

それは良い受け入れテストのように思えますが、自然にユニットテストにつながります。それを取得すると、この魔法のようなことが起こり、開発ライフがはるかに幸福になるためです.

とにかく、優れたテスト ワークフローを開始するための良い議論を知っている人はいますか?

.net の例は素晴らしいでしょうが、ほとんどのテスト フレームワーク cucumber(gherkin)/rspec などはすべてかなり読みやすいように意図されているため、どの例でも良いはずです。

4

2 に答える 2

3

さまざまなタイプのテストに関するビデオを参照してください。さまざまなタイプのテスト手法が表と比較されます。

于 2011-07-14T02:25:50.130 に答える
3

"in practice it could be hard to see what the difference actually is":

私は一般的なテストのアドバイスしかできません。通常、大規模なソフトウェア プロジェクトには、ある種の階層が含まれます。

  • 開発段階では、開発者は通常、小さなユニットのホワイト ボックス テスト (単体テスト) を行います。ここでは、内部に関する知識を使用して、テスト ケースの数を減らすことができます (2 つの関数が直交している場合、考えられるすべての組み合わせをテストする必要はありません)。これは、テスト階層の下端です。
  • 統合では、ソフトウェア コンポーネントがまとめられ、さまざまな担当者 (テスター) がインターフェイスでの動作のみをテストします (ブラック ボックス テスト)。これらの人は、内部の知識はなく、インターフェイスの仕様だけを持っています。
  • システム統合は、さらに大きなシステムを結合します。
  • 等々。

テストを効果的に行うために、各レベルは下位レベルでテスト済みの完全にテスト済みのコンポーネントに依存しています。それ以外の場合は、より高いテスト レベルにそのコンポーネントの基本的な機能を含める必要がありますが、ブラック ボックス テストしか使用できません (テストする機能間の依存関係という最悪のケースを想定する必要があります)。そのため、テスト ケースの数は指数関数的に増加しており、完全なカバレッジでのテストは不可能になっています。

階層的アプローチは、ここでのテスト作業を最適化します。

于 2011-07-13T19:59:02.190 に答える