この記事では、単体テスト、統合テスト、機能テスト、受け入れテストなど、ソフトウェアをテストするさまざまな方法について説明します。
コードの変更がスクリプト化されていることを確認するために適用できるテストには、さまざまな種類があります。 すべての種類のテストが同じというわけではありませんが、ここでは、主なテスト方法が互いにどのように異なるかを見ていきます。
テスト：手動または自動？
最初に、手動テストと自動テストの違いを理解する必要があります。 手動テストは、アプリケーションのボタンをクリックするか、必要なツールを使用してソフトウェアまたはAPIを操作する人によって直接実行されます。 これは、テスターが開発環境をインストールしてテストを手動で実行する必要があるため、非常に高価です。 タイプミスやテストケースのステップのスキップなど、人的要因によるエラーの可能性があります。
一方、自動テストは、事前に作成されたテストスクリプトを実行するマシンによって実行されます。 このようなテストは、クラス内の単一のメソッドのテストから、UIで一連の複雑なアクションを実行して正しく動作することを確認するまで、複雑さに応じて大きく異なります。 この方法は信頼性が高いと考えられていますが、そのパフォーマンスはテストスクリプトがどれだけうまく書かれているかに依ります。
自動テストは、 継続的インテグレーションと継続的デリバリの重要なコンポーネントであり、アプリケーションに新しい機能を追加しながらQAプロセスを拡大する優れた方法です。 ただし、手動テストには依然として独自の価値があります。 したがって、この記事では、確実に探索的テストについて説明します。
さまざまな種類のテスト
単体テスト
ユニットテストは、アプリケーションのソースコードに近い低レベルと見なされます。 これらは、クラス内の個々のメソッドと機能のテスト、プログラムで使用されるコンポーネントとモジュールのテストを目的としています。 単体テストは一般的に特別な自動化コストを必要とせず、継続的統合サーバーを使用すると非常に迅速に解決できます。
統合テスト
統合テストでは、アプリケーションで使用されるサービスとモジュールが適切に機能するかどうかを確認します。 たとえば、データベースとの統合をテストしたり、マイクロサービスが相互に正しく相互作用することを確認したりできます。 これらのテストは、アプリケーションの多くの部分が同時に機能する必要があるため、より高いコストで実行されます。
機能テスト
機能テストは、アプリケーションのビジネス要件に基づいています。 アクションの実行後にのみ出力をチェックし、アクションの再現中にシステムの中間状態をチェックしません。
統合テストと機能テストの間に矛盾がある場合があります。 どちらも、相互作用する複数のコンポーネントを要求します。 違いは、統合テストではデータベースにアクセスできることを簡単に確認できるのに対して、機能テストではデータベースから特定の値を取得して、最終製品の要件の1つを確認することです。
エンドツーエンドのテスト
エンドツーエンドのテストは、ソフトウェアと対話するときのユーザーの動作をシミュレートします。 さまざまなユーザーがアプリケーションの意図されたシナリオをどれだけ正確にたどるかをチェックします。たとえば、Webページの読み込みやWebサイトの入力、またはより複雑なケースでは電子メールアドレス、オンライン支払いなどの確認のように簡単です。
エンドツーエンドのテストは非常に便利ですが、テストの作成には費用がかかり、自動化が難しい場合があります。 いくつかのエンドツーエンドのテストが推奨されますが、主要な変更を迅速に認識できるようにするために、低レベルのテスト（単体テストと統合テスト）にさらに依存しています。
受入試験
受け入れテストは、システムがビジネス要件を満たしていることを確認するために実行される正式なテストです。 アプリケーションを実行して実行し、ユーザーアクションを模倣する必要があります。 受け入れテストはさらに進んでシステムのパフォーマンスを測定し、最終的な開発目標が達成されていない場合は最近の変更を拒否できます。
性能試験
パフォーマンステストでは、システムに大きな負荷がかかったときの動作をテストします。 これらのテストは機能せず、プラットフォームの信頼性、安定性、および可用性をテストするために多くの形式を取ることができます。 たとえば、大量のリクエストを実行するときの応答時間を監視したり、ビッグデータとやり取りするときのシステムの動作を観察したりできます。
パフォーマンステストは本質的に実施に費用がかかりますが、システムを低下させる可能性のある外部要因を理解するのに役立ちます。
煙テスト
煙テストは、アプリケーションの基本的な機能をテストする基本的なテストです。 彼らは十分に早く解決し、彼らの目標は、システムの主要な機能が本来あるべきように機能し、それ以上は機能しないことを明確にすることです。 このようなテストは、明らかなエラーを識別することを目的としています。
煙テストは、新しいビルドをビルドした直後に、より高価なテストを実行できるかどうかを確認したり、展開した直後に、新しい環境でアプリケーションが正常に動作することを確認するのに役立ちます。
テストを自動化する方法
テスターは上記のすべてのテストを手動で実行できますが、これは非常にコストがかかり非生産的です。 信頼性の高いテストを行いながら、多数の反復アクションを実行する能力が限られているためです。 ただし、マシンは同じアクションを簡単に再現し、たとえば、ログイン/パスワードの組み合わせが何の苦情もなく100回動作することを確認できます。
テストを自動化するには、まず、アプリケーションに適したテストフレームワークを使用して、いくつかのプログラミング言語でテストを記述する必要があります。 PHPUnit 、 Mocha 、 RSpecは、それぞれPHP、Javascript、Rubyで使用できるテストフレームワークの例です。 言語ごとに多くの機能があるため、自分で少し調べて、開発者コミュニティと相談して、どのフレームワークが最適かを判断する必要があります。
ターミナルからのスクリプトを使用してテストを実行できる場合、BambooやBitbucket Pipelinesクラウドサーバーなどの継続的統合サーバーを使用してテストを自動化できます。 これらのツールはリポジトリを監視し、新しい変更がメインリポジトリにプッシュされるとすぐにテストスイートを実行します。
テストが初めての場合は、継続的インテグレーションガイドを参照して、最初のテストスイートを作成してください。
研究テスト
各段階でシステムが正常に動作することを確認する必要があるため、コードに追加される機能と改善が増えるほど、テストの必要性が高まります。 また、バグを修正するたびに必要になります。これは、数回のリリース後に再び戻ってこないことを確認するのに余計なことではないからです。 これを可能にする鍵は自動化です。 遅かれ早かれテストを書くことは、開発者のプラクティスの一部になります。
問題は、この場合、手動テストを実施する必要があるかどうかです。 簡単な答えはイエスです。これは、微妙なエラーの特定に役立つ探索的テストと呼ばれるものに焦点を当てる必要があります。
研究テストセッションは2時間を超えてはならず、テスターがソフトウェアの特定の領域に集中できるように、明確に定義された範囲を持つ必要があります。 すべてのテスターにテストの制限について通知した後、システムの動作を確認するために実行するアクションは、各自の裁量に任されています。 このようなテストは本質的に費用がかかりますが、ユーザーインターフェイスの問題を特定したり、ユーザーの複雑なワークフローの状態を確認したりするのに非常に役立ちます。 境界条件でどのように動作するかを理解するために、根本的に新しい機能がアプリケーションに追加されるたびに、このようなテストを実施することが重要です。
テストノート
この記事を終える前に、テストの目的についてお話したいと思います。 一方では、ユーザーがアプリケーションを使用できるようにすること（「ログインできない」、「データを保存できない」など）を確認することが非常に重要ですが、他方では、システムを確認することも同様に重要です間違ったデータや予期しないアクションを入力しても破損しません。 ユーザーがタイプミスをしたとき、不完全なフォームを保存しようとしたとき、または間違ったAPIを使用したときに何が起こるかを予測する必要があります。 ユーザーの1人がデータを簡単に侵害し、アクセスできない特定のリソースにアクセスできるかどうかを確認する必要があります。 適切な一連のテストは、アプリケーションを破壊し、その機能の限界を理解するのに役立つはずです。
そして最後に、テストもコードです！ したがって、コードレビュー中にそれらを忘れないでください。消費者市場で製品を発売する前の最後のステップになる可能性があります。
確立された伝統によると、私たちはあなたのコメントを待っており、3月18日にグループIBの主要なテスト自動化エンジニアであるミハイルサモイロフによって3月18日に開催されるオープンドアデーに皆を招待します。