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

2015年7月4日開催の、システムテスト自動化標準ガイド（ギア本）の読書会での発表資料です。
５章を担当しました。

Transcript

1. 「システムテスト自動化標準ガイド」 第5章 伊藤雅俊（ @masatoshiitoh ） 2015/7/4
2.  日本メディカルネットコミュニケーションズ(株)勤務  本発表は、所属する企業・団t（ｒｙ  サーバー側メインのおおむね何でも屋  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
3.  1990年代 ▪ クライアントサーバー系システム ▪ テスト方法は、手動操作による確認 ▪ テスト項目は、画面とシナリオから作成。お客様側から指定あり。 ▪ GUIテストツールのMicrosoft Testの採用を検討するも、社がクライアン ト部分の開発を担当しなかったので推進できず。 ▪ 内部ライブラリはソースコード目視チェック ▪ テストコードは特に作らず、実行ファイルごとに結果を目視確認。
4.  2000年代前半 ▪ 回線速度測定サービスの企画・開発 ▪ コアプロトコル発案・設計 、v1.0クライアントの開 発を担当。 ▪ テスト方法は、手動操作による確認。 ▪ テスト項目は特に定めず。 ▪ 回線種別ごとに、このぐらいの速度が出るだろう、 という想定で、そこを大きく逸脱した値が出ると 「不具合」として修正を実施。 →びっくりするほ どアドホック ▪ http://www.itmedia.co.jp/broadband/0307/09/lp17.html
5.  2000年代後半 ▪ ネットリサーチとポイントサービスの連携システムの開発 ▪ テスト方法は、手動操作による確認。 ▪ テスト実施数、エラー件数、修正件数などのカウントが入った、統一書式の報告Excelが提供された ▪ テスト項目のリストアップや、手順書作成はExcel方眼紙。  2010年代前半 ▪ ウェブアプリのポイント管理システムの開発 ▪ テスト方法は、テストスクリプトによる一括テスト。 ▪ モックとテストコードを作成。実行は手動。 ▪ スクリプトにはパラメータをハードコード。 ▪ 結合後のテストは手動操作による確認。 ▪ 小規模チームによるゲームアプリの開発 ▪ テスト方法は、手動操作による確認。 ▪ テスト項目は、画面遷移とディレクター指示。 ▪ 開発拠点が遠隔のため、バグ報告はGoogle spreadsheet ▪ 新バージョンがビルドされるたび、手作業でチェック
6.  業務でのシステムテストの自動化経験は「基本的にあり ません」  自動化を推進している方の実践情報をお聞きしたい！  というわけで、のちほど「お客様とやりとりするテスト 関連の資料はどのように整理していますか？」というお 題でポストイットアンケートやります。
7.  ５章 テストウェアアーキテクチャ ▪ 5.1 テストウェアアーキテクチャとは何か ▪ 5.2 カギとなる４つの課題 ▪ 規模 ▪ 再利用性 ▪ 複数のバージョン ▪ プラットフォームと環境からの独立 ▪ 5.3 取り組み方 ▪ 序文 ▪ 基本概念 ▪ テストウェアセット ▪ テストスイート ▪ テストウェアライブラリ ▪ 構成管理 ▪ テスト結果 ▪ 物理的構造 ▪ テストツールとのインターフェース ▪ 5.4 これはやりすぎだろうか？ ▪ 5.5 まとめ
8.  ご紹介したい2つのスライドが。  http://www.slideshare.net/k_suz uki/aaa2015-49898261  http://www.slideshare.net/k_suz uki/1sta-stac2014  ギア本翻訳の鈴木一裕さん！
9. Kazuhiro SUZUKI/ギアと開発とわたし p.24
10. Kazuhiro SUZUKI/ 60 minutes STA (p.39)
11. Kazuhiro SUZUKI/ 60 minutes STA (p.42)
12. Kazuhiro SUZUKI/ 60 minutes STA (p.43)
13.  ギア本の全体像をつかむのに、とてもいいスライド。 「システムテスト自動化標準ガイド」の途中で迷ったと きは、ぜひ俯瞰図として参照されるといいでしょう ☺  http://www.slideshare.net/k_suzuki/aaa2015-49898261  http://www.slideshare.net/k_suzuki/1sta-stac2014
14.  ここからは質疑応答の時間です
15.  ここからは質疑応答の時間です ・・・？
16.  ・・・というわけには。
17.  テストウェアアーキテクチャで管 理される「テストウェア作成物」は、 以下のものがある。  テスト資料 ▪ 「入力」 「スクリプト」 「データ」 「ドキュメント」 「期待結果」  テスト結果 ▪ 生成物 ▪ 「実際の出力」 ▪ 二次生成物 ▪ 「ログ」「ステータス」「比較レポート」
18.  「カギとなる4つの課題」 ▪ 規模 ▪ 再利用性 ▪ 複数のバージョン ▪ プラットフォームと環境からの独立  →ここは5.3節の前振りです ☺
19. ▪ 5.3 取り組み方 ▪ 序文 ▪ 基本概念 ▪ テストウェアセット ▪ テストスイート ▪ テストウェアライブラリ ▪ 構成管理 ▪ テスト結果 ▪ 物理的構造 ▪ テストツールとのインターフェース
20.  「テストスイート」は、テストが実行可能な状態のファイル群。 ▪ 「テストスイート」は、テストの目的ごとに下記のものを任意でピックアップした詰め 合わせである。 ▪ テストセット（テスト固有のスクリプト、データ、ユーティリティ、ドキュメント） ▪ スクリプトセット（共用） ▪ データセット（共用） ▪ ユーティリティセット（共用） ▪ ※上記４種の「セット」の総称がテストウェアセット。  テストウェアライブラリは、全てのテストウェアセットのマスターバージョンを格 納しているリポジトリであり、テスト実行時はここからコピーしてきて実行する。  バージョン管理は適宜行う。
21.  「テストスイート」は、テストが実行可能な状態のファイル群。 ▪ 「テストスイート」は、テストの目的ごとに下記のものを任意でピックアップした詰め 合わせである。 ▪ テストセット（テスト固有のスクリプト、データ、ユーティリティ、ドキュメント） ▪ スクリプトセット（共用） ▪ データセット（共用） ▪ ユーティリティセット（共用） ▪ ※上記４種の「セット」の総称がテストウェアセット。  テストウェアライブラリは、全てのテストウェアセットのマスターバージョンを格 納しているリポジトリであり、テスト実行時はここからコピーしてきて実行する。  バージョン管理は適宜行う。 5.3節は長く、しかも8.3形式（MS-DOS時代の スタイル）のファイル名をサンプルで多用す るという、今となっては非常に分かりにくい 構成になっています。 そのまま読み進めるのは大変なので、ここで はざっくり掴んでいくことにします。
22. テストウェアライブラリ (リポジトリ) テストスイート (実行環境) テストセット スクリプト セット データセット ユーティリティセッ ト テストセットt1 スクリプト セットs1 データセットd1 ユーティリティ セットu1 ユーティリティ セットu1 データセットd2 スクリプト セットs1 テストセットt2 テストセットt1 コピー
23.  「これから示す方法は、テストウェアアーキテクチャで 成功を収めるために、多くの組織にとっての出発点とし て使用されてきた。」  「読者は、自分の状況にこの取り組み方を適応させるか、 魅力的と思えるアイデアだけでも取り上げることをお勧 めする。」
24.  「これから示す方法は、テストウェアアーキテクチャで 成功を収めるために、多くの組織にとっての出発点として使 用されてきた。」  「読者は、自分の状況にこの取り組み方を適応させるか、 魅力的と思えるアイデアだけでも取り上げることをお勧めす る。」
25.  「これから示す方法は、テストウェアアーキテクチャで 成功を収めるために、多くの組織にとっての出発点として使 用されてきた。」  「読者は、自分の状況にこの取り組み方を適応させるか、 魅力的と思えるアイデアだけでも取り上げることをお勧めす る。」 ものすごくオススメされてます
26.  テストウェアには、テストで仕様および生成される全て の作成物が含まれる。（5.1.1） ▪ テスト資料とテスト結果に大別される。 ▪ テスト資料は「入力、スクリプト、 データ、仕様書などの各ドキュメン ト、および期待結果」 ▪ テスト結果は「成果物と二次成果 物」
27.  テスト資料は複数のテストセットの集合  テストセットには1つ以上のテストケースが含まれる  テストセットには、テストケースに関連づけられたスク リプト、データ、期待出力、ドキュメント類を含む
28.  2つ以上のテストセットを目的によって等まとめたものが 「テストスイート」  テストスイートは、テストケースの集合体
29.  しかし、「テストセット」「テストスイート」だけでは 5.2節で提示された4つの課題に対応できない  4つの課題とは？ ▪ 規模 ▪ 再利用性 ▪ 複数のバージョン ▪ プラットフォームと環境からの独立
30.  解決するために→ ▪ スクリプトセット（スクリプトを共有する） ▪ データセット（データを共有する） ▪ ユーティリティセット（ユーティリティを共有する） ▪ そしてテストセット  これをまとめたのが「テストウェアセット」
31.  テストウェアセットは、テストウェアアーキテクチャを構成する要 素である。  テストウェアセットは、以下の種類がある。 ▪ テストセット ▪ スクリプトセット ▪ データセット ▪ ユーティリティセット  テストウェアセットとは、テストウェア作成物を、テストスクリプ トやデータファイルといった種類で分けた論理的な集合（セット） である。
32.  テストセットは1つ以上のテストケースを定義する。  テストセットはテストケース固有のテストウェア作成物を全て含む。内容は ▪ テストスクリプト ▪ 期待結果 ▪ テストデータ ▪ テスト入力 ▪ 文書ファイル（テスト仕様書など） ▪ ユーティリティのソースファイル（テスト用ドライバや独自のコンバーターなど） ▪ ユーティリティの実行ファイル（上述のソースファイルからビルドされたもの）  テストセット内のテストウェア作成物はそのテストケースでしか使用されない  異なるテストセットに含まれるスクリプトを再利用したいときは、スクリプトをテ ストセットからスクリプトセットに移動する。
33.  スクリプトセットはテストスクリプトと、それに対するド キュメンテーションのみを含んでいる。  スクリプトセットに含まれる全てのスクリプトは、再利用さ れる。  複数のテストケースによってそのスクリプトが使われる。  ドキュメントは必須ではないが、作成することを強く推奨  アプリケーションの開始・終了等のナビゲーション、ロギン グなどのスクリプトが例に挙げられている。
34.  データセットは、データファイルとそれに対するドキュ メンテーションのみを含んでいる。  データセット内のファイルは、2つ以上のテストセットの 異なるテストケースで利用される。  複数のテストケースで再利用される。
35.  ユーティリティセットは、2つ以上のテストセットのテス トケースで利用されるユーティリティ（スタブ、ドライ バ、コンバータ、比較ツールなど）を含む。  また、ソースコードと実行ファイル、関連文書も含む。  例として、日付フォーマット変換ユーティリティ、比較 ツールへの簡単なインターフェースを提供するコマンド ファイル等が挙げられている。
36.  テストスイートは、テストの実行に必要なものが全て揃った環境をいう。  選択したテストケースは全て、テストスイートから実行される。  例で挙げられているテストスイートは、修正したScribbleアプリケーションの特定 のバージョンに対して実行したいテストケースを含むもの、として、 ▪ Scribbleの全機能をカバーする幅広いテストを含むテストセット ▪ ログを取る共有スクリプト ▪ 比較ツールの共有ユーティリティ ▪ 文書管理の共有スクリプト ▪ Scribbleをナビゲートする共有スクリプト ▪ 修正した箇所をテストするためのデータセット ▪ 修正した箇所をテストするためのスクリプトセットセット  という構成が示されている。
37.  テストウェアライブラリとは、すべてのテストウェア セットのマスターバージョンを格納しているリポジトリ。  リポジトリの管理・利用についての説明。
38.  テストウェアライブラリは、全てのテストウェアセット のマスターバージョンを格納しているリポジトリ  これらの資料を使うには、コピーを行う必要がある。  ※我々感としては、チェックアウト、でいいいか？  テストスイートを構築するときは、テストウェアライブ ラリから、必要なテストセットをコピーしてくる。
39.  テストウェアライブラリからテストウェアセットをコ ピーする作業は、できるだけ簡単であることが重要。 ▪ 短時間でおこなえる。 ▪ 失敗の余地がない（不完全なコピーが起きないように）  コピー失敗でテストが失敗したりしないように。
40.  テストウェアの構成を管理する方法  難しく書いてあるが、 ▪ テストを更新したら、テストウェアセットの新版として登録す るのが１つめ ▪ テストウェア作成物を修正したら、個々のテストウェア作成物 の新版を登録するのが2つめ  ※我々感としては、バージョン管理システムを使うイ メージでいいか？
41.  複数人での作業に耐えるようにしよう  古いバージョンのテストケースのサブセットを2つの異な る環境で実行するようなことが簡単に行えるならおおむ ね良好  ※テストウェアアーキテクチャの内、テスト実行用ファ イル（テスト資料）については、ここまで。
42.  テスト結果には、 ▪ 実際の出力 ▪ 比較レポート ▪ テストツールのログ  を含むもので、テスト実行のたびに生成される。
43.  テストの出力は直接的な成果物  テスト比較レポートや、テストツールログなどは、日付 や環境情報を含むオペレーションログを含み、こちらも 重要。
44.  テスト実行の証拠として必要なら保存する必要がある  そうでなければ全てのテスト結果は削除可能
45.  テストスイートに含まれるテスト結果一式は、テスト セットごとにグループ化できる。
46.  テストウェアセットと、テストスイートの構造を実装す る場合は、ファイルシステムの階層構造を利用すると良 い
47.  テストウェアセットのディレクトリ構造は厳密に守らな くてはならない。
48.  テストスイートもまたディレクトリ階層  全てのテストウェアセットディレクトリが、テストス イート内の1つのディレクトリに配置される
49.  テストスイートからテスト結果を分離し、独自のディレ クトリ階層に格納する  トップレベルのディレクトリには、対応するテストス イートとの関連が分かるような名前を付けるのがベスト。
50.  もしランダムな名前(Mark, Barbara, Franky, Bobbyなど)をファイルに付けていたら、 個々のスクリプトやデータファイルを探し出すことはかなり困難になるだろう。  本書では、  テストウェアセットは  スクリプトセット：ｓ  データセット：ｄ  テストセット：ｔ  ユーティリティセット：ｕ  で始まり、アンダースコア、アプリケーション名と続き、テストケースが実行する、 もしくはテストウェアがサポートする機能やアクションを記す。  たとえば「s_ScribbleDocument」であれば、Scribbleに関する、何らかドキュメント に関連するスクリプトセットが含まれている。
51.  期待結果がＯＳなど環境に依存する場合がある。  環境固有のファイルは分けて管理。「前処理」で環境固 有バージョンのファイルにスクリプトが正常にアクセス できるようにコピーするのもいい。  テスト結果は環境によって分けて出力されるように。
52.  テストセットの中に、テストケースが多数になると管理 しづらくなる  テストケースを分割する方法がある。
53.  キーワード駆動テストケースでは、テストケースとスクリプトが一意には結びつか ない。期待結果をスクリプトが含んでいる場合、期待結果が独立したファイルで存 在しない。  →構造が一定しない。  実装を知らなければ、たとえばデータ駆動アプローチが使われると分かっていても、 分離されたデータファイルを見つけるのは容易ではない。  →探す場所どころか、探すもの（スクリプト、データファイルなど）すら分かって いないかも知れない！！  テストウェアアーキテクチャが十分に構造化され、一貫性を備えているとしても、 テストケース自体が簡単で一貫した方法で識別できない場合には欠陥がある  →テストケース定義ファイルによって、どのようなテストケースがあるのか、どの テストウェアが使用されるのかといったことを識別できるようになる。
54.  実行したいテストケースを全て含んだテストスイートを 持っているとして、どんなテストケースがあり、どう実 行すればよいか、テストツールが理解出来る必要がある。  実現する方法はテストツールによる。  テストツールに情報を与える部分については、自動化し、 「前処理」タスクで実行するようにしよう。  ※5.3章はここまで
55.  「テストスイート」は、テストが実行可能な状態のファイル群。 ▪ 「テストスイート」は、テストの目的ごとに下記のものを任意でピックアップした詰め 合わせである。 ▪ テストセット（テスト固有のスクリプト、データ、ユーティリティ、ドキュメント） ▪ スクリプトセット（共用） ▪ データセット（共用） ▪ ユーティリティセット（共用） ▪ ※上記４種の「セット」の総称がテストウェアセット。  テストウェアライブラリは、全てのテストウェアセットのマスターバージョンを格 納しているリポジトリであり、テスト実行時はここからコピーしてきて実行する。  バージョン管理は適宜行う。
56.  これはやりすぎだろうか？
57.  筆者の主張：「いや、やりすぎではない！」 ▪ 「テスト自動化の取り組みがうまくいっているならそのテストは拡 大していき、コントロールしなければならないファイルの数も急増 する。」 ▪ 「テストウェアのサブセットが簡単に分離できるということには、 過小評価できないメリットがある。」  正直、今読むと「やりすぎ」感はさほど無い印象。しかし、 原著刊行当時、支援ツールなしでこれを自前で構築しろと言 われたら、「やりすぎ」と言ったかもしれません。
58.  1999年刊行の本なので、そのちょっと前から見てみましょう。  スペック等はコンシューマーPCのものです。  1995年 ▪ Pentium Pro (150MHz ~ ▪ メイン4MB ~ 8MB時代 ▪ 1GB HDD ▪ 10BASE2/-T時代 ▪ Windows95 ▪ MacOS 7.5 ▪ Linux 1.0カーネル (Redhat/Suse)
59.  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
60.  1997年 ▪ Pentium II (233MHz ~ ▪ 8MB ~ 32MB時代 ▪ 4GB HDD ▪ 100BASE-TX時代 ▪ Windows NT4.0 (1996~ ▪ MacOS 8 ▪ Linux 2.0 カーネル(1996~
61.  1997年 ▪ Pentium II (233MHz ~ ▪ 8MB ~ 32MB時代 ▪ 4GB HDD ▪ 100BASE-TX時代 ▪ Windows NT4.0 (1996~ ▪ MacOS 8 ▪ Linux 2.0 カーネル(1996~ メモリは1/1000 HDDも1/1000 ネットワークは1/10 CPUクロックは1/10
62.  1999年 ▪ Pentium III (450MHz~ ▪ 16MB~64MB時代 ▪ 10GB HDD ▪ 100BASE-TX時代 ▪ Windows 98SE ▪ MacOS 9 ▪ Linux 2.2 ▪ Samba 2.0
63.  1999年 ▪ Pentium III (450MHz~ ▪ 16MB~64MB時代 ▪ 10GB HDD ▪ 100BASE-TX時代 ▪ Windows 98SE ▪ MacOS 9 ▪ Linux 2.2 ▪ Samba 2.0 メモリは1/1000 HDDも1/1000 ネットワークは1/10 CPUクロックは1/5
64.  発刊後 ▪ 日本国内のADSLサービスは2000年前後から ▪ USはむしろブロードバンドの普及は遅かった。 ▪ Windows 2000は2000年 ▪ Windows XPは2001年 ▪ 一般向け1000BASE製品が出回り始めたのは2003年 ▪ Mercurial、 Gitは2005年  原著がこうした状況で1999年に刊行された、ということを意 識してあらためて5章（特に3節）を読むと、著者の危機感が 共有できるのではないかと思います。
65.  テストに関連するファイルには何があるか？  あなたはテストに関連するファイルをどう管理しているか？  なぜ管理する必要があるのか？ ▪ （ディレクトリにまとめておけばいいのでは？）  あなたのプロジェクトで古いバージョンのテストは必要か？  あなたの既存のテストはすぐに拡張・再利用できる状態になってい るか？  何かやるとしたら、いつ始めるべきなのか？
66.  テストに関連するファイルには何があるか？  あなたはテストに関連するファイルをどう管理しているか？  なぜ管理する必要があるのか？ ▪ テスト自動化は、すぐに「物量」との戦いになる！  あなたのプロジェクトで古いバージョンのテストは必要か？  あなたの既存のテストはすぐに拡張・再利用できる状態になっている か？  何かやるとしたら、いつ始めるべきなのか？ ▪ 用意をするなら最初から！
67.  ・・・
68.  ・・・と思ったら。  ギア本の日本語版第14章として「CI（継続的インテ グレーション）」が書き下ろされていました！  ※「ギアと開発とわたし_AAA2015」p.23より  TravisCIの利用について紹介されています。 Kazuhiro SUZUKI/ギアと開発とわたし p.23
69.  おもに、お客様ありの開発をしている方への質問となりますが・・・  テスト計画書やテスト項目、手順書、バグ報告書など、テスト前後でお客様とやりとりす るファイルが多数あり、しかもバージョン管理が困難な運用スタイル（日付付きファイル 名のExcelシート等）なことが多いのではないでしょうか？ ▪ テスト項目の管理はExcel？ Google spreadsheet？ ▪ バグ管理はExcel？ BTS？ ▪ テストの進捗を、オンラインでBTS等でお客様に見てもらうかたちにできてる方、いますか？ ▪ テスト管理ツールの出力でいいよ、とお客様を納得させてるかた、いますか？ ▪ Excel職人としての工数が大きくて苦労している方、いますか？  アンケート： ▪ テストの管理（お客様とのテスト項目の共有、進捗、レポート等）のツールは？ ▪ そのツールで満足している点、不満な点は？
70.  そして、アンケートへのご協力、ありがとうございました。