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

arveltのソフトウェア技術メモ

Arvelt's software technology memo

システムテスト自動化カンファレンス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関西
自動化のパターン
1,部分的な自動化
2,システム肥大化
3,システム不適合
4,過剰な自動化

ファクトリオートメーション
信頼性が最も重要視する

システムテスト自動化の歩み
 思ったより効果がなかったとき
 テスト設計の観点
 多品種大量生産
  既存システムの強化
  新システムの展開

 自動化の前に、テストとしての認識を持つ
 不健全な数値目標は捨てる

自動化の難しさ
 従来、人がやる仕事は、すごく賢いし、情報の流れとかは見えてこない
 無意識にやってることは見えるようにすることすら難しい

成功の秘訣
 生産システムは構造化設計されている
 プロセス全体の流れが最適になるようになっている
 現場には効果計測振り返りをベースにした、たゆまぬ改善がある

無意識の意識化
テスト自動化に必要な技術の整理
テストシステムとして最適化・構造化

テスト工程の自動化を行う未来

自動化とは?
「機会にできることは機会に任せ、人間はより創造的な分野で活動を楽しむべきである」オムロン創業者



スマートフォンアプリのテスト自動化をはじめよう」長谷川 孝二 @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などで自動化する
  実行時間もかかるから、テストケースの絞込は意識する
 利益を拡大する
  テスト実行時間の短縮
   4−6習慣でリリースするのが理想
  複数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の活用
導入のポイント
 設計モデルの記述によるメリット
 自動化によるメリット
必要なスキル
 モデルベースドテストのスコープ
まとめ
 テスト対象の理解
 ミス防止
 テストエンジニアが書くしかない
 まずモデリングからしていこう


「手動テストからの移行大作戦」浦山 さつき
テストつまらない
 刺し身たんぽぽのテスト→自動化に向いてます
なぜ定着しなかったのか
 よく止まる
  バグが出そうなやつを自動化
  時間の制約があるものを自動化した
  →スコープを間違えた
 作った人にしかわからない
  →可読性が低かった
テスト自動化システムの3要素と照らし合わせる
 入力値が曖昧→テストケースのフォーマット改修
 操作内容があいまい→1通りの操作をトレース
 判定方法があいまい→どんなときに・どこが・どうであればを決める
 わかりやすいログ


「激しい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
まとめ
 テスト自動化の歴史は古いが、専門家され始めてから15年程度
 自動化はテスト技術者の必須知識。開発に関わる
 ツールを使うだけではなく、自動化ノウハウを方法論としてまとめたり、新しいツール開発を行うこと