Embed Size (px)
Citation preview
第1回 「システムテスト自動化 標準ガイド」
読書会 第1章 テスト自動化のコンテキスト
2015/04/18
ふじさわゆうき
2
自己紹介
3
自己紹介名前ふじさわゆうき現在の仕事部署全体を技術的に底上げするチームに所属テスト自動化、FindBugsルール化、標準開発環境の提供、ミドルウェア検証、OutOfMemory調査&解決、社内WIKI導入&運用など幅広く担当経歴高校~大学~社会人とずっとプログラム書いてます株式投資アルゴリズム(Java)のコンテストで優秀アルゴリズム賞を受賞したことがあります
日本Geb研究会の主催もやっています
4
勤務先の会社は
テスト自動化に
取り組んでいる?
5
テスト自動化に
携わっている?
6
自動テストが
発展していけば
手動テストは必要なくなる?
7
1.2 テスティングと
テスト自動化の違い
8
テスティングとテスト自動化の違い
テスティング良いテストを設計すること。「効果的」、「典型的」、「経済的」、「発展的」の４つのバランスをとりながらテストを作成できるスキルが求められるテスト自動化テスト実行と比較結果を自動化すること。経済性と発展性のみ向上させる。自動化によって良いテストは作成できない
9
良いテストとは？「効果的」であること多くの欠陥を検出できる「典型的」であること正常系のテストケースでは、より多くの条件でassertしている「経済的」であること実行、分析、デバッグが簡単に行える「発展的」であることソフトウェアの変更に少ない工数で対応できる
10
良いテストとは？
「システムテスト自動化 標準ガイド」（テスト自動化研究会）より抜粋
11
テスト自動化において最も重要なこと
高いテスティングスキルをもったテスト担当者が良いテストを作成する
テストオートメーターが、経済性、発展性の優れた形で良いテストを自動化する
12
1.3 Vモデル
13
実装前からテスト設計を開始することが重要テスト実行段階で欠陥を発見するよりも、設計段階のほうが、欠陥を修正するコストが安く済む
受け入れテストケース設計要件の欠陥をみつけるシステムテストケース設計機能仕様の欠陥を見つける統合テストケース設計ソフトウェア設計の欠陥を見つけるユニットテストケース設計コードの欠陥をみつける
14
早期にテスト設計を行うVモデル
「システムテスト自動化 標準ガイド」（テスト自動化研究会）より抜粋
15
要求仕様~設計の
段階でテストを作成
している?
16
1.4 開発ライフサイクル全体
のテスティング活動を助ける
ツール
17
テスティング活動を助けるツールテスト管理ツールテスト設計ツール静的解析ツールカバレッジツール動的解析ツールテスト実行と比較ツール性能テストツール
18
テスト管理ツールとは
http://gihyo.jp/dev/serial/01/testlink/0001より参照
19
テスト管理ツールTestLink
オープンソースで提供されているテスト管理ツールhttp://www38.atwiki.jp/testlink/pages/1.html
CAT(TCM)
ソフトウェアテスト専門の会社であるSHIFT社のテスト管理ツール。SaaSで提供しているhttp://softwaretest.jp/service/saas.html
20
何らかのテスト管理ツール
を導入している?
21
テスト設計ツールastah* professional
ステートマシン図を元に状態遷移パスを表示し、テストケースを作成することができるhttp://urx.nu/j9Et
PICTMaster
ソフトウェアの組み合わせテストのテストケースをExcel上で自動生成することができるhttp://urx.nu/j9EL
CEGTest
テスト技法「原因結果グラフ技法」を、ブラウザ/JavaScriptベースで直感的に実践することができhttp://urx.nu/j9EP
22
何らかのテスト設計ツール
を導入している?
23
静的解析ツールPMD
Javaのソースコードを解析し、潜在的なバグを見つけることができるhttp://pmd.sourceforge.net/
FindBugs
Javaのソースコードを解析し、潜在的なバグを見つけることができるhttp://findbugs.sourceforge.net/
24
何らかの静的解析ツール
を導入している?
25
カバレッジツールJacoco
Eclipseのプラグインである「EclEmma」の開発チームが開発が2005年で止まっている「Emma」の代わりに開発したカバレッジ測定ツールhttp://www.eclemma.org/jacoco/
26
何らかのカバレッジツール
を導入している?
27
動的解析ツールIBM Rational AppScan
数千を超える攻撃パターンをWebサイトに自動実行することでSQLインジェクション等のセキュリティホールを検出することができるhttp://www-03.ibm.com/software/products/ja/appscan
28
何らかの動的解析ツール
を導入している?
29
テスト実行と比較ツールGeb
WebDriverをラッパーしたGroovyでブラウザテストを自動実行するツールhttp://www.gebish.org/
CasperJS
PhantomJSを拡張したJavaScriptでブラウザテストを自動実行するツールhttp://casperjs.org/
Selenium IDE
キャプチャーリプレイ型のブラウザテスト実行ツール
30
何らかのテスト実行ツール
を導入している?
31
性能テストツールJMeter
Jakartaで開発が進められているツールJavaで動作するhttp://jmeter.apache.org/
Gatling
Scalaで動作することが特徴。JMeterよりもパフォーマンスが良いらしいhttp://gatling.io/#/
32
何らかの性能テストツール
を導入している?
33
1.5 テスト自動化の利点
34
テスト自動化の利点１発展性、経済性に優れている複数回実行することで手動テストと比較して実行にかかる工数が少ない
プログラム修正のたびにテストを実行することができる
短い時間で多数のテストを実行できる手動テストではできないテストができる200人のユーザーが同一シナリオを実行するような手動テストでは実行が難しいテストを実行することができる
35
テスト自動化の利点２単純作業を無くすことができる優れたテスト担当者を単純な作業から解放して、テスティングに注力させることができる
常に正確に実行することができる単調で退屈なテストをやっていると手動だとミスが発生するが、自動であれば常に正確に実行してくれる
良いテスト設計を促進することができる良いテストを繰り返し実行（再利用）することができるのでテスト設計に時間をかける価値がでてくる
36
テスト自動化の利点３リリースサイクルの短縮ソフトウェアを市場にすばやく投入できるようになる
リリースに自信が持てるようになる前回、実行したテストが成功することでソフトウェアのリリースに自信がもてるようになる。
37
1.6 テスト自動化に
共通する問題
38
テスト自動化に共通する問題 1非現実的な期待が膨らんでしまう問題テストの保守工数がそれなりに必要なことであるが、それが考慮されずに、マネジメント層の期待に沿うことができない
良くないテストを自動化する問題質が悪く、ドキュメントもない状態で自動化することで手動よりも工数がかかってしまう。テストの質を上げることが重要
新しい欠陥を多く発見できる期待最初に実行したときに欠陥をみつけるもので自動化によって欠陥が発見されるわけではない
39
テスト自動化に共通する問題 2
テスト成功に対する誤った認識テストが成功したからといってそのソフトウェアに欠陥が無いとは言えない。期待結果が間違っていれば間違った結果を保証するだけである
メンテナンスコスト問題ソフトウェア側が変更されると、テスト側も全部のテストを書き換えなければならなくなることが多い。自動テストは特にその影響を受ける。テストのメンテナンス工数はテスト自動化の試みを死に追いやってきた。
40
メンテナンスコストが
高くて困っている?
41
テスト自動化に共通する問題 3技術的な問題テスティングツール自身がテストされていないというツールの技術的な問題
ソフトウェアがテスト容易性を考慮せずに、設計、実装されていてテスト自動は困難
組織の問題自動化の試みはツールの「推進役」がいなければうまくいかない
「推進役」をマネジメントが十分にサポートしないと上手くいかない
サポートとは、テスト自動化の「標準」である。各グループで勝手なアプローチをとっていると上手くいかない
42
1.7 テスティング活動
43
テスティング活動とは
受け入れテストシステムテスト統合テストユニットテスト上記４つのレベルで分析、設計、実行し、期待値と実績値を比較し、各レベルでのソフトウェアの欠陥を発見する活動である。
44
早期にテスト設計を行うVモデル
「システムテスト自動化 標準ガイド」（テスト自動化研究会）より抜粋
45
テスティング活動５つのプロセス
「システムテスト自動化 標準ガイド」（テスト自動化研究会）より抜粋
46
Vモデルとテスティングプロセス
「テストツールまるわかりガイド(入門編)」（ASTERテストツールWG 著 2012/7/2）より抜粋
47
テスティング活動５つのプロセス1.識別
テスト条件を識別し（「何」がテストできそうかを決める）、優先順位付けする。
2.設計「何」を「どうやって」テストするのかを決める
3.実装テストケースを実行する（スクリプト、データ、その他を実装する）
4.実行テストケースを実行する
5.比較テストケースの出力を期待結果と比較する
48
テストケース設計
「何(What)」を「どうやって(How)」テストするのかを決めること設計にあたっては、ソフトウェア実装と並行して行うことが重要で、ソフトウェアの要件の欠陥、機能仕様の欠陥を事前に発見することができるテスト目的に関連する項目を順番に検証するものである。入力値、期待値、その他テストに必要な条件を含む
49
テスト結果と期待結果の比較のポイント
実行結果と期待結果が「同じ」であってもテストが「成功した」とは限らない実行結果と期待結果が「異っていて」もテストに「失敗」したとは限らない期待した結果と違うことは検出することはできるが、結果が正しいかどうかを自動で判断することはできない
50
1.9 ソフトウェアテスティング
自動化の限界
51
テスティング自動化の限界自動化は複数回実行しないとコストが見合わないごくまれにしか実行されない、ソフトウェアが頻繁に全く仕様が変わってしまう場合など
プログラム的に難しいテストはできない例えば、色彩があっているか、画面配置の見栄えは適切か、正しい音が鳴るかなど
新しいバグはあまり見つけられない手動テスティングが85%の欠陥を見つけるのに対して、自動テストはたった15%しか見つけられないと報告している。(出典: Bach, 1997)
52
手動テストのほうが
自動テストよりもバグが
見つかると実感している?
53
1.10 まとめ
54
まとめ１良いテストを自動化することテスト自動化でテストの有効性を高めることはできない
複数回実行されるテストを自動化すること複数回実行されるテストを自動化することで、手テスト動と比較して発展的で経済的となる
テスト設計をソフトウェア実装と並行して行うことソフトウェアの要件の欠陥、機能仕様の欠陥を事前に発見することができる
55
まとめ２
正しい期待結果を認識すること自動テストでは、テスト結果が正しいかどうかを自
動判別することはできない。期待した結果と違うことを判別することができるだけである
この本では、「テスト実行と期待結果の比較」に注力することにして、これを「ソフトウェアテスティングの自動化」とよぶことにする
