Web アプリのテストの自動化 ~ Visual Studio ソリューションシナリオ
<< ”Visual Studio 2012 ソリューションシナリオ" では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>>
Web アプリケーションは企業における様々な活動において、ユーザーあるいはパートナー企業と直接的にコンタクトを持つことを可能にするシステムです。そのため Web アプリケーションによるユーザー体験(User Experience)は、直接的にサービスや企業のイメージに結び付きやすい傾向にあります。つまり、高い品質のユーザー体験を提供できればサービスや企業の印象もよくなりますし、その逆も成り立ってしまうということです。
従って Web アプリケーションの開発においてはアプリケーションの品質を十分に確認し、また誤ったデータ操作や顧客対応が行われないようにテストを行うことが重要になります。Web アプリケーションは通常は3階層(ブラウザ、アプリケーションサーバー、データベースサーバー)以上に分割され、また他のシステムやサービスと連携を行うことがほとんどです。そのためテストを用意する場合には、それらの階層関係を考慮しつつテストの目的を明確にしたうえでテストを作成する必要があります。
Web アプリケーションのテストを行う際には、以下のような課題を意識する必要があります。
- Web アプリケーションは通常は3階層(ブラウザ、アプリケーションサーバー、データベースサーバー)以上に分割され、また他のシステムやサービスと連携を行うことがほとんどです。そのため、それらの階層関係を考慮しつつテストの目的を明確にしたうえで適切なテストを作成する必要があります。
- テストの自動化を行う場合に個別にテスト用のツールを調達するとテストを実施するために必要となる教育コストや、情報一元化のためのコストが追加で必要になります。
通常 Web アプリケーションのユーザー数は C/S 方式のアプリケーションよりも多くなる傾向にあるため、ユーザーに対する高品質な体験を提供する重要性は相対的に高くなります。そのため、開発プロジェクトにおいてはこのような課題を以下に解決し、アプリケーションの品質を高めるかが重要になります。
Visual Stuio 2012 では、Web アプリケーション開発において使用可能な様々なテスト機能を用意しており、また品質向上やチームコラボレーションのツールと合わせて利用することによって、高品質な Web アプリケーション開発をサポートします。
Web アプリケーションのアーキテクチャを考慮し、シンプルなテストを作成しよう
通常 Web アプリケーションにおいては次の図のような階層構造をとることがほとんどです。
例えば、ASP.NET の MVC フレームワークを使用した場合、「ブラウザー」の階層には、Vew のコード(JavaScript のスクリプトを含む)が、「サーバー インターフェイス」には Controller のコードが、また「サーバーロジック」には Model のコードが当てはまります。また「DB」のレイヤーにはデータアクセス コンポーネント等が当てはまります(他のシステムとの連携を行う場合は、DBではなく他のシステムがこのレイヤーに当てはまることになります)。
Web アプリケーションのテストを行う場合は、このほかにこのアプリケーションが動作している Web アプリケーションサーバーや OS についても考慮する必要があります。
そのため Web アプリケーションのテストを行う場合は、テスト対象とするロジックを各階層の中で閉じるように絞込み、各階層をまたぐような依存性に関しては Visual Studio の Fake Framework やモック(Moq)等を使用してできる限り削減し、よりシンプルなテストとすべきです。
ツールの教育コストやコミュニケーションコストを考慮してツール(道具)を選択しよう
階層構造をとる Web アプリケーションでは、階層ごとに使用可能なテスト ツールが異なることがあります。その場合個別にツールの調達を行うと、テスト担当者の教育コストが大きく膨らむことがあります。また、問題が発見された際に、問題の調査やトラッキングに関しても同じように個別のツールをしようとすると教育コストや、連携の煩雑さによるトラッキング漏れなどが発生する恐れがあります。
Web アプリケーションの品質向上を勘案した場合、このような教育コストやコミュニケーションコストも考慮したうえでツールの選択を行いましょう。
Visual Studio 2012 では開発チームがこれらのプラクティス実践をスムーズに行えるように、様々な支援機能を提供しています。
プラクティス1: Web アプリケーションのアーキテクチャを考慮し、シンプルなテストを作成しよう
Vsual Studio 2012 では様々なテスト機能を用意しており、Web アプリケーションのテストにおいては以下のようなテストシナリオにおいて、ツールの支援を利用したテストの作成、実施を行うことが可能です。
① Web アプリケーションの統合的なテスト、およびユーザーエクスペリエンスの確認を目的とした「手動テスト」
ソリューションシナリオ「手動テストの品質向上」におけるプラクティスの一つ目「手動テストの実施環境を整えよう」にて紹介したように、Visual Studio 2012 を使用すると手動テストの効率化を行うことが可能です。
Web アプリケーションのテスト担当者は、この機能を活用することによりテストシナリオを一元管理することができ、また実際に地震で Web アプリケーションを操作しながらユーザーと同じ立場でのユーザー エクスペリエンス確認が可能になります。
② Web アプリケーションの個々のコンポーネントの動作を検証するための「単体テスト」
Web アプリケーションにおいても通常のアプリケーションと同様、ロジックの中心となるのはエンティティ オブジェクトによるビジネスロジックの実装部分です。単体テストを使用すると、Visual Studio のテストエクスプローラー等のルールを利用しながら、エンティティ オブジェクトに対する適切なテスト作成と実行が可能になります。
また、階層構造を持っていて他のコンポーネントへの依存性が高い Web アプリケーションにおいても Fake Framework を利用することで、外部依存性を下げつつ、ロジックの単体テストに注力することが可能です。
例えば、ASP.NET MVC フレームワークにおける Controller 階層のロジックにおいて、「認証に失敗した場合にその旨を画面に表示する」という Login 画面のロジックが以下のように存在したとしましょう。
この Controller の単体テストを記述する場合に、外部のロジックとなる WebSecurity への依存性を排除したい場合、Fake フレームワークを使用することで以下のようなテストロジックを記述可能です
この記述により、Controller の単体テストにおいて、「誤った ID/Pass が渡ったさいに WebSecurity が false を返すかどうか」は考慮する必要がなくなり、純粋に Controller 部分の振る舞いのみをテストすることが可能になります。
※ 「単体テスト」としてではなくシナリオテストや、統合テストとして WebSecurity の動作を含めてテスト行うことが目的であれば、Fake Framework による外部依存性の排除は必要ありません。またそのような場合は Visual Studio の単体テスト機能を使用するのではなく、コード化された UI テストや Web パフォーマンステストの使用をお勧めします。
③ Web アプリケーションの画面遷移やページ毎のパフォーマンスを確認する「Web パフォーマンステスト」
Web アプリケーションにおいて、例えば POST メソッドにより何らかのデータ更新等を行い成功した場合に別のページに遷移するようなアプリケーションを作成する場合、その動作の検証に関しては「Web パフォーマンス テスト」機能が活用いただけます。
「Web パフォーマンス テスト」では、Web サーバーに対する HTTP Request の情報を記録し、それをもとに再生可能な(自動化可能な)テスト情報を作成します。HTTP Request の記録はブラウザ(IE)のアドインとして実行されるので、特別な操作が必要なわけではなく、テストを行いたいシナリオに基づいてブラウザで操作を行うだけでテスト用のデータが作成されます。
また、作成されたテスト用のデータは、C# や Viusal Basic のコードに変換できるため、開発者がコードをもとにしてカスタマイズを行いたい場合などに便利です。
作成したテストを実行すると、各ページの応答速度やページのサイズ(バイト数)、あるいは応答として戻ってきたページの情報(HTTP Response)などを確認することが可能です。
④ 同時一斉アクセス時の Web アプリケーションの振る舞いを検証する「負荷テスト」
Visual Studio 2012 では、あらかじめ用意した Web パフォーマンステストや単体テストを利用して負荷テストを実行することが可能です。負荷テストには (1)想定されたユーザー数のアクセスが起こった際のパフォーマンスを検証する “(狭義の)負荷テスト”、および (2) 想定されるユーザーを超えてアクセスが発生した際のパフォーマンスを検証する ”ストレステスト” が存在します。
Visual Studio ではいずれの場合のテストも可能です。下記は、徐々にユーザー数を増やしながら Web アプリケーションのパフォーマンス、ふるまいを確認しているテストの実行状況です。
Visual Studio 2012 を使用すると、負荷テストにおいて [1] 各ページの応答が期待する時間内に戻ってくるか、[2] ページ間の遷移が期待する通りに行われるか、といった内容を検証しつつ合わせて [3] サーバー側のメモリ、CPU 使用状況、[4] テスト実行コンピューターのメモリ、CPU 使用状況、などのデータを確認しながらテストを実行することが可能です。
⑤ Web アプリケーションの統合テストを自動化する「コード化された UI テスト」
Web アプリケーションのテストにおいて、(1) JavaScript の実行によって Web ページの DOM が書き変わることがある場合にその内容を検証したい、(2) 異なるブラウザを使用した場合においても処理が正しく行われ適切な表示が行われるか検証したい、といった場合に利用いただけるのが「コード化された UI テスト」機能です。
最終的なユーザーエクスペリエンスを確認する、という意味では①の手動テスト支援機能に近いテスト作成が可能であり、かる自動化が可能なためテスト実施に当たってのコストを低減させることが可能です(なお「コード化されたUIテスト」では、個別のブラウザを使用して実際にテストを行うため、これをもとにした負荷テストは作成できません)。
下記の画面は、右下にある「コード化された UI テスト ビルダー」によって、ブラウザに対する操作(ブラウザの立ち上げや、ブラウザの終了なども含むUIに関する操作)を記録し、テストを作成している画面ショットになります。
「コード化されたUIテスト」はその名前の通り、C# や Visual Basic のコードとして生成されるので、開発者によるカスタマイズも容易に行うことが可能です。
このように、Vsual Studio 2012 では様々なテスト機能を用意しているので、Web アプリケーションのテストにおいてテストを粉いたい箇所や検証したいシナリオに併せて最適なテスト機能を活用いただくことが可能です。
プラクティス2: ツールの教育コストやコミュニケーションコストを考慮してツール(道具)を選択しよう
先に解説したように Visual Studio 2012 では Web アプリケーションのテストを支援する様々な機能を提供しています。
Visual Studio 2012 を使って テストを行う場合の最も重要な点はこれら個々の機能が用意されている、というだけではなく、それぞれのツールが Visual Studio に統合されているために開発者は使い慣れた環境でそれらのツールを活用しテストの作成、実施あるいは問題の解決が行えます。またテストの実施情報として個別の状況のみならず全体的な状況を確認できたり、バグを起点にした再現テストの作成やバグ解決のためのコード変更など、様々な情報を一元的に管理することが可能なため、効率的なプロジェクト運営が可能になります。
例えば、負荷テストにより Web アプリケーションにおいて期待通りのパフォーマンスが出なかった際に、パフォーマンス測定ツール(「コード品質の向上 ~ その2 ~」のプラクティス4にて紹介)を利用すれば、ロジック上のボトルネックとなっている箇所を効率的に見つけることが可能になります。また、その情報は Team Foundation Server を利用することで問題の発見から、担当者の割り当て、問題個所の解決(コードの変更)、といった一連の作業を記録することができ、解決までのステップをトラッキングすることが可能です。
また、ユーザー視点でテストを行う場合には、あらかじめユーザーストーリーごとにテストのグループを作成し、そのシナリオに関するテストを関連付けておくことで、ユーザーストーリー単位でのテスト実施状況を Excel や Web を使って確認することが可能になります。これによって、プロジェクトリーダーやプロジェクト マネージャーは、プロジェクト全体の進捗状況を把握することが可能になります。
ユーザー ストーリー テスト状態 Excel レポート (アジャイル)
よりよい Web アプリケーション開発のために、ぜひ Visual Studio 2012 の多彩な Web アプリケーションのテスト機能を活用してください。
今回は、Web アプリケーションのテストの自動化において考慮すべきポイントと、Visual Studio 2012 の支援機能を紹介しました。
ソリューションシナリオには、以下のシナリオがあります。
それでは!