概要nWebシステム開発時、さまざまな工程でテストツールを適用したそれぞれの実践から得 られた「自動化のポイント」について概説する
u 自 動ソースチェック• Checkstyle（オープンソースのJava スタイルチェッカー）による製造時 の リア
ルタイム・スタイルチェック• Jtest （商用のJavaソースコードチェックツール）による ソースコード品質 の底 上げWebシステム開発におけるテスト自動化の実践
JaSST 2004

u 単 体テストの 自動化• JUnit（オープンソースのJava単 体テストツール）による 単体 テスト強 化
u 回 帰テストの 自動化• WinRunner（商 用のGUI テストツール）による 回帰 テストの効 率 化

2004年1月27日
株式会社NTTデータ 井上 康臣

製造単体テスト

結合テスト

システムテスト

自動ソースチェック
単体テストの自動化
回帰テストの自動化-2-導入事例n

Copyright (c) 2004 NTT DATA Corporation, All rights reserved.

自動ソースチェック概要
u CheckstyleとJtestを導入することでソースチェックを自動化し、ソースコード品質と作業効率の 向上を図った

ソースチェック自動化の実践

n

導入の背景
u 全てのソースコードを目視でレビューする作業が非常に大きな負担 だった
u プログラマのスキルにバラつきがあり、ソースコード品質もバラつきがあった
u ソースコード品質が低い場 合、ソースレビューでは基本事項のチェックに追われ効率 が悪かった
u これらの問題を解消するため、ソースチェックツールを導入した-3-

Copyright (c) 2004 NTT DATA Corporation, All rights reserved.

実施内容n

自動ソースチェック

Checkstyle、Jtest導入によるセルフチェックの自動化

-4-

実施結果
n

自動チェック製造
コーディングCheckstyle

リアルタイム・ソースチェック

単体テスト

セルフチェック ソースレビュー
Jtest

自動ソースチェック-5-

JaSST 2004

単体テスト

セルフチェックを通過したもののみ、ソースレビューに進む

Copyright (c) 2004 NTT DATA Corporation, All rights reserved.

導入効果
ソースレビュー、セルフチェック の大幅 な作業工数削減• 全ソースコードを数分〜数時間でチェック。
ソースコード品質と技術者 スキルの 平 準 化ができた
u 全ソースコードを指摘漏 れなくチェック ⇒見逃しバグ削 減• ある担当者：「
この手のバグは目視チェックで徹底的につぶしたはずなのに。」
u ソースチェックの 効果〜ソースチェック を行った 担 当 者のコメントから〜• 「委託先のソースコード品質の分析ができた 」• 「いかに自分たちが常識を知らずにコード扱っていたか思い知らされた」

バグが多発して修正作業に手間 がかかっていた⇒Checkstyleを導入し、軽微なバグ はコーディング時に発見し修正
u セルフチェックの確実な実施による、正規のソースレビューの効率化※セルフチェックに合格しないと先に進めないルール としたタスク

自動ソースチェック

uu 当初、Jtestによりコーディング後の一括チェックを行っていたが、軽微なフェーズ

Copyright (c) 2004 NTT DATA Corporation, All rights reserved.

un

注意事項
チェックできる内容 は限られている• イディオムやコーディング・マナーのチェックのみなので、業務仕様にあっているかといった確認は目視にて行う。
u ルール の絞込 みが 必須• Jtestの344種類のルール中には自プロジェクトにとって不要なものもあり、重要なルールのみをピックアップする作業が必要。
⇒Java有識者によるピックアップを行い100種類程度に絞り込んだ。
u-6-

Copyright (c) 2004 NTT DATA Corporation, All rights reserved.

1

今後の展開n

自動ソースチェック

ソースチェックは高い効果が得られたため、今後、積極的に推 進していく自動チェックツールの’○’と’×’n

社内向け 標準 チェックルールを策定した• 社内コーディング標準に準拠。
• 各ルールを品質特性（機能性、性能など）に分類し、ランク付けした。
u 導入が 円滑に 進められるよう、導入手順書、運用 ルール を作 成したun○と考 えられる点• フリーであり、公開されている情報も充実してきているため、導入は非常に容易。
Sun提供のコーディング標準への準拠性をチェックするのみであればノンカスタマイズで適用できる。
• Eclipseプラグインでの利用の場合、ソースコード保存時にチェックが走るため問題がすぐに明らかになり修正が迅速に行える。
u ×（制限事項 ）• 発見できるのは、命名規約やスタイル基準の準拠など、比較的軽微な問題のみ。

u-7-

Checkstyleu

得られたノウハウ
コーディングアンチパターン• 多くのプロジェクトで検出されたバグに関して取りまとめ、コーディング標準に盛り込むようなフィードバックを行っている
u 下記の ルール は、いくつかの プロジェクトで違反が 検出されたもの （例）• finallyブロックで入力または出力をクローズする• string.equals (“リテラル”)ではなく、“リテラル”.equals(string)を呼び出す• 文字列リテラルを保持するためのStringオブジェクトを作成するのにnewは使用しない• 直接Exceptionをスローするのを避ける。常にexceptionのサブクラスを使用する• Object.equals ()をオーバーライドするときは常に、Object.hashCode()もオーバーライドする• ¥nまたは¥rを行分離記号としてハードコーディングしない• etc …

自動ソースチェックn

Jtest○と考 えられる点• 344種類という、幅広いルールに関してのチェックが可能。
• チェックルールは新規に追加することも含めて高度なカスタマイズが可能（要スキル）。
u ×（制限事項 ）• 重要なルールの絞込みが必須。
• 使いこなすのにスキルが必要（専任の管理者を配置する必要がある）。
u–

ツールの仕様上、コンパイルできる環境を用意しなければならず 、環境に変更があったりすると、Jtest 側もメンテナンスが必要。メカニズムを把握している管理者が必要。

Copyright (c) 2004 NTT DATA Corporation, All rights reserved.

-8-

導入事例
n

Copyright (c) 2004 NTT DATA Corporation, All rights reserved.

単体テストの自動化

概要
u 品質重視のプロジェクトにJUnitを導入し、ソースコード品質の確 保と単 体

テスト作業効率の向上を図った
u 自動ソースチェックツールも併用し、より高品質なソースコードの開発を目

単体テスト自動化の実践

指した
n

導入の背景
u すべてのテスト項目について実施証跡 の提出が 求められていた
u 単体テストレベルの回帰 テストを確実に実行できるようにすることで、高い品質の確保を狙った-9-

Copyright (c) 2004 NTT DATA Corporation, All rights reserved.

実施内容n

単体テストの自動化

JUnit導入による品質確保と作業効率改善- 10 -

実施結果（1）nCopyright (c) 2004 NTT DATA Corporation, All rights reserved.

単体テストの自動化

導入効果

u JUnitでテストを実施し、Jtest でカバレッジを測定した• デバッガ を使 用しなければ 通せない 一部 のパ スは 、JUnitの テストコードを単にドライバとして利用しデバッガ を併 用した。

u ソースコード品質の確保• 例外処理など、結合 テストでないと発 生させづらい 部 分を除いた箇所 を網 羅する回帰 テストが用 意できた。

u JUnitのテストコードと実施結果の 画面を実施証跡 として利用することで、

u 単体テスト作業工数の 削減• 実施証跡として入出力時 の画 面キャプチャ などを取 得しその ドキュメント類を整備す る労 力に比 べると、JUnit の テストコード
作成 は負 担が 少 ない。

実施証跡を取得する作業の工数削減を図った

フェーズ

製造タスク

コーディング

自動チェックCheckstyle

単体テスト

セルフチェック ソースレビュー
Jtest

JUnit ブラックボックステスト
Jtest カバレッジ測定- 11 -

JaSST 2004

単体テスト

u 導入の容易性（JUnitのメリット）• JUnit はシンプル であり、プログラマにとって導入 についての 抵抗感 や初 期コストは少 なくて済む 。
• 当初は 、ツール運 用が スムーズに行 われるか 心配していたが 、実際導入してみると発 生したのは些 細な問題だけだった 。
• 雑誌や 書籍 、Web などでも多く取り上げられているため、各 自 でノウハウ情 報が入手しやすいのも大 きい。

Copyright (c) 2004 NTT DATA Corporation, All rights reserved.

- 12 -

Copyright (c) 2004 NTT DATA Corporation, All rights reserved.

2

実施結果（2）n

単体テストの自動化

注意事項

今後の展開
n

テストコードを”活かす”取り組み
u 自作ツールにより、テストコードから情報を取り出し様 々な作 業を効率化

u ツールが使えることと、よいテストができることとは 別の話• 問題はいかに テスト項 目を「正しく」抽 出するかという点。
• NULL値 の扱いなどエラー 推測的 なテストケースが抽出 できているか、目 視レ
ビュー で確 認す る。

する仕掛けを用意した• テストケース一覧表 をリバース生 成す るツール。
– テストコードにタグつきの コメントを入れておくと、コメント部分を抽出・整形して表示する。
• テストケース数 カウントツール。
– テストコードの中にあるテストメソッド数をカウントするツール。

u テストコードのボリュームは、テスト対象プログラムより大きくなる（平均1.5〜2倍程度）• プログラム作 成の 他に、テストコード作 成の期 間を見込 んでおく必要 がある。
u プログラム上の煩雑な手続 きを共通化するようなライブラリが必要になる• JUnit、Javaの 有 識 者がライブラリを開発し、適用した。

- 13 -

単体テストの自動化

n得られたノウハウ
u テストコード用ライブラリ• 多くのテストコードから呼 び出される一連の 手続 きなどは、ユーティリティクラスとして定義しておく• 例）– 日付比較（Dateクラスをassertで比較）。
– SQL実行（テーブルのクリア/ロールバックなど）。
– privateメソッドの呼び出し など。

Copyright (c) 2004 NTT DATA Corporation, All rights reserved.

- 14 -

Copyright (c) 2004 NTT DATA Corporation, All rights reserved.

導入事例
n概要
u

回帰テスト自動化の実践

n回帰テストの自動化

頻繁に回 帰 テストを手動 で実 施していたプロジェクトにおいて、GUI テストツール・
WinRunner を導 入して回帰 テストの効 率 化を図った導入の背景
回帰 テストの 実施状況
• リリースした後で頻繁にバージョンアップがあり、その都度手動で回帰テストを実施していた。
• 毎回10名の担当者によりテストを実施していたが、同一の要員を継続して確保するのは難しく、入れ替えが頻繁にあった 。
u ここには次 のような問 題があった• 回帰テストには非常に大きな工数を必要としていた（1回あたり約50人時）。
• 手動によるテストでは操作誤りも多く、作業を遅延させる要因となっていた。
• テストシナリオは煩雑で、テスト実施は担当者にとって大きな負担になっていた。
• テスト担当者入れ替え時の教育コストが高くついていた。
uu- 15 -Copyright (c) 2004 NTT DATA Corporation, All rights reserved.

実施内容（1）n

回帰テストの自動化

スクリプト開発体制と作業フロー

共通モジュール作成者

経験者

スクリプト作成者

経験者

プロトタイプ作成

実施内容（2）回帰テストの自動化

スクリプト方式について各役割に必要なスキル
グループ責任者 ：GUIテストツールの深い知識
作業管理能力共通モジュール作成者 ：GUIテストツールの深い知識
スクリプト作成者 ：GUIテストツールの知識

u シナリオ を追加する場合は、呼び出しのみのルーチンとパラメータファイ

ル（テストデータ）のみを作成すれば良い呼び出しのみのルーチン

スクリプト作成準備

呼び出し

ログオン

進捗管理

シナリオ 2

Call ログオン

パラメータ
Aさん

スクリプト作成・確認

記録＆デバッグで作成するモジュール

レビュー

パラメータ
バイク

Call 新規注文
注文状況
確認

新規注文

呼び出しのみのルーチン

シナリオ 1

共通モジュール
共通モジュール作成

Copyright (c) 2004 NTT DATA Corporation, All rights reserved.

u 再利用を考慮した方式の 採用• 呼び出しをするのみのルーチンから共通 モジュールを呼び出 す方式 。
• データ駆 動 型の スクリプト。

スクリプト方式設計

スケジューリング- 16 -n

開発体制• テストスクリプト開発は、「専任」で行った。
u 作業フロー• 役割分担と作業フローが必要。
uグループ責任者

上記の 問題解消 のため WinRunner を導入し、回 帰テストの効率化 を図った

Call 注文取消し

パラメータ
バイク

Call 注文確認
Call 注文取消し
フィギュア

注文取消し

最終テスト»

パラメータファイル- 17 -

JaSST 2004

BさんCall ログオン

Copyright (c) 2004 NTT DATA Corporation, All rights reserved.

- 18 -

パラメータファイル

Copyright (c) 2004 NTT DATA Corporation, All rights reserved.

3

実施結果（1）n回帰テストの自動化

導入効果

実施結果（2）nu テスト担当者 の削減• 人間に代 わってG U I テストツールが 画面操作 を実施 するため、要 員を削減 できる。
• 今回の 事例 では、1 0人 →5 人に削 減 できた。
u テスト担当者にかかる負荷の削減• 回帰 テスト時、数 時 間の 連続操作による 緊張状態 など、担当者に 非常に 大きな負 荷がかかっていた。
• ツール を用いた テストは 、画 面を眺めていて時折必要 な操作 を施すのみでよい。
⇒テストは「面 白く」、「非常に 楽」（担当者談）になった 。
u 正確性の向 上、テストの 実施管理 の容易 な実現• 正確に・確実に 実施したという記録 が残 ることになる。実施漏 れなどは記録 からすぐに発 見できる。
u スクリプト開発中のディグレード発見による品質向上• スクリプト開発中にも数回 、画面操作 を行 う。この際にもディグレードが発 見できた。
• 今回の 事例 でも、運 用 時の 重大 なバ グも含 め5,6件 発 見 できた。

- 19 -

注意事項
u 工数面では、数回以上 の繰り返しが 想定される場面で有効（付録参照）
u スクリプト開発の専任体制が必要。導入時は経験者による支援も必要
u あまり小規模 なプロジェクトには向かない• 要員コスト、ツールコスト（導 入コスト、スクリプト開 発コスト）がデメリットになる。
u 「運用、保守」フェーズでの導入をオススメ• 時間的 な制約 が厳しい新規開発時 で頻 繁に回 帰 テストを実践するのは難しい 。
u 次のような導入リスクも考慮 しておく
必 要がある• ツール を使いこなすには スキル が必 要。スクリプト開 発コストに加 えて「導入コスト」も見込 んでおく必要 がある。

「GUIテストツールを導入すれば、非効率 な回帰 テストが楽々 自動化 される」と安易に考えるのは禁 物⇒導 入に際してはプロジェクトの特性を考慮する

Copyright (c) 2004 NTT DATA Corporation, All rights reserved.

今後の展開
n

回帰テストの自動化- 20 -

回帰テストの自動化得られたノウハウu スクリプト開発作業の標準化• 再利用性を考慮した スクリプト方 式• 作業 プロセスの 定義

nCopyright (c) 2004 NTT DATA Corporation, All rights reserved.

まとめ

テストスクリプト作成はソフトウェア開発そのものと心得る
u プロジェクト管理者と明確な作業規約 が必要• 必要 な作 業 規 約– スクリプト規約。
– 共通モジュールの定義書。
– GUIテストツールのノウハウ。
u テストスクリプト開発にも次のような作 業を実践した• 進捗管理– 毎日ミーティングを行い、状況把握・対応を迅速にできるようにした 。
– 問題発生時には、「誰」が、「いつまで」に対応するのか明確に一覧管理しておく。
• スクリプト管 理– 共通モジュールを複数人で編集することがあり、一日数回バックアップをとっていた。

- 21 -

Copyright (c) 2004 NTT DATA Corporation, All rights reserved.

まとめn- 22 -

Copyright (c) 2004 NTT DATA Corporation, All rights reserved.

（付録）手動テストとの工数比較

テスト自動化により品質面、工数面で成果をあげることが 出来た
u 複数ツールを導入することで高い効果が得られる• シンプルなツールが充 実し、導入障壁が 低くなってきている• テストツールの 推進担当者が 必要nn

手動 テストに必 要な工数と自動 テストを導入した 場合 の工数比較
u 自動テストではスクリプト準備工数が必要になるため、何回か繰り返さないと投資が回収できない
今回、および 過 去の 事例 から損 益 分 岐となる回 数を算出
u GUIテストツールによるテストを下図でM回繰り返すと「工数での」元が取れる
u 手動のテスト担当者が頻繁に入れ替わることを考慮するとN回の繰り返しで元が取れる• 担当者入れ替えによる教育コストなどを考慮。

u より効果的なツール利用のため、適用結果をフィードバックすると良い• ソースチェック結 果をアンチパターンとして活用• テストケースの リバース生成 などJUnit のテストコードを活 用するしくみ• 作業効率を考慮した 作業 プロセスとスクリプト方 式

回帰テストの自動化

手動テスト

累積工数（人時）

累積工数＝一回の手動テスト工数× 繰り返し回数

担当者入替 り時の教育コスト

n

自動テスト

ツール導入により万事がうまくいくわけではない
u よいテスト設計は人間が 行う
u ツールの制限範囲を見極める• 人間の 作業 の一 部を肩代わりするものと考 える• 作業の 一部 をツール で行 うこととした運 用ル ー ルを作成す る必 要が あ るNu- 23 -

JaSST 2004

累積工数＝初期工数 ＋ 一回の自動テスト工数 ×
繰り返し回数

初期工数：
スクリプト準備工数

Copyright (c) 2004 NTT DATA Corporation, All rights reserved.

M

繰り返し回数（回）

導入検討時には、N〜Mを損益分岐点とし、費用効果を考える- 24 -

Copyright (c) 2004 NTT DATA Corporation, All rights reserved.

4