Embed Size (px)
Citation preview
kyon_mm 2014/12/14 #stac2014
State based Checking
kyon_mm
Test Architect
TDD/BDD Expert
27 years old.
Self Introduction
TDD/BDD超入門
システムテスト自動化標準ガイド
Self Introduction
CM
積み重ねが大事だよなぁ。テスト自動化勉強しとくかー。
古典の勉強も大切だよ。「システムテスト自動化標準ガイド」とか。
Chapter 15
18/45
書籍の頁/ 初の頁
今日は真の15章を 見せてやんよ！
Agenda
デプロイメントパイプライン
テスト戦略
Bottle neck
自動化っていっても、効果のあるものをやらないと意味がない。
まずは現状を見えるようにする必要がある。
ValueStreamMap
リーン開発の本質 p102
バリューストリームマップは、常に顧客から始まり、顧客で終わる。開発においては、顧客が注文を出したときにバリューストリームマップの時計が動き出す。それが厳密にいつを指すのかは、組織ごとに
異なるだろう。
リーン開発の本質 p102
時計が止まるのは、ソリューションが導入されるか、稼働するかして、顧客の問題が解決したときである。バリューストリームマップには、時計の開始から終了までに発生する主要なイベントを時間軸
に並べる。
ValueStreamMap
ソフトウェア開発をバリューストリームと捉えた場合、ソフトウェア開発の速度というのは、バリューストリームの長さであると言える。
Test Automation
テストを自動化することが正しいのではなく、ソフトウェア開発自体をよいサイクルにすること、そしてリリースにかかる時間を短くするための有用な選択肢
Deployment Pipeline
Why Deployment Pipeline ?
自動化した結果をつなげればいいだけなんだし、まずはやればいいんじゃないの？
Answer
テスト自動化をする上で、ある程度は俯瞰をしなければ局所適化をしてしまうかもしれない。
Answerテスト自動化をする上で、ある程度は俯瞰をしなければ局所適化をしてしまうかもしれない。
その上で密接に関わるのがデプロイメントパイプライン。
-継続的デリバリー p.153
抽象的に言えば、デプロイメントパイプラインとは、ソフトウェアをバージョン管理から取り出してユーザーの手に渡すまでのプロセスを自動化して表現したものだ。ソフトウェアを変更するたびに、リリースまでの複雑なプロセスを
通過することになる。
このプロセスにはソフトウェアのビルドも含まれている。その後に、テストやデプロイメントなどのさまざまなステージを経てビルドが進展するのだ。このそれぞれのステージで、多くのメンバーや複数のチームにまたがった共同作業が必要になる。デプロイメントパイプラインはこのプ
ロセスをモデル化している。
-継続的デリバリー p.153
そして、継続的インテグレーションおよびリリース管理用ツールを用いてこのプロセス実現することで、チェックインした変更がプロセスを進んでいく様子を見ながらコントロールできるようになるのだ。ソフトウェアはバージョン管理からチェックアウトされ、さまざまなテストやデプロイメントを行った上でユーザーにリリースされるので
ある。
-継続的デリバリー p.153
Design/Implement Deployment Pipeline
ビルドパイプラインを実装するというのは、テストの大まかな分割方針、フィードバック順序、実行頻度を決め、そして実装後には多様なテストを早期から設計、実装、実行することを意味する。
Design/Implement Deployment Pipeline
テスト戦略の一部を具現化したもの
テスト自動化のROIを高める上で重要な要素
Design/Implement Deployment Pipeline
ステージをどのように分割してもよい
テストレベル、テストタイプ、チーム単位、アジャイルテストの4象限、など。
Agenda
デプロイメントパイプライン
テスト戦略
Test Strategy
Broad Test Strategy
テスト戦略と似た使い方をする言葉に、テスト計画という言葉がある。狭義には両者は異なり、広義には同一視する。
Narrow Test Strategy
テスト計画はソフトウェアテストの全体の進め方に関する方針を決めたもの
テスト戦略はテストケース設計に関する方針を決めたもの
ソフトウェアテスト293の鉄則 p256
鉄則278 テスト計画は戦略、段取り、成果
物の三位一体と心得よ
Test Strategyテスト戦略は一度つくって終わりというものではない
テスト戦略はテスト全体のアーキテクチャ、テストスイートの設計、テストケースの設計について方針を与える。そしてその方針を決定する要因は多岐にわたる
Policyfrom「体系的ソフトウェアテスト入門」
リスク(障害の影響、障害の可能性)
アプリケーション(ソフトウェアの品質、システムの性質、取得戦略)
テスト環境（開発ラボ、アルファテストまたはベータテスト、本番環境の模写、ユーザビリティテストラボ、モデルオフィス）
テスト要件（完全性、正確性、安定性）
レビュー戦略（ウォークスルー、インスペクション、机上チェック）
リソース（金、時間、人、スキル）
テスト目的（使用性の例証、破壊テスト、インタフェースのチェック、欠陥の予防、カバレッジ）
テストツール（何を自動化するか、どのようなツールを使用するか）
Strategy meets Automation
「何を自動化するのか」
「テスト環境」
「テスト目的」
Agenda
デプロイメントパイプライン
テスト戦略
Deployment Pipeline Example
システムの状態遷移図はかなり大きく、網羅的に自動テストをすると半日以上かかってしまう
チームは自分が改修した部分のみしか把握していない、本当にシステムが正常にデプロイできているかを確認するテストが勘になりつつある。
共通部分の改修などで他への影響を素早く確認するためにもコンポーネントレベルでの動作が出来ていることを初にテストする
各開発者が把握していない機能が多数あることから、出来るだけ自分が把握していない機能との連携も自動的にテストケースを生成する
システムが正常にデプロイできているかを簡単に確認するためのテストを各デプロイ先でまず実行する。
システムが巨大なため、インテグレーションレベルでのテストはいくつかに絞るが、絞り方は出来るだけバグが出やすそうな部分をプログラムで判断させるようにすることで、自動テストを有効活用する。
システムが巨大なため、網羅的にテストするのは開発者がいない時間帯に自動的に実行させる。
優先順位の高いものから先にチームにフィードバックするためのデプロイメントパイプラインの理想と、それを実現する手法を考える必要がある。
手段だけを考えても、それがデプロイメントパイプラインでボトルネックになっていない部分にしか適用が出来ないのだとしたら、局所 適化であり、テスト全体の改善には繋がりにくい。
コミットステージではユニットテスト、コンポーネントテストを実行する。
クラスやモジュールを単一もしくは複数組み合わせる単位でのテストである。ここではシステムがデプロイされている必要はない。
受け入れステージでは、スモークテストおよびインテグレーションテストの一部を実行する
インテグレーションテストレベルではコンポーネントテストレベルにおいて組み合わせが起きなかったユースケース間のテストも存在する
特定のカバレッジを満たすようなスモークテストを人間が選択することは非常に難しい
そこで巡回セールスマン問題を解くためのアルゴリズムを使うことで、このスモークテストを生成する！！
コンプリヘンシブステージでは、スモークテストと網羅的なインテグレーションテストを実行する。
スモークテストに関しては、受け入れステージで行ったものと同様のテストケースを実行する。網羅的なインテグレーションテストは十分に実行可能な時間を確保して定期的に実行する。
網羅的なインテグレーションテストはシステムを表現しているグラフを可能な限り網羅する形でテストケースを生成する。
キャパシティステージでは、スモークテストとキャパシティテストを実行する。スモークテストに関しては受け入れステージで行ったテストケースと同様のものを実行する。
キャパシティテストはいわゆる性能テストと言ってよいだろう。１処理あたりの量を変化させたり、複数処理の実行だったり、並列数を変化させたりなどして、速度や時間を計測する。これらは本番環境に近ければ近いほどいい
UAT(User Acceptance Test)ステージではスモークテストと、手動テスト、アドホックテスト、探索的テストを実行する。スモークテストに関しては受け入れステージで行ったテストケースと同様のものを実行する。
このステージで、自動生成されないようなテストケースおよび実際に人間による判断が必要な部分をテストする。
本番ステージではスモークテストを実行する。この環境はいわゆるエンドユーザーが使用する環境。
スモークテストが完了したら、Webアプリケーションであればユーザーが使えるようにスワップを実行したり、サーバーを切り替えたりする
Agenda
デプロイメントパイプライン
テスト戦略
Conclusion
Conclusion
デプロイメントパイプラインを効果的に実装するにはテスト戦略は必須である
テスト戦略がなっていないと、自動化の効果は低い
