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