LoginSignup
23
21

More than 5 years have passed since last update.

プロジェクト開始時点で検討しておきたい画面テスト手法

Last updated at Posted at 2015-10-18

最近のテスト自動化環境について調査。(画面テスト編)

■単体テスト

単体テストを導入する意味:
①変更を加えた際に、テストコードがあると比較的安全に編集ができる。
②品質を常に高めていくようにテストコードを記載していくと最後に品質を担保するより作りこめる。

xUnitのようにテストケースを記述できるJavaScriptテストフレームワークを紹介する。

Jasmine (Framework / Assertion / Spy and Mock)

http://jasmine.github.io/
http://qiita.com/opengl-8080/items/cf3acafda9756f4b04c9
JavaScriptで簡潔に単体テストを記述する事ができる。
特徴:Spy, Mockも作れる。
Test Runnerである Karma も一緒に使いたい。
http://qiita.com/hosomichi/items/311e3eac4f55183b62c2

Mocha(Framework)

必要になったらライブラリを追加して使っていく汎用的なフレームワーク。
Assertionを入れる際にはchai.jsを入れる
モックを作る際にはsinon.jsを入れる
TDD(be)・BDD(should be)の両方が利用できる。

QUnit, JsUnit

-> Framework + Assertion
最近見かけないけど、歴史があるフレームワーク。

■結合テスト

結合テストフェーズにおいては、各種ブラウザでも挙動が正しいか確認を行うために、ブラウザを実際に操作するツールを利用するのが望ましい。

Selenium WebDriver

http://totech.hateblo.jp/entry/2014/03/05/181454
「ブラウザを起動して~テキストを入力して~ボタンを押す」といったブラウザの動作をスクリプトで制御できる。
実行するとブラウザが起動して、スクリプト通りにブラウザが動くのを見ることが出来る。
1つスクリプトを作ると複数のブラウザで テスト出来る(IE / FF / Chrome / Opera / Safari / Chrome in Android)
スクリプトはJava / Python / Ruby / C#で記述する。 
スクリプトを書くのが辛い時には、Selenium IDEを使いキャプチャを取ってコードを自動生成する。(細かいコードの修正は必要)

capybara

http://qiita.com/jnchito/items/607f956263c38a5fec24
Selenium(Java)のRubyラッパー。最近ドキュメントが揃ってきた。
gemコマンドだけで準備が出来るため環境構築が簡単。

PhantomJS

コンソールのみでwebkitブラウザを操作する。
画面は出てこないがキャプチャを取ることができる。
実行環境を選ばずにスクリプトで動作を制御できる、という点が大きな利点。
なので、WindowsやMacのみならず、CentOSやUbuntuなどのLinux系のOSでも動作できる。各種ブラウザのインストールも不要。
その特性上、ブラウザ間の挙動の違いを検知することが出来ない。例えば、IEの場合のみ動作しないJavaScriptとかは分からない。

■CI

自動テストの実行環境としてCIツールを紹介する。
CIツールを使って、①テスト+ビルド+デプロイの自動化をしてタスクを減らす②メトリクス分析を使ってコードの品質状態を常に把握する
上記2点だけでもやっておくとプロジェクトのTCOを削減できると感じている。CIを入れることを是非勧めたい。

Jenkins

https://jenkins-ci.org/
我々のチームで用意しているJenkinsを利用して、次のメトリクス情報を取得することが出来る。
・Checkstyle warnings
・FindBugs warnings
・静的解析
・Coberturaカバレッジ・レポート
自動ビルド(Jenkinsの活用)
既に活用準備が出来ているため環境構築コストが低く、また新たに準備するものもビルドスクリプト程度で済む。

・メトリクス分析ツールであるSonar が SonarQubeに変わっていた。

ステップカウント・重複度(コピペコード発見)・複雑度の解析が出来る。問題がある所はドリルダウンして確認していく。
http://www.slideshare.net/masakkuma/sonar-qube

CircleCI

https://circleci.com/
CIツールの運用管理をアウトソースしたいときに利用したい一方、リポジトリが社外にあるためソースコード管理要件が厳しいときには使えない。
circle.ymlをプロジェクト内に入れておくと、ビルド制御ができる。

これにより属人的なJenkins職人が管理するより各領域の専門家がコミットしていくフローに切り替えやすい。

Travis CI

https://travis-ci.org/
Circle CI と近い。

■負荷テストツール

クライアントPCからサーバーに対して複数のリクエストを投げる事ができる。多量のリクエストを投げることによって、サーバーに負荷をかけるツールとして負荷テストツールを利用する。

gatling

http://gatling.io/#/
Scalaによる内部DSLを記述する。JMeter同様シナリオの自動生成もできる。
Analyze画面がカッコイイ。Jenkinsとの相性が良い。
欠点は起動が遅い所。

Oracle Application Testing Suite

http://www.oracle.com/technetwork/jp/oem/app-test/etest-101039-ja.html
良品ではあるが、何をしても動作が遅いのが難点。

JMeter

一番使われているツールと思われる。
http://jmeter.apache.org/
JMeterを使うなら、Googleのプラグインを入れるといろいろ捗る。http://jmeter-plugins.org/

■まとめ

使えると思っているのは、①Jasmine + Karma + Selenium + Jenkins
最近Web系会社でよく見かける組み合わせは、mocha(+ chai.js + sinon.js) + phantomJS + Circle CI( or travis-ci)

■参考にしたページ

1.JavaScriptのテスト環境の参考URLメモ(2015-03時点)
http://hblog.glamenv-septzen.info/entry/2015/03/30/005813
2.mochaとphantomJSとtravis-ciでフロントエンドJavaScriptのテスト
http://webtech-walker.com/archive/2012/10/mocha_phantomjs_travisci.html
3.Jenkins ユーザ・カンファレンス 2015 東京に行ってきた
http://totech.hateblo.jp/entry/2015/01/11/215628
4.TDD & CI for JavaScript [Karma][Mocha][Travis CI]
http://inet-lab.naist.jp/blog/wp/wp-content/uploads/2014/09/test-tools.png

23
21
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
23
21