システムテスト自動化カンファレンス2013
http://kokucheese.com/event/index/118294/
行ったので書く。
公開されたスライドはここで見られるっぽい。
https://sites.google.com/site/testautomationresearch/event#TOC-2013-
まとめとか、感じたこと。
・システムテストの自動化で何が解決できるか考える。
・ROIを考え自動化するのがハッピーならばやる。ROI評価のコストも考慮する。
・手動テストと自動テストは主にコストの発生タイミングが変わることを考慮する。
・自動化やりすぎ自動化ハイに気をつける。なんのためのテストなのか。
・AndroidテスティングはRobotuimおすすめ。非エンジニアならMonkeyTalkおすすめ。
・受け入れテスト駆動開発は、誰にとっての受け入れかを考える。ユーザーがテストスクリプトを書けるのか問題。
・シナリオBDD系ツールのCucumber、Spec系BDD系ツールのRspec
・業務モデルからテスト詳細設計を起こすやりかたもある。
・モデルには、状態遷移モデル、論理モデル、組み合わせモデルがある。
・ツールにはAstash(有償)、CEGTest、Pictmaster等がある
・単純操作のテストは自動化に向いている。
・設計実装の段階でテストしやすいかを考慮する。一意のID、Classを振る
・HPのQTP+ALMは色々できる。それなりに高いので大規模PJでないと見合わない。
以下発表のメモ。敬称略。
「よりよいテスト自動化のためにちょっと考えてみませんか？
―スコープ、ROI、プロセスを中心に―」近江 久美子
ROIの評価
品質・コスト・スコープ
ツール、テストプロセス、人、プロダクト
・手動テストと違って、初期コストと運用コストが異なる
・ツールは外部のものか内部のものか
・自動化すると、必要なプロセス・人材が変わる
・自動化するための制約
評価
・ROI評価にこだわりすぎてしまって割高になってしまわないように、必要な部分のみ
プロセスを見直す
手動テストと自動テストで変わるものはなにか
テスト実行の例
実行するための設計・実装・セットアップ、そのための構成管理は増える
実行する、レポートを作るを手間は減る
テスト条件は事前に確定させる必要
・負荷が変わるもの
・タイミングが変わるもの
スキル、チーム
テスト自動化に必要なもの
プログラミング、テスト、プロジェクト管理、
・自動化されたテスト実行のバグの分析
結果で分類
テスト対象のバグ
テストのバグ
原因による分類
プログラムの問題
環境の問題
スクリプトの問題
テストツールの問題
「事例から見るテスト自動化のポイント」TABOK関西
自動化のパターン
１，部分的な自動化
２，システム肥大化
３，システム不適合
４，過剰な自動化
ファクトリオートメーション
信頼性が最も重要視する
システムテスト自動化の歩み
思ったより効果がなかったとき
テスト設計の観点
多品種大量生産
既存システムの強化
新システムの展開
自動化の前に、テストとしての認識を持つ
不健全な数値目標は捨てる
自動化の難しさ
従来、人がやる仕事は、すごく賢いし、情報の流れとかは見えてこない
無意識にやってることは見えるようにすることすら難しい
成功の秘訣
生産システムは構造化設計されている
プロセス全体の流れが最適になるようになっている
現場には効果計測振り返りをベースにした、たゆまぬ改善がある
無意識の意識化
テスト自動化に必要な技術の整理
テストシステムとして最適化・構造化
テスト工程の自動化を行う未来
自動化とは？
「機会にできることは機会に任せ、人間はより創造的な分野で活動を楽しむべきである」オムロン創業者
「スマートフォンアプリのテスト自動化をはじめよう」長谷川 孝二 @nowsprinting
http://www.slideshare.net/nowsprinting/starcon2013-mobile-testautomationkeynote6
テスト自動化の現状
ユニットテスト
Ios
Xcode標準にOCUUnit
android
AndroidTestingFramework
UI操作のRobotium
Mockito、EasyMock、Robolectric
システムテスト
理想の高い利益
正しい画面表示
OS機種依存バグを検出できる
投資
ツール
スクリプト
保守
データ、スタブサーバー
現実的な利益
テスト実行時間の短縮
複数のOSバージョンで実行できる
テストの目的
血管を摘出
品質レベルが十分か
意思決定のための情報
欠陥の作り込み
欲張らないROI
頑張らないテストスクリプト
乱数起因のテストはユニットテストでモックで頑張る方が楽
レイアウト崩れを頑張ろうとするとつらい
機種依存の問題を狙ってテストしようとしない
頑張らない事例
UIAlertView
UIPickerView
UITableView
AndroidのDrawRect
Viewのヒエラルキーが多い時に、ソフトウェアキーボードが出るとStackOverFlowError
抑えたいポイント
すべての画面遷移、ハッピーケースだけじゃなくエラーケースも含める
CIにのせたときとかのSSの比較はImageMagickなどで自動化する
実行時間もかかるから、テストケースの絞込は意識する
利益を拡大する
テスト実行時間の短縮
４−６習慣でリリースするのが理想
複数OSバージョンでの実行
テスト実行環境を増やす
手動ではできないこと
ロードテスト
メモリリーク
低メモリ
コンカレンシーテスト
再現率低いテスト
Android MonkeyRunner
Androdi Robotuium
Seliumライクにかける
端末回転、スクリーンショットとかかとれる
UiautoMator
Robotuiumuより楽になってる
Espresso
Android
IOS
UIAutomation
Xcode同梱
Appium
両刀
スクリプトとでかける
Calabash
CucumberのテストをIos/Androidで実行できる
MonkeyTalk
専用のIDEでテスト作れる。スクリプト詳しくなくてもいける
選定のポイント
スクリプトを書けるかどうか
Ios/androidでテストを共有したいか
何が実行できるか、の差は縮まりつつある
Genymotion（早いエミュレーター
MonkeyTalkデモ
TestFlight
AppKitBoxRemoteTestKit
まとめ
欲張らない
頑張らない
MonkeyTalkではWebViewのテストもできる
「ATDD実践入門」きょん@Kyon_mm
テストなくしたいからテスト勉強してる
ATDD→受け入れテスト駆動開発
TDD
KentBeck
レッド、グリーン、リファクタリング
UncleBob
失敗するテストを書く、失敗するなら追加してはいけない、成功させるプロダクトがあるならプロダクト
T＿wada
開発の健全さを保つプラクティス
レッド、グリーン、リファクタリングを回す
Kyon−mm
開発者支援フレームワーク
開発者の意図を確認する、開発者が心地よいコードを書く
Fit/Fitness
BDD
常にユーザーの立場でテストを実装する
実装のテストをしてしまうのはよくない
シナリオBDD
Cucunber
SpecBDD
Rspec
Scrum
Readyの定義、Doneの定義
SpecificationByExsample
仕様を例示する生きたドキュメント
ATDDはハッピーケースに限定するわけじゃない
目的
ユーザーと共通の一枚絵のようなものを得ること
十分に対象のソフトウェアの仕様を把握できること
その仕様が満たせているかどうかがいつでもわかること
Fitness
シナリオBDD
Cucumber
SpecFlow
Spec
Rspec
Spock
Groovyによって実装されたフレームワーク
アンチパターン
開発者がAcceptanceTestを書くことはいけない
補助者する人がいない
理想と現実
DDDとATDD
ATDDはユビキタス言語（お客様がわかる言い方）を得られる機会にはなるが、ドメインモデリングには適さない
Role
開発者が行うATDDはSTDDにしかならない。Userが理解できる言葉でのみ実装されたものこそである、しかしほんとうにそれはできるか？
まとめ
誰にとてのAccptanceTestなのか
XDDはツールではなく、プロセスと態度で決まるもの
コンテキストに合わせて取り組まなくてはいけない。現状ではXPを実践できるチームの成果物でしかない
ATDDはやらないよりましだが、間違うと自分たちの生産性を下げる
開発者向けの範囲でより広いTDDを考える GOOS By Stev
テストケースの設計を考える方法 ソフトウェアテスト技法
最高のATDDをやりたい人 つくりましょう
「モデルベースドテスト入門ーテスト詳細設計」 朱峰 錦司(あけみねきんじ)＠kjstylepp
http://www.slideshare.net/kjstylepp/ss-28784815
内容
テスト詳細設計お自動化できる
設計モデルから作ります
デモします
テストとは
JSTQBでの定義
テスト分析と設計
テスト実装と実行
終了基準の評価とレポート
Test.SSFでの定義
テストの要求分析
テストアーキテクチャ設計
その先は同じ
テスト詳細設計
方針にもとづいてテスト対象の仕様からテストケースを作る作業
方針や仕様が決まっていれば自動でつくれるんじゃね！？
モデル
テスト対象の振る舞いや正スツを到底の観点抽象化して表現したもの
ひとつのモデルで全ての仕様を表現することはできない
・状態遷移モデル
・論理モデル
・組み合わせモデル
・フローモデル
・台数モデル
状態遷移モデル
状態の変化に着目してシステムの振る舞いをモデリング
論理モデル
構成要素間の論理関係に着もk空いてロジックをモデリング
組み合わせモデル
構成要素のバリエーションや制約に着もk水、構成要素間の組み合わせ元をモデリング
注意点
特性に応じて適切なモデリング手法を選択
モデルベースドテスト
モデルを活用してテスト成果物を作成（ブラックボックステストになる
モデル→抽象化されたテスト→実行可能なテスト
テストの抽象表現
テストモデリングのための規格
UML Testing Profile
Testing and ContorolNotation version3
状態遷移列にによるテストシナリオ
論理パターンによるテストシナリオ
組み合わせパターンによるテスト条件
注意点
テストパターンが多くなる
詳細化が必要
モデルベースドテストの適用例とツールデモ
状態遷移テスト
Astash品質スイートの活用（有償
論理モデル
デシジョンテーブルテスト
CEGTestの活用
組み合わせテスト
Pictmasterの活用
導入のポイント
設計モデルの記述によるメリット
自動化によるメリット
必要なスキル
モデルベースドテストのスコープ
まとめ
テスト対象の理解
ミス防止
テストエンジニアが書くしかない
まずモデリングからしていこう
「手動テストからの移行大作戦」浦山 さつき
テストつまらない
刺し身たんぽぽのテスト→自動化に向いてます
なぜ定着しなかったのか
よく止まる
バグが出そうなやつを自動化
時間の制約があるものを自動化した
→スコープを間違えた
作った人にしかわからない
→可読性が低かった
テスト自動化システムの３要素と照らし合わせる
入力値が曖昧→テストケースのフォーマット改修
操作内容があいまい→１通りの操作をトレース
判定方法があいまい→どんなときに・どこが・どうであればを決める
わかりやすいログ
「激しいUI変更との戦い」玉川 紘子
http://www.slideshare.net/hirokotamagawa/20131201-lt
自動テストの保守性を高めるにはどうするか
なぜ保守が大変なのか
テストしづらい製品コードは指摘する
要素にIDClassがない
純粋なテスト対象を切り分けられない
テストケースのもとをメンテナンスする
テスト対処のアプリケーションと会話するための基本動作を定義する
スクリプトの元をメンテナンスできるようにする
「テスト自動化の事例紹介による有償ツール選択のポイント」藤井 暢人
投資したら取り返す！
HP所属
短期間でROIのを得られた事例
ツール
QTP；GUIのテスト実行の自動化
ALM；QTPスクリプトの管理、レポート
ポイント
QTPスクリプトのメンテナンス
QTP+ALMの連携
デモ
がんばるところを間違えずに自動化しよう
テスト自動化の目的を実現できる投資を見極める
有償ツールの昨日は、ツール連携、サービスも確認しよう
「組み込み開発での実機テストの自動化」井芹 洋輝
http://www.slideshare.net/goyoki/ss-28809804
組み込み開発の制約
リアルタイム性
物理的なインターフェース
実行環境が変わる
内部観測井の低さ
テストの責務を分散する
テスト自動化の負荷を分散する
「テスト自動化のこれまでとこれから」辰巳 敬三
http://www.slideshare.net/Bugler/2013-28786846
テスト自動化のこれまで
テスト自動化の今
テスト自動化のこれから
Seleniumの名前の由来
Selenium、セレン
水銀中毒 MercuryPoisoning
JasonHuggins MerecuryPoisonを治療するSelenium
まとめ
テスト自動化の歴史は古いが、専門家され始めてから１５年程度
自動化はテスト技術者の必須知識。開発に関わる
ツールを使うだけではなく、自動化ノウハウを方法論としてまとめたり、新しいツール開発を行うこと
