Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to アジャイル開発におけるシステムテストの自動化
Similar to アジャイル開発におけるシステムテストの自動化 (20)
More from Toru Koido
アジャイル開発におけるシステムテストの自動化
- 1. アジャイル開発における システムテストの自動化 小井土 亨 • アジェンダ • システムテストとは • アジャイル開発とシステムテスト • システムテストの自動化について
- 2. 2 システムテスト システムテストとは システムテストとは システムが全体として正しく動作することをテストする 様々な視点でのテストが必要、特に利用ユーザー視点 システムテストの例 運用テスト 実運用に近い環境で、実際に運用するテスト 操作性テスト 利用ユーザー視点で、操作を行うテスト 構成テスト 様々な構成パターンでのテスト マニュアルテスト マニュアル通りに操作して問題なく動作することを確認するテスト 2
- 3. 3 システムテスト システムテスト ＝ エンドツーエンドテスト システムテストは、エンドツーエンド テスト end to end とは 端から端まで システムの端から端までをテストする 全体として正しく動作することを確認するため 3 システム入力 外部 出力 外部 エンド・ツー・エンド テスト
- 4. 4 システムテスト エンドツーエンドテストについて エンドツーエンドのシステムテスト 外部からの入力に対応したシステムの動作によって、外部に対して 行った結果をテストする なぜ、エンドツーエンドテストなのか 部分に対するテストを積上げても、繋がっていることを保証できない システムテストの結果 外部への出力 画面、通信、印刷、ファイル 外部システムへの処理 データベース、外部のサービス エンドツーエンドテストの特徴 テストの実行時間が長い場合が多い テストの準備や結果判断は、システム外部も含めて行う必要がある 4
- 5. 5 アジャイル開発とシステムテスト アジャイル開発におけるシステムテスト アジャイル開発におけるシステムテスト システムテストの目的は、開発手法によって変わることはない 様々な視点でのシステムテストが必要 人の手によるテストは、非常に有効で重要です アジャイル開発ならではのシステムテスト システムテストを実施する回数が多い リリースごとに、システムテストを実施する必要がある システムテストのコストが増大する
- 6. 6 アジャイル開発とシステムテスト テストコスト増大への対応策 対応すべきシステムテスト リリースごとに繰り返されるテスト 前回までのリリースで提供した機能について、同じように動作する ことを確認するテスト 回帰テスト（リグレッションテスト） 今回のリリースと前回のリリースで同じことを確認する 構成テスト さまざま構成で同じテストを実行し、同じ品質であることを 確認する テストを自動化する
- 7. システムテストの自動化について 方針 エンドツーエンドを目指す 100％のエンドツーエンドでなくても、有効と判断できれば自動化する カイゼンを継続する 自動化できる部分から自動化を開始する 自動テストからフィードバッグを得る テストの効果を向上させるためには、カイゼンが必要 理想と現実を近づけるためには、カイゼンする カイゼン対象に聖域なし 自動化に必要であれば、あらゆる可能性を検討する 7 完全性を待たず、改善を作業に取り入れる （完全な状態だけを求めると、十分になる機会を失うことになる） ＸＰ第2版
- 8. 8 システムテストの自動化について 開発の初期段階で行うべきこと 理由 メンバー全員が最初からテストの自動化に取り組むことを 宣言するため システムテストを効率的に自動化するためには、様々な障 害が内在する、それをアイデアで乗り越えるため やるべきこと テスト容易性を高くすることに注力する テストを自動化のために必要であれば、ユーザー要求にな い機能であっても実装する ☑開発ガイドラインに「テストの自動化を追求する」と記述する
- 9. システムテストの自動化について 注意すべきポイント（例） 時間 理由 テストの実行時間から無駄な待ち時間を無くす 例 処理間の待ち時間が1時間固定 時間（時刻）の束縛からテストを解放する 例 午前0時にしか実行されない機能 方法 時間について外部から制御可能とする 外部の定義情報で変更可能とする 9
- 10. 10 システムテストの自動化について 分析・設計段階で行うべきこと 理由 テスト容易性を追求することで、設計品質が向上する システムの重複が多いと、同じようなテストをたくさん用意し なければならなくなる ＧＵＩを使用しないＡＰＩを用意できれば、自動化が容易にな る やるべきこと ＴＤＤを導入し、内部品質を向上させる ☑テスト容易性を追求した設計を行う ☑設計の基本「Don’t repeat yourself」を守る（重複を避ける） ☑GUIでしか実行できない機能をできる限り作らない
- 11. 11 システムテストの自動化について システムテストの作成について 理由 システムテストは、様々な視点で行うことが有効 メンバーの様々な視点でテストケースを作成する システムテストでは、準備や結果比較も容易ではない 様々なツールや技術を組合わせることが必要となる やるべきこと テストケースの記述方法の抽象度を上げる テストケースがテスト目的の視点で記述できる テストケースの作成コストを低くする ☑テストケースは、メンバー全員で作成する
- 12. システムテストの自動化について テストケースの記述方法の粒度とは 抽象度を上げるべき理由 抽象度が高いとテストケースの作成コストが低くなる 抽象度が高いとテストケースが理解しやすくなる テストケースの保守コストも低くなる 例 実行ボタンを押す 抽象度が低いテストケースの例 マウスを座標(xx,xx)に移動する マウスの左ボタンをクリックする 10秒待つ 抽象度の高いテストケースの例 12 種別 ID ボタン 実行ボタン
- 13. システムテストの自動化について デバッグ機能 デバックとしての機能 問題の通知 ソフトウェアに問題が発生したことを通知する 状況の提供 ソフトウェアの内部状況を提供する 状況の再現 ソフトウェアの内部状況を再現する 13 製品 デバッグ機能 検査ツール
- 14. システムテストの自動化について デバッグ機能 概要 製品機能として提供 製品の一部としてデバッグ機能を提供する 製品内部で動作し、精度の高い機能と情報を提供する 製品の本体とは独立して動作させる 検査プロセスでの利用 内部状況を提供と再現を利用して、システムテストを実現 内部情報の表現方法は、形式したテキスト – 抽象度の高いテストケースの作成を実現 トレース方式でない、再現機能 問題の発生後に、状況を収得し、再現する 14
- 15. システムテストの自動化について デバッグ機能を使用したシステムテスト 特徴 高い状況再現性の提供 抽象度の高いテストケース 分かりやすくメンテしやすいテストケース 自動でのテストケース作成が可能 デバッグの機能 再現状況を受信し、内容を解析して再現する 解析処理を実装することで、 システム内部で動作する スレッドモデルの対応などを行うことも可能 詳細な処理結果を提供する 処理の結果判断に利用する 15
- 16. システムテストの自動化について テスト実行時の同期/非同期について ユーザーインターフェイスのスレッド（UIスレッド） メインスレッド ＵＩの操作は、必ずこのスレッドを使用する シリアライズ（順次処理）される ＵＩの操作は、順番に処理される 待ち状態が発生する場合あり マーシャリング スレッドの境界を越えて処理を呼出す機構 テストのスレッドからコントロールを操作する場合、UIスレッドへの マーシャリングが必要となる テストでは、最低２つのスレッドが存在する テスト対象のスレッド テストのスレッド 16
- 19. システムテストの自動化について 同期テストと非同期テスト 同期テスト 利点 同期テストは、無駄な待ちが必要ない 欠点 システムが止まるとテストも止まる 非同期テスト 利点 システムの動作を監視できる 欠点 再現率か低い 待ち時間を事前に想定することが難しい システムテストと同期・非同期 時間が掛かるシステムテストでは、同期テストが効率的 同期だけでは再現できない場合があり、非同期との使い分けが必要 19
- 20. 20 システムテストの自動化について システムテストの運用で行うべきこと 理由 システムテストの実行には、時間が掛かるため、効果的に 運用するためには様々な工夫が必要となる 自動化はゴールではなく、新たな自動化へスタート テスト結果からのフォードバックには、様々な情報が含まれ ている やるべきこと テストケースを色分けして、実行計画を作成する テストの実行は、夜間や休日を有効に利用する テスト結果を分析し、新たなテストケースを作成する ☑自動化したテストを効率的・効果的に運用するためにはコストが必要 ☑テスト結果からフィードバッグで運用を改善する
- 21. システムテストの自動化について 自動テストの運用計画（例） テストケースを色分けする 毎日行うテストケース 週に一回は実行するテストケース 実行しないテストケース システムテストの運用計画 一週間を実行単位とする 週末のテスト（金曜日の夜から月曜日の朝まで ） すべてのテストケースを実行 日次のテスト（その日の夜から次の日の朝まで） 毎日行うとマークされたテストケースを実行 週末のテストで、エラーとなったテストケースを実行 テスト結果からのフィードバック テストケースの色分け変更や追加、テストマシンの追加を検討する 21
- 22. 22 システムテストの自動化について まとめ 理由 テストすることが目的ではない 人の手によるテストは非常に重要である テストの自動化にはコストが掛かるので、効果のあるところから自動化 を開始する テスト結果を予想することが難しいのでカイゼン（再計画）が有効 やるべきこと システムのリスクを考慮し、自動化することで効果のあるところから自 動化に取り組む できるだけ早い段階から開始し、システムに対するフィードバックを得る 機会を作る ☑自動化を目的にしない ☑システムテストをすべて自動化しない
- 23. 2323 参考文献 ＸＰ エクストリーム・プログラミング入門 変化を受け入れる 第2版 Kent Beck 実践テスト駆動開発 Steve Freeman・Nat Pryce トヨタ生産方式 脱規模の経営をめざして 大野 耐一 著