単体テストと統合テストとは何ですか？また、他にどのような種類のテストについて知っておくべきですか？
Stack Overflowでのいくつかのタイプのテストについて他の人が言及するのを見てきました。
私が思い出せるのは、単体テストと統合テストです。特にユニットテストはよく言及されています。ユニットテストとは正確には何ですか？統合テストとは何ですか？他に知っておくべき重要なテスト手法は何ですか？
プログラミングは私の職業ではありませんが、いつかなりたいと思います。制作に関することなども歓迎します。
私の頭の上から：
- ユニットテスト「アプリケーションの分離可能な最小単位をテストする」という意味です。これは通常、規模に応じて、メソッドまたはクラスです。
- 統合テスト
- 機能テスト：これはユニット全体に及ぶ可能性があり、TDDの焦点です。
- ブラックボックステスト：パブリックインターフェイスのみのテスト。
- ガラス箱のテスト：動作の完全な知識を備えたモノのすべての部分をテストします。
- 回帰テスト：後で再現しないようにバグを再現するために構築されたテストケース。
- 無意味なテスト：同じ基本的なケースを複数の方法でテストする、またはそれらを実際にテストする必要がないほど簡単なものをテストする（自動生成されたゲッターやセッターなど）
コードの他の重要なテストに注意する必要がありますか？
これらは、ソフトウェアライフサイクルのさまざまなフェーズに応じた、さまざまな種類のテストの一部です。
- 単体テスト：この小さなコードは機能しますか？
- ユニットテストスイート：多くのユニットテストのシーケンス（コードの多くの小さなビット用）
- 統合テスト：2つのコンポーネントが組み合わされた（または「統合された」）ときに2つのコンポーネントが一緒に機能するかどうかをテストします
- システムテスト：コンポーネントが結合（または「統合」）されたときにallコンポーネントが一緒に機能するかどうかをテストします
- 受け入れテスト：顧客があなたに支払いたいかどうかを決定するために何をするか（システムテストはソフトウェアが設計どおりに機能するかどうかを検出します...受け入れテストは「設計どおり」が顧客の望んだものであるかどうかを検出します）
さらにあります：
- 使いやすさテスト
- 性能試験
- 負荷テスト
- ストレステスト
そして、はるかに...テストソフトウェアは、ソフトウェアを書くこととほぼ同じくらい広い主題です。
単体テストの主な目的は、アプリケーション内のテスト可能な最小のソフトウェアを採用し、それをコードの残りの部分から分離し、期待どおりに動作するかどうかを判断することです。各ユニットは、モジュールに統合する前に個別にテストされ、モジュール間のインターフェースをテストします。単体テストは、その使用中に欠陥の大部分が識別されるという点でその価値を証明しています。
統合テストは、単体テストの論理的な拡張です。最も単純な形では、すでにテストされた2つのユニットがコンポーネントに結合され、それらの間のインターフェースがテストされます。この意味でのコンポーネントとは、複数のユニットの統合された集合体を指します。現実的なシナリオでは、多くのユニットがコンポーネントに結合され、さらにコンポーネントがプログラムのさらに大きな部分に集約されます。アイデアは、ピースの組み合わせをテストし、最終的にプロセスを拡張して、他のグループのモジュールでモジュールをテストすることです。最終的に、プロセスを構成するすべてのモジュールが一緒にテストされます。さらに、プログラムが複数のプロセスで構成されている場合は、一度にすべてではなくペアでテストする必要があります。
詳細については、サイトを確認してください。 Microsoft以外のソースからの情報もたくさんあります。
他の重要なテクニックは回帰テストです。この手法では、一連のテスト（回帰スイートと呼ばれます）を維持します。これは通常、毎晩、およびすべてのチェックインの前に実行されます。バグを修正するたびに、スイートに1つ以上のテストを追加します。目的は、すでに修正されている古いバグを再導入しないようにすることです。 （問題は驚くほど一般的です！）
プロジェクトが大きくなる前、または後悔する前に、回帰スイートの蓄積を開始します。きっとある！
ソフトウェア開発ライフサイクルのどの段階にあるかに応じて、さまざまなレベルのテストがあります。最高レベルは要件分析であり、最低レベルはソリューションの実装です。
単体テストとは何ですか？
- 単体テストでは、その実装に関してソフトウェアを評価します。
- 私たちは、プログラムのユニット（つまり、個々のメソッド）のテストに焦点を当て、これらのユニットを呼び出す/使用する人は無視します。したがって、基本的には各ユニットをスタンドアロンユニットとして扱います。
多くの単体テストツールがあり、最も人気のあるものの1つはJUnitです。
単体テストを実行するとき、特定のカバレッジ基準を満たすテストセット（テストケースのセット）を作成します。これは、いくつかの構造カバレッジ基準（NC、EC、PPCなど））またはデータフロー基準（ADC、AUC、ADUPCなど）になる可能性があります。
- ユニットテストは、実装後に生成された実際のコードユニットを評価するため、最低レベルのテストであることに注意してください。統合テストの前に行われるこのタイプのテスト。
- 効率的な単体テストは、単体テストを行うときにバグを見つけて修正するのがより安く簡単であるため、統合テストが苦痛でないことを保証するのに役立ちます
統合テストとは何ですか？
- 統合テストは、2つ以上のコンポーネントを組み合わせてもソフトウェアが機能することを確認するために必要です。
- システムが完成する前に、統合テストを実行できます。
- クラス統合テストオーダー（CITO）の問題は、統合テストに関連しています。 CITOはコンポーネントを統合する戦略に関係しています。トップダウン統合、ボトムアップ統合など、CITOには多くのソリューションが提案されています。主な目標は、コードスタブの作成が常に容易でなく時間がかかるため、効率的なテストと最小限のスタブを可能にする方法でコンポーネントを統合することです。 。これはまだ研究の活発な分野であることに注意してください！
- 統合テストは、単体テストの後に行われます。
- 個々のコンポーネントが正常に機能することはよくありますが、すべてを組み合わせると、インターフェースとの非互換性/問題が原因で突然バグが表示されるようになります。
その他のレベルのテストには次のものが含まれます：
回帰試験
- 開発者がソフトウェアへの変更を頻繁にコミットするため、このタイプのテストは非常に重要です。これらの変更によってバグが発生しないことを確認したいのです。
- 効果的な回帰テストの鍵は、回帰テストのサイズを制限して、テストの完了に時間がかかりすぎないようにすることです。そうしないと、次のコミットの前にテストセットの実行が完了しません。また、バグを見逃さない効果的なテストケースを選択する必要があります。
- このタイプのテストは自動化する必要があります。
- 増加する回帰テストに対抗するために、常にマシンを追加し続けることができますが、ある時点でトレードオフに価値がないことに注意することが重要です。
受け入れ試験
- このテストでは、提供された要件に関連してソフトウェアを評価します。基本的に、作成したソフトウェアが指定された要件を満たしているかどうかを確認します。
- これは通常、一連のソフトウェア開発アクティビティで行われる最後のタイプのテストです。その結果、このタイプのテストは、単体テストと統合テストの後に行われます。
単体テストは、アプリケーションの独立した部分をテストするためのコードの小さなブロックを（うまくいけば）書くというアイデアです。
たとえば、電卓アプリケーションがあり、加算機能が動作することを確認する必要があるとします。これを行うには、加算関数を直接呼び出す別のアプリケーションを記述します。次に、テスト関数が結果を評価して、期待どおりに動作するかどうかを確認します。
基本的には、既知の入力で関数を呼び出し、出力が期待どおりであることを確認します。
グーグルでの最初の2つの検索結果「テストの種類」は包括的に見える
最も関連性が高いと思うもの。 ここを参照 。
これは私が書いたエントリです 自動テストのさまざまなタイプ 。
ユニットテスト：ユニットまたはソフトウェアの最小部分に対して行われたテスト。機能仕様または目的の設計構造を満たしているかどうかを確認するために行われます。
統合テスト：関連モジュールを組み合わせて機能をテストします。
回帰テスト：アプリケーションをテストして、変更が意図しない影響を引き起こしていないことを確認します。
煙のテスト：煙のテストは、ビルドがテスト可能かどうかを検証します。