テスト自動化を導入してみたものの思ったより効果が出ない……その解決策は2つの仮想化にある
機能テストの自動化や負荷テストのシステム化を進めている開発現場が増えている。Quality(品質)、Cost(費用)、Delivery(納期)を改善するためだ。しかし、せっかくのテスト自動化が、思ったような効果をもたらさないケースがある。本記事では、テスト自動化における思わぬリスクと、その解決策として2つの「仮想化」を紹介していきたい。
システムを構成するすべてのサービスをテスト時に準備することの難しさ
テストを自動化すれば、テスト作業は当然スピードアップするはずだ。しかし、実際にはそうならないケースがある。機能テストの場合、自動化できる範囲が連続していればいるほど、自動化のメリットが大きくなる。しかし実際の開発現場では、すべての環境(サービス)が早期に揃うことはめったにない。このため、せっかくテストを自動化しようとしても、ぶつ切りになってしまい、効果が得られないのだ。システムを構築するサービスが揃わないケースとしては、以下のような例がある。
- 外部サービスのため接続すると課金対象になる
- 接続できる時間が限られている(早朝の1時間のみなど)
- そもそも開発途中でアクセスできない
例えばECのシステムを構築するケースを考えてみたい。[ユーザーがログインする→商品をカートに入れる→クレジットカードで支払いする→商品を発送する]という一連の流れでも、ECのWebサイトやアプリ以外に、認証システム、クレジットカード会社のシステム、商品の在庫管理システム、配送会社の管理システムやトラッキングシステムなど、さまざまなシステムが組み合わされている。このように外部サービスが含まれていて、そのサービスをテスト段階では利用できない、という問題が発生するのだ。
また、すべて社内で開発している業務システムなどでも、いくつかのシステムを組み合わせている場合、プロジェクトごとに進捗が違うのは当然だ。このため、他システムに依存する箇所に関するテストについてはそれらのシステムが揃うまで待ち時間が発生する。あるいは、部分的に外部に開発を委託しているというケースもあるだろう。更に酷いケースとして、すべてのサービスが揃うのがリリース直前という場合すらある。そこで初めて全体のテストを行なった結果、不具合が見つかっても対応が間に合わない、という事態にもなりかねない。できるだけ早くテストして、不具合があれば早めに対処するシフトレフト(テスト工程の前倒し)が理想だ。
そこで、ポイントとなるのが、1つ目の仮想化である。揃っていない(利用できない)サービスを仮想化、つまり、あたかもそこに存在するかのような状態を作り出し、システムを結合した状態のテストを前倒しで行う、という対策である。一般的な方法としてはスタブの作成を思いつく方も多いだろう。しかし、ここにも課題がある。例えば、開発作業中にスタブを作ること自体が工数をとられることにもなるし、限りある時間の中では簡易なものとなってしまい現実と乖離してしまう可能性があるのだ。また、複数の開発現場でスタブ用のサーバが乱立することでその運用コスト、メンテナンスコストも膨らんできてしまう。近年こうした課題を克服する仕組みが登場し始めている。例えば、HPEが提供する外部サービス仮想化ツール「HPE Service Virtualization」を利用すると、様々な外部システムやサービスを効率的に仮想化でき、テスト時に大きな効果が見込めるのだ。
「HPE Service Virtualization」ではリクエストと応答パターンを登録し、サービスを仮想化する。システムが既にあり、アクセスできるなら実際の通信を記録しリクエストとレスポンスを利用することも可能だ。応答する優先順位をGUIで設定するなど、基本的にプログラミングレスでシンプルに仮想化できるのが特徴だ。
さまざまな環境からのアクセスを想定したテストを行うことの難しさ
さて、次はネットワーク環境を意識したテストについて考えたい。社内ネットワークに繋がったPCからアクセスするだけだったかつてのシステムと違い、現在はモバイルが普及して、Wi-FiやLTE、3Gなどさまざまな方法でアクセスされる。これらの環境の変化を勘案せずに、従来どおりの社内LANの閉じた環境のみで性能テスト等を行っていると、リリース後に思わぬトラブルに直面することがある。例えば、以下のようなケースだ。
- キャパシティプランニングのためにテストしたのに、実環境では想定よりパフォーマンスが落ちる
- LAN環境では快適だったアプリケーションが、3G回線ではうまく動かない
もともと限界値を探るための性能試験のはずが、いざリリースしてみると、実際は予想外に性能限界が早く来てしまうことがある。これらの原因の1つとして”ネットワーク速度が遅いユーザーの影響を考慮できていないこと”があげられる。つまり、LAN環境だけでテストしたキャパシティプランニングでは、運用環境の動作が確認できない、ということだ。たとえ、9割のユーザーがLAN接続の社内アプリでも、1割が外出先からモバイル接続してくると、遅いネットワークでアクセスしているユーザーが性能上の不満を感じるだけでなく、社内からアクセスしている速いユーザー、つまりシステム全体に影響を及ぼすこともあるので要注意だ。
これは、一般的なシステムでは遅いユーザーであっても、処理が終わるまでセッションが維持されるため、そのユーザーにリソースが占有され、結果的に速いユーザーについても接続待ちになるためだ。こうした影響を軽減するため、モバイルユーザーが想定されるシステムでは、環境による遅延を考慮したネットワーク品質でのテストが必要となる。
また、モバイル以外でも、海外にあるデータセンターへのアクセスなど、高速でないネットワーク使用するケースも増えており、想定しないレスポンス遅延やタイムアウト等が発生したり、結果としてアプリケーションの機能にも影響を与えてしまう場合もある。このような問題を避けるためには、開発の早い段階から実際のネットワーク品質でテストし、どこまでが許容範囲かを確認する必要がある。場合によっては、コンポーネントを減らすことで問題を改善できるケースもあるだろう。問題によっては、「お待ち下さい」というお知らせページに飛ばす、アプリを再起動させるなど、回線速度が遅い場合の挙動を、アプリケーションの機能として実装しておかなければならないケースもあるだろう。
このような問題点の発見やその結果による対応策等を考えるにあたっても現実のネットワーク速度でテストすることが重要だとわかる。しかし、大量のモバイル端末を用意してテストを行うのは現実的ではない。そこでポイントとなるのが、2つ目の仮想化である、ネットワークの仮想化だ。HPEが提供するネットワーク仮想化ツール「HPE Network Virtualization」では、帯域幅や遅延、パケットロスといったネットワークコンディションを、LAN環境の中で設定してテストが可能になる。このソリューションでは、利用キャリア、アクセスする場所、端末などの情報が既存で設定されていて、さまざまな試用ができる。つまり、仮想的にモバイル環境からアクセスしている状況を社内で構築してテストできるのだ。さらに負荷テストツール「HPE LoadRunner」や、機能ストツール「HPE UFT」などと連携し、ネットワーク品質を考慮した状態で性能テストや機能テストを実現することができる。
ここで、最後にHPEが提供する2つの仮想化ソリューションの特長をおさらいしておこう。
「HPE Service Virtualization」の特長
テストスタブ作成工数が容易
プログラムレスのシンプルなGUI操作でスタブを作成できるので、作業工数が削減できる。テストを前倒しで実施することで、問題検出時の手戻りコストの削減にもなる。
低い運用コスト
複数サービスを同一サーバで稼働可能なため、サーバ台数を削減できる。
ウェブサービスやMQ、SAP AQ、JDBCなど幅広いプロトコルに対応
例えば既存のERPと連携するシステムを作る場合、本番環境で動いている基幹システムに繋いでテストすることはできない。「HPE Service Virtualization」はウェブサービス以外にも幅広いプロトコルに対応し、SAPの認証を受けている唯一のツールでもある。
負荷テストに対応できるスケーラビリティ
大規模負荷にも耐えられる設計がされており、負荷テストにも利用可能。スタブからのレスポンス速度も設定でき、より現実に近い負荷テストを実行できる。
シンプルなテストデータ管理
一般的に、スタブモジュールは定数を返すだけという作りになっていることが多いが、「HPE Service Virtualization」では、固定応答だけでなく、さまざまな応答パターンを設定できる。
「HPE Network Virtualization」の特長
ネットワークコンディションの収集
実運用環境のネットワークコンディションを測定する方法は2種類ある。また、世界各国の拠点のネットワークコンディションのライブラリーを用意しているので、それを利用することもできる。
- エージェント(NC Agents)
クライアントPCとサーバにエージェントをインストールし、各拠点から実際に通信させて測定する。グローバル展開している場合、海外拠点からのアクセスも考慮できる。 - モバイルアプリ(NC Express App)
Android、iOSの端末にネットワーク記録用アプリをインストールし、実際に通信させて測定する。アクセスが想定される場所に、実際に行って通信することができる。 - ライブラリー(NC Global Library)
世界各地のネットワークコンディションをHPEが測定してライブラリー化してあり、どこからどこの通信か、ネットワークの種類、キャリア、時間帯を設定できる。場所は、都市名よりも細かく、例えば「東京・丸の内」などの指定ができる。
アプリケーションパのフォーマンス検証
「HPE Network Virtualization」のサーバに、測定したネットワークコンディションを設定して、テスト対象のアプリケーションにアクセスする。ネットワーク品質を高精度で再現し、テスト対象アプリケーションの機能や応答性を正確に確認できる。
分析と最適化
テスト結果を分析し、パフォーマンス改善の最適なアプローチを探ることができる。
開発にテストはつきもの。早い段階で直す方が、後で直すより全体工数が少ない。それがシフトレフトの効果だ。「HPE Service Virtualization」と「HPE Network Virtualization」でサービスやネットワークを仮想化すれば、外部サービスやモバイルネットワークなどの外部環境によって、テストの効率化が阻害されることはない。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- モバイルアプリケーション開発のトレンドやテストの方向性とは
- アプリケーションライフサイクルの最適化がモバイルアプリの企業価値を高める
- アプリの差別化を図るにはインフラ監視だけでは不十分。UXを担保するAPMの必要性と手法とは
- モバイルアプリのテスト時における5つの課題とHPEが考えるテスト自動化とその先
- クックパッドの開発体制、モバイルアプリを取り巻く環境と課題解決―Think IT Mobile Developer Seminar 2015レポート
- 危険なモバイルアプリで会社を傾ける前に、低価格で簡単に使えるサービスで欠陥を洗い出そう
- コニカミノルタのワークプレイスハブの詳細が明らかに
- Windows Vistaの評価
- モバイルアプリの継続的テストフレームワーク、配信後のユーザー体験を測定―Think IT Mobile Developer Seminar 2015レポート
- ウインドリバー、NFVプロジェクトでチャイナモバイルと協業