読者です 読者をやめる 読者になる 読者になる

システムテスト自動化カンファレンス2014に参加しました

STAC2014 テスト テスト自動化

概要

ヤフーで開催されたシステムテスト自動化カンファレンス2014に参加しました。
説明では、「テスト自動化は普及のキャズムを超えたようで、
テスト対象のシステムやアーキテクチャパターンについても考えていこう。」
今回のテーマは、「ツールに依存しないテスト自動化技術の知識体系を築き上げる。」でした。
191人の予約が24時間経たない間に埋まってしまった人気の勉強会である。
今回は、この勉強会の内容を簡単に紹介します。資料が公開されているものは、
資料へリンクしているので気になったものは、そちらで。

今年のSTAC2014では現在でも深い知見を与える書籍「Software Test Automation」のSTAR有志による翻訳書「システムテスト自動化 標準ガイド (CodeZine BOOKS) 」( http://www.amazon.co.jp/dp/4798139211/ )を中心に、実践者、Webで集められている各種のアーキテクチャとパターンを紹介し、参加者の皆様と共有します。

http://connpass.com/event/

システムテスト自動化カンファレンス2014 - connpass
システムテスト自動化カンファレンス2014 - connpass

1時間で分かるSTA /鈴木 一裕さん

約450ページのボリュームの『システムテスト自動化 標準ガイド』には一体、どのようなことが書かれているのか。 目次からだけでは読み取れない本の構成と各章のポイントを概説します。 特に、第3章で解説されているテストスクリプトの「レベル」の考え方についてお話しします。

http://connpass.com/event/9618/

1時間で分かるSTA (Software Test Automation) #stac2014

1時間で分かるSTAということで、訳したSTAのPart1について、
各章の位置付けを図解で示しながら、確証の内容について説明していく形式でした。
各章では、どんな説明があったのか簡単に箇条書きにします。

1章 テスト自動化のやるべき場所

  1. 自動化は実行フェーズが向いている
  2. ビジネス面よりも技術面の方がやりやすい

2章 キャプチャーリプレイはテスト自動化ではない

準備がすぐにできて、すぐに再生可能
だけど、構造が無いので読み辛いし、ソフトウェアが変わると追随が難しい。

3章 スクリプティング技法

テストスクリプトの構造は、テスト自動化知識体系で3つに分けられる。

  1. レベル1 リニアスクリプト、構造化スクリプト
  2. レベル2 共有スクリプト、データ駆動スクリプト
  3. レベル3 キーワード駆動スクリプト、モデルベース

リニアスクリプト+分岐+反復+呼び出し
→構造化スクリプト:柔軟性、冗長性が上がる。

構造化スクリプト+機能ごとに切り離し
→共有スクリプト:再利用性が上がる。

構造化スクリプト+データを変数として切り離し
→データ駆動スクリプト:テストケースが追加しやすくなる。

構造化スクリプト+機能ごとに切り離し+データ切り離し
→キーワード駆動スクリプト:再利用性、テストケースが追加しやすくなる。

4章 自動比較

結果の比較は退屈なプロセスなので、自動化したい。

自動比較では、「対象」と「機会」と「方法」の観点で考える。
「対象」は、できるだけ多く比較するセンシティブ比較と、必要最低限比較するロバスト比較がある。
「機会」は、実行しながら行う動的比較と、実行後に行う実行後比較がある。
「方法」は、そのままを比較する単純な比較と、本質的な部分だけの複雑な比較がある。

5章 テストウェアアーキテクチャ

テスト実行可能になるための必要な作成物、テスト資料は以下

  1. テストセット:テストケースの集り
  2. スクリプトセット
  3. データセット
  4. ユーティリティセット

6章 前処理と後処理の自動化

前処理と後処理は退屈なプロセスなので、自動化したい。

  1. ファイルの生成、削除再配置
  2. テストケースの事前条件を見たしているかチェック
  3. 入力や比較のための変換

7章 アンチパターン

テストケース数は、多ければ良いのか
→ メンテコストや実行時間がかかるので草刈する

長くて複雑なものを自動化するのが良いのか
→ 解析・メンテが大変なので短いテストケースから

データセットはアプリケーション用の形式が良いのか
→特殊な形式は変更しづらいのでテキスト形式で

8章 メトリクス

メトリクスのオススメのスタータキット

テスト

重大な欠陥をテストで見つけた割合(DDP)

自動テスト

自動化に要する時間
自動スクリプト保守に要する時間
実行できるテストケース数、回数

テスト自動化のパターンと実践 /.reviewrc

テスト自動化を適用していくのは、多くのハマりどころがあり中々難しいものです。 しかし、そのハマりどころは多くの人が同様の経験している場合もあり、「パターン」としてまとめることで皆さんの役に立つと考えております。 今回は現場で多く発生するテスト自動化パターンの紹介と、フレームワークを構築することでより開発が加速したというパターン実践事例をあわせて紹介します。

http://connpass.com/event/9618/

テスト自動化パターンの話

テスト自動化のパターンと実践

テスト自動化では、みんなが共通してハマる罠がある。
それを、パタンランゲージで紹介することで、テスト自動化を定着への道標にする。
具体例をいくつか上げる。

皮をむく
  • 自動化を妨げる、動作が不安定なレイヤ・ 変化の激しいレイヤを取り除いてテストを行う
  • 安定なテストを行うことができるが、 皮を向くための作業が必要なことも
  • 剥いた皮は捨てないように!!
ピンを生やす
  • テストに使いやすいようなアクセス ポイントをアプリケーションに設けておく
  • ハードウェアの世界におけるデバッグピン
  • 便利だけれど、デバッグピンのテストを書かないように注意
皮もおいしく
  • 剥いた「皮」といってもそれも アプリケーションの一部。
  • その部分の テストは計画しておく必要がある。
自動家を作る
  • テスト自動化を専業とする役割を組織の中に作るパタン
  • テスト・実装・予算獲得などの自動化に関するお仕事を引受け、他のエンジニア と協業する
  • ゆくゆくはテスト以外も自動化していく!

テクいやつ 「Friendlyで皮をむく」

Stac2014 石川

Windows用アプリの皮剥き器であるFriendlyの設計と使い方を例にして、
皮剥きの実例の紹介であった。他のシステムでも皮剥きができるよう、
抽象的なレベルでの説明もあった。勝手な解釈では、テスト対象は、
GUIで操作する部分をAPIを叩くようにして、皮を分離しやすくという意味だと。
以下、発表時のメモ

システム自動化のボトルネックは、操作技術

自分達が作るときはAPIを使っていたのに、
テスト対象のGUIというプログラムとは別のもの。
だから難しい。

別プロセスのシステムを操作できる。

自在にテスト自動化コードを書くために
普通のプログラムと同じようにテストをしたい。

テストしづらい部分があるときは、それを操作しなくても良いように
元のプログラムを作っておくことができる。
(勝手な理解:たぶん、いろんな処理をAPI化しておけってことだと。)

剥く皮の厚さは対象に応じて。

ボトルネックの所以外はできる限り自動化する。

技術的な部分は隠蔽してシナリオテスト

システムをプログラムとして見る
操作上のボトルネックを取り除くむ
剥いた皮に注意(厚いのか薄いのか)
それぞれの特性を活かせるテスト設計にしよう

参考

エモいやつ 「自動家(オートメータ)をつくる」

「自動家(オートメータ)をつくる」-システムテスト自動化カンファレンス2014 「.reviewrc」枠発表-
「自動家(オートメータ)をつくる」-システムテスト自動化カンファレンス2014 「.reviewrc」枠発表-

現場ごとの自動化を企画・実行する人である「自動家」の話。
自動化のメリットと自動家に必要なものについて紹介している。

自動化のメリット
  1. 合理性・効率性の向上
  2. 「本懐」の仕事に近づける
  3. 楽しい(問題を技術課題に転化できる)
自動家に必要なもの
  1. 自動化術:テスト、CI/CD、インフラなど自動化に活かせる術
  2. 自動化脳:自動化できないかと考え続ける思考
  3. 自動化主義:「自動化マインド」を知り「したい」という意思を伝搬する活動

STA 第2部:GUI自動テストの保守性を高めるには /伊藤 望さん

GUIテストの自動化はスクリプトを作成して終わりではなく、その後も継続的にスクリプトを保守していく必要があります。このセッションでは、オープンソースのテストツールSelenium」を題材として、「ページオブジェクトデザインパターン」を始めとする、テストスクリプトのメンテナンス性を高める様々な技法や工夫について解説します。

http://connpass.com/event/9618/

GUI自動テストの保守性を高めるには


Seleniumを使ったテストを例にして、自動テストの保守性を保つ話です。

Seleniumを使ったテスト

  1. キャチャーリプレイ(SeleniumIDEなど)
  2. プログラミング言語(Selenium WebDriver)
  3. スクリプト生成

キャプリャーリプレイで生成されたコードはそのまま使わない

保守性を高めるために重要なこと

  1. 失敗要因を減らす
  2. 失敗調査コストを減らす
  3. 共通化する

ページオブジェクトデザインパターンを使って共通化しましょう

メリット
  1. カプセル化して読みやすくなる
  2. 目的の共通メソッドが見付けやすい

STA 第2部:状態遷移テストにおけるテスト設計と実行の自動化 /きょんさん

状態遷移を活用したJUnitスティングフレームワークの開発例について解説します。 また本書では削除された内容である、自動テストを前提としたテスト戦略の設計とビルドパイプラインにおける実装についても紹介します。

http://connpass.com/event/9618/

#STAC2014 状態遷移を活用した自動テストのテスト戦略とデプロイメントパイプライン

はじめに

ボトルネック
自動化っていっても効果のあるところをやらないと意味がない。
まずは現状を見える化する必要がある。

テストを自動化することが正しいのではなくて、開発自体をよいサイクルにすることと
リリースにかける時間を短かくするための有用な選択

テストにかける工数が開発の35パーセントってのは、どこの国でも同じ

でも、フェイルしないようなテストは書いても無駄

デプロイメントパイプライン

なぜ、デプロイメントパイプライン

テスト自動化するときに俯瞰的に見ないと局所最適してしまうかも。
それに密接にかかわるのがデプロイメントパイプライン

フィードバックの順序、実行頻度を考えるのに
デプロイメントパイプラインを考えることで効率が良くなる。

各機能を全部通るような状態遷移図を作って巡回セールスマン問題のように、
スモークテストで網羅する。
他には、幅優先探索だったり、ダイクストラ使ったり。

テスト戦略

テスト戦略は、テストケース設計に関する方針を決めたもので、
戦略、段取り、成果物、三位一体である。一度作って終わりではない。

テスト戦略は、アークテクチャ、テストスイートの設計、テストケースの設計について方針を与える。

そして自動化のための自動化戦略は、
「何を自動化するか」「テスト環境」「テスト目的」である。

参考資料


STA 第2部 : ビルドプロセスとCI /長谷川 孝二さん

システムテスト自動化 標準ガイド』で言及されている「テストウェアの管理」「テストの前処理・後処理」について、その必要性を再確認するとともに、原書から10年経った今、ビルドツールやCIを活用することで実現できることを事例を交えてお話しします

http://connpass.com/event/9618/

ビルドプロセスとCI #STAC2014

テストウェアを管理するときの問題と対策(STA5章に対応)

  1. 規模(ファイル数が多い)
  2. 再利用性(建て増し旅館)
  3. 複数バージョン(製品のバージョンとの同期)
  4. プラットフォームと環境からの独立

(動作環境ごとにテストウェアのコピーをつくのか)

→規模とバージョンはツールで解決できるので解決しましょう

規模→CIツール
バージョン→バージョン管理ツール

前処理と後処理(STA6章に対応)

前処理と後処理とは

前処理・・・生成、チェック、再配置、変換
後処理・・・削除、チェック、再配置、変換

なぜ自動化が必要なのか
  1. テスト実行環境の再現性
  2. 繰り返しテスト

実装は、コマンドファイル、専用のビルドツールで対策する

なぜCIなのか
  1. バグの作り込みを、早期に検出できる
  2. メトリクスの採取、通知(チャットやメール)などとの連動できる
ビルドパイプラインを考える

テストレベル(結合度)ごとに順番に実行することで、
フィードバックを素早くする効果がある

社内スマホアプリのビルド配信ツールによる自動化事例 /赤根 稔朗さん

社内のアプリ開発サイクル効率化の一環として取り組んでいる全社のスマホアプリビルド配信ツールを事例にあげその仕組みについて、具体的にどのように自動化を実現しているか紹介します

http://connpass.com/event/9618/

内容は、ヤフー社内で展開されたスマホアプリのビルド配信ツールの事例紹介であった。
下記の問題に関して、社内版のDeploygateを作成して問題を回避した。

コミット漏れでビルドが通らない

→ クリーンな環境でビルドできるか確認通知

PCに繋がないとインストールできない

→ 社内版DeployGateみたいなのでワイヤレスインストール

本番・テスト用、環境が増えれば倍々に

→ 環境毎の設定でビルド

全員がCI勉強するとコスト大

→ 設定はリポジトリの場所だけ

Test Automation Patterns 2014 冬コレ!/松木 晋祐さん

テスト自動化における、プロセス、アーキテクチャ、実行などのパターン集から、2014年現在の国内事情に「似合いそう」なものを厳選。解説とともにお届けいたします。明日から、街の視線を独り占めません!

http://connpass.com/event/9618/

海外と日本で提唱されているテスト自動化のパターンを紹介でした。
※ パターンとは、特定のコンテキストにおいて繰り返し起きる一般的な問題を解決する方法

プロセス:LAZY AUTOMATOR

怠け者は最高のテスト自動化エンジニアになる可能性がある

プロセス:TEST THE TESTS

テスト自体をテストする。

テストは以下の順でバグが発生しやすい。

判定系 作りはじめたころ
駆動系
報告系 マネージャや上司が仕様変更をお願いされる

最初はテスト自体に信頼がないから細かい修正などの依頼はない。
報告系に修正依頼が来れば信頼されてきたってこと。

immutable infrastructureもテストで使えば

デザイン:TEST SELECTOR

テストセレクタを実装しよう。

フォルダ管理だけでなく、タグでテストケースを管理すれば柔軟なテストができる。

例:[機能テスト]だけど負荷がかかるから[負荷テスト]に使える。など

デザイン:AUTOMATE GOOD TESTS

自動化が"効く"テスト

ROIが高くなる優れたテスト
スモーステスト/リグレッションテスト/異なる環境/複雑なテスト/
精度が要求されるテスト/精度が要求されるテスト

システムも80/20の法則になっていて、20%の機能が80%使われる。
なので、20%の良く使われる部分のテストを自動化する

デザイン:SINGLE PAGE SCRIPTS

ページオブジェクト

Webサイトのテストを利用するときに、使うラベル・ボタンごとに1オブジェクトに
テストコードと、対象を認識するコードを分離する
(副作用) IDEテストコードを書くときにサジェストされやすくなる

マネジメント:AUTOMATION ROLES

テスト自動化に関わるひとたち

実践(TABOK)

  1. チームリーダ
  2. テストエンジニア
  3. ☆リード 自動化 アーキテクト(テスト自動化アーキテクト)
  4. クロスカバレッジコーディネーター(他の組織も見て俯瞰して全体最適を考える)
  5. ☆テスト自動化エンジニア

欧米では、テストエンジニアとテスト自動化は別

テスト自動化エンジニアは、テスト経験よりも開発経験を重視する。

テスト自動化のコストは、
テストコードを書くことは10%、設計がメイン。

実行:VISUALIZE EXECUTION

いまどのテストやってますか。

欲しいFALEが置きたときに、どこが実行されているの??ってなるので
分るようにしておくと良い。

実行:COMPARE WIHTH PREVIOUS VERSION

前の版と比較する

何があっているか、何があってないかっていうのは、過去のバージョンと比較するとよい。
最初に人間が正しいバージョンを決めておく。

テスト自動化が進むと一気に分析すべきものが増えるのは良くない。
ずっと正しい結果か確認しないといけなくなる。
実行できるテストが増えて分析に時間がかかるのは非常によくないですよ。

画像系とか分りづらい。

(同じ処理をする他のソフトと比較してもいいのでは)

実行:VARIABLE DELAYS

可変遅延
スリープはイベントに基づく可変な値を設定しよう

最近だと非同期処理がどんどん増えてきている。
非同期処理のページだと開いた瞬間にはコンテンツが取得されていないことがある。

ツイッターのページは全部非同期取得しているので、
通常期待される見れるまでに時間までに見れるようにしないといけない。

こんなときは、最低何秒待てばいいのか考える。2秒も待てば十分でしょう。

非同期UIの場合はパフォーマンスのテストも同時に行うことになる。

デザイン(JP):DJR

自動テストシステムのアーキテクチャ

自動テストに含まれるべき側面

駆動(drive)、判定(judge)、報告(report)

デザイン(JP):TA_Model

自動化システムのアーキテクチャ

V字になっている。

マネジメント(JP):RED MAGICIAN

テスト設計も自動化もできる赤魔道士

日本ではいっしょくただけど、
テストケースを書く人とテスト自動化エンジニアはかなり差がある。

キーワード駆動テスト、モデルベースド・テスト、テスト設計自動化設計生成をできれば活き残りやすいのでは。

まとめ

「テスト」の役割が「保証」から拡大している
「開発インフラとしてのテスト」その実装としてのテスト自動化

自動化エンジニアは品質を背負った「環境エンジニア」

これからの超基盤技術に、みんなでワクワクしていこう!


自分まとめ

保守性の高いコードを生産する

開発コストはかかるけど、ページオブジェクトデザインパターンを使って、
キーワード駆動スクリプトで実装を検討してみる。

局所最適化でなく全体最適する

デプロイメントパイプラインを見て最適化すべき場所を学ぶ

ROIを考える

あまり細かくROIを考えてはいなかったまでも、少しの時間でメインの重要な
機能だけにテストを書いていたので方向性に安心しました。
しかし、デプロイパイプライン?という一連の流れを考えての最適化という
視点には欠けていたので別途検討する。

困ったらテスト自動化パタン言語を見るようにする

まだテスト自動化に対する取り組みがあまり行えていないので、
困ったことがあったら随時パタン言語を参照する。
テスト自動化パタン言語 オーバービュー | テスト自動化パターン言語プロジェクト

STA読まないと

STAの内容紹介の部分では、まったく考慮してなかったことについての
気づきばかりでした。これは、体系的になったSTAを熟読するしかないですね。