Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (14)
Semelhante a 20161218 selenium study4
Semelhante a 20161218 selenium study4 (20)
Mais de Naoya Kojima
20161218 selenium study4
- 2. Profile I am … Father / Husband / A just application developer interested in Application design & Testing I love making / drinking coffee very much (^^)v Specialty Automation Test ( with JavaSE AspectJ Junit/TestNG Selenium WebDriver ) I make a keyword-driven test system.
- 4. テストの自動化に興味ある皆さんへ テストの自動化をはじめるにあたり、皆さんが気になるであろうポイントを、 キーワード駆動テストの実践を通してご紹介します 難しく考えずに、できる範囲ではじめてみてください テストを自動化する目的を明らかにしてみてください テストをシステム化する上で重要だと思うことを、テストシステムの開発方針に取 り入れてみてください 取り組んだ結果をぜひ皆さんに教えてください Selenium を使う自動テストの手法は状況に応じて千差万別だと思います。私 の伝えたいことが皆さんとって適切なシステム構築の一助になれば幸いです
- 5. 話の流れ 伝えたいこと キーワード駆動テストに取り組む前に考えたこと キーワード駆動テストとは 構造化スクリプティングとの比較 キーワード駆動テストを実践した話 深く考えずにまずはやってみた編 リファクタリング編 テストシステムの構造、機能の検討 テストのしやすさの検討 ICONIX によるテストシステムの要求分析設計の実施 適切なキーワードの検討 まとめ
- 8. 自動化アプローチの種類 システムテスト自動化標準ガイドによると スクリプティング技法 リニアスクリプト テスト対象への操作をレコーディングして、何度も実行出来るようにするアプローチ 構造化スクリプト 「テスト対象の操作方法」を"テストコード"を書き、何度も実行出来るようにするアプローチ データ駆動スクリプト 構造化スクリプトを構成するテストコードからテストデータを独立させて、テストコードに柔軟性 を持たせたアプローチ キーワード駆動スクリプト 特定のルールに基づき構成されたスクリプトをテストシステムが解釈（プリプロセス）してから実 行するアプローチ
- 9. 概要 ISO/IEC/IEEE 29119-5 によると 一般的に、次の２つで構成される 自動テスト テスト自動化フレームワークの開発 すべてのテストレベルで使用できる システム様々なタイプのテスト 例）機能テスト、信頼性テスト キーワード駆動テストの基本的な考え方 プログラミングやテストツールの専門知識を詳しく知らなくても、手動または自動のテストケースの作成に 使用する「キーワード」と呼ばれる一連の「構成要素」を提供する この為、各キーワードをソフトウェアで実装する必要がある
- 10. 「キーワード駆動テストとは」 まとめ 目的 構造化/データ駆動の課題の、「テスト対象の操作方法」を１つ１つテストシステムに伝える、 という手間を軽減する 実現方法 テストシステムが「テスト対象の操作方法」を解釈してから、テストを実行できるようにする 解釈（プリプロセス）の為に、テストシステムには特定のルールに基づいて抽出した「キーワー ド」を知識として与える 効果 テストシステムが「解釈」出来るようになった結果、テスト実装者は「テスト対象の操作方法」 をある纏まりとして扱うことが可能になる 特定のドメインにフォーカスして、一定のルールに基づき「ある纏まり」を構成することで、テ ストコードを書けない組織でも比較的容易にスクリプトを記述出来るようになり、自動化の敷居 を下げることが出来る
- 13. 観点 構造化 キーワード ・テストシステム開発要員のスキル テスト計画、分析、設計に関する知識や経験 例）どのようにテストを実施していくか 必要 必要 各々が置かれた状況から導かれた要求に対して適切に設計をするスキル 例）保守、拡張しやすい構造にするスキル、キーワードの設計スキル 必要 必要 ・コーディングスキル 必要 必要 ・テストシステムの開発工数（相対比較） 低 高 テストシステム開発時の比較観点
- 14. テスト実装時の比較観点 観点 構造化 キーワード ・テスト実装者のスキル テスト技法に関する知識 例）どのように効果的なテストを実施するか 必要 必要 コーディングスキル 必要 不要 キーワードの設計スキル 不要 必要 ・テストの実装環境 開発環境 必要 不要 ・テストの実装工数（相対比較） 高 低
- 15. テスト実行時の比較観点 観点 S/K テスト実行者のスキル コーディング 不要/不要 テスト失敗時の原因分析スキル 不要/不要 テストの実行環境 テストシステム稼働環境 必要/必要 テストスクリプト実行環境 必要/必要 観点 構造化 キーワード ・テスト実行者のスキル コーディング 不要 不要 テスト失敗時の原因分析スキル 不要 不要 ・テストの実行環境 テストシステム稼働環境 必要 必要 テストスクリプト実行環境 必要 必要
- 16. テストシステム保守時の比較観点 観点 構造化 キーワード ・テストシステム保守要員のスキル テストプロセスに関する知識 例）どのようにテストを実施していくか 必要 必要 開発時の方針 に従って保守・拡張設計をするスキル 例）キーワード設計方針に従いキーワードを拡張する 必要 必要 コーディングスキル 必要 必要 ・テストシステムの保守工数（相対比較） 低 高
- 17. 構造化スクリプティングとの比較 まとめ 自動化のアプローチを決定する上で大切な事 自動テストのライフサイクル別に必要なリソースを検討すること ライフサイクルの一部だけに「テストシステム開発」だけ、「テストの実装」だけに焦点 を当ててしまうと、想定していないフェーズで必要となってくるリソース不足で、自動テ ストを継続できなくなってしまう 状況に応じて判断、選択すること 判断基準となる 観点を導くポイント ヒト、モノ、カネ 自分が置かれた状況にどれだけあるか 、手配できるかを踏まえて判断すること
- 19. 実践の背景 定期的に同じ操作のテストを繰り返していた 約 30 時間 依頼通りに値が設定されてることを検証する必要があった 約 20 時間 テストデータは間違いなく入力する必要があった 間違えたらやり直し 間違いなく入力されていることを検証（受入）する必要があった テストコードを書ける人がいなかった
- 20. ビジネス要求 同じテスト内容を何度も繰り返し入力したくない 受入検証で誤ったテストを発見するような運用はやめたい 例え誤りを発見しても、迅速に修正、短時間で再実行したい テストコードを書けない人でも自動テストを実装出来るようにしたい
- 21. 機能要求 １つのテストケースで何度も同じテストを実施出来なければならない テストは自動実行される必要がある テストの実施中にテストの合否を誤りなく判定しなければならない 誤りがあったテストケースだけを実行出来る仕組みが必要である キーワード駆動テスト手法を採用しなければならない さらに、テストケース表は自然言語で記述される必要がある
- 22. ユースケース テストケース取り込み、実行、合否判定、結果報告 POI TestNG DataProvider 、Suite、Assertion、Report 実行有無の判定処理の追加 Maven キーワード駆動テスト専用のテストケース表の作成 テスト対象への自然言語による操作を、テストシステムが処理可能な形に変換する テストケース表の作成
- 23. テストシステムビルダー（Maven） テストランナー（TestNG） テストケース ローダ（POI） WebDriverの 管理 キーワードエンジン テストケース ファイル （Excel） テストステップ ファイル （Excel） キーワード ページオブ ジェクト レポーター （TestNG） 作ったもの 1/3 テストシステムの構造 Programming Part selenium-javaを利用した「WebDriver」、 「操作」、「ロケータ」の記述箇所
- 26. 成果 同じ内容のテストを繰り返し操作しなくて済むようになった 受入検証ではテスト結果と証跡を確認するだけで済むようになった テストシステムが意図した通りに動作することが保証されている為 誰でも自動テストを実装出来るようになった さらに ちょっとしたテストデータの変更にも対応できるようになった
- 27. 課題 1/2 1. テストシステムのあるべき姿が分からなかった テストシステムがどのような構造を持つべきか分からなかった テストシステムの目的が不明確だった 2. 適切なキーワードの実装方法が分からなかった 汎用性の高いキーワードはテストケースが長くなった。一方でテストケースを短くする為にキーワード の独自性を強めると、汎用性に欠けた再利用性の低いキーワードが増えてしまった。
- 28. 課題 2/2 3. 脆いテストになった 画面上の要素の変更を伴う改修により、テストケース表毎にロケータを書き直す羽目になってしまった 4. テストの実装よりテストシステムの実装に工数を取られた マルチブラウザのテストを独自に実装する必要があった ブラウザの種類によりスクリーンショットの範囲が異なっていた スクリーンショットに基づいたブラウザ間の差異の比較を出来なかった 失敗したテストの原因を特定する為に、自分でロギングを設計する必要があった テストの実行を並列化出来ず、実行に時間が掛かっていた テストの実行により画面を占有されてしまい、別の端末が必要になっていた
- 29. 対応方針 1/2 1. テストシステムの構造、機能の検討 先駆者のテストシステムを参考にした 現状の構造と比較し、改善した テストシステムの目的を明確化した テストシステムは一つのシステムであると捉え、テストシステムへの要求、及び機能を整理した 2. テストスクリプトにおける適切なキーワードの検討 先駆者の考え方を参考にした シナリオテストに登場するドメインの用語をキーワードとした デザインパターンを参考にした クラス階層と機能階層を分離するBridgeパターン オブジェクトをコマンド化するCommand パターン…etc OOADによるオブジェクト抽出方法を参考にした ICONIXのドメイン分析手法から、特定のドメインからオブジェクトを抽出できるようにした
- 30. 対応方針 2/2 3. 脆いテストへの対策 テストシステムに実装したロケータをテストケース表に取込可能にした 4. テストシステムの実装の省力化 Pitaliumにテストシステムの基本機能を委譲した マルチブラウザテスト対応 スクリーンショットの範囲補正、取得 テストログ（stacktrace含む）取得 テストのマルチスレッド実行 Selenium Server をdaemon（サービス）化した Java Service Wrapperを利用した
- 33. 先駆者のテストシステムを参考にした 参考にしたテストシステム、考え方 SQiP 併設チュートリアル 2「キーワード駆動による自動テスト構築」 http://jugemix.hatenablog.com/entry/2016/09/20/230954
- 34. テストシステムの目的を明確化した テストシステムは一つのシステムであると捉え、テストシステムへの要求、及 び機能を整理した 要求、機能整理の為に採用したアプローチ 「テストのしやすさ」の検討 テストのしやすい状況、テストを検討してテストシステムの目的を明確にする ICONIX （OOADのプロセスの一つ）によるテストシステムの要求分析設計の実施 ICONIXでは、ビジネス要求→機能要求→ユースケースというOOA（分析）を経て、ユース ケースは機能設計へと落とし込まれていきます。そこで、ICONIXの要求分析アプローチに 基づき、テストシステムへの要求を明確化していきます。
- 35. 「テストのしやすさ」の検討
- 36. 自動テストにしやすい状況 手動テストがテストスクリプトに基づいて実施されていること テスト実行者への指示となるもの（ドキュメント等）があること これはアドホックなテストを否定する意味ではなく、テストを実行するテストシステムへの指示が物理的な形 になっていることを意味する 一般に知られる方法だが、ドキュメントに従い作られた正しさが証明されたテストのアウトプット（ログ）と、 今回実行したテストのアウトプットを比較することで、テスト対象に変更が無いことを回帰的に確認すること も出来る 効果的なテストがあること テストがテストとしての目的を果たしている テスト対象を適切に分析、設計できること 不適切な（意味のない）テストを自動化しても時間と労力が無駄になるだけである テスト技法はテストプロセスを示すものではなく、効果的に欠陥を発見する為のものであることを理解する
- 37. 自動テストにしずらい状況 テストスクリプトの無い機能が多い場合 テストを実装する為には、その元（ドキュメント等）が必要である為 アドホックなテストを否定しているわけではない 以下の投稿でアドホックな手動テストが必要、大切とされる理由を参照して頂きたい http://qiita.com/ledsun/items/b6c22afe321ac3052182 頻繁に改修のある機能 改修が加われば、成功していたテストも失敗するようになる。手動テストなどを経た上で、 成功するように誤りがなく適切な自動テストを実装する必要がある為。
- 39. 実施しやすいテスト 2/2 システムテストに焦点を絞った場合 テストレベル テストタイプ 目的 システムテスト ユースケーステスト（シナリ オテスト） アクターにとってのシステム目的 の、様々なシナリオによる検証 サイクルテスト 性能テスト Easy to test relatively
- 40. テストの実施時期と自動化の対象 いつどのテストを実施すべきかーという判断は、開発の効率に影響する 例えば、単体テストで発見できる欠陥がその後工程で発見されれば、その分の手戻りが発生する 一方、開発の効率を抜きにして考えれば、実施すべきテストはいつ実施さても良いことになる よって、テストレベル毎のテストタイプに縛られずに、対象に必要なテストと実施手法を検討 してその中から自動化すべきテストを決定する
- 41. ユースケーステスト ユースケーステスト ユースケーステストは、「ユースケース記述」で表現する基本シナリオ・代替シナ リオから、比較的テストシナリオを導きやすい 参考情報 https://www.ibm.com/developerworks/jp/rational/library/04/r-3217/ テストシナリオを導きやすい為、テストスクリプトの準備が容易になりやすい ただし、テストシナリオ導出の為には、テスト対象の分析、設計の実施が前提である そこで、次スライドからOOADによるテスト対象の要求分析設計手法を紹介する
- 42. ICONIX によるテストシステムの要求 分析設計の実施 • Object-Oriented Analysis and Design • The ICONIX Practical Method of OOAD
- 43. Object-Oriented Analysis and Design Abstract OOAD Structure Requests Application Architecture Components Object Object Object Object Analysis Design Object Roles Responsibilities Task Info has Roles
- 44. The ICONIX Practical Method of OOAD Quote from 「Use Case Driven Object Modeling with UML Theory and Practice」Doug Rosenberg, others. Abstraction of ICONIX ICONIX自体はOOADよりも広い範囲をサポートする開発手法 静的＋動的なワークフローが構成するイテレーティブなプロセス １イテレーションでは、ユースケースまたはその論理的な集合に対 して、要求分析〜単体テストをスコープとする実践的な手法 イテレーティブな為、agileプラクティスとの親和性が高い UP（統一プロセス）よりも使用するUMLやドキュメントの種類が少 なく、軽量である 他の手法との折衷案を採用してもよい（私見） マイルストーンと確認ポイントが示されているので分かりやすい
- 45. The ICONIX Practical Method of OOAD 2 Abstraction of ICONIX Process （One Iteration） 要求定義 機能要求 振る舞い要求 ドメイン分析 ドメインモデリング レビュー 要求分析 予備設計 ロバストネス分析 属性追加（ドメイン モデルの更新） コントローラオブ ジェクトの識別 レビュー 詳細設計 シーケンス図作成 操作の追加（ドメイ ンモデルの更新） シーケンス図の更新 レビュー 実装 コーディング ユニットテスト実施 統合テスト、テスト シナリオの実施 コードレビュー 各モデルの更新 To Next Iteration
- 46. The ICONIX Practical Method of OOAD 3 要求定義 機能要求 • システムができることを記述する。 • 例）1ヶ月ログインのないユーザは、パス ワードを再設定しなければならない。 振る舞い要求 • アクター（ユーザ、システム等）との対話 を叙述的に記述（ユースケース記述）する。 • 例）ログイン画面で、ユーザはIDとパス ワードを入力する。システムは、ユーザの 最終ログイン日を取得し、現在日付との比 較結果が１ヶ月以内かを判定する。また、 ログイン情報と一致するかを判定する。シ ステムは、判定結果を元にメニュー画面を 表示する。 ドメイン分析、モデリング • ユースケース記述から問題領域のオブジェ クトを抽出する。 • 抽出にはCRCカードを使うとオブジェクト の目的、責務、相互作用先の候補を挙げや すい。（私見） • ドメインオブジェクト同士を相互作用の観 点で結ぶ。
- 47. The ICONIX Practical Method of OOAD 4 分析・予備設計 ロバストネス分析 • ユースケース記述をロバストネス図上に表 現する。 • UC記述中、オブジェクトはバウンダリ、エ ンティティとし、タスク・処理はコント ローラとする。 • 例）ログイン画面で、ユーザはIDとパス ワードを入力する。システムは、ユーザの 最終ログイン日を取得し、現在日付との比 較結果が１ヶ月以内かを判定する。また、 ログイン情報と一致するかを判定する。シ ステムは、判定結果を元にメニュー画面を 表示する。 ドメインモデルの更新１ • ロバストネス図を記述した結果、ドメイン モデルに不足するオブジェクトがあれば追 加する。 • 例えば、UC記述上ではユーザはアクターだ が、判定処理を行う際にIDとパスワードは どこに格納しておくのか？ • 結果、「ユーザ情報」というエンティティ （タスクの実行を補助判断する情報を格納 するオブジェクト）が必要であると考える ことができる。 • IDとパスワードはユーザ情報の属性とする。 コントローラオブジェクトの識別 • ロバストネス分析の結果、次の箇所をコン トローラの候補とする。 • 「ユーザの最終ログイン日を取得」 • 「現在日付との比較結果が１ヶ月以内かを 判定する」 • 「ログイン情報と一致するかを判定する」
- 48. The ICONIX Practical Method of OOAD 5 詳細設計 シーケンス図作成 • ロバストネス図から、バウンダリ、エン ティティ、コントローラをシーケンス図に 反映する。 • 例）ログイン画面とユーザ情報はオブジェ クトとして表現する。 • 例）「ユーザの最終ログイン日を取得」、 「現在日付との比較結果が１ヶ月以内かを 判定する」、「ログイン情報と一致するか を判定する」、「メニュー画面を表示す る」は相互作用（オブジェクト間のメッ セージ）として表現する。 ドメインモデルの更新２ • シーケンス図を記述した結果、ドメインモ デルのオブジェクトにメッセージを追加す る。 • その他、メッセージのインプット（引数）、 アウトプット（戻り値）等からオブジェク トに不足する属性を判断する。 • この結果、ドメインモデルはクラス図とし て完成する。 シーケンス図の更新 • Java EEやフレームワークを利用する場合は、 RequestDispatcherの実装オブジェクトも シーケンス図上で表現することでActorとオ ブジェクト間の相互作用がより詳細に分か るようになる。
- 49. The ICONIX Practical Method of OOAD 6 実装 コーディング・ユニットテストの記述 • 完成したクラス図を元にクラスを実装する。 • 設計を元にユニットテストを記述する。 統合テスト・テストシナリオの実施 • 設計を元に統合テスト、テストシナリオを 実装する。 • テストシナリオにおいては、ユースケース を元に実装することでユースケーステスト を設計することができる。 コードレビュー・各モデルの更新 • コードレビューを実施し、パターンの適用 や適切な責務の実装を促す。 • 次のIterationに備えてモデルを更新する。
- 50. 新たなテストシステムのビジネス要求 テストシステムの目的 想定するユースケースにおける欠陥の発見 テストシステムの構築方針 利用者の学習コストが少ないこと 利用者が既存の開発プロセスでも受け入れ易いテスト手法であること 利用者がテストの実装に専念できる事 テストシステム開発者（Java User）が保守し易いこと OOADに基づきドメインオブジェクトとその相互関係を表したドメインモデルを作ること 複数の問題領域で共通するドメインオブジェクトの実装には既存のツールを積極活用し、個別に考察を必要とする ドメインオブジェクトの実装に専念する テストシステムがテスト対象システムの変更に強いこと
- 51. ドメインモデルとは 特定の領域（問題領域）を解決領域へと導く為に、それを構成する抽象的な概念（オブ ジェクト）同士の関係でその領域を表した図のこと 例えば、「テストをする」という行為を１つの業務（ビジネス領域）と捉え、「〇〇業務システ ムの回帰テストを実行したい」というビジネス要求を受けたとする ドメインモデルを作ると、ビジネス要求から「〇〇業務システム」、「回帰テスト」というワードを元に、 それらを構成するオブジェクトを抽出し、ビジネス要求が対象とするオブジェクトとオブジェクト間の関 係をモデルとして表現出来る
- 52. ドメインオブジェクトとは 問題領域を構成する要素 例えば「〇〇業務システムの回帰テストを実行する」という問題領域では、以下をドメイン オブジェクトの一例として挙げられる 〇〇業務システムへの要求、機能仕様 テストケース テストシナリオ テストシステム テスト結果 「〇〇業務の回帰テストを達成すること」が一番の問題（本質）であり、「どのように回帰 テストを達成するか」は一番では無い どちらも実装される必要はあるが、本質的な部分（テストケース、テストシナリオ）の作り 込みに専念する為に、ここでは本質でない部分（テストシステム）には外部の解決策を利用 する手段を採用した
- 53. 新たなテストシステムの機能要求 テストシステムの利用目的 シナリオの実行を通してユースケースの正しさを検討すること 対策も加味した新たな機能要求 テストケース表は従来の書式を踏襲しなければならない 従来のテスト実装から、キーワード駆動テストケース表が導出される必要がある Pitalium、JUnitを活用して適用対象システムの改修、変更時に実装するオブジェクトを以下に限定する 必要がある テストケース表の取り込み（TestcaseLoader） キーワード（Keyword） ページオブジェクト（PageObject） WebElementの変更による影響を一箇所に集約する必要がある
- 54. 新たなテストシステムのユースケース テストケース取り込み、実行、合否判定、証跡取得、結果報告 POI Junit、Pitalium、AspectJ ParameterizedRunner 、Parameters 、AssertView 実行有無の判定処理の追加 Maven テストケース表の作成 テスト対象への自然言語による操作を入手すると、テストシステムが処理可能なキキー ワードを選択するセルを従来の表に追加 レイアウトは従来のままとし、テストケース表が参照するページオブジェクト一覧表の作 成
- 55. テストシステムの要求分析設計の成果物 ユースケース図 ユースケース記述 ドメインモデル ロバストネス図 シーケンス図 クラス図
- 56. テストスクリプトにおける適切な キーワードの検討 • キーワードの粒度の検討ー先駆者の考え方を参考にした • キーワードの実装方法の検討ーデザインパターンを参考にした • キーワードの抽出方法の検討ーOOADによるオブジェクト抽出方法を参考にした
- 57. キーワードの粒度の検討 ー 先駆者の考え方を参考にした 粒度の調整 「ドメイン言語 ＞ スクリプト言語 ＞ プログラム言語」 参考情報 51スライド http://www.slideshare.net/koido1961/2015-56092163 「ISO/IEC/IEEE 29119-5」でも上記と同様に以下の表現で言及されている ドメインレイヤーキーワード 例）ファイルを保存する（＝アクターに提供する一連の画面操作の組み合わせ） コンテンツを取得する→メニューを選択する→保存する アクターへ提供するシステムの振る舞いを表す為、ユースケースに近いと思う（私見） テストインタフェースレイヤーキーワード（キーワードの実装部分） 例）メニューを選択する
- 58. キーワードの実装方法の検討 1/2 ー デザインパターンを参考にした Command Pattern 「キーワード」をクラスとして定義し、 OOADの恩恵（保守/拡張性）を受ける DomainLayerKeyword Class 例） Class ファイルを保存する action() ファイルを保存する 1. コンテンツを取得する 2. メニューを選択する 3. 保存する Class メニューを選択する Action() メニューを選択する 1. メニューリンクをクリックする Selenium-java等のライブラ リを使い実装する キーワードクラスのaction()内で 別のキーワードクラスのaction() を再帰的に呼び出している
- 59. キーワードの実装方法について 2/2 ー デザインパターンを参考にした Bridge Pattern 機能のクラス階層が実装のクラス階層の インスタンスを保持し、役割を保持する 例）SaveFileAsXmlキーワードクラス Implフィールド SaveFileのインスタンス or SaveDBのインスタンス saveFileAsXML_actionメソッド rawSave_actionメソッドを実行する 機能のクラス階層 （繰り返し階層化して深くなる） 実装のクラス階層 （並列化して実装が増える）
- 60. キーワードの抽出方法について ー OOADによるオブジェクト抽出方法を参考にした キーワードをオブジェクトとして扱うアーキテクチャ にできた テスト対象システムの要求分析設計にもICONIXを用いる テスト対象システムのユースケース記述から、ドメインオ ブジェクトの抽出と同時に、「タスク・処理」の抽出も行 うことになり、それを元にキーワードの抽出が出来る また、この開発アプローチにより、同時にユースケーステ ストの為のシナリオを作成するテスト分析も出来た状態に なる この結果、キーワード駆動テストを実施しやすい環境を整 えることができる ICONIXによるテスト 対象の開発 「タスク・処理」の 抽出 キーワードの抽出 キーワード駆動テス トスクリプトの作成 キーワード駆動アプ ローチによるテスト キーワード駆動テストシステムの 設計にもICONIXが使われている
- 61. ドメインオブジェクトからキーワードの抽出 「ファイルを保存する」ユースケース ユースケース記述 「タスク・処理」の抽出 • ログイン画面で、ユーザはIDとパスワードを入力する。 • システムは、ユーザの最終ログイン日を取得し、 • 現在日付との比較結果が１ヶ月以内かを判定する。 • また、ログイン情報と一致するかを判定する。システム は、判定結果を元にメニュー画面を表示する。 • ユーザの最終ログイン日を取得する • 現在日付との比較結果が１ヶ月以内かを判定する • ログイン情報と一致するかを判定する • メニュー画面を表示する キーワードの抽出 キーワードの精査 抽出結果を基に、キーワードを精査することで、 無駄なくテストに必要なキーワードを抽出できる • ログインする ＞Loginキーワード • 最終ログイン日を取得する ＞GetLastLoginTimestampキーワード • 現在日付との比較結果が１ヶ月以内かどうか比較する ＞AssertWithinAMonthキーワード • 一致するかどうか判定する ＞AssertAccountEqualsキーワード • 画面を表示する ＞DisplayKeywordキーワード
- 62. 脆いテストへの対応 • to be continued on Next time • テストシステム上のロケータをテストケース表に取込可能にした
- 63. テストシステムの実装の省力化 • to be continued on “Selenium AdventCalendar 2016” • Pitaliumにテストシステムの基本機能を委譲した • Selenium Server をdaemon（サービス）化した
- 64. テストシステムビルダー（Maven） テストランナー（Pitalium based JUnit） TestCaseLoder（POI） テストケースファ イル（Excel） テストステップ ファイル（Excel） TestClass KeywordInvoker Class Abstruct Keyword Class Concrete Keyword Class PageLocator Class リファクタリング後のテストシステム テストシステムの構造 Programming Part Ptaliumに「WebDriverの管理」、 「レポート」機能を委譲 selenium-javaを利用した「操 作」、「ロケータ」の記述箇所
- 67. 大切だと思ったこと 難しく考えずに、はじめてみること 自動テストに対する要求が、課題として自然と湧いてくると思います 自動化する目的を明らかにすること テスティングについて再考する場面に出会すと思います テストの目的と自動テストの目的を分けて考えてみましょう 今大切にしたいと思うことを、開発方針に取り入れてみること 現状に合うテスト手法を検討することができると思います 取り組んだ結果を共有すること 誰かの助けになれば、それがいつか自分に返ってくると思います
- 69. 本日はありがとうございました