ISOROOT Tech Blog

ブラウザテストの便利ツール「BrowserStack」の知っておくべき5つのポイント

2016-09-26T12:00:00+09:00

こんにちは、kureyです。

みなさんブラウザテストをする際の環境はどのように用意していますか？

利用するデバイス×OSのバージョン×ブラウザの数だけテストの実行環境を用意してテストする…。考えるだけでめんどくさいし、コストもかかるのが容易に想像できますね。

そんな時は世の中にあるWebサービスを使ってこの問題を解決しちゃいましょう。

今回取り上げるのはBrowserStackというWebサービスです。

このサービスを利用する事でどんな事ができるのか、そして他のサービスとどのような違いがあるのかをご紹介します。

1. BrowserStackってどんなサービス？使うと何が嬉しいの？

BrowserStackというサービスがどういうものかを一言でいうと各種OS、各種ブラウザをあなたがお使いのブラウザ上から操作をできるようにしてくれるサービスです。

このサービスの一番の魅力はブラウザテストするために必要な環境を準備する事が不要になることです。

2. どのぐらいの環境が用意されてるの？

BrowserStackにはとても豊富な環境が用意されています。（詳しくはコチラ）

Windows XPからWindows 10まで、MacはOS X Snow Leopard(v10.6)からOS X El Capitan(v10.11)までをサポートし、ブラウザはIE、Safari、Chrome、Firefox、Operaなど主要ブラウザはほぼ網羅しています。

3. ブラウザ毎の表示確認ぐらいなら他サービスで良くね？

ブラウザのスクリーンショットだけを確認したいだけであれば「modern.IE¹」や「BROWSER SHOTS」など確認したいWebページのURLを入れるだけで確認ができるWebサービスが存在します。

もちろんBrowserStackにも「Screenshots」というものがあり、他サービスと同様にWebページのURLを入力し、スクリーンショットを取りたいOSとブラウザを選択することでお手軽に表示確認をすることができます。

…だが、BrowserStackには更にLiveという機能が存在し、あなたのブラウザ上から全く別のOS、まったく別のブラウザをリアルタイムで操作することができ、より細かな動作確認ができるのです。

例えば動的なページに対して何か操作を行った結果が問題ないかを確認したい場合などに効果を発揮します。

4. もちろん自動実行も備えてます。

ScreenshotsやLiveという機能で表示確認や操作を毎回手動でテストするのはやはりコストがかかってしまいます。

そこで登場するのがBrowserStackのもう一つの機能Automateです。

これはSeleniumなどのテストコードを実行する事でBrowserStack上で用意されているブラウザのテストを自動で行うことができます。

Jenkinsと組み合わせて毎日定期実行することで継続インテグレーションを実現することができます。

また、AWS Device Farmも2015年11月にWebアプリケーションテストに対応し、同じようにテストコードからブラウザのテストを自動実行できるようになったため、スマートフォンのブラウザテストはAWS Device Farm、PCのブラウザテストはBrowserStackといった使い分けができます。

5. 有料サービスであること

最後はデメリットになります。

BrowserStackはとても魅力的なサービスではありますが、いいサービスには対価が伴います。

そうです、お金ですね。

プラン	料金
Live	$29
Automate	$59
AutomatePro	$99

※上記は１ユーザ１セッションの場合の値段のため、複数人で同時に利用する場合には更に値段が高くなります。

BrowserStackは月額プランとなっており、あまりお気軽に試してみようというには若干高い金額となっておりますが、他サービスのAWS Device Farmと比べると多少安価²な値段設定となっている。

まとめ

いかがでしたでしょうか。

Web開発者にとってクロスブラウザの確認はほぼ必須となっており、確認するための環境作りなどで手間を割かれてしまうのはとても勿体ない事であり、その時間をもっと開発に使える事ができればより良いサービスを生み出す事ができるでしょう。

BrowserStackはそんな手間を解消してくれるとても魅力的なサービスであるため、まずはFreeTrialで試してみるのはいかがでしょうか。

modern.IEはBrowserStackを使ってスクリーンショットをとっている。 ↩
AWS Device Farmの料金設定は$0.17/分、$250/1デバイススロット(iOS/Android毎に契約可能な月額プラン) ↩

Selenium(Java)でブラウザテストをするときにやっておくべき３つのこと

2016-08-15T12:00:00+09:00

こんにちは、kureyです。

今回は私がSeleniumとJavaを使ってWebアプリケーションの画面テストをする際に気を付けたことを３つご紹介します。

Seleniumとは？

Seleniumとは、ブラウザのテストで用いられるフレームワークです。

ブラウザに表示されているテキストなどの要素が正しく表示されているか？
ボタンをクリックすることで遷移する先のURLが正しいか？

などのサイト上の動作を様々な言語¹で記述されたプログラムによりテストする事ができます。

これは世に出ている様々なブラウザ上で自分のサイトが正しく動作しているか、定期的にテストするためによく使われます。

1. Seleniumでテストする範囲を決める

１つ目に気を付けるべき点はSeleniumでテストする範囲を決めることです。

最初から全ての画面の全ての操作をSeleniumで自動化しようとすると、テストコードを書くコスト物凄くかかる上、メンテナンスも大変となります。

私がSeleniumでテストを行った時は各画面で必ず存在するようなヘッダーやフッターの表示、メニューなど共通の画面で利用できるもの、ブラウザリロードやブラウザバックした時の動作、それぞれが想定通りの動作となっているかという点に観点を絞り、テストの範囲を最小限にしました。

このように自動化する範囲を各画面で必ず行うような操作に限定する事でテストコードは汎用的にしやすく、プログラムに落とし込むコストは大幅に削減でき、最小限のコストで最大限のパフォーマンスを発揮する事ができます。

2. テストコードを書く上でルールを決める

２つ目はテストコードを書く上でもコーディングルールを決めることです。

複数人でテストを書く場合、ルールを決めておかなければそれぞれが好き勝手書いてしまい、せっかくテストする範囲を限定したにも関わらず煩雑なテストコードが生まれてしまいます。

煩雑なテストコードとは、FirefoxのSelenium IDEを利用して画面上の操作をキャプチャし、それをそのままテストコードとして利用する場合が該当します。

FirefoxのSelenium IDE自体は画面上の操作を記録してテストコードを生成してくれるため、テストコードを作る上ではとても早いですが、テストコードの再利用が出来ないことや、画面変更が発生した際にSelenium IDEで操作を記録してテストコードを生成する必要が出てきてしまいます。

通常のプログラム同様、ある一定のルールを用いて開発を進めないと保守性の低いアプリケーションが完成しますよね？

たかがテストコード、されどテストコード。

アプリケーションの品質を高い保つためにはテストコードもクリーンにすることをオススメします。

ページオブジェクトパターンというデザインパターン

ここでご紹介するのはページオブジェクトパターンというデザインパターンです。

ページオブジェクトパターンとは、テストコードを記述する上でWebアプリケーション上の画面１つをオブジェクトとして捉えるデザインパターンの１種です。

Seleniumの公式でも推奨されている保守性の高いテストコードの書き方となります。

以下、公式に記載されているPageObjectの原則

・The public methods represent the services that the page offers（publicメソッドは、ページが提供するサービスを表す）

・Try not to expose the the internals of the page （ページの内部を公開しないこと）

・Generally don’t make assertions （原則としてassertionを行わないこと）

・Methods return other PageObjects （メソッドは他のPageObjectsを返す）

・Need not represent an entire page （ページ全体を表す必要はない）

・Different results for the same action are modelled as different as different methods （同じアクションに対して異なる結果となる場合には異なるメソッドとしてモデル化する）

このデザインパターンで書かれたテストコードの利点は画面変更が発生した場合にテストコードの修正が最小限で済むことにあります。

3. テストすべき内容をインターフェースとして定義

３つ目は各画面で共通して必ずテストするものをインターフェースとして定義することです。

デザインパターンである程度テストコードの統一性は生まれますが、チェックすべきテストを書く・書かないはその人次第になってしまう事があります。

私はそれを防ぐために必要なチェック項目をインターフェースとして定義する事でテストの漏れをできる限り少なくなるようにしました。

public interface MyTestCaseInterface {
    public void testCheckUrl();          // URLのチェック
    public void testCheckPageTitle();    // ページタイトルのチェック
    etc...
}

サンプルコード

以下は参考までに私がテストを行ったときのパッケージ構成とテストコードのサンプルとなります。

パッケージ構成

jp.co.isoroot.sample.page        // ページオブジェクトクラス
jp.co.isoroot.sample.scenario    // シナリオクラス
jp.co.isoroot.sample.fixture     // データクラス

ページオブジェクトクラス

画面１つ１つをクラスとして定義します。

また各画面で共通の部分がある場合、ベースクラスを定義して各画面で継承させると良いでしょう。ただし、なんでもかんでも共通化しようとしてベースクラスが肥大化しすぎないように注意が必要です！

以下はログインページとトップページのサンプルコードです。

public class PageBase {
    protected WebDriver driver;
    public PageBase (WebDriver _driver) {
        this.driver = _driver;
    }
    /**
     * <title>要素のテキスト取得
     */
    public String getPageTitle() {
        return driver.findElement(By.tagName("title")).getText();
    }
    /**
     * URL取得
     */
    public String getUrl() {
        return driver.getCurrentUrl();
    }
}

public class LoginPage extends PageBase {
    public LoginPage(WebDriver _driver) {
        super(_driver);
    }

    /**
     * ログインページにURLアクセス
     */
    public HogePage access() {
        driver.get(ログインページURL);
        return this;
    }

    /**
     * ログインボタンクリック
     */
    public TopPage clickLogin(String _id, String _pass) {
        driver.findElement(ログインID入力フォーム).sendKeys(_id);
        driver.findElement(ログインパスワード入力フォーム).sendKeys(_pass);
        driver.findElement(ログインボタン).submit();
        return new TopPage(driver);
    }
}

public class TopPage extends PageBase {
    public TopPage(WebDriver _driver) {
        super(_driver);
    }

    /**
     * トップページにURLアクセス
     */
    public TopPage access() {
        driver.get(トップページURL);
        return this;
    }
    /**
     * ログアウトボタンクリック
     */
    public LoginPage clickLogout() {
        driver.findElement(ログアウトボタン).click();
        return new LoginPage(driver);
    }
 }

シナリオクラス

このクラスではページオブジェクトクラスを利用してテストするシナリオを定義します。

以下はログインページのURLとページタイトルをチェックするサンプルコードです。

public LoginPageTest implements MyOperationTestCaseInterface {
    WebDriver driver;
    public LoginPageTest() {
        driver = new ChromeDriver();
    }
    @Test
    @Override
    public void testCheckUrl() {
        LoginPage _login = new LoginPage(driver).access();
        assertTrue(_login.getUrl().equals(ログインページURL));
    }
    @Test
    @Override
    public void testCheckPageTitle() {
        LoginPage _login = new LoginPage(driver).access();
        assertTrue(_login.getPageTitle().equals("ログインページ"));
    }
}

補足：WebDriverの取得もFactoryクラスを作って切り替えられるようにするとより汎用的になります。

最後に

今回はWebアプリケーションの画面テストをする際に注意すべきこととして

テスト自動化の範囲
テストコードの記述ルール(デザインパターン)
テストケースの抽象化(インターフェース定義)することによるテスト漏れの防止

をご紹介しました。

テストコードを書くのはとてもコストがかかりますが、Seleniumのようなテストツールを上手く活用する事でテストにかける時間を少なくし、産性を最大限に引き出す事ができるきっかけの一つとなりますので、ぜひ活用してみてはいかがでしょうか。

Selenium WebDriverはC#、Java、Perl、PHP、Python、Ruby、Node.jsに対応。 ↩