A4-3

Transcription

1 今回のテスト題材 Google 社が提供するフリーの Web Web と POP3 SMTP IMAP に対応し 転送も可能である 現在 53 カ国語に対応 全世界で ユーザ数は数億人に達しており (Google 社より正確な数字を公開していない ) 第三位のサービスとなっている テストの範囲 今回のセッションでは テストアーキテクチャを分かりやすく説明するために テストの対象とするを一部に限定しています 前提として 携帯電話等との連携は考慮しないものとします アカウント : ログイン : アカウントの作成 :Gmail の設定 : や連絡先のインポート : 連絡先の管理 : バズ : 優先トレイ :Labs :Google の保存容量 : セキュリティセンター Gmail へのその他のアクセス方法 :POP :IMAP : オフライン メッセージ : チャット : 作成と : : 閲覧 : ラベルとフィルタ : 削除 : : 検索 : 迷惑 : 疑わしいメッセージ : お知らせ :Google Apps Sync for Microsoft Outlook My テストアーキテクチャの流れ 1 テスト対象の整理 2 テスト目的の展開 仕様書などから を階層的に整理し 全体像が分かるようにする 何を確認するのか? という視点で テストの目的を詳細化していく JaSST 11 Tokyo 智美塾テストアーキテクチャ 2011/01/25 エスエムジー株式会社鈴木貴典 3 テストアーキテクチャマップの作成 JaSST'11 Tokyo A 4 智美塾テストアーキテクチャ鈴木貴典 テスト対象とテスト目的から それらの関係性を示す マップを作成する 4 1 テスト対象の整理 2 テスト目的の展開 網羅性を意識して ( もしくは要件 ) を 階層的に整理する 何を確認したいか? という視点で テストの目的を詳細化していく には 何かしらの他のと関連する場合があるが マインドマップでは示しにくいため 関連線を補足して整理する 今回は テストアーキテクチャの流れをメインとしているため 一部の要素は割愛しています JaSST'11 Tokyo A 4 智美塾テストアーキテクチャ鈴木貴典 5 第 1 階層 ( / 非 / 制約 ) は 原則固定 階層の詳細化は 品質属性モデルのひとつである FURPS+ をベースにしている 今回は テストアーキテクチャの流れをメインとしているため 一部の要素は割愛しています JaSST'11 Tokyo A 4 智美塾テストアーキテクチャ鈴木貴典 6 1

2 3 テストアーキテクチャマップの作成 3 テストアーキテクチャマップの作成 マトリクス形式で と観点との関連をグループ化する 標準仕様性能 プロトコル 形式 作成と 転送 テストフレーム 下書き 指定 の 他プロバイダからの テストバスケット ( 横方向 ) 閲覧 スレッド アーカイブ テスト対象視点 未読 / 既読の管理 宛先 メッセージ JaSST'11 Tokyo A 4 智美塾テストアーキテクチャ鈴木貴典 7 件数 サイズ スループット レスポンスタイム 大量データ テストバスケット ( 縦方向 ) テスト目的視点 テストバスケットに対して テストレベル テストタイプを決める 標準仕様性能 プロトコル 形式 作成と 転送 下書き 指定 の 他プロバイダからの 閲覧 スレッド アーカイブ 単体テスト テスト 境界値テスト 未読 / 既読の管理 総合テスト 性能テスト 宛先 メッセージ JaSST'11 Tokyo A 4 智美塾テストアーキテクチャ鈴木貴典 8 件数 サイズ スループット レスポンスタイム 大量データ 3 テストアーキテクチャマップでの整理 1. 視点に応じて テストバスケットを複数指定する テストアーキテクチャマップ全体を網羅するように テストバスケットを決める テストバスケット同士で 重なる部分があっても良い ただし その場合は 異なる部分 ( テストタイプなど ) が明確に分かるようにする 2. テストバスケットに対して テストレベル テストタイプを割り当てる テストのタイミングと方法が決定する 3. テスト対象が大きい場合は テストアーキテクチャマップを 階層化して整理しても良い My テストアーキテクチャ設計のポイント 1. マインドマップは 3 階層以上で整理する 階層 テスト対象 テスト目的 第 1 階層 サブシステム / グループ 非 制約 第 2 階層 / 画面 出力 / 性能 信頼性 保守性など 第 3 階層 / 操作 システム特性に応じた詳細化 第 4 階層以上 状態 遷移 パターンなど 2. マインドマップで整理する際に 重要度 優先度などを付けるなど プロジェクトや組織のニーズに応じて拡張する リスクベーステストなども 設計しやすくなる JaSST'11 Tokyo A 4 智美塾テストアーキテクチャ鈴木貴典 9 JaSST'11 Tokyo A 4 智美塾テストアーキテクチャ鈴木貴典 10 メリット 1. テストアーキテクチャ設計を一定のステップで行うことにより テスト設計の品質自体が安定する 担当者によるバラつきや漏れを低減する 2. テスト設計者の思考 視点を共有しやすい マインドマップは中間作業成果物だが それを利用することで テスト関係者だけでなく 設計 開発者ともコミュニケーションを取りやすくなる 3. テスト目的の再利用が可能である 同類のシステムであれば テスト目的も類似のモノになる 本アーキテクチャでは テスト目的を テスト対象と別に作成するため 再利用がしやすい 4. テストの重複を回避する テストアーキテクチャマップで テストレベル テストタイプを整理することで 異なる工程で 同じようなテストをする無駄を省ける 5. 仕様 設計漏れに気づきやすい テスト対象とテスト目的の関連性を整理することで 仕様 設計の漏れを検出しやすくなる Gmail のテストアーキテクチャ - 魁!! 智美塾テストアーキテクチャという考え方の提案 - JaSST'11 Tokyo 電気通信大学大学院智美塾一号生河野哲也 JaSST'11 Tokyo A 4 智美塾テストアーキテクチャ鈴木貴典 11 2

3 テストアーキテクチャ設計の流れ 1) テストアーキテクチャの構成要素の洗い出し ユーザ視点 / / 作りの3つの着眼点で構成要素を横断的に洗い出していく 2) 構成要素の整理 構成要素に漏れがないかを確認 構成要素間の関係を明らかにしていく 明らかにした関係に基づいてどのレベルでどのようなテストを行うかを検討しながらテストアーキテクチャを構築していく 1) テストアーキテクチャ構成要素の洗い出し ユーザ視点 / / 作りの 3つの着眼点で構成要素を横断的に洗い出していく ユーザ視点 : ユーザが求めることもしくはユーザに損害を与えないために求められること : ユーザ視点の要素を実現するための働きの集まり 作り : を実現するためのテスト対象の構造 1) テストアーキテクチャ構成要素の洗い出し : 解説 テスト観点をユーザ視点 / / 作りの3つの入れ物に分けていく 3つの着眼点をもとにテスト観点を洗い出す ここでは マインドマップを使っているが ツールは何でも良い ツリー構造のほうが直感的に分かり易い ユーザ視点 : テスト目的 : テスト対象作り : テスト対象 テスト対象 テスト目的 テスト対象 2) テストアーキテクチャ構成要素の関係の整理 テストアーキテクチャの構成要素の関係を表で整理する ユー情報を伝えたい 情報を知りたい 情報を探したい を管理したい ザ 楽にをしたい 視 他人のPCでも使用したい 点 直感的に操作したい : サクサク操作したい : パフォーマンス 自分の情報は第三者にはみれないようにしたい ログイン転送情報管理管理 パスワード タイトル 本文 キーワード 分類ラベル名 見出し 分類ラベル名 転送 閲覧 作 ラベル り 承認 検索 分類 消去 保存 出力 管理情報 情報管理情報 PC 機種 構成 OS 種別 ブラウザ種別 2) テストアーキテクチャ構成要素の関係の整理 : 解説 ユーザ視点 作りの関係で整理する ここでは T 型マトリクスを使って 横断的な検討が行えるようにしているがユーザ視点 と 作りの 2 つの表で整理しても良い 関係の整理 各交点に対して関係性を検討する ( 関係しているときは をつける ) 部分的な検討ができるようになる 漏れの確認 一つの着眼点のみだと ユーザ視点 情報を伝えたい 情報を知りたい 漏れが発生しやすいユー情報を探したい を管理したい ザ楽にをしたい ここでは漏れを視他人の PC でも使用したい 点直感的に操作したい : 確認するためにサクサク操作したい : パフォーマンス 自分の情報は第三者にはみれないようにしたい もう一つの着眼点ログイン転送情報管理管理 パスワード を使うタイトル 本文 が付いていないキーワード 分類ラベル名 行 列があると見出し 分類ラベル名 何らかの漏れがある 転送 作閲覧 りラベル 承認 検索 分類 消去 保存 出力 管理情報 情報管理情報 PC 機種 構成 OS 種別 ブラウザ種別 作りの交点の各 はテストフレームにつながる 各 はテスト対象 テスト目的を次で考える 作り 整理した表の 作り交点に基づいて - 作りの枠組みを作る 作りの交点の各 を抜き出してくるイメージ 枠組みに対してどのようなテストをすれば良いかを検討する テストタイプを当てはめていく 詳細から全体への視点で埋めていく 作り パスワードログイン承認 PC 機種構成 OS 種別ブラウザ種別タイトル本文転送構成 PC OS ブラウザタイトル本文転送転送構成 PC OS ブラウザ出力構成 PC OS ブラウザキーワード分類ラベル名閲覧ラベル情報検索管理分類消去保存出力情報管理情報構成 PC OS ブラウザキーワード見出し分類ラベル名ラベル検索管理分類消去保存出力管理情報構成 PC OS ブラウザ 3

4 ユーザ視点 整理した表の 作り交点に基づいて - 作りの枠組みを作る を抜き出してくるイメージ 枠組みに対してどのようなテストをすれば良いかを検討する テストタイプを当てはめていく 詳細から全体への視点で埋めていく 作りの視点 作り パスワードログイン承認 PC 機種構成 OS 種別ブラウザ種別タイトル本文転送構成 PC OS ブラウザタイトル本文転送転送構成 PC OS ブラウザ出力構成 PC OS ブラウザキーワード分類ラベル名閲覧ラベル情報検索管理分類消去保存出力情報管理情報構成 PC OS ブラウザキーワード見出し分類ラベル名ラベル検索管理分類消去保存出力管理情報構成 PC OS ブラウザ 要求の視点 サクサク操作したい : パフォーマンス自分の情報は第三者にはみれないようにしたい 他人の PC でも使用したい直感的に操作したい : 情報を探したいを管理したい楽にをしたい ログイン 転送 情報管理 管理 情報を伝えたい情報を知りたい ユーザ視点 整理した表の 作り交点に基づいて - 作りの枠組みを作る を抜き出してくるイメージ 枠組みに対してどのようなテストをすれば良いかを検討する テストタイプを当てはめていく 詳細から全体への視点で埋めていく 作り 単体レベル レベル 最大値 境界値 パスワード 最大値 境界値 統合テスト ログイン 承認 時間確認 ( 有効 無効含 PC 機種 む ) 構成 OS 種別 ブラウザ種別 タイトル 本文 最大値 境界値 最大値 境界値 テスト 時間確認 転送 時間確認 時間確認 タイトル 本文 最大値 境界値 最大値 境界値 テスト 転送 転送 最大値 境界値 時間確認 時間確認 テスト 最大値 境界値 出力 最大値 境界値 キーワード 分類ラベル名 閲覧 ラベル 情報 検索 時間確認 管理 分類 時間確認 消去 時間確認 保存 時間確認 出力情報管理情報 キーワード 見出し 分類ラベル名 ラベル 検索 管理 分類 消去 保存 出力 管理情報 複合レベル シナリオテスト シナリオテスト シナリオテスト システムレベル セキュリ ティ パフォーマンス : 解説 ユーザ要求のようなテスト目的から出てくるテストタイプと作り ( 実装 ) に関係して出てくるテストタイプがある 下から攻める と 上から攻める の両面で検討する 全体として何にしたいしてどのようなテストを行うのかの全体像が見える レビューがしやすい 次工程の部分的な範囲を 担当するテストエンジニアが回りとの関わりを把握しやすい 下位レベルと上位レベルのテストタイプの関係が見える 下位のテストの手抜きができなくなる 下位レベルで行うテストを決め上位でたくさんのテストを行うことを防ぐ : 効率化につながる 次工程で部分的な検討ができる 分業ができる - 作りとテストタイプをあわせてたもの : テストフレーム 各レベルでテストフレームをまとめたもの : テストバスケット 作りの視点 要求の視点 作り複合システム単体レベルレベルレベルレベル 最大値 境界値 パスワード最大値 境界値 統合テストログイン承認 時間確認 ( 有効 無効含 PC 機種む ) 構成 OS 種別ブラウザ種別タイトル本文最大値 境界値 最大値 境界値 テスト シ 時間確認ナ転送 時間確認リ 時間確認オセ構成 PC OS ブラウザーテキタイトルュストリ本文最大値 境界値 ティ転送最大値 境界値 テスト転送最大値 境界値 ユーー 時間確認構成 PC OS ブラウザーザビ 時間確認テストリ最大値 境界値 出力テ最大値 境界値 ィ構成 PC OS ブラウザー キーワードパ分類ラベル名シフ閲覧ォナラベルーリ情報検索 時間確認オ管理分類 時間確認マテ消去 時間確認ンス保存 時間確認スト出力情報管理情報構成 PC OS ブラウザーキーワード見出し分類ラベル名シラベルナ検索リ管理分類オ消去テ保存スト出力管理情報構成 PC OS ブラウザー テストバスケット テストフレーム ご清聴ありがとうございました そろそろ就職活動始めます!! JaSST'11 Tokyo 電気通信大学大学院智美塾一号生河野哲也 手順 : テストアーキテクチャ設計を行うときにすること 現時点での考え ( きっとこうだと思う ) 準備 ( 分析 ) の段階から記載する JaSST 11 Tokyo 智美塾 テストアーキテクチャについて 2011/01/25 智美塾塾生 : 坂静香 1. ( 準備 ) テストベースや関連ドキュメントやプロジェクト情報などを収集する 2. ( 準備 ) マインドマップで書き出す メインブランチは決め打ち テンプレートを使用 3. テストアーキテクチャ設計をすべく 構成要素ごとにまとめ直す これもマインドマップのテンプレートを使用 4. テスト対象とテスト条件を掛け合わせ その他の情報をもとにテストタイプと厚みを決める 5. 他のテストレベル ( あるいは別のチームが行うテスト ) と調整をはかる 4

5 まずは情報を洗い出してみる ( 分析 ) 抽出した情報を以下の分類 ( 要素 ) にまとめなおす これは準備段階 ( 分析作業 ) このようなブランチ ( テンプレートとして持っている ) にぶら下げていくかたちで情報を展開していく テストバスケット ( テストレベル ) 観点 2 テスト目的 観点 1 テスト対象 ( 振る舞い ) 観点 3 関連するモノ ( 対象物や環境など ) 厚みや順番を決めるための情報 テストバスケット ( テストの種類 やりかた ) 表にあてはめてみるこの表はテストレベルごとに作成する ココが テスト目的 着目点を列挙する 本題 :Gmail のテストアーキテクチャを考える 1. ( 準備 ) 洗い出しをする 着目点に関連するモノ ( テスト対象物や環境など ) をピックアップしておく どういう厚みにするか? を決めるための情報を書いておく ここからテストアーキテクチャ設計に必要な情報を抜き出して整理していく テスト対象 期待される振る舞いを列挙する 交点が テストフレーム の単位 ( ここに厚みとテストタイプを表示する ) 厚みの表現はまだ暫定 本題 :Gmail のテストアーキテクチャを考える 2. 構成要素にまとめ直す テスト対象 ( 振る舞い ) について 2. 構成要素にまとめ直す : つづき テスト目的 ( 着目点 ) について テストしない箇所 まとめてテストできる箇所なども分かるようにメモしていく 仕様書のを列挙するというより ユーザが求める振る舞いなど システムとして期待される振る舞いを列挙する まず全体をざっくりとみるために 大まかに分類している このあと もっと細かく分ける必要もあるかもしれない この時点では 多少詳細まで落とし込む ( 重複しそうな事項やどこに該当するか悩むものなど ) 具体的な事項をどこに位置させるか? を決める 5

6 テストで確認するもの表示操作動作遷移組み合わせ システム ( 製品 ) に対しテストが必要かどうか 着目点ごとに考慮するときに注目すべき対象物や環境 ( モジュールや部品 状態 ) テストの有無と厚みを決めるための情報 その他の情報 着目点 ( 仕様ビュー ) 着目点 ( 品質特性ビュー ) 性セキュリティ 性相互運用性 GUI 部品 可変表示部は各で確認 GUI 全体については環境毎のテストと兼ねる 装置 ( マウス キーボード タッチ ) webアプリとしての振る舞いショートカットキー割り当て状態 ( サーバとの通信状態とアプリ自動更新との組み合わせサーバへのリクエストフォーカス移動の状態 ) データ組み合わせサーバからのレスポンスの GUI 操作部品 ( ボタン チェッ画面 ( 各ページ ) 設定値組み合わせ反映クボックス テキストボックス リンク ) 設定 ( 設定が正しく行われたか ) については 設定に対するテストとして行う 状態遷移については統合テストまでで網羅を意識したテスト済みと仮定 ユーザ操作を意識したシナリオベースで設計 また 画面遷移で兼ねられるようなら画面遷移テストでまとめる 攻撃などセキュリティ特化したものはサービスを対象としていないので不要? HTTPSの確認は設定項目があるため 仕様ビューで補える OS 環境ブラウザ環境データプロトコル 環境組み合わせ ( 膨大なので方針を決める必要あり ) 受け取るメッセージデータ負荷部の互換性 ( ヘッダ部などの ) プロトコル互換性 信頼性成熟性 信頼性障害回復性 信頼性障害許容性 データデータデータ ( 壊れたデータなデータデータ ( 壊れたデータなデータ ( 壊れたデータなサーバとの通信状態サーバとの通信状態ど ) サーバとの通信状態ど ) ど ) ( サービス ネットワー ( サービス ネットワーサーバとの通信トラブル ( サービス ネットワーク ) サーバとの通信トラブルサーバとの通信トラブルク ) ク ) ( サービス ネットワーク ) クライアント側の状態 ( メ ( サービス ネットワーク ) ( サービス ネットワーク ) クライアント側の状態クライアント側の状態クライアントトラブルモリなど ) クライアントトラブルクライアントトラブル ( メモリなど ) ( メモリなど ) 例外がきちんと行われ負荷るか サーバ側のトラブルクライアント側のトラブル 負荷 サーバ側のトラブルクライアント側のトラブル 使用性 テストを行うのではなく シナリオテスト実行の中でユーザ視点の問題点を探る程度 様々なユーザを考慮する必要がある 効率性時間効率性 Web サーバとのやりとり 理解性 ( 表示や操作のわかりやすさ ) 習得性 ( 操作の憶えやすさ ) レスポンス速度魅力性 ( デザイン 使いやすさ ) テスト対象に求められている期待結果 ( 振る舞い ) に対し着目点ごとにテスト実施有無と厚みを検討する インポート 作成 保存 閲覧 検索 整理 連絡先管理 アカウント管理 情報表示 設定 GUI( ブラウザ上の表示や操作 ) ( 画面遷移 ) Webサーバとのやりとり (HTTP/HTTPS) ( 各操作で確認するので ) テストシナリオテスト ( ユーザ視点 + 状態遷移 ) 画面遷移テスト組み合わせテスト環境組み合わせテスト負荷テストいじわるテスト性能テスト 保守性 移植性 環境についてはシステムテスト相互運用性としてでは考慮しない 考えた データ互換も同様 2. 構成要素にまとめ直す : つづき その他の情報について 本題 :Gmail のテストアーキテクチャを考える 3. 表にあてはめてみる テストフレームに対し テストタイプを色分けして表現している 厚みや有無については 現在 ( 重点的に )( 通常 ) ( ライトに ) ( やらない ) で表示しているが これはまだ暫定的 考察 : テストアーキテクチャ設計の効能を考えてみる 1. 全体を把握でき 大まかな分類 割り振り状況が見える 詳細事項について どこに含めるかを決めやすくなる 2. その後の作業の見通しが立ちやすい 作業分担について 単なるではなくテストタイプなど他の分け方にすることが可能 どこから着手するか といった作業優先度もつけやすい 3. 五月雨式に浮かんでくる観点をまとめやすくなる 先にフレームを設けることで 都度 どこに該当する ( まとめられる ) か 追加すべきか を考えられる 4. 初期段階でレビューが可能 根本的な間違いや抜けに早期に対応できる 5. 他のテストレベル ( あるいは別のチームが行うテスト ) 間でテスト範囲やボリュームを調整しやすくなる 6