システムテスト自動化標準ガイド５章発表資料

「テストウェアアーキテクチャ」発表資料

「システムテスト自動化標準ガイド」　第 5 章

伊藤雅俊（ @masatoshiitoh ）2015/7/4

自己紹介

日本メディカルネットコミュニケーションズ ( 株 ) 勤務本発表は、所属する企業・団 t （ ry

サーバー側メインのおおむね何でも屋

JS/PHP/Obj-C/Java ここ 3 ヶ月では、 Wordpress カスタマイズ職人、 Android アプリ改修職人、 iOS アプ

リ改修職人などなど。

プライベートで Erlang/OTP 、 Unity(C#) など Unity から RabbitMQ(AMQP) や MQTT を使うライブラリなどを公開。 https://github.com/masatoshiitoh/unity_mqlib https://m2mqtt.codeplex.com/SourceControl/network/forks/masatoshiitoh/M2mqtt4Unity

https://github.com/masatoshiitoh/unity_mqlib

https://github.com/masatoshiitoh/unity_mqlib

https://m2mqtt.codeplex.com/SourceControl/network/forks/masatoshiitoh/M2mqtt4Unity

https://m2mqtt.codeplex.com/SourceControl/network/forks/masatoshiitoh/M2mqtt4Unity

テスト経験について自己紹介 (20 世紀 )

1990 年代クライアントサーバー系システム

▪ テスト方法は、手動操作による確認。▪ テスト項目は、画面とシナリオから作成。お客様側から指定あり。▪ GUI テストツールの Microsoft Test の採用を検討するも、社がクライア

ント部分の開発を担当しなかったので推進できず。

▪ 内部ライブラリはソースコード目視チェック▪ テストコードは特に作らず、実行ファイルごとに結果を目視確認。


2000 年代前半回線速度測定サービスの企画・開発

▪ コアプロトコル発案・設計、 v1.0 クライアントの開発を担当。

▪ テスト方法は、手動操作による確認。▪ テスト項目は特に定めず。▪ 回線種別ごとに、このぐらいの速度が出るだろう、とい

う想定で、そこを大きく逸脱した値が出ると「不具合」として修正を実施。　→びっくりするほどアドホック

▪ http://www.itmedia.co.jp/broadband/0307/09/lp17.html

http://www.itmedia.co.jp/broadband/0307/09/lp17.html




2000 年代後半ネットリサーチとポイントサービスの連携システムの開発

▪ テスト方法は、手動操作による確認。▪ テスト実施数、エラー件数、修正件数などのカウントが入った、統一書式の報告Excel が提供された。▪ テスト項目のリストアップや、手順書作成はExcel 方眼紙。

2010 年代前半ウェブアプリのポイント管理システムの開発

▪ テスト方法は、テストスクリプトによる一括テスト。▪ モックとテストコードを作成。実行は手動。▪ スクリプトにはパラメータをハードコード。

▪ 結合後のテストは手動操作による確認。小規模チームによるゲームアプリの開発

▪ テスト方法は、手動操作による確認。▪ テスト項目は、画面遷移とディレクター指示。▪ 開発拠点が遠隔のため、バグ報告は Google spreadsheet でした。▪ 新バージョンがビルドされるたび、手作業でチェック。

今回の発表での立ち位置

業務でのシステムテストの自動化経験は「基本的にありません」。

自動化を推進している方の実践情報をお聞きしたい！

というわけで、のちほど「お客様とやりとりするテスト関連の資料はどのように整理していますか？」というお題でポストイットアンケートやります。

５章構成

５章　テストウェアアーキテクチャ 5.1 テストウェアアーキテクチャとは何

か 5.2 カギとなる 4つの課題

▪ 規模▪ 再利用性▪ 複数のバージョン▪ プラットフォームと環境からの独立

5.3 取り組み方▪ 序文▪ 基本概念

▪ テストウェアセット▪ テストスイート▪ テストウェアライブラリ▪ 構成管理▪ テスト結果▪ 物理的構造▪ テストツールとのインターフェース

5.4 これはやりすぎだろうか？ 5.5 まとめ

その前に…

ご紹介したい 2つのスライドが。

http://www.slideshare.net/k_suzuki/aaa2015-49898261

http://www.slideshare.net/k_suzuki/1sta-stac2014

ギア本翻訳の鈴木一裕さん！







とてもすばらしいスライド！

Kazuhiro SUZUKI/ギアと開発とわたし p.24

とてもすばらしいスライド！ 2 of 4

Kazuhiro SUZUKI/ 60 minutes STA (p.39)

ギア本の全体像をつかむには

ギア本の全体像をつかむのに、とてもいいスライド。「システムテスト自動化標準ガイド」の途中で迷ったときは、ぜひ俯瞰図として参照されるといいでしょう

http://www.slideshare.net/k_suzuki/aaa2015-49898261 http://www.slideshare.net/k_suzuki/1sta-stac2014




ご静聴ありがとうございました

ここからは質疑応答の時間です。


ここからは質疑応答の時間です。　　　　・・・？


・・・というわけには。

５章は何を言っているのか

テストに関連するファイルには何があるか？

あなたはテストに関連するファイルをどう管理しているか？

なぜ管理する必要があるのか？ディレクトリにまとめておけばいいのでは？

あなたのプロジェクトで古いバージョンのテストは必要か？

あなたの既存のテストはすぐに拡張・再利用できる状態になっているか？

何かやるとしたら、いつ始めるべきなのか？

5.1 節のトピック

テストウェアアーキテクチャで管理される「テストウェア作成物」は、以下のものがある。

テスト資料「入力」　「スクリプト」　「データ」

　「ドキュメント」　「期待結果」

テスト結果生成物

▪ 「実際の出力」二次生成物

▪ 「ログ」「ステータス」「比較レポート」








テストで使用される入力、スクリプト、データ、ドキュメント。テスト実行で生成される成果物（出力結果）、二次成果物（レポート類）　

(5.1.1)↓

1つのテストケースだけでも6 種類のファイルが必要！

5.2 節のトピック

「カギとなる 4つの課題」規模再利用性複数のバージョンプラットフォームと環境からの独立

→ ここは 5.3 節の前振りです








自動化されたテストケースがほんの十数個であり、そのテストケースを扱う人が 1～ 2名である間は、構造化されていようと、その場しのぎに作ったもの

であろうと、どのようなテストウェアアーキテクチャでも問題は無い (5.2.1)↓

逆に言えば、本格的にチームで自動テストを利用し始めると、テストに関連するファイルの管理法が重要になる、ということ。







テストケースが 10倍に増加したり、自動テストのメンテナンス担当が変わったりすると、すぐにミスが多発するようになり、

自動テスティングを役に立たないものにしてしまう。 (5.2.1)







再利用可能なスクリプトや、データの開発には多くの努力が必要だが、この努力はスクリプトやデータが実際に再利用

された場合にだけ報われる。（ 5.2.2 ）↓

テストの自動化をし続けるためには管理が大事。






あるソフトウェアの旧バージョンで緊急の欠陥が見つかった（中略）持っていると思っていた適切なバージョンのテストスクリプトは、

以前テストをアップデートしたときに保存されておらず、一部が失われていることが分かったのだ (5.2.3 経験談コラム )

↓旧バージョンを完全に放棄できる環境でなければ、古いバージョンのテストが保存される仕組みが必要だ。





自動テスト全体に一貫性がなければ、難解で間違いが発生しやすくなる（中略）どのテスト技術者がどのライブラリのスクリプトを探すにしても 2 分以上

かかるようではいけない。スクリプトが見つかったら、テスト技術者がその使用方法を妥当な時間内で正確に判断できなければならない。 (5.2.2)

↓拡張・再利用のためには、内容をつかみやすいライブラリが必要だ。

5.3 節の目次

5.3 取り組み方▪ 序文▪ 基本概念▪ テストウェアセット▪ テストスイート▪ テストウェアライブラリ▪ 構成管理▪ テスト結果▪ 物理的構造▪ テストツールとのインターフェース

5.3 節の概要（先出し）

「テストスイート」は、テストが実行可能な状態のファイル群。

「テストスイート」は、テストの目的ごとに下記のものを任意でピックアップした詰め合わせである。

▪ テストセット（テスト固有のスクリプト、データ、ユーティリティ、ドキュメント）

▪ スクリプトセット（共用）

▪ データセット（共用）

▪ ユーティリティセット（共用）

▪ ※上記 4 種の「セット」の総称がテストウェアセット。

テストウェアライブラリは、全てのテストウェアセットのマスターバージョンを格納しているリポジトリであり、テスト実行時はここからコピーしてきて実行する。

バージョン管理は適宜行う。







▪ ※上記４種の「セット」の総称がテストウェアセット。



5.3節は長く、しかも 8.3形式（ MS-DOS時代のスタイル）のファイル名をサンプルで多用するという、今となっては非常に分かりにくい構成になっています。

そのまま読み進めるのは大変なので、ここではざっくり掴んでいくことにします。

5.3 節の概要（先出し）

図にすると

テストウェアライブラリ

( リポジトリ )

テストスイート( 実行環境 )

テストセット

スクリプトセット

データセット

ユーティリティセット

テストセット t1

スクリプトセット s1

データセット d1

ユーティリティセット u1

ユーティリティセット u1

データセット d2

スクリプトセット s1



コピー

5.3.1 序文

「これから示す方法は、テストウェアアーキテクチャで成功を収めるために、多くの組織にとっての出発点として使用されてきた。」

「読者は、自分の状況にこの取り組み方を適応させるか、魅力的と思えるアイデアだけでも取り上げることをお勧めする。」

5.3.1 序文

「これから示す方法は、テストウェアアーキテクチャで成功を収めるために、多くの組織にとっての出発点として使用されてきた。」

「読者は、自分の状況にこの取り組み方を適応させるか、魅力的と思えるアイデアだけでも取り上げることをお勧めする。」

ものすごくお勧めされてます！

テストに必要なファイルとは（再掲）

テストウェアには、テストで仕様および生成される全ての作成物が含まれる。（ 5.1.1 ）

テスト資料とテスト結果に大別される。テスト資料は「入力、スクリプト、

データ、仕様書などの各ドキュメント、および期待結果」。

テスト結果は「成果物と二次成果物」。

5.3.2.1 テストセット

テスト資料は複数のテストセットの集合。

テストセットには 1つ以上のテストケースが含まれる。

テストセットには、テストケースに関連づけられたスクリプト、データ、期待出力、ドキュメント類を含む。

5.3.2.2 テストスイート

2つ以上のテストセットを目的によって等まとめたものが「テストスイート」。

テストスイートは、テストケースの集合体。

5.3.2.3 基本概念の限界

しかし、「テストセット」「テストスイート」だけでは5.2節で提示された 4 つの課題に対応できない。

4 つの課題とは？規模再利用性複数のバージョンプラットフォームと環境からの独立

5.3.2.3 基本概念の限界　（解決編）

解決するために→

スクリプトセット（スクリプトを共有する）データセット（データを共有する）ユーティリティセット（ユーティリティを共有する）

そしてテストセット

これをまとめたのが「テストウェアセット」。

5.3.3 テストウェアセット

テストウェアセットは、テストウェアアーキテクチャを構成する要素である。

テストウェアセットは、以下の種類がある。テストセットスクリプトセットデータセットユーティリティセット

テストウェアセットとは、テストウェア作成物を、テストスクリプトやデータファイルといった種類で分けた論理的な集合（セット）である。

5.3.3.1 テストセット

テストセットは 1つ以上のテストケースを定義する。

テストセットはテストケース固有のテストウェア作成物を全て含む。内容は、テストスクリプト期待結果テストデータテスト入力文書ファイル（テスト仕様書など）ユーティリティのソースファイル（テスト用ドライバや独自のコンバーターなど）ユーティリティの実行ファイル（上述のソースファイルからビルドされたもの）

テストセット内のテストウェア作成物はそのテストケースでしか使用されない異なるテストセットに含まれるスクリプトを再利用したいときは、スクリプトをテス

トセットからスクリプトセットに移動する。

5.3.3.2 スクリプトセット

スクリプトセットはテストスクリプトと、それに対するドキュメンテーションのみを含んでいる。

スクリプトセットに含まれる全てのスクリプトは、再利用される。

複数のテストケースによってそのスクリプトが使われる。ドキュメントは必須ではないが、作成することを強く推奨。

アプリケーションの開始・終了等のナビゲーション、ロギングなどのスクリプトが例に挙げられている。

5.3.3.3 データセット

データセットは、データファイルとそれに対するドキュメンテーションのみを含んでいる。

データセット内のファイルは、 2つ以上のテストセットの異なるテストケースで利用される。

複数のテストケースで再利用される。

5.3.3.4 ユーティリティセット

ユーティリティセットは、 2つ以上のテストセットのテストケースで利用されるユーティリティ（スタブ、ドライバ、コンバータ、比較ツールなど）を含む。

また、ソースコードと実行ファイル、関連文書も含む。

例として、日付フォーマット変換ユーティリティ、比較ツールへの簡単なインターフェースを提供するコマンドファイル等が挙げられている。

5.3.4 テストスイート

テストスイートは、テストの実行に必要なものが全て揃った環境をいう。選択したテストケースは全て、テストスイートから実行される。

例で挙げられているテストスイートは、修正した Scribble アプリケーションの特定のバージョンに対して実行したいテストケースを含むもの、として、

Scribble の全機能をカバーする幅広いテストを含むテストセットログを取る共有スクリプト比較ツールの共有ユーティリティ文書管理の共有スクリプト Scribble をナビゲートする共有スクリプト修正した箇所をテストするためのデータセット修正した箇所をテストするためのスクリプトセットセット

という構成が示されている。

5.3.5 テストウェアライブラリ

テストウェアライブラリとは、すべてのテストウェアセットのマスターバージョンを格納しているリポジトリ。

リポジトリの管理・利用についての説明。

5.3.5.1 テストウェアライブラリ、テストスイート、テストセットの例

テストウェアライブラリは、全てのテストウェアセットのマスターバージョンを格納しているリポジトリ。

これらの資料を使うには、コピーを行う必要がある。※我々感としては、チェックアウト、でいいいか？

テストスイートを構築するときは、テストウェアライブラリから、必要なテストセットをコピーしてくる。

5.3.5.2 テストウェアライブラリへのアクセス

テストウェアライブラリからテストウェアセットをコピーする作業は、できるだけ簡単であることが重要。短時間でおこなえる。失敗の余地がない（不完全なコピーが起きないように）。

コピー失敗でテストが失敗したりしないように。

5.3.5.3 構成管理

テストウェアの構成を管理する方法。

難しく書いてあるが、テストを更新したら、テストウェアセットの新版として登録する

のが 1つめ。テストウェア作成物を修正したら、個々のテストウェア作成物の

新版を登録するのが 2つめ。

※我々感としては、バージョン管理システムを使うイメージでいいか？

5.3.5.4 テストウェアの更新の制御

複数人での作業に耐えるようにしよう。古いバージョンのテストケースのサブセットを 2つの異

なる環境で実行するようなことが簡単に行えるならおおむね良好。

※テストウェアアーキテクチャの内、テスト実行用ファイル（テスト資料）については、ここまで。

5.3.6 テスト結果

テスト結果には、実際の出力比較レポートテストツールのログ

を含むもので、テスト実行のたびに生成される。

5.3.6.1 テストの成果物と二次成果物

テストの出力は直接的な成果物。

テスト比較レポートや、テストツールログなどは、日付や環境情報を含むオペレーションログを含み、こちらも重要。

5.3.6.2 テスト結果は保存すべきか？

テスト実行の証拠として必要なら保存する必要がある。

そうでなければ全てのテスト結果は削除可能。

5.3.6.3 テスト結果の論理構造

テストスイートに含まれるテスト結果一式は、テストセットごとにグループ化できる。

5.3.7 物理的構造

テストウェアセットと、テストスイートの構造を実装する場合は、ファイルシステムの階層構造を利用すると良い。

5.3.7.1 テストウェアセットディレクトリ

テストウェアセットのディレクトリ構造は厳密に守らなくてはならない。

5.3.7.2 テストスイート

テストスイートもまたディレクトリ階層。

全てのテストウェアセットディレクトリが、テストスイート内の 1つのディレクトリに配置される。

5.3.7.3 テスト結果

テストスイートからテスト結果を分離し、独自のディレクトリ階層に格納する。

トップレベルのディレクトリには、対応するテストスイートとの関連が分かるような名前を付けるのがベスト。

5.3.7.4 命名規則

もしランダムな名前 (Mark, Barbara, Franky, Bobby など ) をファイルに付けていたら、個々のスクリプトやデータファイルを探し出すことはかなり困難になるだろう。

本書では、テストウェアセットはスクリプトセット：ｓデータセット：ｄテストセット：ｔユーティリティセット：ｕ

で始まり、アンダースコア、アプリケーション名と続き、テストケースが実行する、もしくはテストウェアがサポートする機能やアクションを記す。

たとえば「 s_ScribbleDocument 」であれば、 Scribble に関する、何らかドキュメントに関連するスクリプトセットが含まれている。

5.3.7.5 プラットフォームと環境への依存性

期待結果がＯＳなど環境に依存する場合がある。

環境固有のファイルは分けて管理。「前処理」で環境固有バージョンのファイルにスクリプトが正常にアクセスできるようにコピーするのもいい。

テスト結果は環境によって分けて出力されるように。

5.3.7.6 拡張性

テストセットの中に、テストケースが多数になると管理しづらくなる。

テストケースを分割する方法がある。

5.3.7.7 テストケースの定義とトレーサビリティ

キーワード駆動テストケースでは、テストケースとスクリプトが一意には結びつかない。期待結果をスクリプトが含んでいる場合、期待結果が独立したファイルで存在しない。

→構造が一定しない。

実装を知らなければ、たとえばデータ駆動アプローチが使われると分かっていても、分離されたデータファイルを見つけるのは容易ではない。

→探す場所どころか、探すもの（スクリプト、データファイルなど）すら分かっていないかも知れない！！

テストウェアアーキテクチャが十分に構造化され、一貫性を備えているとしても、テストケース自体が簡単で一貫した方法で識別できない場合には欠陥がある。

→ テストケース定義ファイルによって、どのようなテストケースがあるのか、どのテストウェアが使用されるのかといったことを識別できるようになる。

5.3.8 テストツールとのインターフェース

実行したいテストケースを全て含んだテストスイートを持っているとして、どんなテストケースがあり、どう実行すればよいか、テストツールが理解出来る必要がある。

実現する方法はテストツールによる。

テストツールに情報を与える部分については、自動化し、「前処理」タスクで実行するようにしよう。

※5.3 章はここまで。

5.3 節の概要（再掲）







▪ ※上記 4 種の「セット」の総称がテストウェアセット。



5.4 節「これはやりすぎだろうか？」

これはやりすぎだろうか？

5.4 節「これはやりすぎだろうか？」

筆者の主張：「いや、やりすぎではない！」

「テスト自動化の取り組みがうまくいっているならそのテストは拡大していき、コントロールしなければならないファイルの数も急増する。」

「テストウェアのサブセットが簡単に分離できるということには、過小評価できないメリットがある。」

正直、今読むと「やりすぎ」感はさほど無い印象。しかし、原著刊行当時、支援ツールなしでこれを自前で構築しろと言われたら、「やりすぎ」と言ったかもしれません。





テスト自動化の取り組みの開始時に、適切なアーキテクチャを導入しておかなければ、あとから適切なアーキテクチャでやり直すのには、ずっと手間がかか

るだろう。手に負えない状態になってしまってからではなおさらだ。 (5.4)↓

テスト自動化の取り組みの開始時から！

余談：時代環境

1999 年刊行の本なので、そのちょっと前から見てみましょう。スペック等はコンシューマー PC のものです。

1995 年 Pentium Pro (150MHz ~ メイン 4MB ~ 8MB時代 1GB HDD 10BASE2/-T時代

Windows95 MacOS 7.5 Linux 1.0 カーネル (Redhat/Suse)


1999 年刊行の本なので、そのちょっと前から見てみましょう。スペック等はコンシューマー PC のものです。

1995 年 Pentium Pro (150MHz ~ メイン 4MB ~ 8MB時代 1GB HDD 10BASE2/-T時代

Windows95 MacOS 7.5 Linux 1.0 カーネル (Redhat/Suse)

メモリは 1/1000HDD も 1/1000

ネットワークは 1/100CPU クロックは 1/20


1997 年 Pentium II (233MHz ~ 8MB ~ 32MB時代 4GB HDD 100BASE-TX時代

Windows NT4.0 (1996~ MacOS 8 Linux 2.0 カーネル (1996~


1997 年 Pentium II (233MHz ~ 8MB ~ 32MB時代 4GB HDD 100BASE-TX時代

Windows NT4.0 (1996~ MacOS 8 Linux 2.0 カーネル (1996~

メモリは 1/1000HDD も 1/1000



1999 年 Pentium III (450MHz~ 16MB~64MB時代 10GB HDD 100BASE-TX時代

Windows 98SE MacOS 9 Linux 2.2 Samba 2.0


1999 年 Pentium III (450MHz~ 16MB~64MB時代 10GB HDD 100BASE-TX時代

Windows 98SE MacOS 9 Linux 2.2 Samba 2.0

メモリは 1/1000HDD も 1/1000



発刊後日本国内の ADSL サービスは 2000 年前後から。

▪ US はむしろブロードバンドの普及は遅かった。 Windows 2000 は 2000 年。 Windows XP は 2001 年。一般向け 1000BASE製品が出回り始めたのは 2003 年。 Mercurial 、 Git は 2005 年。

原著がこうした状況で 1999 年に刊行された、ということを意識してあらためて 5 章（特に 3節）を読むと、著者の危機感が共有できるのではないかと思います。

５章は何を言っているのか（まとめ）

テストに関連するファイルには何があるか？テストで使用される入力、スクリプト、データ、ドキュメント。テス

ト実行で生成される成果物（出力結果）、二次成果物（レポート類）。

あなたはテストに関連するファイルをどう管理しているか？本格的にチームで自動テストを利用し始めると、テストに関連する

ファイルの管理法が重要になる。

なぜ管理する必要があるのか？テストの自動化をし続けるためには管理が大事。

５章は何を言っているのか（まとめ 2 ）

あなたのプロジェクトで古いバージョンのテストは必要か？旧バージョンを完全に放棄できる環境でなければ、古いバージョンの

テストが保存される仕組みが必要だ。

あなたの既存のテストはすぐに拡張・再利用できる状態になっているか？拡張・再利用のためには、内容をつかみやすいライブラリが必要になる。

何かやるとしたら、いつ始めるべきなのか？用意をするなら、テスト自動化の取り組みの開始時点から！

5 章を受けて我々が考えるべきは

・・・

5 章を受けて我々が考えるべきは

・・・と思ったら。

ギア本の日本語版第 14 章として「 CI （継続的インテグレーション）」が書き下ろされていました！

※「ギアと開発とわたし _AAA2015 」 p.23

TravisCI の利用について紹介されています。

Kazuhiro SUZUKI/ギアと開発とわたし p.23

アンケート：お客様とやりとりするテスト関連の資料の管理についておもに、お客様ありの開発をしている方への質問となりますが・・・

テスト計画書やテスト項目、手順書、バグ報告書など、テスト前後でお客様とやりとりするファイルが多数あり、しかもバージョン管理が困難な運用スタイル（日付付きファイル名の Excel シート等）なことが多いのではないでしょうか？テスト項目の管理はExcel ？　 Google spreadsheet ？バグ管理は Excel ？　 BTS ？テストの進捗を、オンラインで BTS等でお客様に見てもらうかたちにできてる方、いますか？テスト管理ツールの出力でいいよ、とお客様を納得させてるかた、いますか？ Excel 職人としての工数が大きくて苦労している方、いますか？

アンケート：テストの管理（お客様とのテスト項目の共有、進捗、レポート等）のツールは？そのツールで満足している点、不満な点は？


そして、アンケートへのご協力、ありがとうございました。

システムテスト自動化標準ガイド５章発表資料

Software

Transcript of システムテスト自動化標準ガイド５章発表資料

システムテスト自動化標準ガイド ５章発表資料

Software

Transcript of システムテスト自動化標準ガイド ５章発表資料

システムテスト自動化標準ガイド５章発表資料

Transcript of システムテスト自動化標準ガイド５章発表資料