ソフトウェアテストシンポジウム 2012
JaSST’12: Japan Symposium on Software Testing 2012

実機テスト自動化によるテスト効率改善について－大規模なテスト自動化におけるテストスクリプト設計方針と実現－于澎††株式会社 ACCESS ソフトウェア事業部 〒261-0023 千葉県千葉市美浜区中瀬 1-10-2
E-mail:Yu.Peng@access-company.com

あらまし 組込みソフトウェア開発において、最低限のコストでビルドの作成毎に改修確認を兼ねてシステムテストとストレステストを実施するため、実機を使用した自動テストを行った。テストスクリプトを適切に作成しなければ逆に工数増加、実施時間増加、テストチームのモチベーション低下に繋がってしまう恐れがあるため、テストスクリプトの保守性、移植性、信頼性の向上に重点を置きながら、効率よくテストスクリプトを作成し、最終的にテスト実施コストが約 70%に短縮することができ、開発全体の効率を改善することができた。また、将来を見据えてテストスクリプト仕様の理想像について考察した。
キーワード 実機、テスト自動化、テストスクリプト

Improving efficiency of test automation test running on a real device－Design strategy and implementation of automated test scripts for large test－Peng Yu†Software Business Unit, ACCESS Co., LTD
1-10-2 Nakase, Mihama-ku, Chiba-shi, Chiba 261-0023 Japan
E-mail: Yu.Peng@access-company.com
Abstract In an embedded software development, We performed an automated test in order to make the system tests andstress tests executable for each release at the lowest cost. To reduce testing cost as much as possible, we focused on improving
the reliability, the maintainability and the portability of test scripts and tried auto-creating test scripts using Excel Macro. As aresult, we succeeded in reducing the testing costs by about 70% eventually. And we also discussed the vision of thespecification of test scripts.
Keyword Real Device，Test Automation，Test Script

1. は じ め にリリースごとに回帰テストを実施することにより、品質の悪いテストスクリプトは導入効果を薄め、場合によっては逆効果を招いてしまうこともある。

不具合の修正によるコードの変更や新たな実装についそのため、テストスクリプト設計時にスクリプトのての品質を確認することができるが、ソースコードの保 守 性 、移 植 性 、信 頼 性 、効 率 性 に 重 点 を 置 き な が ら 、規模に比例してテストにかかる工数も増大するため、マクロを利用して効率的にスクリプト生成を行うことテスト自動化を導入し、テスト工数の削減の必要性がに よ り 、導 入 効 果 を 最 大 限 に 引 き 出 す こ と を 実 現 し た 。

あった。テスト自動化の導入効果として以下があると1.1. テスト対 象について考えられる。
・ テスト工数削減（人手の確保）
・ テスト期間短縮
・ テストチームのモチベーション維持
・ 品質の定点観測
・ 再利用可能
しかし、実機を使用したテスト自動化は参考文献が
少 な い 上 、 テ ス ト ス ク リ プ ト の 品 質 へ の 要 求 が PC 上で行う自動テストのスクリプトより格段に厳しくなる。

本稿では某メーカー向け端末機器（タッチパネル搭載 ） に 搭 載 さ れ た 弊 社 主 力 製 品 Netfront Ⓡ Browserを テス ト 対 象 と す る 。PC版 シ ミ ュ レ ー タ で テ ス ト を 行 っ た
後、実機に搭載された状態で品質評価と品質確保のた
め 、リ リ ー ス 毎 に 合 計 5000 件 ほ ど の シ ス テ ム テ ス ト と6 時間のストレステストを行った。

1.2. 自 動 化テストツールの選 定について弊社では自動化テストツールの導入に伴い、複数のテストツールについて次のような視点でツールの評価を行った。

1.4.2. テ ス ト 実 施（ 工 数 ）
表 2 Testing by Manual(予 想 )・ 必要とされる全ての実機操作が可能であること
・ 強力な画像処理機能が搭載されていること
・ 柔軟なフロー制御が可能、かつ習得しやすいスクリプト言語によるコーディングが可能であること
・ スクリプトの文法チェック機能を有すること・ WindowsPC を 同 時 に 制 御 可 能 で あ る こ と・ 他言語と連携できるインターフェースを持ってい

表 3ることTesting by Robot(実 績 )・ 技術面・運用面でのサポートが得られること
これらの条件を元に検討の結果、弊社では日本ノーベ ル 社 の テ ス ト 自 動 化 ツ ー ル 『 Quality Commander 5』（ 以 下 QC と 略 す ） を 導 入 し た 。

1.3. テスト自 動 化ツールの利 用時の問 題点
本 案 件 よ り 以 前 に も QC を 導 入 し た こ と が あ り 、 既知の問題点として、以下のものがあった。
・ テストスクリプトの作成、品質確保に時間を要す
る・ 作成済みテストスクリプトを他案件に流用することが困難
・ 仕様変更等でテストスクリプトのメンテナンス作※ ツ ー ル の レ ン タ ル 料 金 は 約 500 ,000 円 /月・ 合 計 で コ ス ト を お よ そ 70%に 削 減 で き た・ リリース毎にテスト実施ができ、不具合調査、改修が早くなる業が頻繁に発生する・ リリース毎に顧客に引き渡す時間が決まっており、・ 人間の休み時間にテスト実施ができ、最終的にテスト 3 回多めに実施できた

仕様変更対応に要する時間が十分に与えられなく、一部テストの手動実施を余儀なくされる・ 人間が実施に向いていない長時間ストレス系テス
ト実施も楽になり、チームモチベーション維持に

・ テストスクリプトの不具合により、自動テストが貢献止まる
上記の問題点を解決すべく、テストスクリプト作成に取り組んだ。詳細を 2 章から 3 章で説明する。

1.4.3. テ ス ト 実 施（ 実 施 時間 ）表 4

自動テスト実行時間の実績

1.4. 実 績
1.4.1. ス ク リ プ ト作 成
表 1 テストスクリプト作成工数の実績※1

稼 働 率 =実 質 実 行 時 間 ÷実 行 時 間 ×100%

最 初 の 1 パ ス 目 は 不 具 合 が た く さ ん 残 っ て お り 、 12回も止まったが、2 パス目以降止まる回数が減り、安定してテストできるようになった。

1.4.4. 不 具 合 検 出件 数
表 5

不具合検出件数

2. テ ス ト ス クリ プ ト の品 質 特性
テストスクリプトもソフトウェアであるため、ISO9126 で 定 め ら れ て い る 品 質 特 性 と 品 質 副 特 性 で 品

2.2. 信 頼 性
テスト対象以上にテストスクリプトに信頼性が求められる。

質を評価することができる。しかし、ソフトウェアを人間は週末、休日、業務時間外を合計すると、年間テストするソフトウェアという特殊な位置づけから、78%の 時 間 仕 事 を し て い な い 。 そ の 時 間 を 利 用 し 、 テ

設計時に作りこまなければならない品質特性の優先度ストを可能にすることがテスト自動化の大きなメリッは普通のソフトウェアとは異なる。本案件では、以下トの一つである。しかし、人間が休んでいる間にテスの品質特性に重点を置いて設計を行った。

トがスクリプトの不具合により止まった場合、テストを再開させることができず、テスト自動化のメリット

2.1. 保 守 性
テスト対象以上にテストスクリプトに保守性が求められる。
テストスクリプトは一度作成すれば、長く続いて使用できるものでなく、以下のように様々な要因により変更する必要がある。

テストスクリプトは安定していなければならないわけである。
主なテストスクリプトの不具合：
・ 無限ループ
・ 画面遷移がずれて、操作が無意味になる・ テスト対象の仕様変更
・ テストコンテンツの変更
・ テストケースの変更
テスト対象の仕様変更はテストスクリプト変更の一要因でしかないため、テストスクリプト変更の確率はテスト対象の仕様変更が発生する確率よりも大きいということになる。
（図 1は 薄 れ て し ま う 。そ の た め 、テ ス ト 対 象 が 不 安 定 で も 、振り幅は変更発生確率を表・ 致命的なメモリの使用ミスでテストツールがクラッシュする
・ 画像判定ミスよる誤分岐
・ テスト対象の既知バグによる誤動作

2.3. 移 植 性
テスト対象並にテストスクリプトに移植性が求められる。

す）

一度作成したテストスクリプトが会社の資産となり、次の案件に流用できることがテスト自動化の大きなメリットの一つである。そのため、・ テストスクリプトの機能を細分化して、機能もしくはモジュール毎に切り出せるように設計する・ なるべくモジュールに汎用性を持たせる
・ 弊社の場合、自社製品のソフトウェアを顧客のハードウェアに載せてテストすることが多いため、ハードウェアに依存する部分と依存しない部分を分けて設計することが求められる。
図 1

テストスクリプトの変更確率が大きい

一方、テストスクリプトの修正時間は十分に与えら

3. テ ス ト ス クリ プ ト 設計
3.1. テストスクリプトの階 層 化れないことが多い。そのため、どのようにテストスク大規模なテストスクリプトでは、端末操作以外にもリプトの保守性を高めるかがテスト自動化を成功に導座標変換、実行時画面解析、端末の操作に対する反応くための鍵となる。保守性を高めるには、以下の方針確認やリトライなどの操作がよく行われるため、テスでテストスクリプトを作成する必要がある、

トスクリプトを作成する前に、よく行われる操作をま・ 変更箇所を特定しやすくする

とめてライブラリ化することでテストスクリプトの保・ 変更箇所を少なくする守性を向上させることができると考えられる。また、・ 変更漏れ、変更副作用を最低限に抑える

実機を使用した自動化テストにおいて一般的なライブ

また、テスト対象の仕様変更は過去データを分析すラリ構造をまとめておいて、本案件以降も同様な構造ればある程度分かるため、仕様変更を見越したスクリでテストスクリプトを作成することでライブラリ部分プト作成も重要である。の保守性と移植性を向上させることができると考えられる。本案件では以下の階層化モデルを提案し、その階層モデルでテストスクリプトの階層化を行った。試・ テストケース

験手順層以下の層がライブラリという位置づけである。

・ テストコンテンツ
・ テ ス ト 対 象 ソ フ ト ウ ェ ア （ UI、 遷 移 方 法 な ど ）・ テスト対象ハードウェア（サイズなど）
・ テスト環境（実機の置き方など）
・ テストツールがあると考えられる。以上の情報を無秩序に関数に記入すると、可読性、メンテナンス性が低下してしまうことがある。そのため、本案件では以上述べた要素を別々に管理するようにし、効率化を図った。その結果3.1と ほ ぼ 同 様 な メ リ ッ ト が 得 ら れ た 。

図 2

テストスクリプト階層図

3.3. 座 標 変 換
タッチパネル操作の場合、押下位置を座標で指定す

・ 試験手順層：この層の関数はテストケースをテス

る こ と が 多 い が 、ス ク リ プ ト に 座 標 を 直 接 記 入 す る と 、トケースと同じ粒度で転記したもので、コード行可読性が悪くなる上に、メンテナンスが難しいため、

数 は テ ス ト ケ ー ス ス テ ッ プ 数 の 1～ 2 倍 が 望 ま し い 。

本案件では、座標を直接指定せず、文字列で押下位置下位層で定義された関数を呼び出して操作を行う。

を示し、実行時に文字列を座標に変換する方法を取っ

関 数 の 先 頭 に テ ス ト ケ ー ス ID、 詳 細 、 手 順 、 期 待た。試みた変換方法には以下があった。

結果などの情報を記入する。試験手順層の関数は・ マクロ定義：実行前に座標に直接名前をつける。

テストケースが変更されない限り、変らない

実行時にマクロ定義ファイルを引いて座標に変換

・ 操 作 確 認 層：操 作 が 行 わ れ る た び に 呼 び 出 さ れ る 。

する。押下位置が頻繁に変らない場合に有効操作が正しく行われたかを確認し、正しく行われ

・ 画像変換：実行前に押下位置の画像を切り取ってなかった場合、取るべき操作を取る。
・ 座標変換層：座標以外の形で指定された押下位置を座標に変換する

ファイルに保存し、ファイル名に意味のある名前をつけておく。実行時に指定されたファイル名から保存しておいた画像を読み込む。次に読み込ん

・ 判定層：静止画、文字列、音声、動画などを比較だ画像を現画面から探し、見つかった場所を押下し、一致するかを判定する。または片方がもう一す る 。 押 下 位 置 が 変 っ て も UI（ 画 像 ） さ え 変 ら な方のどこに位置するかを割り出す。

け れ ば 変 更 す る 必 要 は な い 。押 下 位 置 の UI（ 画 像 ）・ 情報処理層：画像処理、音声処理などを行う。
・ 操作層：座標を受け取って押下する、カメラで写真を撮るなど最も基本的な操作をする
・ 物理層：ハードウェアのドライバなど電気的に操作層の操作を実現するが頻繁に変らない場合に有効
・ 連続番号：実行前に画面要素にある規則で連続番号を振り、各番号に名前をつける。実行時に名前から番号に変換し、現画像を画像処理し画面要素の該当番号が示すところを押下する。画面要素の階層化には以下のメリットがあると考えられる。

順 番 さ え 変 ら な け れ ば 、 UI と 座 標 が 変 っ て も 変 更・ 各層の機能が明確になり、問題が出た際に問題特する必要はない。変更するときにも番号の書き換定に要する時間が少なくなる・ 今後の案件も同様な階層化モデルで設計すること
で、テストスクリプト（ライブラリ部分）の移植性が向上する
・ 各層で行われる作業が明確になることでバグを作えだけで済むため、メンテナンスが簡単である。
しかし、高精度で汎用性のある画像処理技術が必要だ。
以上の三つの手法はいずれも一長一短あるが、それらを統合するとよりよい手法になる。

りこむことが少なくなり、信頼性が向上する。ま・ 連続番号とマクロ定義の併用：連続番号を使用した、修正時の修正漏れと修正副作用も少なくなるて画面要素を抽出する際、画面要素の認識率は3.2. テスト情 報の分 離3.1で は 、操 作 の 観 点 で テ ス ト ス ク リ プ ト を メ ン テ ナ
ン ス し や す い よ う に 小 分 け す る が 、3.2で は デ ー タ の 観
点でテストスクリプトを小分けする。
実機を 使用 した自 動テ スト にかか わる 要素 として 、100%に な ら な い こ と が 多 い 。 誤 判 定 が 発 生 し た 場
合でも正しい位置を押下できるように、文字列に連続番号だけでなく、座標も登録しておくことで精度をさらに上げる。座標は参考にしかならない
ため、座標が少しずれる程度で変更する必要はない。

・ 空気を読む変換方法：マクロ定義、画像変換、連続番号、さらに画面要素の配置などの情報を統合

・ テストスクリプト設計自体に大きな影響を与えるして、どの位置を押下したいかを汲み取って押下バグがある場合、設計段階から考慮できる（例：する※2

めることができる。

※2。

極 端 に 発 熱 量 が 多 い と い う バ グ が 未 解 決 の 場 合 、1

本手法は現在まだ開発中

時 間 毎 に 試 験 を 10 分 停 止 さ せ て か ら 復 帰 さ せ る よ

本案件では、テスト対象の状況を考慮し、連続番号う に 設 計 し な け れ ば な ら な い ）。

法 を 採 用 し た 。そ の 結 果 、押 下 位 置 の UI、座 標 、フ ォントが変っても、メンテナンスする必要はないため、

4. テ ス ト ス クリ プ ト 仕様 の 理想 像

メンテナンス工数を削減することができた。

4.1. オブジェクト指 向 化

3.4. テストスクリプトの自 動 生成
テストスクリプトを手動で作成する場合、作成、テストに時間がかかる上に、大量のメンテナンス作業が必要となってくる。そのため、本案件ではスクリプト量が最も多い試験手順層に対してテストスクリプトの自動生成を試みた。手順は以下に示す。
1.

Excel ベ ー ス の 試 験 仕 様 書 を 用 意 す る 。 弊 社 の 試
験仕様書は一行が一テストケースに対応しており 、列 に 試 験 概 要 、 上 位 ド キ ュ メ ン ト 章 番 号 、 試
験 手 順 、期 待 値 、テ ス ト コ ン テ ン ツ URL、テ ス ト
実施者などの情報が入っている。

2.

使用されていない列の最も左寄りの列から操作を記入していく。
操作の引数は前の列に記入されていることが多いので、省略して記入することが可能。

3.

QC を 含 め て 従 来 の テ ス ト ス ク リ プ ト 仕 様 は ほ と ん
どプロセス型である。これはテストスクリプトとはテスト手順に従って書いていけばよいという既成概念から来たものと考えられる。しかし、小規模なテストスクリプトであれば問題ないが、規模が大きくなると、
プ ロ セ ス 型 テ ス ト ス ク リ プ ト に 限 界 が あ り 、 3.1と 3.2のように操作とデータの観点で人間がメンテナンスできる規模に小分けしなければならない。
そのため、テストスクリプト仕様をオブジェクト指向化することで、メンテナンス性のよいテストスクリプトが作成しやすくなる上に、オブジェクト指向の継承、ポリモーフィズムの特徴を応用すれば、テストスクリプトの流用もしやすくなると考えられる。

4.2. テストプラットフォームの構 築
きちんと設計しなければテスト自動化は効果を挙

ま た 、ス ク リ プ ト 同 士 で 似 た 操 作 が あ れ ば 、フ ィ

げられない可能性があるため、毎回設計をする必要がルハンドルを押したままドラッグすることで簡ある。しかし、設計できるスペシャリストがいるか、単にコピーできる。

設計するだけの時間があるかなどの問題もあれば、設VBA で マ ク ロ を 作 成 し 、テ ス ト ス ク リ プ ト を 自 動計したとしても、人間のミスによる設計の欠陥も考え生成する。

られる。

テストスクリプト自動生成を試みた結果、生産性がそのため、業界で統一したオープンソースのテスト

自 動 生 成 し な い 場 合 50～ 100 本 /人 日 か ら 約 200 本 /人プラットフォームが必要となってくると考えられる。

日となり、およそ 2 倍～4 倍まで上がった。

開発エンジニアには開発用プラットフォームが揃って3.5. その他
ここまでに述べてきたのはテストスクリプトの特性に注目して考えられた手法であるが、テストスクリプトもソフトウェアであるため、ソフトウェア開発にお け る 一 般 的 な 手 法 も 併 用 す る と 、更 に 効 果 が あ が る 。
・ 上位ドキュメントとのトレーサビリティ確保。テ
ストスクリプト変更となったときに変更箇所が特定でき、変更漏れを防ぐ・ 分岐を減らし、スクリプト複雑度を低減
・ スクリプト可読性の向上
また、可能であればテストスクリプト設計前に既存バグについて調べておくと、以下のメリットがある。
・ 自動テストが可能な程度の安定性を持っているコいるのにもかかわらず、テストエンジニアにはテスト用のプラットフォームがないのが現状だ。テスト自動化なら最も基本の・ データベース
・ 常時監視・ テスト機材のドライバ
・ テストスクリプトインタプリターとデバッガー
・ その他テストスクリプト開発ツールなどの機能を揃えて提供し、また、誰でも開発ツールなどを開発して組み込めるようになれば、テスト自動化はしやすくなると考えられる。

5. 結 論

ンポーネントと持っていないコンポーネントの見実機を使用したテスト自動化では、テストスクリプ分けがつき、テストスクリプト作成の優先度を決

トはテスト手順に沿って書いていけばよい、テスト手順をツールで記録してそれを毎回再生すればよいなどの考え方があるが、大規模なテストでは、テスト自動化の効果を発揮できないどころか、逆効果になってしまうことさえある。
テスト自動化の効果を最大限に発揮するには、テスト ス ク リ プ ト の 保 守 性 、移 植 性 、信 頼 性 に 重 点 を 置 き 、きちんとした設計を行う必要がある。
本案件では、テストスクリプト設計、テストスクリプト自動作成を実施し、最終的にテスト工程で試験回数を倍近く増やし、手動により実施不可能なテストを可 能 に し な が ら 、コ ス ト を 70%に 削 減 し 、 製 品 品 質 の向上に貢献できた。
今後はさらにテストスクリプト設計を追及しながら、テスト工程の時間短縮、画像処理技術をテスト自動化への導入などに力を入れていきたい。

文献[1] 大 西 建 児 ， 勝 亦 匡 秀 ， 加 藤 大 受 ，佐 々 木 方 規 ， 鈴木三紀夫，町田欣史，湯本剛，吉澤智美，ソフトウ ェ ア テ ス ト 教 科 書 JSTQB Foundation（ 第 2 版 ），有 限 会 社 風 工 社 （ 編 ）， 株 式 会 社 翔 泳 社 ， 東 京 ，
2009[2] http://www.jnovel.co.jp/qc/