特集 エキスパートに聞く

 

 

特集 エキスパートに聞く
日本ヒューレット・パッカード株式会社 HPソフトウェア事業統括 小宮山晃 

「高品質」について優れた開発チームにみられる取り組み~その2~

日本ヒューレット・パッカード株式会社
HPソフトウェア事業統括 小宮山晃

第九回:ALM支援ツール

前回に引き続き、「HPの考えるALMアプローチ(コアライフサイクルと完全ライフサイクル)」の冊子である「アプリケーションハンドブック~最新のアプリケーションライフサイクルを理解するためのガイド」の概要を紹介していきます。

第5回~8回にかけて従来のSDLCによって培われたお客様のプロセス管理手法をHPがヒアリングし把握した、優れた開発チームに共通する4つの特性のうちの「変更対応力」、「予測能力」、「反復性」について説明しました。前回は最後の「高品質」について過去のHPがこれまで支援した優れた開発チームにみられた3つの取り組みのうち、「1.機能は正しく動作するか?」について説明しました。

今回は、2つ目である、「2.性能目標は達成しているか?」の取り組みを紹介します。

高品質:性能目標は達成しているか?

前回も紹介しましたが、旧BTOClubサイト内において、「テストの近代化」がアプリケーションの近代化に伴い必要となってくるという話をしました。そのアプリケーション・モダナイゼーションを実現する理由の一つに「ユーザー体験の充実」という目的があることにも触れましたが、近年、以前よりも、このユーザー体験(UX)を意識した開発が実施されているように思います。
理由としては、PCからタブレットやスマートフォンなどへユーザー利用端末が大きくシフトしている事と、タブレットやスマートフォンの端末において、UXが重要な位置づけになっている事が考えられます。
以前はRIAと言えば、Adobe Flex、Microsoft Silverlight、AJAXなどのテクノロジーが主流でしたが、最近ではそれらに加え、タブレットやスマートフォンで利用できるテクノロジーという意味でHTML5の導入も進んでいます。これらのテクノロジーの特徴はかつての「クリックしてからサーバー側の反応を待つ」と言うWebアプリケーションから、ユーザーの操作にあわせて動的にコンテンツを表示させるというユーザー体験を満足させる事への変化だと言えます。

しかしながら、「テストの近代化」で触れたように、WebブラウザとアドインだけでこれらRIAのテクノロジーが実現できるとはいえ、テストという視点で見ると、課題がでてきます。クライアント側でロジック処理が行われるため、アプリケーションの性能計測がいままでのWebアプリケーションのテストに比べ、複雑になります。

RIAで採用されるテクノロジーはクライアント側とサーバー側とで常時、細切れのデータを通信し合っています。そして、動的なコンテンツを表示させるために通信内容が変化するという特徴があります。これがテスト、特に負荷テストを複雑にする要因になります。    負荷テストにはツールを利用する事が現在では一般的になってきましたが、ツール用のスクリプト作成はクライアント側での人のアプリケーション操作で発生する通信を記録し、シュミレーションする方法が多く採用されています。その際、典型的に使われてきたテクノロジーが、クライアント側とサーバー側の通信セッションを記録しそこからセッションIDなどの動的に変わる情報をパラメータ化してスクリプトにするという機能になります。(負荷テストにおけるツールを利用する事の必要性については、HPコミュニティサイト内の「エキスパートに聞く」のコーナーにてアシスト様による負荷テストの連載があり、そちらに詳しく書かれています。)
RIAの場合は、既存の技術を利用した記録エンジンでは対応できない場合もでてきます。Webブラウザ上のユーザー操作そのものに依存したスクリプトが必要になるためです。このようにリッチアプリケーションの利用はますます採用されるものの負荷テスト時を考えた場合、新しい課題がでてきます。ベストプラクティスとなった開発チームからヒアリングした課題は以下のようなものでした。

  • RIAクライアントとサーバコンポーネントの両方のパフォーマンスの検証
  • 複数のWebページのHTTP呼び出しに必要な時間の調査
  • エレメントのドラッグ&ドロップ、Webメールの表示と削除など、RIAクライアントでよく使われる操作が完了するまでの時間の調査
  • データの更新や変更の速度など、クライアントの活動に対するアプリケーションの応答性の検証
  • アプリケーションの非同期動作
  • 特定のクライアントコンポーネントのトランザクションの内訳
  • 分散化の進んだ異機種サーバーシステムに関するパフォーマンス上のボトルネックの診断と監視

上記課題のうちいくつかを解決する方法としては、「クライアント側での操作をいかに負荷テスト用のスクリプトにできるか」だと言えます。

どう記録するか

では、RIAのクライアント側の操作やそれに伴う動的なブラウザの情報をいかにスクリプトに反映できるでしょうか。ブラウザそのものを動かしてしまうのであれば忠実に再現できるため、一つの方法としてHP Unified Functional Testing(HP UFT)のGUI機能テストツール(旧QTP)を負荷テストツールであるHP LoadRunner(HP LR)のスクリプトとして利用する事が考えられます。
ただ、この場合、1クライアントマシンにインストールできるHP UFTが1つという制限から仮想したいユーザー分のクライアントマシンとHP UFTを準備しなくてはならないという問題が発生します。

そこで、HPでは一昨年リリースしたHP LRバージョン11の新機能として「TruClient」という記録エンジン(いままでの負荷テストツールの記録方法とHP UFTのような機能テストツールの両方の中間のような記録エンジン)を実装しました(図1参照)。見ていただくと分かるようにWebブラウザのアドインとして記録エンジンが実装され、ブラウザのAPIを利用してユーザーの操作を忠実に記録します。

図1:TruClient(LRの記録エンジン)

図1:TruClient(LRの記録エンジン)

もちろん、これまでの負荷テストツールのスクリプト編集と同様に、データ駆動型のパラメータ編集なども可能ですが、特質すべきところは同じWeb画面上のパーツ(ボタンやフォームなどのオブジェクト)の認識方法が複数ある場合はどれで認識させるかを編集する事ができ最適な選択が可能になるところがこのTruClientの強みです。簡単な例をあげてみますと、リスト化されて縦表示される項目の記録時の認識方法がリストの上からの5番目という「順番」で認識していたとします。ところが、これが毎回動的に順番が変わってしまう場合、認識方法を項目の「ラベル名」に変更すると言った事が簡単にGUI上から数ステップで可能になります。
また、TruClientでは、下記の図2にて「スクリプトレベル」とかかれたバーが示すように、3つのレベルで操作の深度を設定する事ができ、マウスの操作までをスクリプトでシミレーションできます。スクリプト内のステップ単位に設定する事もできますので、操作の深度をステップ単位で設定したスクリプトが生成可能になります。

図2:TruClientのスクリプトレベル

図2:TruClientのスクリプトレベル

HP LRでは、上記の方法でAJAXなどへの負荷テストに対してブラウザ操作をシュミレーションするTrueClientエンジンだけでなく、Flex、SilverlightといったRIA技術に対応した専用の記録エンジンも提供しています。

最近では、スマートフォンやタブレット用のアプリケーションを開発する事も進んでいます。これは個人レベルのアプリケーションという意味ではなく、エンタープライズの業務アプリケーションがこれらのデバイスを端末として利用するように設計されてきていると言う事です。海外では、「モバイル・ファースト」という考えも提唱されています。これは、「アプリケーションは、まずモバイル端末向けに提供し、それから他の端末向けを提供する」という開発方針を意味しています。
ここでのパフォーマンスを左右するのは、記録の仕方もたしかにありますが、回線をいかにテスト時にシュミレーションするかという点も重要な所です。以降、回線品質のテストについて簡単にご説明します。

下の図3をみていただくと分かるように、スマートフォン、タブレットのアプリケーションを提供する場合、実際はまずキャリアの通信回線を通り、そこからインターネット経由などで企業のアプリケーションシステムへ接続する事になります。しかし、システムテストにおけるステージング環境では、負荷テスト時にそこまでの環境を用意できる事はまれではないでしょうか。そこで、考えられるのは回線のシミュレーションという方法です。
回線をシミュレーションしたテストをしておかないと、回線の品質によって、アプリケーションの応答時間がシュミレーションしない状態で負荷テストした場合と比較して激しく遅くなるという事があります。回線品質というと、スマートフォン登場以前は基盤担当者側の問題でしたが、今後はアプリケーションのテスト担当者もテスト時に押さえておかないといけないポイントになります。

図3:負荷テスト時の回線シミュレーション必要性

図3:負荷テスト時の回線シミュレーション必要性

例えば、回線の状態が500Kb/秒を想定してトラフィック制限アプライアンスなどを利用してシステムテストを実施したとします。
ところが、実際のキャリアを利用したネットワークでは、上下が非同期帯域であることや、利用する時間帯、アクセスしてくる場所によってネットワーク品質(遅延やパケットロス)の状態が異なります。そのため、500Kb/秒でテストした際には応答時間が4秒だったアプリケーションが40秒になることもあり得るのです。そのため、これらをテスト段階で考えられるネットワーク品質パターンでテストしておくことはモバイル端末に業務アプリケーションのインターフェースが移行する時代には重要な要因だと言えます。
HP LRでは、標準で非同期の回線帯域シュミレーションができます。また、Shunra社のシュミレータ(ソフト版とアプライアンス版があります)とHP LRが連携し、これまでの負荷テストのシナリオに回線品質のパターンを組み合わせたテストができるようになります(図4参照)。具体的な利用方法などはモバイル向けのスクリプト記録と併せて別の機会にしようと思います。

図4:Shunra社LR向けソフトウェア版回線品質シミュレータ

図4:Shunra社LR向けソフトウェア版回線品質シミュレータ

このように、HPでは最新のテクノロジーやアプリケーションの動向にあわせてベストプラクティスからえられた課題に対して解決の支援をしています。

まとめ

前回からの続きとして優れた開発チームに共通する4つの特性の4つ目である「高品質」についてお話させていただきました。特に高品質の2つ目である「性能目標は達成しているか?」について、現在主流になっているRIAやモバイルに対して負荷テストするかのポイントについて説明しました。たしかにテクノロジーとしてはこれまで様々なテストチームが実績やノウハウを積み重ねてきたWebアプリケーションへの負荷テストであるにも関わらず、新たなテスト時の課題があると言う事が理解していただけたかと思います。

次回は、引き続き「高品質」の「性能目標は達成しているか?」について分析をテーマに話をしたいと思います。