第1回 「システムテスト自動化 標準ガイド」 読書会 第1章 テスト自動化のコンテキスト

第一回 システムテスト自動化 標準ガイド 読書会の登壇資料です。
https://software-test-automation.connpass.com/event/13255/

Transcript

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