fbpx

【テストを自動化】 第01回 Web-UI操作によるテストを自動化しよう！～概要～

Uncategorized

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

これから数回に分けて弊社で開発・運用している「テスト自動化ツール」および「テスト自動化のノウハウ」について紹介していきます。本稿では、機能テストのひとつである「Webブラウザを通して操作するテスト」を自動化したものを紹介します。

テスト自動化とは

インテグレーションとサービスプロバイダーにとって、アプリケーションを顧客に納品する場合はしっかりとテストをすることが大事です。Webブラウザの多様化やWebアプリケーションの改修など、アプリケーションが取り巻く環境に対応しているか確認するテストが増えています。大部分のプロジェクトでは、テストはプロジェクトの後半に行われます。環境構築や仕様変更など、テストを行う環境準備が遅れるとテスト期間が短縮されるなどの影響がでてしまう可能性があります。

手動テストは時間やコストがかかるのが一般的です。人海戦術でスケジュールに間に合わせるといった方法は、今後増えていくテストに対応できるとは限りません。テストを自動化することによって、テストにかかる時間やコストを抑えることができます。

テスト自動化とは、手動で行うテストをコード化したものとなります。自動化されたテストは無人でのテストも可能です。テストをコード化する作業もテスト自動化といえます。テストをコード化することによって「再実行」「コードの再活用」「資産管理」を容易に行うことが可能です。

テスト自動化のメリット

yubari

某牛丼屋ではありませんが、「早い、安い、旨い上手い」になります。

  • テストスケジュールの短縮、マシンリソースの有効活用（早い）
    人手より素早く、夜間問わず稼動可能ですので、テストに必要な日数は少なくなります。テスト内容によりますが、人手で2週間ほど要したテストが1晩で実施することが可能です。日中は他チームが利用していてテストできない環境でも夜間に実行する等マシンリソースを有効活用することが可能です。
  • テスト実施工数の削減（安い）
    テスト実施そのものの要員が不要となるため、テスト実施に限れば大幅なコスト削減となります。デメリットにて後述しますがテスト自動化の開発そのものにコストが必要になるため、費用面はそちらとの天秤になります。
  • テスト品質の平準化（旨い上手い）
    あらかじめプログラム化された操作を行うため、人により作業品質が変わることがなくなります。ヒューマンエラーも発生せず、作業漏れ等の心配はありません。

テスト自動化のデメリット（考慮点）

  • テスト自動化開発のためのコスト・期間
    テスト自動化もプログラミングされた1つのソフトウェアとなりますので、開発コストと期間が必要となります。
    コストのみを追い求めるのであれば、Web-UI操作のテスト自動化は、流用可能なテスト自動化フレームワークがない場合は実施しないほうがよいと考えます。
  • 自動化のメンテナンスコスト
    UIが変わると自動化プログラムのメンテナンスも必要となります。
    無計画にテスト自動化を行うと、ほぼすべての自動化プログラムを書き換えることになる可能性があります。
    一般的なソフトウェア同様、テスト自動化プログラムの設計を検討することにより、影響を局所化することが可能です。
  • 使用方法の習得コスト
    テスト自動化プログラム開発者が使用し続けるのであれば不要になりますが、他の人の場合は習得コストが発生します。
  • 全てのテストを自動化するのではなく、テスト自動化のポイントを絞る
    例えばとあるWebシステムを構築・運用した際に、周辺ソフトウェアがバージョンアップした場合を例にあげると
    - システムとして正常に動作するのかの回帰テスト（既存機能のリグレッションテスト）
    - システム運用中に異常が発生していないか検知するための正常性確認テスト
    といったようなテストを実施したいケースがあります。
    どういったテストがいつ必要なのかは、対象とする製品やシステムにより変わります。
    都度適用する業務内で自動化するテストのポイントを絞り込んでWeb-UIのテスト自動化を取り組むのが良いと考えます。逆に1回だけテストして終わり、のような場合はコストとの兼ね合い上Web-UIのテスト自動化を考える必要はないとも言えます。
  • テスト自動化は魔法の言葉ではない
    テスト自動化 = 品質向上と考えられがちですが、あくまで手動でやっていたテストを自動化するのであって、テスト自動化そのものは品質向上には繋がりません。
    周りに「自動化すれば品質が向上する！担保できる！」と考えている方がいらっしゃいましたら説得が必要となります。
    また、手動でやっていたテストそのものに意味がなければ自動化しても意味がないものになります。テストケースが誤っている、テストドキュメントが無いといった場合は、まずはあるべきテストを整理することがテスト自動化のスタートラインになります。

テスト自動化ツール

今回Web-UIテスト自動化を実現するため、フレームワークとしてWatirとRspecをメインとして使用し、CloudStackで構築されたシステムのテスト自動化を実現しています。（以降その自動化製品をYubariと記載します）
Yubariは大きく以下の技術要素で構成されています。

Rspec

RspecはRubyで書かれた、テストコードを記述・実行するためのフレームワークです。テストを実行するための機能と基本的なテスト関連の機能が提供されています。
以下は、RSpecを用いたコードサンプルです。

# in spec/calculator_spec.rb
RSpec.describe Calculator do
describe '#add' do
it 'returns the sum of its arguments' do
expect(Calculator.new.add(1, 2)).to eq(3)
end
end
end

振る舞いと確認内容を記述します。
RSpecの詳細は、http://rspec.info/をご覧ください。

Watir

Webブラウザの操作をテストするために、watir-webdriver(watirの発音は水のウォーター)を使用しています。
Watir-webdriverは、様々な機能をAPIとして提供していますが、内部では良く知られているSeleniumを用いて動作しています。
特定のWebページへの移動、リンククリック、フォームへの値入力、ボタン操作などWebブラウザで行う操作をプログラムとして記述することができます。
Watirの詳細は、http://watir.comをご覧ください。

RSpec、Watirを組み合わせることにより、CloudStackUIの操作を自動化し、一例ですが以下のテストを自動実行しています。
- インスタンス作成、ネットワーク追加、ファイアーウォール設定など

また、Rye & StackerBeeを組み合わせることにより、UI操作以外の自動化を実現しています。

Rye

RyeはSSH経由でシェルコマンドを実行するためのRubyライブラリです。
CloudStackUI操作の自動実行後に、データベースに期待されるレコードが入っているか、ログの出力内容が正しいか（エラーが出力されていないか）など、UI操作後に期待される結果を確認することが可能です。
詳細は、https://github.com/delano/rye/ をご覧ください。

StackerBee

StackerBeeは、非公式のCloudStackクライアントツールです。YubariでのテストにおいてCloudStackAPIを実行するために使用しています。
例えば
- インスタンス作成後にインスタンスの一覧を取得するCloudStackAPIを実行し、インスタンスの情報が正しく設定されているか
- テスト実行後のリソースクリーンアップ
等に使用しています。
詳細は、https://github.com/promptworks/stacker_bee をご覧ください。

上記がYubariの主な技術要素となりますが、次回以降Yubariの開発を通したノウハウを記載していきます。
第2回は、テスト自動化の設計について記載予定です。

新規CTA