では、基本から始めましょう。2 つの一般的なテストモードと、3 つの一般的なテスト自動化のタイプについて説明します。
誰もが経験したことがあるでしょう。実生活でよくある、繰り返し発生するコーディング ミームとは何か？
このミームは、この問題をよく表しています。各引き出しは個別に問題なく動作しますが、他の引き出しと組み合わせると、互いに干渉して機能しなくなります。両方の引き出しが互いにうまく機能し、同時に操作できるようにします。
これをウェブ開発に適用すると、テストを作成してテスト カバレッジを 100% に達成しても、他の部分が整ったらアプリケーションが機能するようにする必要があります。ユニットは単体では正常に動作しても、相互に関連して動作しない場合があります。テストの作成は重要ですが、プロジェクトに最適なテスト設定の一部にすぎません。まず、アプリケーションの品質のどの部分を確保する必要があるか、そしてそれをどのように実現できるかを判断する必要があります。
つまり、実際のテストコードの作成を開始する前に計画を立てておく必要があります。テストを実際に行う方法について説明する前に、まず次の 2 つの基本的な質問に答えましょう。
- テスト方法を選択してください
- テストの対象を指定してください
この記事では、最初の質問に回答するために知っておくべき一般的な事項について説明します。共通の基盤から始めるために、まず、どのようなテストモードがあるのかを確認し、次に一般的なテストの種類について説明します。後の記事では、2 つ目の質問に回答し、回答を組み合わせて、プロジェクトに最適なテスト戦略を見つけます。出発しましょう🙌
基本から始める: 一般的なテストモード
テスト方法に関する質問に回答する際、最初に明確にすべき点は非常に抽象的です。テストは手動で行うべきか、コンピュータに任せるべきか？ただし、ここでは二分法に陥らないことが重要です。
手動テストと自動テスト
品質保証エンジニアにテストを定義するよう依頼すると、まず 2 つの「モード」に分類されるでしょう。
- 手動テスト。これは、実際のユーザーが実施する一般的なテスト方法です。品質保証エンジニアは、アプリケーションを操作して動作を確認するとともに、同時に不具合を発生させようとします。最も一般的な方法は探索的テストです。エンジニアは、事前定義されたパスまたはチェックリストに基づいて、アプリケーションに関する知識を使用してアプリケーションを調査します。
- 自動テスト。これは、コンピュータによって実施されるテストの一種です。品質保証エンジニアは、反復的で単調なテストを自動化するためにこれを実装します。
このガイドシリーズでは、主に自動テストについて説明します。ただし、テスト方法を 1 つに絞り込まないでください。自動化によって時間と労力を大幅に節約できたとしても、人間と手動テストは常に重要な役割を果たします。テスト自動化は、探索的テストと創造的な問題解決に集中できるようにするためのものです。たとえば、ユーザー エクスペリエンスの品質を確保したり、リスクの高いビジネス ロジックを保護したりします。つまり、自動化がサポートしてくれるのです。❤️
不透明ボックスと透明ボックス
これで、一般的なテストモードを定義できました。ただし、それでは十分ではありません。テスト戦略を計画するには、もう 1 つ質問に答える必要があります。アプリケーションの内部動作を把握しておくべきか、それとも把握せずにテストするべきかです。回答に応じて、テストケースの導出と選択に次の 2 つの手順から選択できます。
- 不透明ボックステスト（ブラックボックス テスト）。コンポーネントまたはシステムの内部構造を考慮せずに、機能要件または非機能要件（仕様）を分析することをベースとしています。
- クリアボックス テスト（ホワイトボックス テスト）は、ボックスの内部構造を考慮した手順です。つまり、アプリケーションの内部動作です。
どちらの手順も、手動テストと自動テストの両方に適用できます。ただし、一般的なテストモードの一部は、どちらか一方に重点を置いている場合があります。この点については後で説明します。ここでは、テスト自動化をさらに種類に分類しましょう。
テスト自動化の種類: どのようにテストするか
「どのように」という質問に答える段階に近づき、すでに手動テストを行うことを決めています。ただし、テスト自動化の種類を選択して適用するのは、少し難しい作業です。自動テストの種類は、プロジェクトで作成する指標に密接に関連しています。では、最も重要な変更点について詳しく見ていきましょう。
前述のミームに示されているように、単体テストと統合テストの 2 種類のテストについてすでに学習しています。エンドツーエンドのテストは、考慮すべき 3 つ目の重要なテストです。ただし、まだすべてではありません。では 詳しく見ていきましょう
単体テスト
単体テストは、アプリのテスト可能な小さな部分やユニットを個別に独立してテストし、適切に動作することを確認するテストの種類です。これらのユニットの範囲は、関数、クラス、インターフェースから、サービスや完全なコンポーネントまでさまざまです。主な属性は、実行速度、分離、メンテナンスのしやすさです。単体テストについて詳しくは、単体テストのガイドをご覧ください。
統合テスト
インテグレーション テストは、コンポーネントまたはシステム間の相互作用に重点を置いて行います。つまり、連携の良し悪しです。統合テストの典型的な例としては、API テストやコンポーネント テストがあります。
エンドツーエンドのテスト
これらのテストは UI テストとも呼ばれ、この名前の方が機能がより明確に表されます。これらのテストは、アプリケーションの UI（アプリケーション スタック全体を含む）とやり取りし、アプリケーションをエンドツーエンドでテストします。
品質保証の理論に照らし合わせると、システムテストに似ています。これらのテストでは、実際のユーザーとその操作をシミュレートします。エンドツーエンド テストはシステム全体を対象としているため、実行時間が長くなり、実行時間が長くなるとコンピューティング能力も必要になります。その結果、メンテナンス費用が増加します。
ビジュアル UI テスト
UI テストの興味深いサブカテゴリに、ビジュアル テストがあります。これらのテストは、アプリケーションの表示出力を検証する手段を提供する拡張エンドツーエンド テストです。このようなテストでは、変更後のスクリーンショットに加えて、「現状」（またはゴールドファイル）を含む別のスクリーンショットを取得し、その結果を人間の審査担当者に提供して検査と確認を行います。つまり、純粋に機能的なバグを超えて、ページの外観に関する「視覚的なバグ」を見つけるのに役立ちます。これらのバグは、アサーションに明示的に記述されていません。
静的分析
ここでもう 1 つ紹介したいのが、静的分析です。教科書的な意味でのテスト形式ではありません。ただし、これは後で品質保証戦略において重要な要素になります。スペルチェック機能のように動作します。プログラムを実行せずにコードをスキャンし、重大な欠陥や構文エラーを検出して、コードスタイルの問題を検出します。この簡単な対策で、多くのバグを防ぐことができます。静的分析について詳しく知りたい場合は、この機会に学習することをおすすめします。
さまざまな形態でのテスト: これらはすべてどのように連携するのですか？
これらの質問に対する答えを探しているうちに、類推から解決策が見つかるかもしれません。特にウェブとテストのコミュニティでは、デベロッパーはこれらの類比を使用して、どのタイプのテストをいくつ使用すべきかを示唆する傾向があります。
この画像に示す 5 つの戦略が最も一般的です。
- テスト ピラミッド
- テストダイヤモンド
- テスト用アイスクリーム コーン（テスト用ピザとも呼ばれます）
- Honeycomb をテストする
- テスト トロフィー
これは処理すべき情報量が非常に多くなります。これらに基づいて、適切なマッチング テスト戦略をどのように決定すればよいでしょうか。ご安心ください。次のセクションでは、これらのさまざまな戦略について詳しく説明し、プロジェクトに最適なものを選択する方法を説明します。最新情報をお待ちください。🔥