Agileツール適合化分科会（テスト自動化ツール）

1Copyright (C) Masanori Kataoka. All Rights Reserved.
テスト自動化ツールの概要と動向
２０１５年２月４日
片岡雅憲
2015/2/5
1
Agileツール適合化分科会（第４回）資料

＜内容＞
１．テスト自動化の必要性
２．テスト自動化の推進戦略
３．単体・コンポーネントテストと支援ツール
４．コード分析・検証ツール
５．機能テストとその支援ツール
６．GUIテストとその支援ツール
７．GUIテスト自動化ツールSelenium
８．BDDとCucumber
９．システムテスト支援ツール
１０．まとめ
＜参考文献＞

1.1 テスト自動化を必要とする背景
１）ITの利用範囲の拡大、技術の進歩と共にテスト工数負荷が急拡大
しつつある。ソフトウェア開発規模そのものが拡大している。また、
ソフトウェアの既存部品、コンポーネント、サービスを活用することが
進んでいるが、これら既存ソフトウェア部分についてもテストが必要と
される。急速なテスト作業量の増大に対応するために、テストの
自動化が強く要請されている。
２）ビジネスや技術革新の加速化に伴いテスト期間の短期化が強く要
求されており、テスト自動化が必須になっている。
３）テスト作業は、多くの単調な仕事と、少量だが高度の緻密性を要求
される仕事の組み合わせで構成されている。このため、作業者のモ
ティベーションが下がりがちである。単純作業の部分を自動化して、
作業全体の質の向上を図る必要がある。
４）ITシステムの社会的重要性が増してきて、コンプライアンス上から
テスト証跡が求められることが出てきている。

1.2 アジャイル開発とテストの自動化
１）アジャイル開発では、短期間での繰り返し循環型の開発が行われ
る。全ての作業は、これを可能とするべく、限られた時間枠（タイム
ボックス）内で行われなくてはならず、開発作業の高度の自動化が
必要とされる。
２）この繰り返し循環プロセスの中で、作業が正しく行われたかを検
証するテスト作業が大きな比率を占める。したがって、テストの自動
化が極めて重要である。
1.3 テスト自動化をCI/CDプロセスに組み込む
１）アジャイル開発では、 CI(Continuous Integration)/CD(Continuous
Delivery)技術により、ソフトウェアを短期間で継続的に顧客に提供
する。
２）テスト自動化技術はこのCI,CDプロセスの中に有機的に組み込ま
れることにより効果を発揮する。

2.1 テスト自動化の推進戦略
テスト自動化の必要性は理解しても、実際にそれを推進するとなる
と多様な困難に直面することになる。ただやみくもに自動化を進める
のではなくテスト作業全体を考慮に入れた自動化戦略が大切である。
テスト自動化戦略は、次の基本要素を考慮に入れて立案されるべ
きである。
① テスト対象となるソフトウェア構造
② テスト作業のライフサイクル（テスト仕様の作成、テストデータの
作成、テスト実行順序の決定、テスト環境の作成、テストの実行、
テスト結果の検証、不良の分析・管理、テスト進捗状況の管理）
③ 標準化（被テストソフトウェアの標準化、テスト資産の標準化）
④ 既存テスト資産の蓄積・再利用

2.2 テスト構造ピラミッド
テスト作業では、小さな単位のテストから始めて、これを順次に大き
な単位へと組み上げてテストしていく。テスト自動化技術もこれに対応
していく必要があり、図2.1 に示すようなテスト構造ピラミッドが形成さ
れる。
１）単体・コンポーネントテストでは、システムの内部構造に基づく最
小単位でのテストを行う。また、これと共に、コードの分析・検証を行
う（これを静的テストと呼ぶことがある）。これらにより、最小単位での
正しさを検証して、不良を早期に検出出来る。このテストは、「内部仕
様に基づくテスト」ということが出来る。
２）機能テストでは、システムを外部から使う観点で
のテストが行われる。また、GUIテストではGUIの妥当性を含めた機
能テストを行う。したがって、これらのテストは、システムの
「外部仕様に基づくテスト」と位置付けることが出来る。

図2.1 テスト構造ピラミッド
単体・コンポーネントテスト
およびコード分析・検証
機能テスト
(API Layer)
GUI
テスト
システム
テスト
リリース
テスト
2.2 テスト構造ピラミッド（続き）
３）システムテストでは、システム
全体の特性としての、ユーザビリ
ティ、セキュリティ、性能等につい
てのテストを行う。
４）リリーステストでは、顧客が実
際に使用する実システム環境下、
または、それと全く同等の環境
下でテストが行われる。すなわち、
システム環境自体とソフトウェアと
の整合性もテストの対象となる。
５）上記のうち、１）２）は、１００％
の自動化をしていく。３）４）につい
ては、一部に手作業が入るが、
極力自動化することが望ましい。

2.3 テスト作業のライフサイクル
一言でテストと言ってもその内容は次のような複雑なライフサイクル
で構成されている。テスト自動化を推進するに当たってはテスト作業の
ライフサイクルのどの部分を自動化するのかを明確にしなければなら
ない。
１）テスト仕様（テストケース）の作成
設計仕様に基づきテスト仕様を作成し、文書化する。TDDでは
テスト仕様＝設計仕様との考え方になっている。
２）テストデータの作成
十分なテストカバレッジを実現するテストデータを作成する。
３）テスト実行順序の決定
テストの相互依存関係を考慮に入れてテスト実行順序を決定する。
４）テスト環境の作成
テスト実行に必要とされる環境を作成する。初期設定、未作成モ
ジュールのスタッブの作成、関連サービスの仮想化などを準備する。

2.3 テスト作業のライフサイクル（続き）
５）テストの実行
テストを実行する。３）テスト実行順序の決定に基づいて、繰り返し
実行、連続実行、条件付き実行などが指定できる必要がある。
６）テスト結果の検証
期待するテスト結果が得られているかどうかを自動検証する。
７）不良の分析・管理
期待するテスト結果が得られなかった場合に不良の原因を分析し、
不良を修正する。また、その経緯を管理する。
８）テスト進捗状況の管理
テストの実行状況、合格状況、不良の検出・修正状況等、テストの
の進捗状況を管理する。

2.4 標準化と自動化
どのような作業であっても、自動化の前提として標準化が必須である。
すなわち、テスト対象とするソフトウェアをあるがままにテストし、それを
自動化する、との考え方ではなく、テスト自動化に適したソフトウェア構
造とすることが大切である。すなわち、テスト自動化を意識したソフト
ウェアの設計を作り込むことである。具体的には、次のような点に配慮
することが望ましい。
１）命名規則（機能、モジュール、テストケースの間の対応付けが自動
化できるような命名規則）
２）単位機能の独立性の確保
３）モジュール化の徹底
４）機能間、モジュール間の相互関係の把握（改造時の影響範囲、
再テスト範囲の把握の自動化を可能とする）
また、上記と対応したテスト資産についても標準化を徹底していく必
要がある。

2.5 テスト資産の再利用とテスト自動化
テスト資産を標準化して、蓄積・再利用することにより、自動化の効
果を上げ易くなる。例えば、次の観点からのテスト資産の再利用に基
づく自動化が大切である。
１）既存テストとテスト結果の再利用によるリグレッションテスト
２）入力データの一部を変更しながら、何度も繰り返し実行する必要が
あるテスト
３）入力項目、入力データ量が多いデータ入力系のテスト
（入力項目、データのテーブル化とテストプロセスのProfiles化）
４）複数環境（OS、ブラウザ、スマートフォン）でのテスト
５）仕様変更が少ない機能のテストでの既存テスト資産の再利用
６）他のサービス(SaaS)との連携機能のテスト
７）大きなテストケースをそのまま自動化することは望ましくない。小さ
なテストケースに分解してモジュール化し、それを結合する形で大き
なテストケースを組み立てるべきである。

単体・コンポーネントテストは、ソフトウェアの内部構造上の最小単位
である単体・コンポーネントに対するテストである。したがって、内部構
造、内部仕様面からのテストと言える。
プログラムコードを新規に開発した場合、あるいは改造を加えた場合
に、その正しさを検証するための基本的なテストである。新規開発ある
いは改造したコードと、それに対応するモジュール単体、あるいはコン
ポーネントとは直接的な関連付けが出来る。したがって、このテストに
より、不良が早期に検出できることが特徴である。
単体・コンポーネントは、それ単独では動作しない。したがって、当テ
ストを実行するためには、JUnit等のテスティングフレームワークや関
連モジュールをシミュレートするMock等の仕組みが必要になる。

3.1 TDD
１） TDDと単体テスト
TDD(Test Driven Development：テスト駆動開発）は、テストを
主体としたソフトウェア開発法である。テストを先に記述し、それに
合格する様にコードを開発する。
TDDのキイワード：Red/Green/Refactor
―最初はテストだけなの不合格（赤）、
コードを書いてテストに合格（緑）、
そしてそれを磨いてきれいにする
（リファクタリング）。
―Test a little/Code a little
/ Refactor a little
(少しづつ着実に進む)
＝＞テストを繰り返し実施する必要があ
り、テストの自動化が、必須である
テスト
コンパイル
動作
リファクタリング

3.1 TDDと単体テスト（続き）
２） TDDは、単体テスト支援フレームワーク xUnit と共に発展してき
て、今や主要な単体テスト技術となっている。xUnitはTDD作業の
自動化のためのツールであり、フレームワークであると言うことが
出来る。xUnitは、XPの開発者として有名なKent Beckが開発した
ものであり、現在はそのうちでもJUnit4.0が最も多く使われている。
３） xUnit の”x”の部分にはテスト対象プログラムの記述言語により
多様な文字が埋め込まれるが、JUnitがその代表とみなされている。
４） xUnitは、次の部分から構成される。
―テストコンテキスト：テストを実行、成功させるための前提条件の
集合、テストフィクスチャとも呼ばれる。
―テストスィート：同じテストコンテキストを共有するテストの集合
―テストの実行環境：テストのための環境を準備し、テストを実行し、
実行後の環境を実行前のクリーンな環境に戻す。
―アサーション（表明、検証）環境：テストの成否を確認する。

3.2 JUnit による効果
JUnit は、単体テスト用のFW(FrameWork)として位置付けられ、次
のような効果をもたらす。
１）単体テスト作業を標準化する。
２）その結果として、作業環境、作業手順、関連ツールを作業者間で
共有可能とする。また、保守性を向上させる。
３）ソースコードとテストコードを分離する。
４）回帰（regression、デグレード防止）テストを自動化する。
５）他のツールとの連携を容易にする。例えば、Eclipse配下のツール
として次のような連携を可能とする。
－機能テスト支援ツール配下の一機能として起動される
－Ant, Maven 等のビルドツールから自動起動される
（デグレード防止テストの自動起動）

3.3 JUnit と共に用いられる他の単体テスト支援ツール
JUnitは、単独ではなく次のようなツールと連携しながら実行される。
１）モックオブジェクトの作成：
EasyMock, jMock, djMock(Virtual Mock Object)
（注）djMockは、テストカバレジを測定する機能も持っている
２）データベースアクセスを伴う単体テスト支援：
DbUnit, S2Unit
３）サーブレット、EJB, JSP 等の単体テスト支援：
Cactus, StrutsTestCase
４） HTTP通信をエミュレート：
HttpUnit
５）テスト実行時の作業を支援：
Automated Continuous Testing（詳細は3.4で後述）
６） GUIのテストを支援：
Selenium（詳細は7.で後述）、Jameleon

3.4 Automated Continuous Testingによるテスト実行の効率向上
Automated Continuous Testingは、JUnitによるテスト実行時の
作業を支援するための次のような機能を提供している。
１）Automated Continuous Testingではテストコードを保存した時点
（Just In Time）でテスト実行結果を表示することが可能である。テス
トコードを作成しながらタイムリーにテストを実行し、テスト失敗の原
因をすぐに修正したい場合に有効な機能である。
２）JUnitでは、常に同じ順序でテストが実行される。Automated
Continuous Testingを使用することで、テストの実行順序をカスタマ
イズしたり、必要なテストのみを選択し、実行させることが出来る。
テストの実行順序の調整やテストのフィルタリングは、Automated
Continuous Testingが提供するフィルターを用いて行われる。
３）Automated Continuous TestingではJUnitの実行結果リストから必
要な情報のみを選択して表示させることが可能である。

3.5 TDDの課題
「TDDの皮肉は、それがテスト技法で無いことである」と言われる。
TDDは、テスト技法と誤解されることがあるが、TDDは、開発技法であ
り、テスト技法ではない。これに対して次のような批判がある。
１）本来「テスト」とは、開発作業全体の一部の作業を示すものであり、
それが開発の主体となることに抵抗がある。TDDでは、
①テスト ②コーディング ③リファクタリング
の順序で行われ、設計が③リファクタリングで代替されて、一番後
になっている。
２） TDDの考え方は、単体テスト作業の改善と共に生まれてきており、
テストがコードの内部構造に強く依存することになる。このために、
内部構造を大きく変更すれば、テスト自身も大きく作り直さなくては
ならない。
これらの批判に対してBDD（詳細は後述）等での対応が図られている。

4.1 コード分析・検証とリファクタリング
単体・コンポーネントテストにより正しく動作することが確認されたモ
ジュールやコンポーネントに対して、夜間や週末にコード分析・評価
ツールを使って、その内部構造の妥当性を評価することが大切である。
このコード分析・評価をプログラムを動作させずに評価することから「静
的テスト」と呼ぶこともある。
そして、コード分析・評価結果に基づきリファクタリングを行う。
リファクタリング（Refactoring）とは、
「外部から見たプログラムの振る舞いを変えずに、後からの理解や
修正を容易にするべく、プログラムの内部構造を改善すること」
である。優れた内部構造を初めから作り込むことが出来れば、それが
望ましい。しかし、作ってみて、実物を見てから問題点に気がつくことは
少なくない。したがって、リファクタリングとは「フィードバック型設計、進
化型設計である」と言うことも出来る。

4.2 コード分析・検証ツールの分類と代表的ツール
コード分析・評価ツールは、その役割により次のように分類できる。ま
た、各分類についての代表的なツール例を示す。
１）標準コード規約チェッカー
コードが標準的なコード規約に従っているかをチェックする。
―CheckStyle (Java用、ルール数120)
―PMD (Java用、ルール数240)
―FindBugs(Java用、ルール数300)
―Jtest(Java用、ルール数1,000）
―DevPartner(.NET用、ルール数340）
（注１：上記のうちCheckStyle, PMD, FindBugsはOSS、
Jtest（Parasoft社製）, DevPartner(Compuware社製）は
商用ソフトである）
（注２：FindBugsは、ソースコードではなくコンパイル結果を分析する）

２）ソースコードの共通部分の抽出ツール
コードの共通部分を抽出して、共通モジュール化を推奨する。
―PMD-CPD(Copy and Paste Detector)
―Simian(Similarity Analyzer)
３）モジュール間の相互関係分析ツール
モジュール間の相互依存関係を分析する。
―JDepend(Java用)
―NDepend(.NET用)
―CAP(Code Analysis Plugin)
―Understand(テクマトリックス社商用ツール）

４）ソースコードの複雑度評価
ソースコードの複雑度CCN（cyclomatic complexity number）を
数える。 CCN計測ツールとしては次のようなものがある。
—JavaNCSS
―Eclipse Metrics Plugin（Frank Sauer）
―Eclipse Metrics Plugin（Team in a Box）
―CCMetrics
５）テストカバレッジ評価
テストカバレッジ（注）およびテスト未実行コードを表示する。
（注）テスト実行済みのコード比率
―Cobertura
―Eclips djUnit
―Emma

テストピラミッドの第２層として機能テストがある。機能テストは、ス
トーリーテスト、アクセプタンステストとも呼ばれることがある。
機能は、単体・コンポーネントを組み合わせて実現され、ユーザから
見た API(Application Program Interface) を提供する。また、GUIを
実現するための”Behind GUI” を提供する。
単体テストが、モジュール内部の作り方も意識した”White Box Test”
（内部仕様テスト）であるのに対して、機能テストは、モジュール、モ
ジュール群の外部から見た機能をテストする “Black Box Test” （外部
仕様テスト）となっている。単体テストでは、内部構造を意識しているの
で、多様な入出力の組み合わせをテストするには工数的な限界がある。
一方、機能テストでは、入出力の組み合わせの作成を容易にしている
ことから、これが可能になっている。
また、機能テストは、顧客にも内容が理解できる点が強みである。

5.1 APIテスト支援ツール
APIのテストのためには多様な入出力の組み合わせのテストが必要
であり、たとえば、次のようなツールがある。
１） Fit(Framework for Integrated Test)
テストケースを表形式（MS Excel/Word等の形式）で記述し、ユー
ザと開発者との間のコミュニケーションを良くする。Java, C#, C++,
Python に対応している。Fitは、OSSである。現状では日本語版はな
い。Fitは、Wikiの発明者である W. Cunninghamが開発した。
図5.1にFitによるテストの例を示す。
２） FitNesse
Wiki形式で入力と出力の関係をユーザレベルで容易に記述できる。
内部で、Fitを用いている。すなわち、HTML表を含むWikiページが
テストの単位となる。Wikiを自然言語のように使いこなす技術者に
とって、FitNesseは極めて使い易いツールである。
図5.2に、FitNesseを用いたテストの構成を示す。

＜テスト内容＞このビール会社は様々なタイプの飲料を販売している。大きく分けると、季節商
品（seasonal）と通年商品（year-round）、という2つのカテゴリーに分類することができる。すべ
ての飲料はケース単位で販売され、複数ケース買いに対する値引きサービスがある。
図5.1 Fit を用いたテスト

5.1 APIテスト支援ツール
３） DSL(Domain Specific Language:応用領域固有言語）
前記のWiki言語よりも更に記述し易さを狙っている。DSLは、各々
のアプリケーションドメインに適した記述方式で入力と出力の関係
を記述して、多様な組み合わせ条件のテストを実施する。
例えば、ThoughtWorks社のテスト支援ツール twist は動的スクリ
プト言語Groovyにより、DSL相当の記述を可能としている。
（注：Groovyは、Java環境下で動作するスクリプト言語であり、
JavaにRubyの長所を取り入れている）
後述するBDD支援ツールCucumberもこのようなDSLの一つであ
る。また、Rubyは様々なDSLを作成（記述）するためのメタ言語と
して活用されていて、それは更に広がっていく動向にある。

5.2 TestNG(Testing, the Next Generation)
JUnitは、テスティングフレームワークの代表的な存在であるが、こ
のTDDの考え方と機能を引き継ぎながら、かつ、その限界を打ち破る
ものとして、TestNG(Testing, the Next Generation)がある。TestNG
は、Java SE5.0から導入されたアノテーション機能を用いる等により、
機能テストに向けた次の特徴を実現している。
１） Java SE5.0のアノテーション機能をサポート
２）テストにおける各種の設定をXMLで記述可能
３）前後処理のタイミングを細かく指定出来る
４）テストをグループ化することが出来る
５）テスト間に依存関係を作れる
６）テストを並列実行出来る、スレーブマシンで分散実行出来る
７） Antからテストを実行出来る
８）これら１）～７）の特徴により、単体テストだけに限らず、機能テス
ト、結合テスト、統合テスト他にも利用できる

5.3 TestNG対JUnit
TestNGは、JUnitに物足りなさを感じたGoogle社のエンジニアが
開発したものである。TestNGは、アノテーション機能を活用して、テスト
の自動化をより深めたこと、テスト間の依存関係やグループ関係を指
定可能にして結合テストを可能にしたことなどで、xUnitよりも高度の自
動化を推進した。
一方、JUnitの方でもこのような動きを見て、JUnit4.0でアノテーション
機能を取り入れるなどの改善を図ってきている。しかし、単体テスト支
援機能の改善に的を絞っている。
このようなことから、しばしば、TestNG対JUnitについての議論が行
われる。この議論に、まだ決着はついていない。現在の状況では、単
体テストでは、JUnitを、結合テストではTestNGを、うまく組み合わせて
使うのが現実的と捉えられている。

5.4 Eclipse TPTP(Test and Performance Tools Platform)
Eclipse TPTP は、Eclipse環境においてテストを単体テスト、機能テ
スト、性能テストについて、総合的に支援するテスト支援環境である。
TPTP配下で他のテスト支援ツールを動かすことも出来る。
5.4.1 TPTPの機能
TPTPは、次の機能から構成されている。
１） TPTP Platform: 共通インフラ機能
２） Testing Tools: テストの編集、実行を支援
３） Monitoring Tools: モニタリングやログ解析等の性能評価、
分析機能
４） Tracing and Profiling Tools: 実行状況のトレースやリソース
（CPU、メモリ等）の使用状況の分析

5.4 Eclipse TPTP(Test and Performance Tools Platform)
5.4.2 TPTPのTesting Tools
TPTPの機能の一つであるTesting Toolsでは、JUnitによるテスト作
業に関連する次に様な支援機能を提供している。
１）テストエディタと呼ばれるGUIエディタを通してテストクラスおよびテ
ストスイートの編集・管理を可能としている。テストを実行するために
必要となるリソースや実行環境、配備などについて定義したテスト資
材を、テストエディタを使用することで簡単に作成することが出来る。
２）TPTPはテスト結果をテストログファイルとして作成する。このテスト
ログファイルを基に、テスト結果の統計を作成し、HTMLレポートとし
て出力する。
３）ローカルホスト上でのテストだけでなく、エージェントコントローラが
起動しているリモートホストでのテスト実行を簡単に行うことが出来る。
４）テストデータを管理するDataPoolという機能を提供する。DataPool
機能では、専用のGUIエディタによりテストデータを編集出来る。

６． GUIテストとその支援ツール
6.1 GUIテストの自動化の重要性
GUIテストの自動化は、極めて重要なものになって来ている。
１） GUIベースのAP の急増
GUIベースのAP(Application Program)は、これまでも急増してき
たが、今後とも更なる増加が見込まれる。
a) 情報の共有、統合化を目的としたネットベースのAPの増加、
そして、そのGUIとしてのWebの活用。
b) スマートフォンの出現が、上記を加速化。
c) GUIの利用は、Androidなどを活用した組み込み機器にも拡大。
２） GUIテストの自動化が必須
a) GUIのテストの全てを手作業で行うには膨大な工数がかかると
共に、確認漏れ等の信頼性の問題が生じる。
b) ビジネスが加速化される中で、WebApに対する短期間、高頻度
の改変要求が生じる。改変に伴うデグレードを防止するためのテス
トの自動化が必須となって来ている。

6.2 主なGUIテスト支援ツール
１） Selenium: Seleniumは、OSSベースのWebApテスト自動化支援
システムの代表的な存在である。Webブラウザを実行させるための
スクリプトを記述し、それを実行させることが出来る。このことにより、
手間をかけて手動で実行していたWebApのテストを自動化するこ
とが出来る。Seleniumについては、その詳細を７．で説明する。
２) Watij(Web Application Testing in Java): Web, Javaアプリケー
ション向けの総合テスト支援ツール。Ruby向けのテスト支援ツール
Watirのシンプルさを引き継ぎながら、Java向けの機能を強化して
いる。（Seleniumよりも使い易いという人もいる。しかしながら、現
状においては、Seleniumと比べて日本での普及は遅れている。）

6.2 主なGUIテスト支援ツール（続き）
３） Jameleon：Javaアプリケーション向けの総合テスト支援ツールで
ある。Jameleon のテスト記述スクリプトは,Jelly スクリプト(XML
ベースのスクリプト）となっている。Jameleon は、OSSである。
Jameleonは様々なテストを支援していて、次のプラグインがある。
―JUnit：ユニットテスト用のフレームワークを提供
―HttpUnit：HTTPレベルでのテスト用フレームワークを提供
―jWebUnit：WebApのテスト用フレームワークを提供
―Jiffie：IEを利用したテスト用フレームワークを提供
―Jagacy：MF用の3270端末エミュレータ対応プラグイン
Jameleonのテストケースは複数のセッションに、セッションは複数
のファンクションポイントに分解され、これには次の３種類がある。
―アクションポイント：フォーム、ボタンが正しく動作することを検証
―バリデーションポイント：出力が正しいことを検証
―ナビゲーションポイント：リンクによる遷移が正しいことを検証

6.2 主なGUIテスト支援ツール（続き）
４） QTP(Quick Test Professional): Mercury社の製品。現在は、同
社をHP社が買収したためHP社の製品となっている。Webアプリ
ケーションの機能テストを支援する。
テストオペレーションを自動記録して、そのオペレーションの中で
確認すべきポイントと内容を指定していく。それが、VBScriptに展開
され、再テストで利用できる。そして、このテストスクリプトは、編集
することにより他のテストスクリプトへと再利用できる。
QTPは、総合テスト支援ツールとして、他のツールと比べて完成
度が高く、次のような機能も備えている。
―テストスクリプトの構造化（条件分岐、他のテストスクリプトの呼
び出し等）
―テスト実行のスケジューリング
―リグレッションテストの自動化
―Mercury Business Process Testingとの連携によるERPの
業務アプリケーションテストの自動化

6.2 主なＧＵＩテスト支援ツール（続き）
５）Worklight: Worklight は、IBM社が提供するモバイルソフトウェア
開発環境である。２０１２年にイスラエルのWorklight 社を買収し、
その技術を製品化したもので、買収後も積極的な機能拡張を推進し
IBM社ソフトウェアの重要なセールスポイントとしている。
Worklightは、Eclipse環境の上に構築されており、総合的なソフト
ウェア開発環境を提供している。再テストの自動化機能も充実してお
り、各種のスマートフォン、タブレット端末のテストが自動実行出来る
ようになっている。

7.1 Seleniumの役割
Seleniumは、WebApのテスト自動化支援システムである。Webブラ
ウザを実行させるための、スクリプトを記述し、それを実行させることが
出来る。このことにより、手間をかけて手動で実行していたWebApの
テストを自動化することが出来る。
Seleniumは、JavaScript, HTML, iFrame(inline Frame)を用いて
実現されている。このために、極めて広範囲のOS, Windowシステム
に適用可能になっている。
Selenium Coreは、ThoughtWorks 社の社内ツールとして開発され、
利用されていたが、これが２００４年にオープンソース化されて誰でもが
使えるようになった。また、オープンコミュニティーの力により、
Seleniumファミリーとして機能的にも大きな追加・改善が加えられ、今
日の隆盛を迎えている。

7.2 Seleniumの発展経緯
１）２００４年、ThoughtWorksのJason Hugginsが
JavaScriptTestRunnerの名でSeleniumのベースを開発。
２）これがThoughtWorks社内の同僚の間で評判になり、社内で拡張さ
れるとともに、さらにユーザを広げるためにオープンソース化された。
３）Bea(後にOracleが買収）のDan FabulichとNelson Sproulが、
Selenium RCを開発。
４）２００６年、日本のAppirits社の笠谷が、Selenium IDEを開発。
５）２００７年、 Jason Hugginsは、Googleに移り、そこでSelenium RC
を拡張し、Selenium Gridを開発。
６）２０１１年、SeleniumとGoogle社が開発したWebDriverを統合した
Selenium2が提供開始された。WebDriverは、Seleniumと同様な機
能を持ちながら、より使い易いAPIを持っている。この統合化により
Seleniumの普及が加速化された。Selenium2は、ブラウザとして、
Firefox, Chrome, IE, iPhone, Android, Operaをサポートしている。

7.3 Seleniumの構成
Seleniumは、次の４つのコンポーネントから構成されている。
１） Selenium Core
Seleniumの中核機能コンポーネントである。
２） Selenium Remote Control
リモートサーバ対応機能および言語対応機能を提供している。当コ
ンポーネントは、Selenium Grid（並列サーバ機能）へも発展した。
Selenium GridによりGUIテストを並列化、高速化できる。
３） Selenium IDE
Seleniumを活用するためのIDE(Integrated Development
Environment:開発支援環境）。
具体的には、ブラウザの操作を自動的に記録して、それに基づくテ
ストコードの自動生成する。したがって、再テストが自動化される。
４） Selenium on Rails:
Ruby on Railsで、Seleniumを使うためのコンポーネントである。

7.4 Selenium Core
１） Selenium Coreの表示画面
Selenium CoreのデモソフトTest Runnerで試用すると,画面は
図7.1/7.2 のように表示される。
a) 上方向左画面：テストケースの一覧が表示される。
b) 上方向中心画面：左画面で選択したテストケースの内容が表示さ
れる。テストケースを一件づつ選択することが可能なだけでなく、
左画面の全てのケースを自動実行することも可能である。
c) 上方向右画面：テスト制御画面（図7.2参照）。テスト結果が表示
される。この制御画面でテストの実行速度を調整することも出来る。
d) 下方向画面：テスト対象プログラムの実行画面（この事例では、
Googleの画面）が表示される。

図7.1 Selenium Core の表示画面

図7.2 テスト制御画面(Control Panel)の詳細

7.4 Selenium Core（続き）
２） Seleniumコマンドの記述形式
Seleniumコマンドの記述形式は次のようになっている。
コマンド名第一引数（ターゲット）第２引数（バリュー）
第一引数は対象（ターゲット）となるHTML要素を示し、第２引数は入
力したり、検証する値（バリュー）を示す。
HTMLでテストコードを記述する場合は、上記の記述形式に従って、
一行３カラムのtable形式で、複数のコマンドを複数行のテーブルとして
記述することが出来る。HTMLでの記述は、ユーザにも理解出来て、ソ
フトウェアの内部の実現方式に依存しない。しかし、共通部分の共有
等の高度の利用が出来ない（共通部分の共有のためには、次に述べ
るSelenium RCを用いる必要がある）。

7.5 Selenium RC
Selenium RC(Remote Control)は、
① リモートサーバにアクセスしてテストを行う
② 開発言語でテストを作成し、実行する
の二つの機能を持つ。
Seleniumコマンドによりテストを実行する方法については、既に7.4
で述べた。Selenium RCを用いて、開発言語でテストを作成すれば、
繰り返し使われる機能等は共通メソッドとして作成して、必要時に呼び
出す、と言ったより高度なことが出来る。そして、その開発言語に備
わっているテスト支援機能と組み合わせての活用も出来る。
Selenium RCは、Java, C#, Ruby, PHP, Perl, Python
等、多様な開発言語に対応している。Javaの場合は、単体テスト支援
ツールJUnitと組み合わせて利用することも出来る。

7.6 Selenium IDE
Selenium IDEは、
① ブレイクポイントの設定が可能なデバッグ支援機能
② Web操作の記録機能
③ 上記②によるテストコードの自動生成機能
等を実現している。Selenium IDEの開発者は、日本のAppirits社の笠
谷氏であり、日本語にも対応している。
上記の③の機能では、HTML形式のSeleniumコマンドの他に、各開
発言語対応のテストコードを生成する。したがって、最初に手作業でテ
ストした後は、２回目からは、生成したコードを使って自動リグレッショ
ンテストが実行出来る。また、いちいちテストコードを自分で記述する
手間が省ける。
しかしながら、生成されたテストコードが正しいか、また、共通化等の
改善の必要性が無いか、の確認が必要である。

7.7 Selenium2
Google社のSimon Stewart は、Web GUIのテスト自動化支援を目
的としたWebDriverを開発した。２０１１年にリリースされたSelenium2
は、Seleniumの特徴を継承しつつWebDriverの良さを取り込んでいる。
Selenium + WebDriver = Selenium2
Selenium 2 は WebDriver の簡潔なオブジェクト指向の API を継承
し、ブラウザーとのやりとりは、そのブラウザーに最善の方法で行うよう
になっていて、テストプログラムが書きやすくなっている。
また、Selenium2は、Seleniumの機能を包含していて、Seleniumで
作成したテストデータをSelenium2向けに簡単に変換・移行できるよう
にしてある。

8.1 BDDが求められる背景
BDD(Behavior Driven Development)は、顧客が求める動作要求
(Behavior)に基づき、ソフトウェアを開発しよう、とする開発技法である。
このBDDが求められてきた背景として次の二つがあげられる。
① TDDへの批判、改善要求（3.5 TDDの課題を参照）
② 顧客要求を顧客にも理解できる形式で記述し、それに基づき
テストをしたい、との基本的要請への対応
BDDという言葉は、上記①を意識したもので、TDDの利点を取り込
み、欠点を改善しようとの考え方に基づく。
一方、②は、古くから現在に至るまで継続的に追及されてきたテーマ
であり、その実現方式が多様な形態で発展してきた。現代的には、
DSL(Domain Specific Language)と表現されることが多い。
BDDとDSLは、表現形式は異なるが考え方に共通する部分が多い。
BDDのBehavior = DSLのDomain Specification ＋テストシナリオ
と捉えられる。

8.2 TDD 対 BDD
Dan Northは、TDDの考え方を発展させて、BDD (Behavior Driven
Development)を提案した。BDDでは、考えかたを徹底するために用
語体系から変更している。
<TDD> <BDD>
テストクラス振る舞い(Behavior)
テストケース実行可能サンプル(example)
アサート(assert) 期待する振舞(expectation)
すなわち、BDDでは、仕様＝実行可能仕様＝テスト仕様
であり、DSLによる記述を前提としている。
（注）要求仕様＝テスト仕様を実現した先駆者は、テーブル形式テス
トツール Fit, FitNesse であり、BDDはそれを更に一般化したと言える。
逆に、Fit, FitNessを用いればBDDを実行していることになる、と言う人
もいる。

8.3 BDDの歴史(Cucumberが生まれるまで）
BDDの歴史の中で、Cucumberが生まれるまでを辿ってみる。
１） TDD用テストフレームワークxUnitとその後継
xUnitは、TDD用のテストフレームワークであり、そのJava版が
JUnit, Ruby版がRUnitである。そして、RUnitは現在では、
Test::Unitに引き継がれている。
２） JBehave
Dan North は、BDDの研究を進め、２００３年にJUnit を置き換える
ものとして、BDD用のテストフレームワークJBehave を開発した。
JBehaveは、当初は実験的なものであったが、その後、改良が続け
られ現在でも利用されている。また、その後に開発された多くの
BDDツールに影響を与えた。(Dan Northは、当時、ThoughtWorks
社に所属していた。）

8.3 BDDの歴史(Cucumberが生まれるまで）
３） RSpec
RSpecは、Ruby用のTest::Unitを置き換えるものとして、２００５年
に Steven Baker により開発された。RSpecは、BDD向けの単体
テストフレームワークであり、その考え方は、先行する JBehave を
参考としている。RSpecは、現在、Ruby向けに活用されている。
４） RSpec Story Runner
Dan North は、JBehave のRuby版 RBehaveを開発し、更には
RSpecとマージして、RSpec Story Runner とした。
５） Cucumber
２００８年に、Aslak Hellesoyは、RSpec Story Runnerを文法的
に整理して書き直し、Cucumber と名付けた。
当初は、RSpecに統合する予定であったが、独自の地位を占める
ようになった。Cucumberは、単体テストに限らず、機能テストを含
めた広い範囲のテストに使える。

8.4 BDD支援ツールCucumber
Cucumber は、自然言語に近い特定の形式で書かれたシステムの
振る舞いをテストとして実行するBDDに基づくテスティングフレーム
ワークである。Cucumberは、単体テストだけでなく、機能テスト等にも
広く適用される。図8.1に、Cucumberによる記述事例を示す。
１）記述した振る舞いは、ユーザ、企画者、業務担当者等のプログラ
マ以外の人々にも理解が出来る。したがって、関与者間の合意が
取れた内容のテストが出来る。
２）国際化されていて、日本語の記述も可能である。
３） Rubyで記述されたBDD用のDSLである。
４）テストの対象となるソフトウェアは、Ruby記述のものだけでなく、
Java, C++, Python 等、広く適用できる。
５）要求仕様＝テスト仕様を実現した先駆者は、テーブル形式テスト
ツール Fit, FitNesseである。BDDはそれを更に一般化して、自然
言語に近い形式で「要求仕様＝テスト仕様」を記述可能とした。

#language: ja
フィーチャ: ログインしてユーザを識別できる
ユーザとして、
ログイン機能などで自分の情報を識別したい。
なぜなら、メッセージなどを「自分のもの」として区別したいからだ。
シナリオ: ユーザ登録してログインする
前提 "新規ユーザ登録"ページを表示している
もし "ログイン名"に"moro"と入力する
かつ "E メール"に"moronatural@gmail.com"と入力する
かつ "作成"ボタンをクリックする
ならば "こんにちはmoro さん"と表示されていること
シナリオ: 既存のユーザが、ログイン名とE メールアドレスを入力して、ログインする
前提ログイン名が"moro"、E メールアドレスが"moronatural@gmail.com"のユーザがいる
かつ "ログイン"ページを表示している
もし "ログイン名"に"moro"と入力する
かつ "E メール"に"moronatural@gmail.com"と入力する
かつ "ログイン"ボタンをクリックする
ならば "こんにちはmoro さん"と表示されていること
図8.1 Cucumberによる要求仕様＝テスト仕様記述事例＜参考文献＞ 5）から転載

8.5 Cucumberにおける Story の構造
Cucumberにおいては、一つの Story（説明）は、次の要素から
構成される。
－A title: 標題
－A narrative: 説明記述
① feature: 仕様
② benefit: 目的、期待する効果
③ stakeholder: 関与者（ユーザ、企画者、運用者等）
－A acceptance criteria: Storyが成り立つためのシナリオ
① given: どんな条件が成り立つ場合に
② when: 何がおきたら（どんな入力、イベントがあると）
③ then: どのような結果、出力が期待できるか

システムテストでは、システム全体の特性としての性能、セキュリ
ティー、ユーザビリティー等をテストする。
以下に示すように、性能を評価するための支援ツールは、多くのもの
が出回っている。
しかし、セキュリティー評価については評価指標の標準は確立されつ
つあるものの、そのための支援ツールはまだ少ない。
また、ユーザビリティーについては、評価指標自体が確立されてなく
て、ユーザビリティーそのものを評価する支援ツールも確たるものは存
在していない。しかしながら、ユーザビリティーの一つの構成要素であ
るWebアクセス状況の評価ツールは存在する。

9.1 性能評価支援ツール
１） AppLoader：アプリケーションプログラムがどれだけのユーザー
（クライアント）数を処理出来るかをテストする。米国NRG Global社
の製品。
２） AppWatch：アプリケーションプログラムの応答時間を24H,7days
測定し、問題点を検出する。米国NRG Global社の製品。
３） AQTime： Windowsおよび.NETアプリケーションの性能および
メモリー使用状況（メモリーリークを含む）を評価する。
米国SmartBear社の製品。
４） HP Loadrunner： Web2.0アプリケーションを含むプログラムに対
して仮想負荷をかけて、どれだけのユーザー数を処理出来るかを
評価する。HP社の製品。
５） Jmeter： Webアプリケーションの負荷テストを行う。Apacheソフト
ウェア財団が開発を進めているOSSである。

9.1 性能評価支援ツール（続き）
６） Rational Performance Tester： Webアプリケーションの負荷テス
トを行う。IBM社製。
７） SOAtest：SOA(Service Oriented Architecture)に基づくシステム
開発の支援ツールである。WSDLの検証、WebサービスやXMLの
相互運用性、クライアントサーバシステムの単体テスト、機能テスト、
性能テスト等、広い範囲をカバーしている。米国Parasoft社の製品。
日立のCosminexusは、SOAtestと連携している。
８） TestMaker：Webアプリケーションの負荷テスト、性能テストを行う。
Seleniumと連動することが出来る。米国PushToTest社の製品。
９） soapUI： SOAアプリケーションの機能テスト、性能テストを行う。
soapUIオープンコミュニティーで運用されている。
１０） DevPartner: .NET向け開発支援ツール。ソースコード静的分析、
パフォーマンス分析、テストカバレジ分析を行う。Compuware社製。

9.2 セキュリティ評価ツール
１） Rational AppScan：Webアプリケーションのセキュリティー（攻撃に
対する）脆弱性、コンプライアンス（標準への準拠）上の問題点を
ブラックボックステストによりテストする。IBM社製品。
２） MBSA(Microsoft Baseline Security Analyzer)：Microsoft社の
セキュリティ評価ツールである。
３） ratproxy： Webアプリケーションのセキュリティー脆弱性を評価する。
Google社の製品である。
（注）セキュリティ評価は、ネットワーク時代の現代においては、IT社会
の最大関心事の一つであり、次々と新しいツールが発表されて
いる。

9.3 Webアクセス評価ツール
１）ClicTale：一人一人のユーザーのマウスの動き、クリック、キー入力、
ページ遷移を記録し、後から、その一連の操作を動画として確認し、
分析することが出来る。いわば、ミクロ分析ツールである。ClicTale社
の製品である。
２） Google Analytics：Google社の製品であり、以下の項目について
集計結果を確認する事が出来る。いわば、マクロ分析ツールである。
・サイト滞在時間
・ページビュー数（そのページが閲覧された回数）
・直帰率（サイト内の閲覧開始ページだけを見て、他のサイトへ移動
した割合）
・離脱率（そのページを最後に、他のサイトへ移動した割合）
・参照サイト（どのサイトから来たか）
・検索ワード（どのような検索ワードで来たか）

１０．まとめ
１）アジャイル開発を効率良く進めるためには、開発サイクルを高速
に回転する必要があり、テスト自動化技術が極めて重要である。
２）テスト自動化技術は、次の５階層に分類できる
a) 単体・コンポーネントテスト技術およびコード分析・検証技術
b) 機能テスト技術
c) ＧＵＩテスト技術
d) システムテスト技術
e) リリーステスト技術
３）テストの自動化に当たっては、関連するツール間、機能間の緊密
な連携が必要である。この連携により、顧客に短期間で要求された
仕様のシステムを、繰り返し提供するためのライフサイクルを高速
で回転させて行くことが出来る。

１）「現場で使えるソフトウェアテスト Java編」町田欣史、高橋和也、小堀一雄、飯
山教史２００８年翔泳社
２） “The ThoughtWorks Anthology-Essays on Software Technology and
Innovation” R. Singham, M. Fowler, et al. 2005 by O’Reilly
「ThoughtWorksアンソロジー」（訳）オージス総研２００８年オライリー・ジャ
パン
３） “Agile Testing: A Practical Guide for Testers and Agile Teams” L. Crispin,
J. Gregory 2009 by Pearson Education, Inc. 「実践アジャイルテスト：テス
ターとアジャイルチームのための実践ガイド」（訳）榊原彰他翔泳社
４） “The RSpec Book: Behavior-Driven Development with RSpec, Cucumber,
and Friends” David Chelimsky 2010 The Pragmatic Bookshelf
５）「はじめる！ Cucumber」諸橋恭介２０１０．１２．０９版達人出版会
（電子ブック）
６） Cucumberのblogから転載： http://blog.geekdaily.org/2009/06/cucumber-
webrat-who-names-these-things.html
＜以上＞

Agileツール適合化分科会（テスト自動化ツール）

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Agileツール適合化分科会（テスト自動化ツール）

Semelhante a Agileツール適合化分科会（テスト自動化ツール） (20)

Mais de masanori kataoka

Mais de masanori kataoka (15)

Agileツール適合化分科会（テスト自動化ツール）