#STAC2014 状態遷移を活用した自動テストのテスト戦略とデプロイメントパイプライン
17 likes24,859 views
システムテスト自动化カンファレンス2014の発表资料です。
More Related Content
What's hot (19)
Viewers also liked (14)
Similar to #STAC2014 状態遷移を活用した自動テストのテスト戦略とデプロイメントパイプライン (20)
![[CB16] CGCで使用した完全自動脆弱性検知ツールを使ったセキュリティの分析とその効果 by InHyuk Seo & Jason Park](https://cdn.slidesharecdn.com/ss_thumbnails/cb16inhyukseoja-161108074102-thumbnail.jpg?width=560&fit=bounds)
More from kyon mm (20)
Recently uploaded (11)
#STAC2014 状態遷移を活用した自動テストのテスト戦略とデプロイメントパイプライン
- 1. State based Checking kyon_mm 2014/12/14 #stac2014
- 2. Self Introduction kyon_mm Test Architect TDD/BDD Expert 27 years old.
- 3. Self Introduction TDD/BDD超入門 システムテスト自動 化標準ガイド
- 4. CM
- 5. 古典の勉強も大切 だよ。「システムテ スト自動化標準ガイ ド」とか。 積み重ねが大事だよ なぁ。テスト自動化 勉強しとくかー。
- 6. Chapter 15
- 7. 18/45
- 8. 书籍の页/最初の页
- 11. Bottle neck 自動化っていっても、効果のあ るものをやらないと意味がない。 まずは現状を見えるようにする 必要がある。
- 12. ValueStreamMap
- 13. バリューストリームマップは、常 に顧客から始まり、顧客で終わる。 開発においては、顧客が注文を出 したときにバリューストリームマッ プの時計が動き出す。それが厳密 にいつを指すのかは、組織ごとに 異なるだろう。 リーン開発の本質 p102
- 14. 時計が止まるのは、ソリューショ ンが導入されるか、稼働するかし て、顧客の問題が解決したときで ある。バリューストリームマップ には、時計の開始から終了までに 発生する主要なイベントを時間軸 に並べる。 リーン開発の本質 p102
- 16. ValueStreamMap ソフトウェア開発をバリュース トリームと捉えた場合、ソフト ウェア開発の速度というのは、 バリューストリームの長さであ ると言える。
- 17. Test Automation テストを自動化することが正し いのではなく、ソフトウェア開 発自体をよいサイクルにするこ と、そしてリリースにかかる時 間を短くするための有用な選択 肢
- 19. Why Deployment Pipeline ? 自動化した結果をつなげればい いだけなんだし、まずはやれば いいんじゃないの？
- 20. Answer テスト自動化をする上で、ある 程度は俯瞰をしなければ局所最 适化をしてしまうかもしれない。
- 21. Answer テスト自動化をする上で、ある 程度は俯瞰をしなければ局所最 适化をしてしまうかもしれない。 その上で密接に関わるのがデプ ロイメントパイプライン。
- 22. 抽象的に言えば、デプロイメント パイプラインとは、ソフトウェア をバージョン管理から取り出して ユーザーの手に渡すまでのプロセ スを自動化して表現したものだ。 ソフトウェアを変更するたびに、 リリースまでの複雑なプロセスを 通過することになる。 -継続的デリバリー p.153
- 23. このプロセスにはソフトウェアのビ ルドも含まれている。その後に、テ ストやデプロイメントなどのさまざ まなステージを経てビルドが進展す るのだ。このそれぞれのステージで、 多くのメンバーや複数のチームにま たがった共同作業が必要になる。デ プロイメントパイプラインはこのプ ロセスをモデル化している。 -継続的デリバリー p.153
- 24. そして、継続的インテグレーションお よびリリース管理用ツールを用いてこ のプロセス実現することで、チェック インした変更がプロセスを進んでいく 様子を見ながらコントロールできるよ うになるのだ。ソフトウェアはバージョ ン管理からチェックアウトされ、さま ざまなテストやデプロイメントを行っ た上でユーザーにリリースされるので ある。 -継続的デリバリー p.153
- 25. Design/Implement Deployment Pipeline ビルドパイプラインを実装する というのは、テストの大まかな 分割方針、フィードバック順序、 実行頻度を決め、そして実装後 には多様なテストを早期から設 計、実装、実行することを意味 する。
- 26. Design/Implement Deployment Pipeline テスト戦略の一部を具現化した もの テスト自動化のROIを高める上 で重要な要素
- 27. Design/Implement Deployment Pipeline ステージをどのように分割して もよい テストレベル、テストタイプ、 チーム単位、アジャイルテスト の4象限、など。
- 29. Test Strategy
- 30. Broad Test Strategy テスト戦略と似た使い方をする 言葉に、テスト計画という言葉 がある。狭義には両者は異なり、 広義には同一視する。
- 31. Narrow Test Strategy テスト計画はソフトウェアテス トの全体の進め方に関する方針 を決めたもの テスト戦略はテストケース設計 に関する方針を決めたもの
- 32. 鉄則278 テスト計画は戦略、段取り、成果 物の三位一体と心得よ ソフトウェアテスト293の鉄則 p256
- 33. Test Strategy テスト戦略は一度つくって終わ りというものではない テスト戦略はテスト全体のアー キテクチャ、テストスイートの 設計、テストケースの設計につ いて方針を与える。そしてその 方針を決定する要因は多岐にわ たる
- 35. リスク(障害の影響、障害の可能性) アプリケーション(ソフトウェアの 品質、システムの性質、取得戦略) テスト環境（開発ラボ、アルファテ ストまたはベータテスト、本番環境 の模写、ユーザビリティテストラボ、 モデルオフィス） テスト要件（完全性、正確性、安定 性）
- 36. レビュー戦略（ウォークスルー、イ ンスペクション、机上チェック） リソース（金、時間、人、スキル） テスト目的（使用性の例証、破壊テ スト、インタフェースのチェック、 欠陥の予防、カバレッジ） テストツール（何を自動化するか、 どのようなツールを使用するか）
- 37. Strategy meets Automation 「何を自動化するのか」 「テスト環境」 「テスト目的」
- 40. システムの状態遷移図はかなり 大きく、網羅的に自動テストを すると半日以上かかってしまう チームは自分が改修した部分の みしか把握していない、本当に システムが正常にデプロイでき ているかを確認するテストが勘 になりつつある。
- 41. 共通部分の改修などで他への影響を素早く確認するため にもコンポーネントレベルでの動作が出来ていることを 最初にテストする 各開発者が把握していない機能が多数あることから、出 来るだけ自分が把握していない機能との連携も自動的に テストケースを生成する システムが正常にデプロイできているかを簡単に確認す るためのテストを各デプロイ先でまず実行する。 システムが巨大なため、インテグレーションレベルでの テストはいくつかに絞るが、絞り方は出来るだけバグが 出やすそうな部分をプログラムで判断させるようにする ことで、自動テストを有効活用する。 システムが巨大なため、網羅的にテストするのは開発者 がいない時間帯に自動的に実行させる。
- 43. 優先順位の高いものから先にチー ムにフィードバックするための デプロイメントパイプラインの 理想と、それを実現する手法を 考える必要がある。
- 44. 手段だけを考えても、それがデ プロイメントパイプラインでボ トルネックになっていない部分 にしか適用が出来ないのだとし たら、局所最適化であり、テス ト全体の改善には繋がりにくい。
- 46. コミットステージではユニットテス ト、コンポーネントテストを実行す る。 クラスやモジュールを単一もしくは 複数組み合わせる単位でのテストで ある。ここではシステムがデプロイ されている必要はない。
- 48. 受け入れステージでは、スモークテ ストおよびインテグレーションテス トの一部を実行する インテグレーションテストレベルで はコンポーネントテストレベルにお いて組み合わせが起きなかったユー スケース間のテストも存在する
- 49. 特定のカバレッジを満たすようなス モークテストを人間が選択すること は非常に難しい そこで巡回セールスマン問題を解く ためのアルゴリズムを使うことで、 このスモークテストを生成する！！
- 51. コンプリヘンシブステージでは、スモー クテストと網羅的なインテグレーション テストを実行する。 スモークテストに関しては、受け入れス テージで行ったものと同様のテストケー スを実行する。網羅的なインテグレーショ ンテストは十分に実行可能な時間を確保 して定期的に実行する。 網羅的なインテグレーションテストはシ ステムを表現しているグラフを可能な限 り網羅する形でテストケースを生成する。
- 53. キャパシティステージでは、スモー クテストとキャパシティテストを実 行する。スモークテストに関しては 受け入れステージで行ったテストケー スと同様のものを実行する。 キャパシティテストはいわゆる性能 テストと言ってよいだろう。１処理 あたりの量を変化させたり、複数処 理の実行だったり、並列数を変化さ せたりなどして、速度や時間を計測 する。これらは本番環境に近ければ 近いほどいい
- 55. UAT(User Acceptance Test)ステー ジではスモークテストと、手動テス ト、アドホックテスト、探索的テス トを実行する。スモークテストに関 しては受け入れステージで行ったテ ストケースと同様のものを実行する。 このステージで、自動生成されない ようなテストケースおよび実際に人 間による判断が必要な部分をテスト する。
- 57. 本番ステージではスモークテスト を実行する。この環境はいわゆる エンドユーザーが使用する環境。 スモークテストが完了したら、Web アプリケーションであればユーザー が使えるようにスワップを実行し たり、サーバーを切り替えたりす る
- 59. Conclusion
- 60. Conclusion デプロイメントパイプラインを 効果的に実装するにはテスト戦 略は必須である テスト戦略がなっていないと、 自動化の効果は低い