CodeZine(コードジン)

特集ページ一覧

【デブサミ2014】13-A-6 レポート
Mobageオープンプラットフォームの品質を担保するSWETグループのテスト方法とは?

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2014/03/17 14:00

目次

Web API、Webアプリ、モバイルWebのテスト方法を披露

 Mobageオープンプラットフォームアーキテクチャの中で、SWETグループがテスト対象としているのは次の4つである。

  • Mobage RESTful API(Web API)
  • Mobage Developers(Webアプリケーション)
  • mbga.jp&ProxyServer(モバイルWeb)
  • Mobage SDK(クライアントSDK)

 「チーム立ち上げ時に、私たちはエンド・ツー・エンドのテストの確立という目標を掲げた。これらはいずれもユーザーに一番近いところ。だから、ターゲット(テスト対象)とした」(中川氏)

Mobage RESTful API(Web API)

 では、具体的にどのようなテストを行っているのか。最初に中川氏が紹介したのは、Web APIのテストである。Web APIのテストでは、APIサーバーとHTTPで通信してテストを行うが、テストクライアントはAPIサーバーやデータベースなどと同じセグメントに置く構成をとる。これにより、データベースやキャッシュのデータを、テスト中に参照したり変更したりすることを可能にしている。

 SWETグループでは、これを「Gray Box Fixture」と呼んでいる。テスト自体はブラックボックスで行いながらも、テストの条件を作るところはホワイトボックスで行う。特にWeb APIでは、この「グレーボックス」を重視していると中川氏は語る。

 その他にも、テスト用にDNSサーバーを利用して特定のサーバー1台をテスト対象にしたり、Web APIのドメインに特化したクライアント (Domain Specific Client) である「mobage-api-client」を作成したりして、テストを行っている。また、HTTPの通信内容をダンプできるようにしたり、テストを対話実行できるようにして、テスト中でのデバッグを可能にしているとのことだ。

Mobage Developers(Webアプリケーション)と
mbga.jp&ProxyServer(モバイルWeb)

 WebアプリケーションやモバイルWebに対するテストは、ブラウザ上で行っている。先述のWeb APIのテストと異なるのは、UIやJavaScriptを多用している点である。

 Webアプリケーションのテストは最近のデファクトに忠実で、ツールとして「Selenium WebDriver」を採用。高速化のため、Headlessブラウザも使用している。

 特徴的なのは、「ブラウザとエミュレータを使い分けてテストしている点」と中川氏。ブラウザでは、一般的にHTTPヘッダは取得できない。一方、mechanizeのような方法では、HTTPヘッダは取得できるが、JavaScriptの解釈ができないことが多い。そこでブラウザの状態を保存し、ブラウザとエミュレータを自動的に切り替える工夫を施しているという。そのほか、ここでもDomain Specific Clientである「mobage-browser」というライブラリを作成して、テストを実施している。

 また、UIテストではPage Object Patternを使っていない。モバイルエミュレーションについては、今はリアルデバイスを使う方向に動いており、「CalabashやAppiumなどに手を出していこうとしている」(中川氏)。

Mobage SDK(クライアントSDK)

 クライアントSDKのテストについては、「実際に自分たちでSDKを使ったアプリを開発し、そのアプリ操作を自動化するテストを実行することで、SDKがちゃんと動いているかをチェックする方法でテストをしている」(中川氏)という。UIオートメーションに関しては、複数のデバイスでもテストケースに一貫性を持たせられるよう、「Calabash」や「Appium」を利用。Calabashによるテストについては、自身も執筆に参加した「『WEB+DB PRESS vol.77』(技術評論社刊)の特集1『スマートフォンテスト最前線』をぜひ読んでほしい」と述べた。

 最後に中川氏は、Domain Specific Clientの強みを生かしたテストの例を示した。例としたテストの対象と内容、およびテストシナリオは次のとおりである。テストシナリオは、(中川氏があまり好きではないという)Cucumberで書かれている。

●テスト対象
「ゲームから送られるブロードキャストの通知に対し、ユーザーが、モバゲーチャットでnotificationを受け取るか受け取らないかの設定を、モバゲーのサイトから変更する」という機能

●テスト内容
❶ 「ユーザーがログインし設定ページでnotificationの受け取りを有効にすると、notificationのブロードキャストが飛んできて、そのメッセージを確認できる」こと
❷ 「ユーザーがログインし設定ページでnotificationの受け取りを無効にすると、notificationのブロードキャストが飛んできても、そのメッセージを表示しない」こと

●テストシナリオ

❶ notificationの受け取りを有効にする場合
Feature: Notification from Games
  Scenario: User can receive notification
    Given user login to mbga.jp
    When user visit to settings page
      And user enable to “notification” setting
      And game broadcast notification using API
      And user visit to Mobage Chat page
    Then user can show notification message

❷ notificationの受け取りを無効にする場合
Feature: Notification from Games
  Scenario: User can ignore notification
    Given user login to mbga.jp
    When user visit to settings page
      And user disable to “notification” setting
      And game broadcast notification using API
      And user visit to Mobage Chat page
    Then user can not show notification message

 

 このシナリオには登場人物としてuserとgameがいるが、それぞれのテストコードの実装に、mobage-browserおよびmobage-api-clientというDomain Specific Clientを使っている点がポイントである。これにより、APIとWebをまたがる結合テストが容易に実装できている。「ここに、Domain Specific Clientにこだわってやってきた利点が出ている。コンポーネント単位のエンド・ツー・エンドのテストから、複数のコンポーネントを対象とするシステムテストまで、クライアントを再利用できるメリットがある」(中川氏)。

 全体として、事例や実際に活用しているテスト技術に踏み込んだ密度の濃いセッションであった。

お問い合わせ

株式会社ディー・エヌ・エー

〒150-8510 東京都渋谷区渋谷2-21-1 渋谷ヒカリエ

フォーム: http://dena.com/contact/

URL: http://dena.com/

 



  • LINEで送る
  • このエントリーをはてなブックマークに追加

あなたにオススメ

著者プロフィール

  • CodeZine編集部(コードジンヘンシュウブ)

    CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

バックナンバー

連載:【デブサミ2014】セッションレポート

もっと読む

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5