Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a テスト自動化とアーキテクチャ
Similar a テスト自動化とアーキテクチャ (20)
Más de Toru Koido
テスト自動化とアーキテクチャ
- 2. 2 アジェンダ システムテストの自動テストとアーキテクチャ システムアーキテクチャ
- 3. システムテストの自動テストとアーキテクチャ 1.システムテストとは 2.自動テストのシステム構成 3.システムごとのアーキテクチャ定義 4.自動テストシステムに要求される品質特性
- 4. システムテストとは システムテストとは システム全体を対象としたテスト システムテストの特徴 1つのテストケースを行う時間が長い 回帰テスト、構成テスト、パフォーマンステストなど多様 自動化されたシステムテストとは 「~と同じ」という確認を行うことが主な目的 繰り返し実行するテスト 4 起動操作終了 これを検査
- 5. 自動テストのテストケースの構成 テストケースの仕様 テストケースの目的/概要など テストデータ テストケースを実行するための初期データ テストスクリプト テストの実行手順を記述したスクリプト 想定結果 テストが成功したか失敗したか判断するために用意する結 果 想定結果には、ファイルとして用意する場合や判断するた めのスクリプト内に用意する場合など様々 5
- 6. 自動テストとは 自動テストはシステム 自動テストは、検査を実行するシステム 自動化されたシステムテストとは システムをテストするという目的を持ったシステム 6 検査対象のシステムシステムを検査するためのシステム 検査という 明確な目的と機能
- 7. 自動テストのシステム構成 自動テストのシステム構成 二つのシステム テスト対象システム 自動テストシステム 自動テストシステムのサブシステム テストケースの作成 テストケースの実行 自動テストの運用 7 自動テストシステム テストケースの作成 テスト対象システムテストケースの実行 自動テストの運用
- 8. システムごとに異なった関心事 自動テストの観点からの関心事 テスト対象システム テストしやすいシステムであること テストケースの作成 効率よく作成できること テストケースの実行 確実に実行できること 自動テストの運用 上手にテストの運用を行うこと 各システムと品質特性 システムごとに異なった品質特性の要求がある 品質特性を具体化するために、アーキテクチャを定義する アーキテクチャ＝ 品質特性に基づく方針や構造など 8
- 9. システムごとのアーキテクチャ アーキテクチャを構築する対象 自動テストを構成するシステムは複数であり、それぞれ異なった関心事 を持つため、各システムごとにアーキテクチャを定義する必要ある 更にプロジェクトごとに自動テストに要求する品質特性が異なるため、 プロジェクトごとに各システムのアーキテクチャを定義する必要がある システムごとのアーキテクチャを定義 9 テスト対象システム 自動テストシステム テストケースの作成 テストケースの実行 自動テストの運用 テスト対象システムのアーキテクチャ定義 テストケースの作成アーキテクチャ定義 テストケースの実行アーキテクチャ定義 自動テストの運用アーキテクチャ定義
- 10. アーキテクチャ定義の手順 アーキテクチャ定義の手順（通常のシステムアーキテクチャ定義と同じ） 品質特性の分析 品質特性の具体化 アーキテクチャの定義 パターンを利用してアーキテクチャを定義する 10 品質特性を リストアップする 各品質特性の 具体的なゴールを 決める 品質特性の 優先順位などを 分析する アーキテクチャ定義 アーキテクチャ アーキテクチャ パターン アーキテクチャ パターン パターン 利用
- 11. 自動テストシステムに要求される品質特性 「テスト対象システム」に対する品質特性 操作性（実行性） 自動テストのプログラムから対象のプログラムを実行し、制御でき ること 確認性 対象のプログラムを実行した結果が確認できること 再現性 テストを行う特定の状況を再現できること 11
- 12. 自動テストシステムに要求される品質特性 「テストケースの作成」に関する品質特性 理解性 テストケースが読みやすく理解しやすいこと テストケースを容易に作成することができること テストケースができるだけ多くのメンバーが作成できること 効率性 多様で効果的なテストケースを適切なコストで作成できること 保守性 テストケースはテスト対象の変更に素早く対応する必要がある テストケースの変更が容易であること 拡張性 テストケースの機能を必要に応じて拡張できること 12
- 13. 自動テストシステムに要求される品質特性 「自動テストの実行」に関する品質特性 安定性 テストケースを安定して実行できること 同じテストケースを何度でも安定して実行できること 信頼性 テスト結果の判定が信頼できること 移植性 異なった環境でテストを実行できること 13
- 14. 自動テストシステムに要求される品質特性 「自動テストの運用」に関する品質特性 効率性 必要な自動テストを効率的に運用することができること 柔軟性 状況に合わせて、柔軟な運用ができること 障害許容性 対象のプログラムで予測しないエラーが発生しても、他のテストケ ースが継続的に実行できること 並列性 複数の環境で効率的にテストを並列して実行できること 14
- 16. 「目的はChecking」 問題 自動化したシステムテストの良い使い方が分からない システムテストを自動化してコスト的に問題ないかわからな い 解決策 自動化したシステムテストは、ある時点やある環境と現在 や他の環境との比較して、壊れていないことを確認するも のである 比較する状況の発生と回数と自動化するコストを比較して コストメリットを考える 効果 的確に壊れていることや問題があることが発見できる Checking以外のテストに人手を回すことができる 16
- 18. 「同期で操作」 問題 テストしたい処理の処理時間が不定期で、事前に待ち時間を想定でき ない 長い待ち時間で実行すると無駄な待ちが発生して、実行時間が長くな ってしまう 解決策 テスト対象のシステムに同期通信で外部から処理を呼び出す機能を実 装する 効果 処理時間を気にしないでテストスクリプトを作成できる 待ち処理が必要ないため、高速にテストを実行することができる 注意 確認ダイアログなどが表示されると処理が止まる 18
- 19. 「ソフトウェアで処理するためのID」 問題 テスト結果を取得したいのにIDがなく処理できない IDが実行ごとに異なりテストスクリプトで処理できない 解決策 結果を表示するような場合でも、必ずIDを用意する 固定的なIDを用意する 自動テストだけで利用する連番IDなども検討する 効果 自動テストで操作しやすく、確実に実行できるようになる テストスクリプトの共通化が可能となる 注意 人間が理解しやすいIDとソフトウェアが処理しやすいIDは 異なることが多いため、複数のIDが必要となる 19
- 20. 「テストケースの作成」のパターン 1.シナリオをユースケースで分析 2.粒度の調整 3.テストスクリプトに共通変数 4.正しいのは以前の自分 5.時間への挑戦
- 21. 「シナリオをユースケースで分析」 問題 テストスクリプトに重複部分が多く、作成や保守コストが掛かる テストスクリプトを作成するために、テストシナリオを分析したいが方法 わからない 解決策 似ているテストシナリオを基にユースケースを作成し、ユースケースご とに、テストスクリプトの作成方法を決定する 効果 重複がなくなり、作成や保守コストを下げることができる 例 ECサイトでの商品の購入 ユースケース的には、以下の3つから構成される – ログイン＞ 商品の選択＞ 決済 「ログイン」と「決済」は重複されることが多い、また、処理フローはある程 度限定される 「商品の選択」は検索やキャンセル、個数の変更などバリエーションが多い 21
- 22. 「粒度の調整」 問題 テストスクリプトを作成できるメンバーが限定される テストスクリプトの品質が安定しない テストスクリプトの作成と保守コストが掛かる 解決策 テストスクリプトを複数の粒度で実装できるようにする 粒度は以下のようになる ドメイン言語＞ スクリプト言語＞ プログラム言語 例：タブ区切りのテキスト＞ PowerShell ＞ C# 効果 バリエーションが必要な部分の粒度を大きくすることで、テストスクリプト 全体の作成と保守コストを下げることができる 粒度の大きい部分の作成は重熟度があまり必要ないためチームメンバ ー全員が作成することができるようになる 粒度の大きい部分は、ツールとの組み合わせで自動生成が可能であ る 22
- 23. 「テストスクリプトに共通変数」 問題 環境を変えるとテストスクリプトが正しく動作しない 環境に合わせてテストスクリプトを変更すると保守コストが爆発する 解決策 テストスクリプトに共通変数を導入する 環境に依存する部分は、テストスクリプトではなく共通のファイルに定義 する 自動テストの実行時に、共通定義内の値でテストスクリプトを変更する 効果 テストスクリプトを書き換えることなく、待ち時間や実行年月日などを実 行時に設定することができる 環境ごとのテストスクリプトを作成する必要がなくなる 23
- 24. 「正しいのは以前の自分」 問題 システムテストの正しい結果を事前に用意するのにコスト が掛かる 実行できたかどうかだけで、成否を判断している 解決策 ある時点、ある環境の結果を正解とする 検査時は、検査の結果と正解を比較して、成否を判断する 効果 実行結果を正解とすることで、容易に結果を用意できる 正解とした結果の内容を確認しないと、間違った結果を正 解としてしまう可能性がある 24
- 25. 「時間への挑戦」 問題 システムで利用する時間が実行ごとに異なるため、結果が 必ず異なってしまう システムの環境によって実行時間が異なるため、安定して 実行できない 解決策 時間取得部分を一か所にして、モック化する 結果判断から時間を除外する 同期で処理を行う 効果 システムにより結果判断が可能となる 安定した自動テストの実行が可能となる 25
- 27. 「非同期で操作」 問題 テストしたい処理の中で、確認メッセージや確認入力があり、同期では 処理が止まってしまう 解決策 APIなどを使用して、テスト対象のシステムを非同期で外部から処理を 呼び出す 確認処理の呼出し部分を非同期で行う、確認処理は同期で行う 確認処理を同期で処理することで、状態の変更待ちなどが可能となる 効果 同期では止まってしまう処理を実行できるようになる 注意 待ちを時間で行う場合、事前に時間を想定する必要がある 27
- 28. 「スクリプトで実行」 問題 システムテストを実行するための関連システム（データベースなど）の設 定が自動で行えない 解決策 システムテストの実行に、スクリプト言語を導入する スクリプト言語を利用して、データベースなどの設定を行う 効果 スクリプト言語は、システム間の連携のための機能が豊富で、容易に 他システムとの連携ができる 28
- 29. 「自動テストの運用」のパターン 1.自動テストの運行スケジュール 2.テストケースのランキング 3.自動テストの並行実行
- 30. 「自動テストの運行スケジュール」 問題 自動テストの実行とプロダクトのリリースタイミングが合わない システムテストの実行時間が長く、すべてのテストを効率よく運用できな い 解決策 自動テストの実行スケジュールを日次、週次、月次で考える 日次は夜間の１２時間、週次は金曜日の夜から月曜日の朝までの６０ 時間で実行できるテストケースを選びスケジュールを作る 週次で実行して成功したものは日次からは除外するなどのルールを作 る 効果 プロダクトの日次、週次、月次にあった、テストの実行を行うことで、タイ ムリーな実行結果を提供できるようになる 注意 正しくテストケースを分類しないと、効果が出ない 30
- 31. 「テストケースのランキング」 問題 システムテストの実行時間が長く、すべてのテストを効率よく運用できな い 必要ないテストケースを削除することができず、テストケースが増大して いる 解決策 テストケースにランクを付けることで、効果的なテストケースと必要ない テストケースの分類を行う 効果的なテストケースとは、過去に問題を発見したもの よ週次で実行して成功したものは日次からは除外するなどのルールを 作る 効果 プロダクトの日次、週次、月次にあった、テストの実行を行うことで、タイ ムリーな実行結果を提供できるようになる 注意 ランク付けにコストが必要になる、システム化も検討 31
- 32. 「自動テストの並行実行」 問題 システムテストの実行時間が長く、実行時間が足りない 解決策 複数のマシンで、並行して自動テストを実行できるようにする 以下の３つのテストケースの結果リストを共有する 成功したテストケース/失敗したテストケース/現在実行中のテストケース テスト対象のテストケースのリストから上記３つに含まれないテストケー スを探して実行する 効果 飛躍的に実行時間を増やすことができ、タイムリーに検査結果を得るこ とができる 注意 並列実行できるからといって、無駄なテストケースをそのまま運用する と結果も膨大になり効率が悪いので、テストケーズの削除を怠ってはな らない 32
- 33. 参考 システムアーキテクチャ 1.システムアーキテクチャ 2.設計品質特性 3.システムアーキテクチャの定義 4.システムアーキテクチャの構築 5.システムアーキテクチャの複数のビュー 6.設計品質特性
- 34. システムアーキテクチャ システムアーキテクチャとは システムの構造や構造化の原則 システムアーキテクチャの目的 システムの品質特性を強制（支配）する構造を構築する 品質特性とは システムが実現するべき品質の特徴 代表的なもの パフォーマンス（性能・速度） 安全性 信頼性 可用性（Availability） 堅牢性（セキュリティ） ユーザビリティ（使いやすさ） 拡張性 34
- 35. 品質特性の分析 ４つの視点による分析 センシティビティ分析 品質特性に良い効果を表す仕組み 論理的な根拠 コンフリクト分析 副作用として、他の品質特性に悪い影響を与える制約 論理的な根拠 トレードオフ分析 複数の品質特性間で良い影響と悪い影響ものの優先順位 正当性の根拠 トレードオフ関係表 リスク分析 トレードオフによってサービスレベルが低下する要求品質に対する リスクの識別し、影響の出る損失 正当性の根拠 35
- 36. 品質特性の具体化手順 品質特性に対するステークホルダを明確化する 例：拡張性 プログラマの拡張性 利用者の拡張性 目的や達成すべきゴールを具体的に定義する ポイント 成果物が目的に合っているか、判断できる内容で記述する 例：拡張性 利用者が機能を拡張できるように、外部ファイルに拡張機能を定義 できるようにする 例：ユーザービリティ 5秒以上掛かる処理は、処理の進行状況を通知する 目的やゴールの理由を説明する 36
- 37. 37 システムアーキテクチャの定義 システムアーキテクチャの定義 複数の定義が必要 複数の角度からの表現を組み合わせて定義を行う システム開発のビジョンを実現するために必要なシステム 構造 構造化原則 抽象的な構造やガイドライン 概念的な構造（モデリング） ANSI/IEEE Std 1471-2000 構成要素を統合したシステムの基本的な構造，構成要素 の相互および構成要素と環境間の関係，そしてシステム設 計と発展を導く方針 全体の分け方と、分けた部分をどのように関係づけるか
- 38. システムアーキテクチャの構築 システムアーキテクチャへの要求 達成すべき品質特性への要求 各品質特性は、相反する項目がある トレードオフを考慮し、アーキテクチャを決定する 要求の種類 非機能要求 長期的な機能要求 システムアーキテクチャ構築時の考慮点 可変性 変わる要求と変わらない要求の分析 リスクの方針 さまざまの視点からリスクの洗い出しと方針を決定 38
- 39. 39 アーキテクチャの複数のビュー ビューポイントとは ステークホルダの関心事に応じた視点 ビューとは 複数の関連した視点（ビューポイント）によって、アーキテクチャを記述 するものがビューである ４つのビュー 論理ビュー システムが必要とされている機能を実現する、論理的な構造 実行ビュー 実行時のプロセスやタスクやスレッドといった実行時の単位の構造 開発ビュー システムが開発時のファイル等を単位とした構造 配置ビュー システムをどのようなマシン上で動作させ、各プロセスがどのマシン（CPU) 上に配置される等を表した構造
- 40. 40 設計品質特性 正確性 仕様を正しく満たしていること 理解性 設計結果が読みやすく理解しやすいこと 一貫性（統一性） 設計上の個々の概念が首尾一貫して、ぶれがない 変更容易性 機能強化などに伴う変更が容易であること 頑健性 誤った使い方に対して、システムが適切に対処できること システムの一部のバグが全体に波及しないこと 移植性 いろいろなハードウェア、ソフトウェア環境へ容易に移植できること 効率性 実行効率、資源効率ともに十分実用に適応していること
- 41. 品質特性ISO/IEC 25010：2011 利用時の品質 有効性 効率性 満足性 実用性 信用性 快感性 快適性 リスク回避性 経済リスク緩和性 健康・安全リスク緩和性 環境リスク緩和性 利用状況網羅性 利用状況完全性 柔軟性 41
- 42. 品質特性ISO/IEC 25010：2011 システム／ソフトウェア製品品質 機能適合性 機能完全性 機能正確性 機能適切性 性能効率性 時間効率性 資源効率性 容量満足性 互換性 共存性 相互運用性 使用性 適切度認識性 習得性 運用操作性 ユーザエラー防止性 ユーザインタフェース快美性 アクセシビリティ 信頼性 成熟性 可用性 障害許容性（耐故障性） 回復性 セキュリティ 機密性 インテグリティ 否認防止性 責任追跡性 真正性 保守性 モジュール性 再利用性 解析性 修正性 試験性 移植性 適応性 設置性 置換性 42
- 43. 43 参考文献 実践ソフトウェアエンジニアリングロジャーS・プレスマン 森口繁一編『ソフトウェア品質管理ガイドブック』日本規格協会(1990) アジャイルソフトウェア開発の奥義ロバート・C・マーチン 日経ソフトウェア「正しく学ぶソフトウェア設計」 ソフトウェアアーキテクチャ岸知二、野田夏子、深澤良彰 ＩＴ アーキテクチャ・メタモデルセマンティック解説ITスキル標準V2 2006 アーキテクトの審美眼萩原正義