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

「システムテスト自動化標準ガイド」第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

 1990年代
 クライアントサーバー系システム
▪ テスト方法は、手動操作による確認。
▪ テスト項目は、画面とシナリオから作成。お客様側から指定あり。
▪ GUIテストツールのMicrosoft Testの採用を検討するも、社がクライアント部分
の開発を担当しなかったので推進できず。
▪ 内部ライブラリはソースコード目視チェック
▪ テストコードは特に作らず、実行ファイルごとに結果を目視確認。

 2000年代前半
 回線速度測定サービスの企画・開発
▪ コアプロトコル発案・設計、v1.0クライアントの開発を担
当。
▪ テスト項目は特に定めず。
▪ 回線種別ごとに、このぐらいの速度が出るだろう、という
想定で、そこを大きく逸脱した値が出ると「不具合」として
修正を実施。 →びっくりするほどアドホック
▪ http://www.itmedia.co.jp/broadband/0307/09/lp17.ht
ml

 2000年代後半
 ネットリサーチとポイントサービスの連携システムの開発
▪ テスト実施数、エラー件数、修正件数などのカウントが入った、統一書式の報告Excelが提供された。
▪ テスト項目のリストアップや、手順書作成はExcel方眼紙。
 2010年代前半
 ウェブアプリのポイント管理システムの開発
▪ テスト方法は、テストスクリプトによる一括テスト。
▪ モックとテストコードを作成。実行は手動。
▪ スクリプトにはパラメータをハードコード。
▪ 結合後のテストは手動操作による確認。
 小規模チームによるゲームアプリの開発
▪ テスト項目は、画面遷移とディレクター指示。
▪ 開発拠点が遠隔のため、バグ報告はGoogle spreadsheet でした。
▪ 新バージョンがビルドされるたび、手作業でチェック。

 業務でのシステムテストの自動化経験は「基本的にありませ
ん」。
 自動化を推進している方の実践情報をお聞きしたい！
 というわけで、のちほど「お客様とやりとりするテスト関連の資
料はどのように整理していますか？」というお題でポストイット
アンケートやります。

 ５章テストウェアアーキテクチャ
 5.1 テストウェアアーキテクチャとは何か
 5.2 カギとなる4つの課題
▪ 規模
▪ 再利用性
▪ 複数のバージョン
▪ プラットフォームと環境からの独立
 5.3 取り組み方
▪ 序文
▪ 基本概念
▪ テストウェアセット
▪ テストスイート
▪ テストウェアライブラリ
▪ 構成管理
▪ テスト結果
▪ 物理的構造
▪ テストツールとのインターフェース
 5.4 これはやりすぎだろうか？
 5.5 まとめ

 ご紹介したい2つのスライドが。
 http://www.slideshare.net/k_su
zuki/aaa2015-49898261
 http://www.slideshare.net/k_su
zuki/1sta-stac2014
 ギア本翻訳の鈴木一裕さん！

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

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.1)
↓
1つのテストケースだけでも
6種類のファイルが必要！

 「カギとなる4つの課題」
 規模
 再利用性
 複数のバージョン
 プラットフォームと環境からの独立
 →ここは5.3節の前振りです 

は？
か？
自動化されたテストケースがほんの十数個であり、そのテストケースを扱う
人が1～2名である間は、構造化されていようと、その場しのぎに作ったもの
であろうと、どのようなテストウェアアーキテクチャでも問題は無い(5.2.1)
↓
逆に言えば、本格的にチームで自動テストを利用し始めると、
テストに関連するファイルの管理法が重要になる、ということ。

は？
か？
テストケースが10倍に増加したり、自動テストのメンテナンス
担当が変わったりすると、すぐにミスが多発するようになり、
自動テスティングを役に立たないものにしてしまう。(5.2.1)

は？
か？
再利用可能なスクリプトや、データの開発には多くの努力が
必要だが、この努力はスクリプトやデータが実際に再利用
された場合にだけ報われる。（5.2.2）
↓
テストの自動化をし続けるためには管理が大事。

は？
か？
あるソフトウェアの旧バージョンで緊急の欠陥が見つかった（中略）
持っていると思っていた適切なバージョンのテストスクリプトは、
以前テストをアップデートしたときに保存されておらず、
一部が失われていることが分かったのだ(5.2.3経験談コラム)
↓
旧バージョンを完全に放棄できる環境でなければ、
古いバージョンのテストが保存される仕組みが必要だ。

 あなたの既存のテストはすぐに拡張・再利用できる状態になって
いるか？
 何かやるとしたら、いつ始めるべきなのか？自動テスト全体に一貫性がなければ、難解で間違いが発生しやすくなる（中略）
どのテスト技術者がどのライブラリのスクリプトを探すにしても2分以上
かかるようではいけない。スクリプトが見つかったら、テスト技術者が
その使用方法を妥当な時間内で正確に判断できなければならない。(5.2.2)
↓
拡張・再利用のためには、内容をつかみやすいライブラリが必要だ。

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

 「テストスイート」は、テストが実行可能な状態のファイル群。
 「テストスイート」は、テストの目的ごとに下記のものを任意でピックアップした詰め合わせである。
▪ テストセット（テスト固有のスクリプト、データ、ユーティリティ、ドキュメント）
▪ スクリプトセット（共用）
▪ データセット（共用）
▪ ユーティリティセット（共用）
▪ ※上記4種の「セット」の総称がテストウェアセット。
 テストウェアライブラリは、全てのテストウェアセットのマスターバージョンを格納
しているリポジトリであり、テスト実行時はここからコピーしてきて実行する。
 バージョン管理は適宜行う。

 「テストスイート」は、テストが実行可能な状態のファイル群。
 「テストスイート」は、テストの目的ごとに下記のものを任意でピックアップした詰め合わせである。
▪ テストセット（テスト固有のスクリプト、データ、ユーティリティ、ドキュメント）
▪ スクリプトセット（共用）
▪ データセット（共用）
▪ ユーティリティセット（共用）
▪ ※上記４種の「セット」の総称がテストウェアセット。
 テストウェアライブラリは、全てのテストウェアセットのマスターバージョンを格納
しているリポジトリであり、テスト実行時はここからコピーしてきて実行する。
 バージョン管理は適宜行う。
5.3節は長く、しかも8.3形式（MS-DOS時代のス
タイル）のファイル名をサンプルで多用するという、
今となっては非常に分かりにくい構成になってい
ます。
そのまま読み進めるのは大変なので、ここでは
ざっくり掴んでいくことにします。

テストウェアライブラリ
(リポジトリ)
テストスイート
(実行環境)
テストセット
スクリプト
セット
データセット
ユーティリティセット
テストセットt1
スクリプト
セットs1
データセットd1
ユーティリティ
セットu1
ユーティリティ
セットu1
データセットd2
スクリプト
セットs1
コピー

 「これから示す方法は、テストウェアアーキテクチャで成功を
収めるために、多くの組織にとっての出発点として使用されて
きた。」
 「読者は、自分の状況にこの取り組み方を適応させるか、魅
力的と思えるアイデアだけでも取り上げることをお勧めす
る。」

収めるために、多くの組織にとっての出発点として使用さ
れてきた。」
力的と思えるアイデアだけでも取り上げることをお勧め
する。」

収めるために、多くの組織にとっての出発点として使用さ
れてきた。」
力的と思えるアイデアだけでも取り上げることをお勧め
する。」
ものすごくお勧めされてます！

 テストウェアには、テストで仕様および生成される全ての作成
物が含まれる。（5.1.1）
 テスト資料とテスト結果に大別される。
 テスト資料は「入力、スクリプト、
データ、仕様書などの各ドキュメン
ト、および期待結果」。
 テスト結果は「成果物と二次成果
物」。

 テスト資料は複数のテストセットの集合。
 テストセットには1つ以上のテストケースが含まれる。
 テストセットには、テストケースに関連づけられたスクリプト、
データ、期待出力、ドキュメント類を含む。

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

 しかし、「テストセット」「テストスイート」だけでは5.2節で提示さ
れた4つの課題に対応できない。
 4つの課題とは？
 規模
 再利用性
 複数のバージョン
 プラットフォームと環境からの独立

 解決するために→
 スクリプトセット（スクリプトを共有する）
 データセット（データを共有する）
 ユーティリティセット（ユーティリティを共有する）
 そしてテストセット
 これをまとめたのが「テストウェアセット」。

 テストウェアセットは、テストウェアアーキテクチャを構成する要素
である。
 テストウェアセットは、以下の種類がある。
 テストセット
 スクリプトセット
 データセット
 ユーティリティセット
 テストウェアセットとは、テストウェア作成物を、テストスクリプトや
データファイルといった種類で分けた論理的な集合（セット）である。

 テストセットは1つ以上のテストケースを定義する。
 テストセットはテストケース固有のテストウェア作成物を全て含む。内容は、
 テストスクリプト
 期待結果
 テストデータ
 テスト入力
 文書ファイル（テスト仕様書など）
 ユーティリティのソースファイル（テスト用ドライバや独自のコンバーターなど）
 ユーティリティの実行ファイル（上述のソースファイルからビルドされたもの）
 テストセット内のテストウェア作成物はそのテストケースでしか使用されない
 異なるテストセットに含まれるスクリプトを再利用したいときは、スクリプトをテス
トセットからスクリプトセットに移動する。

 スクリプトセットはテストスクリプトと、それに対するドキュメン
テーションのみを含んでいる。
 スクリプトセットに含まれる全てのスクリプトは、再利用される。
 複数のテストケースによってそのスクリプトが使われる。
 ドキュメントは必須ではないが、作成することを強く推奨。
 アプリケーションの開始・終了等のナビゲーション、ロギング
などのスクリプトが例に挙げられている。

 データセットは、データファイルとそれに対するドキュメンテー
ションのみを含んでいる。
 データセット内のファイルは、2つ以上のテストセットの異なる
テストケースで利用される。
 複数のテストケースで再利用される。

 ユーティリティセットは、2つ以上のテストセットのテストケース
で利用されるユーティリティ（スタブ、ドライバ、コンバータ、比
較ツールなど）を含む。
 また、ソースコードと実行ファイル、関連文書も含む。
 例として、日付フォーマット変換ユーティリティ、比較ツールへ
の簡単なインターフェースを提供するコマンドファイル等が挙
げられている。

 テストスイートは、テストの実行に必要なものが全て揃った環境をいう。
 選択したテストケースは全て、テストスイートから実行される。
 例で挙げられているテストスイートは、修正したScribbleアプリケーションの特定のバー
ジョンに対して実行したいテストケースを含むもの、として、
 Scribbleの全機能をカバーする幅広いテストを含むテストセット
 ログを取る共有スクリプト
 比較ツールの共有ユーティリティ
 文書管理の共有スクリプト
 Scribbleをナビゲートする共有スクリプト
 修正した箇所をテストするためのデータセット
 修正した箇所をテストするためのスクリプトセットセット
 という構成が示されている。

 テストウェアライブラリとは、すべてのテストウェアセットのマス
ターバージョンを格納しているリポジトリ。
 リポジトリの管理・利用についての説明。

 テストウェアライブラリは、全てのテストウェアセットのマスター
バージョンを格納しているリポジトリ。
 これらの資料を使うには、コピーを行う必要がある。
 ※我々感としては、チェックアウト、でいいいか？
 テストスイートを構築するときは、テストウェアライブラリから、
必要なテストセットをコピーしてくる。

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

 テストウェアの構成を管理する方法。
 難しく書いてあるが、
 テストを更新したら、テストウェアセットの新版として登録するのが1
つめ。
 テストウェア作成物を修正したら、個々のテストウェア作成物の新版
を登録するのが2つめ。
 ※我々感としては、バージョン管理システムを使うイメージで
いいか？

 複数人での作業に耐えるようにしよう。
 古いバージョンのテストケースのサブセットを2つの異なる環
境で実行するようなことが簡単に行えるならおおむね良好。
 ※テストウェアアーキテクチャの内、テスト実行用ファイル（テ
スト資料）については、ここまで。

 テスト結果には、
 実際の出力
 比較レポート
 テストツールのログ
を含むもので、テスト実行のたびに生成される。

 テストの出力は直接的な成果物。
 テスト比較レポートや、テストツールログなどは、日付や環境
情報を含むオペレーションログを含み、こちらも重要。

 テスト実行の証拠として必要なら保存する必要がある。
 そうでなければ全てのテスト結果は削除可能。

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

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

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

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

 テストスイートからテスト結果を分離し、独自のディレクトリ階
層に格納する。
 トップレベルのディレクトリには、対応するテストスイートとの
関連が分かるような名前を付けるのがベスト。

 もしランダムな名前(Mark, Barbara, Franky, Bobbyなど)をファイルに付けて
いたら、個々のスクリプトやデータファイルを探し出すことはかなり困難になる
だろう。
 本書では、テストウェアセットは
 スクリプトセット：ｓ
 データセット：ｄ
 テストセット：ｔ
 ユーティリティセット：ｕ
で始まり、アンダースコア、アプリケーション名と続き、テストケースが実行する、も
しくはテストウェアがサポートする機能やアクションを記す。
 たとえば「s_ScribbleDocument」であれば、Scribbleに関する、何らかドキュメ
ントに関連するスクリプトセットが含まれている。

 期待結果がＯＳなど環境に依存する場合がある。
 環境固有のファイルは分けて管理。「前処理」で環境固有
バージョンのファイルにスクリプトが正常にアクセスできるよう
にコピーするのもいい。
 テスト結果は環境によって分けて出力されるように。

 テストセットの中に、テストケースが多数になると管理しづらく
なる。
 テストケースを分割する方法がある。

 キーワード駆動テストケースでは、テストケースとスクリプトが一意には結びつ
かない。期待結果をスクリプトが含んでいる場合、期待結果が独立したファイ
ルで存在しない。
 →構造が一定しない。
 実装を知らなければ、たとえばデータ駆動アプローチが使われると分かってい
ても、分離されたデータファイルを見つけるのは容易ではない。
 →探す場所どころか、探すもの（スクリプト、データファイルなど）すら分かって
いないかも知れない！！
 テストウェアアーキテクチャが十分に構造化され、一貫性を備えているとしても、
テストケース自体が簡単で一貫した方法で識別できない場合には欠陥がある。
 →テストケース定義ファイルによって、どのようなテストケースがあるのか、ど
のテストウェアが使用されるのかといったことを識別できるようになる。

 実行したいテストケースを全て含んだテストスイートを持って
いるとして、どんなテストケースがあり、どう実行すればよい
か、テストツールが理解出来る必要がある。
 実現する方法はテストツールによる。
 テストツールに情報を与える部分については、自動化し、「前
処理」タスクで実行するようにしよう。
 ※5.3章はここまで。

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

 筆者の主張：「いや、やりすぎではない！」
 「テスト自動化の取り組みがうまくいっているならそのテストは拡大してい
き、コントロールしなければならないファイルの数も急増する。」
 「テストウェアのサブセットが簡単に分離できるということには、過小評価
できないメリットがある。」
 正直、今読むと「やりすぎ」感はさほど無い印象。しかし、原著刊
行当時、支援ツールなしでこれを自前で構築しろと言われたら、
「やりすぎ」と言ったかもしれません。

か？
テスト自動化の取り組みの開始時に、適切なアーキテクチャを導入しておかなければ、
あとから適切なアーキテクチャでやり直すのには、ずっと手間がかかるだろう。手に負
えない状態になってしまってからではなおさらだ。(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/1000
HDDも1/1000
ネットワークは1/100
CPUクロックは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
 Windows NT4.0 (1996~
 MacOS 8
 Linux 2.0 カーネル(1996~
メモリは1/1000
HDDも1/1000

 1999年
 Pentium III (450MHz~
 16MB~64MB時代
 10GB HDD
 Windows 98SE
 MacOS 9
 Linux 2.2
 Samba 2.0

 1999年
 Pentium III (450MHz~
 16MB~64MB時代
 10GB HDD
 Windows 98SE
 MacOS 9
 Linux 2.2
 Samba 2.0
メモリは1/1000
HDDも1/1000

 発刊後
 日本国内のADSLサービスは2000年前後から。
▪ USはむしろブロードバンドの普及は遅かった。
 Windows 2000は2000年。
 Windows XPは2001年。
 一般向け1000BASE製品が出回り始めたのは2003年。
 Mercurial、 Gitは2005年。
 原著がこうした状況で1999年に刊行された、ということを意識して
あらためて5章（特に3節）を読むと、著者の危機感が共有できる
のではないかと思います。

 テストで使用される入力、スクリプト、データ、ドキュメント。テスト実行で生
成される成果物（出力結果）、二次成果物（レポート類）。
 本格的にチームで自動テストを利用し始めると、テストに関連するファイ
ルの管理法が重要になる。
 なぜ管理する必要があるのか？
 テストの自動化をし続けるためには管理が大事。

 旧バージョンを完全に放棄できる環境でなければ、古いバージョンのテス
トが保存される仕組みが必要だ。
 あなたの既存のテストはすぐに拡張・再利用できる状態になって
いるか？
 拡張・再利用のためには、内容をつかみやすいライブラリが必要になる。
 用意をするなら、テスト自動化の取り組みの開始時点から！

 ・・・と思ったら。
 ギア本の日本語版第14章として「CI（継続的インテグ
レーション）」が書き下ろされていました！
 ※「ギアと開発とわたし_AAA2015」p.23
 TravisCIの利用について紹介されています。
Kazuhiro SUZUKI/ギアと開発とわたし p.23

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

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

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

More Related Content

What's hot

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

More from Masatoshi Itoh