Webアプリのテスト方法
ソフトウェア業界では、誰もが何らかの方法でアプリケーションをテストしています。 多くの開発者チームは、継続的な統合パイプラインとうまく統合された精巧なテストスキームを持っていますが、自動テストを持っていない人でも、コー
ウェブサイトを構築し、ブラウザの助けを借りて手動でクリックすることは、さまざまなテストです。 それは最も洗練されたものではありませんが、それはまだ重要です。 コンソールでcURLを起動し、作成したばかりのAPIエンドポイントに合成要求を送信する場合も同じです。
この記事では、さまざまなテストタイプと方法論に飛び込む前に、すでに行っている手動テストを自動化する方法について説明します。
自動テスト
小さなアプリには手動テストで十分ですが、これらのアプリが成長すると、テスト可能な表面が成長し、二つの問題が発生します。
一つは、新しいバージョンのアプリが終了するたびにテストを実行する必要がある場合、不一致が発生する可能性があります。 これは、多くのテストがある場合に特に当てはまります。 第二に、テストを行う人は、他のタスクを実行することはできません。 大きなアプリでは、テストには数日かかる場合があります。
これら二つの問題を解決する最も論理的な方法は、これらの手動タスクを自動化することです。 Webアプリには、UIテストとAPIテストの2つの主なタイプのテストがあります。 二つのツールは、それらを自動化することができます。
UIテスト
UIテストはPuppeteerというツールで実行できます。 Puppeteerを使用すると、JavaScriptを使用して手動UIテストを自動化できます。 次のコマンドでNPM経由でインストールされます:
$ npm i puppeteer
その後、テストを実行するためにヘッドレスバージョンのChromeを制御するスクリプトを書くことができます。 このスクリプトは次のようになります:
(async () => { const browser = await puppeteer.launch(); const page = await browser.newPage(); await page.goto('https://google.com', {waitUntil: 'networkidle2'}); const heading = await page.$('h1'); await browser.close(); if(!heading) console.log('No heading found!');})();
このスクリプトでは、Chromeのヘッドレスインスタンスを開始し、次の場所に移動しますexample.com、およびh1要素を探しています。 存在しない場合は、エラーメッセージがログに記録されます。
APIテスト
ApiテストはPostman経由で自動化できます。 Postmanには、保存できるHTTP要求を構築するためのグラフィカルインターフェイスが付属しています。 これらの要求は、マウスをクリックするだけで後で実行できます。
開始するには、Postman UIをダウンロードしてインストールします。 要求を作成して保存するには、次の手順が必要です:
- 左側のコレクションの作成をクリックします
- コレクション名としてコレクションを入力します
- 作成をクリックします
- 左側のコレクションの省略記号(…)をクリックします
- リクエストの追加を選択します
- リクエスト名としてリクエストを入力します
- コレクションに保存をクリックします
-
リクエストは、新しく作成したコレクションの下の左側のサイドバーに表示されます。
それを選択した場合は、次のように入力する必要がありますexample.com URLとして、テストを追加します。 テストを追加するには、URL入力フィールドの下にあるタブバーの[テスト]をクリックします。
JavaScriptでテストを記述できるテキスト領域が表示されます。 テストの例を次に示します:
pm.test("Status code is 200", () => { pm.response.to.have.status(200);});画面の右上にある「保存」をクリックして、その直後に送信すると、リクエストが送信されます。 その後、テストスクリプトが実行され、応答のステータスが200であるかどうかが判断されます。
テストの種類
テストには三つの異なるタイプがあります。 これらを理解することで、ソフトウェアスタックのさまざまな部分に適したタイプのテストを選択できます。
単体テスト
単体テストは最も単純なタイプのテストです。 彼らはあなたのコードの小さな部分の正しさをチェックします。 単体テストは、通常、関数への1つの呼び出しまたはクラスを使用する1つの方法をカバーします。
単体テストは通常、コードの最初の”ユーザー”です。 一部のテスト方法論では、実際のアプリケーションコードを実装する前にテストを記述する必要があります。
単体テストは、バックエンドとフロントエンドの両方の開発で使用できます。 一部の開発チームは、フォームやメニューなど、コードの小さな部分のレンダリングされたDOM出力をチェックするために単体テストを使用します。 バックエンドでは、HTTPサーバーとデータベースまたは他のApi間のコードをテストするために単体テストが使用されることがよくあります。
単体テストで広く使用されているテストランナーは次のとおりです。
‐Jest—Jestは、uiの回帰などの問題に役立つスナップショットテストのようなユニークな機能が付属しているため、主にフロントエンド開発で使用されています。 Jestのチュートリアルはここで見つけることができます。
‐AVA—AVAは、テストの高度に並列実行に特化しているため、バックエンド開発で好まれています。 AVAのチュートリアルはここで見つけることができます。
‐PHPUnit—PHPUnitはPHPの単体テストのための一般的なフレームワークです。 PHPUnitのチュートリアルはここにあります。
単体テストでネットワーク接続やデータベースなどの外部リソースが必要な場合は、おそらく統合テストを作成しているでしょう。 このタイプのテストについては、次に説明します。
統合テスト
実装の観点から見ると、統合テストは単体テストのように見えます。 違いは、統合テストがスタックの複数の部分を一緒にテストすることです。 たとえば、クライアントとサーバーが同じプロトコルを話すかどうか、またはマイクロサービスアーキテクチャでは、サービスが正しく一緒に動作しているかどうかをテストすることができます。
通常は複数の独立した単体テストで終わるチェックは、すべてがうまく機能しているかどうかを判断する1つの統合テストに集約できます。
統合テストは、フロントエンドとバックエンドの両方の開発で使用されます。 これらは、2つのパーツが正しく相互作用しているかどうかを確認するために使用されることがありますが、1つのパーツの異なるモジュールが意図した
単体テストに使用したのと同じテストランナーを統合テストに使用できます。 ただし、手動APIテストを自動化するために上記で使用されたUIツールであるPostmanには、CI/CDパイプラインと統合できるNEWMANというCLIツールも付属しています。
newmanはエクスポートされたPostmanコレクションを実行できるため、Postman UIを使用して要求とテストを作成し、後でCLI経由で実行できます。 Newmanのチュートリアルはここで見つけることができます。
統合テストがUIとの対話を必要とする場合、それはUIテストアドレス指定された次と呼ばれます。
UIテスト
UIテストは最も洗練されたテストです。 彼らは、テスターが手動でアプリのすべての部分をクリックする必要がないように、自動化された方法でユーザーの行動をエミュレートしようとします。
UIテストは、多くの場合、ユーザーのエラーにつながった特定の操作をキャプチャするのに役立ちます。 それがキャプチャされると、それはバグを修正し、新しいバージョンに戻ってくるからそれを防ぐために、ワンクリックで再現することができます。
前に述べたJestとAVAのテストランナーはここで使用できますが、通常はブラウザを介したUIの対話を容易にするために余分なライブラリが必要です。 現在このプロセスで使用されている2つの主要なライブラリは次のとおりです。
‐Puppeteer—Puppeteerは、バックグラウンドでプログラムでUIテストを実行できるChromeのヘッドレス実装が付属しているJavaScriptライブラリです。 人形師のチュートリアルはここで見つけることができます。
‐Selenium—SeleniumはWebDriverと呼ばれるライブラリを介してブラウザのリモート制御を可能にするフレームワークです。 Seleniumのチュートリアルはここにあります。
ここに記載されているものよりも多くの種類のテストがあります。 たとえば、負荷テストではパフォーマンスのボトルネックを見つけようとします。 ここで説明するテストには異なる名前が与えられることがあることに注意してください。 上記の3つのタイプは、開始時に実装するために不可欠なタイプです。 そのうちの1つを使用する方が、自動テストをまったく使用しないよりも優れています。
テスト方法論
テスト方法論は、テストについて考える方法です。 以下の3つが最も一般的に使用されるものです。
テスト駆動開発(TDD)
TDDは最も広く使用されている方法論であり、最も技術的な方法論です。 テストする実際のコードを記述する前に、テストを記述することをお勧めします。 実装しているコードの一部のみのテストを記述する必要があるため、記述するテストのタイプは単体テストです。
単体テストはかなり粒状であるため、時間の経過とともにこの方法論を使用すると、多くのテストが蓄積されます。 この現実は、初心者のTDD実践者が些細なテストを書く傾向があるという事実と対になって、無駄なテストの山を作成することができます。 これを回避するには、チームがTDDやテスト全般に精通しているときに、テストを更新してクリーンアップすることが重要です。
テストを頻繁に実行することは、CI/CDパイプラインだけでなく、開発マシン上でもローカルで実行することが重要です。 テストを作成し、実行し、失敗を確認し、テストに合格するのに十分な実装を行い、プロセスを繰り返します。
さらに読むには、Agile AllianceのTDDの説明をチェックしてください。
Acceptance Test Driven Development(ATDD)
ATDDは、ビジネスケースに重点を置いており、技術的な実装に重点を置いていないTDDの修正版です。 この方法論で使用されるテストの種類は、多くの場合、ビジネスニーズを解決するためにシステムの複数の部分を組み合わせて使用する必要があるた
テストは技術的ではないので、テストプロセスに技術的ではない人を含めることもお勧めします。 製品所有者と顧客は、開発者がテストを作成できるように、ビジネスケースを定義するのに役立ちます。 テストを正常に実行できない場合は、より多くの機能を実装する必要があることは明らかです。
ATDDはTDDとは異なる抽象化レベルで動作するため、二つの方法論を一緒に使用することができます。
さらに読むには、Agile AllianceのTDDの説明をチェックしてください。
Behavior Driven Development（Bdd）
BddはTDDとATDDを組み合わせたもので、その目標は両方の長所を活用してシステム全体をより安定させることです。 BDDは、その使用法を示すテストを持つシステムを指定しようとします。
ATDDと同様に、BDDはビジネスケースをキャプチャしようとします。 ただし、「whys」はATDDに欠けている部分であるため、「5whys」でこれらのユースケースに疑問を呈する必要もあります。 確かに、開発者の入力だけに頼るのではなく、顧客に何を求めているのかを尋ねる方が良いでしょう。 しかし、これらのグループの両方の仮定に疑問を呈することも重要です。
bddは、抽象化レベルの意味でTDDとATDDの組み合わせでもあります。 TDDはアプリケーションの小さな部分のみをテストし、ATDDはこれらの部分がどのように連携するかをテストします。 BDDでは、この方法論をアプリの大きな全体とその小さな部分に適用する必要があり、BDDはテストに対するより包括的なアプローチになります。
さらに読むには、Agile AllianceのBDDの説明をチェックしてください。
結論
テストはひどいものではありませんが、手動テストの方が優れており、自動テストが最善です。
アプリのサイズに応じて、手動テストは、開発チームのメンバーが数日または数週間の間、他のプロジェクトで作業するのをブロックすることができ、ビジ さらに、同じ相互作用を何度も何度も実行する単調な作業は、キャッチされていないバグにしばしば現れるスリップにつながる可能性があります。
コンピュータは同じタスクを何度も繰り返すのに非常に優れているので、テストをスクリプトに委任し、開発者の時間を解放することをお勧めします。 これらのテストがCI/CDパイプラインに統合されている場合、既に書かれているテストは、新しいコミットがリポジトリに到着したときに暗黙的に実
テストを開始するときの大きな問題は”何を””いつ”テストするかであることが多いので、テスト方法論を早期に採用することをお勧めします。 これらの方法論は、チームのすべてのメンバーに対してテストを書くことをより一貫性のあるものにするプロセスを明確にするのに役立ちます。
Leave a Reply