はじめに : JSTQB FLの学習内容・解釈・気づきを共有
JSTQB Foundation Level(シラバスVersion2018J03)について学習した内容と自分の解釈・気づきをまとめてブログで公開しています。JSTQB FLをシラバスや教科書で学習されている方は、不明点があるときに、本ブログの内容と照らし合わせて頂いて、理解の助けになればいいなと考えています。
(※このブログを全部を読むというよりは、学習中に分からないことがあったときに、覗いていただくという使い方が良いと思います。)
今回の内容 : 第4章.テスト技法
目次
テスト技法のカテゴリ
テスト技法の選択
テスト技法のカテゴリと特徴
静的テストと動的テストの違い
ブラックボックステスト技法
同値分割法
境界値分析法
デシジョンテーブルテスト
状態遷移テスト
ユースケーステスト
ホワイトボックステスト技法
ステートメントテストとカバレッジ
デシジョンテストとカバレッジ
ステートメントテストとデシジョンテストの価値
経験値ベースのテスト技法
テスト技法のカテゴリ
テスト技法の選択
- テスト技法は、以下のものを考慮して選択する
- コンポーネント/システムの種類
- テスト対象の種類 (組み込み系/エンプラ系/IoT系/オンラインシステム/バッチシステム)
- コンポーネント/システムの複雑さ
- テスト対象の複雑さ・構造
- 単一アプリ/複数のアプリが統合されたパッケージ製品/システムオブシステムズ
- 規則や基準
- 使用すべきテスト技法が規定されているか、いないか
- 顧客/契約上の要件
- 顧客からテストのアプローチや使用するテスト技法の要求があるか
- リスクのレベルやタイプ
- 機能のリスクの高さと優先度
- テスト目的
- 例えば、以下のように考える
- 欠陥検出が目的ならエラー推測(仕様にないケースをテストする)
- 要求や仕様に対する動作確認が目的ならブラックボックステスト技法
- 例えば、以下のように考える
- 入手可能なドキュメント
- テストベースを入手可能か否か
- (できなければ同等なテストベースを入手するか、作成する)
- テスト担当者の知識とスキル
- テスト担当者に利用するテスト技法の知識があるか
- テスト担当者のスキル・経験は十分か（経験ベースの技法を選択する場合）
- 利用できるツール
- 例えば、ホワイトボックステスト技法を利用するなら、カバレッジ自動測定ツールが利用可能か
- スケジュールと予算
- 時間・予算が不足していないか
- 不足しているならテストは最低限に限定するために、最適なテスト技法を選択する
- 時間・予算が不足していないか
- ソフトウェア開発ライフサイクルモデル
- アジャイル開発手法でテストファーストを実践するなら、コーディング前にテスト設計を行う
- ソフトウェアの想定される使用方法
- ユースケースに応じて、テストのシナリオを考える
- テスト対象のコンポーネント/システムに関してテスト技法を使用した経験
- 過去のテスト活動の経験 (十分に効率よくできた技法はないか)
- コンポーネント/システムで規定される欠陥の種類
- 対象となる設計工程で作り込まれやすい欠陥の種類
- テストレベルに応じて適用しやすいテスト技法は変わる
- 特定のテストレベルでは適さない技法 (例：コンポーネントテストにユースケーステスト)
- どのテストレベルでも適用可能な技法(例：境界値分析)
- コンポーネント/システムの種類
テスト技法のカテゴリと特徴
- テスト技法の目的
- 「テスト条件、テストケース、テストデータを決定すること」
- テスト技法のカテゴリ
- ブラックボックステスト技法
- ソフトウェア外から見える振る舞いに観点を設定してテスト設計する技法
- プログラムへのインプットとアウトプットに注目
- ソフトウェアの要件仕様に基づいてテスト設計する
- 前提：要件仕様があきらかであること (←テスト技法の選択の考慮事項)
- ブラックボックステスト技法で設計したテストケースを用いて実施するテストがブラックボックステスト
- ソフトウェア外から見える振る舞いに観点を設定してテスト設計する技法
- ホワイトボックステスト技法
- ソフトウェアの内側構造に注目してテスト設計する技法
- ソフトウェアの設計/実装の詳細仕様に基づいてテスト設計する
- 前提：詳細仕様があきらかであること (←テスト技法の選択の考慮事項)
- ステートメントカバレッジ(C0)、デシジョンカバレッジ(C1)でカバレッジ(網羅度)を確保する
- ホワイトボックステスト技法で設計したテストケースを用いて実施するテストがホワイトボックステスト
- ソフトウェアの内側構造に注目してテスト設計する技法
- 経験ベースのテスト技法
- テスト担当者が持つスキルや経験、情報、勘、過去に遭遇した欠陥などを基にテスト設計する技法
- テスト担当者の知識とスキルに依存する (←テスト技法の選択の考慮事項)
- 時間短縮のためアドホックになりがちというネガティブな面もある
- テストケースが残らないことがある
- テストの記録が残らないことがある
- 探索的テスト
- スキルの高いテスト担当者に経験ベースのテスト技法を適用するとこれになる
- 一通りのテストが終わった後の最終確認の位置づけとして一定の効果が期待できる
- モンキーテスト(やみくもなテスト)になる可能性がある
- スキルの低いテスト担当者に経験ベースのテスト技法を適用するとこれになる
- 効果を期待できない
- テスト担当者が持つスキルや経験、情報、勘、過去に遭遇した欠陥などを基にテスト設計する技法
- (参考)グレーボックステスト技法
- プログラムの内部構造も考慮してたうえで、インプットとアウトプットの確認をする
- ブラックボックステストとホワイトボックステストの中間のイメージ
- アーキテクチャの妥当性を確認をするときなど適用
- ブラックボックステスト技法
ブラックボックステスト技法
同値分割法
- システム/ソフトウェアへの入力データを「同じ処理が行われる」と想定したパーティションに振り分ける。パーティション内のデータは、システム/ソフトウェアで同じ処理が行われるため、同じものとみなせる。パーティション内の代表的なデータでテストをすれば、同じーパーティション内の他のデータもテストしたものとみなすことができる
- 効率的にテスト項目を絞ることができる
- 出力データの同値パーティションもある
- ある入力データに対する出力データが複数ある場合
- 例えば、Webサイトで単語検索をしたとき、出力される検索結果は、「検索」という一つの入力データに対し、「まったくない」「1ページで収まる」「複数ページにわたる」という複数の出力データになる
- 同値分割法の注意点 「無効同値パーティションの値は、単独で使うこと（ほかの故障を隠してしまう可能性があるから）」
境界値分析法
- 同値パーティションの境界上の値に対する多くの欠陥が潜んでいる。それを効率よく検出するための技法
デシジョンテーブルテスト
- デシジョンテーブルの規則(入力条件の組み合わせに対する結果)を用いて、テストケースを設計する
- 入力データや入力条件に対する出力結果(処理や動作)を表にまとめたもの
- 複雑な論理を把握するのに効果的
状態遷移テスト
- 状態遷移テストは、状態遷移図/状態遷移表を用いてテストケースを設計する
- システムは、「状態」によって、同じ入力データに対し複数の異なる出力結果となる場合がある。
- 状態遷移図
- システムの「状態」が「イベント」によってどのように遷移するのかを表現した図
- システムが持つ状態の種類、システムの開始/終了、状態間の遷移、イベントが表現される
- 状態遷移図は、無効な遷移を除外し、有効な遷移のみを表現する
- 状態遷移表
- システムの「状態」と「イベント」のマトリクスで表現したものが状態遷移表という
- 状態遷移図に比べ、状態とイベントの組み合わせを漏れなく検討できるため、無効な組み合わせも明確にできる
- 状態遷移表を作成するだけで、仕様の不備や誤りを検出することができることがある
- 状態遷移表テストでのテストケース設計方法
- 典型的な状態遷移の順序をカバーするように設計
- すべての状態を網羅するように設計
- すべての遷移を網羅するように設計
- 特定の順序で遷移するように設計
- 無効な遷移を確認するように設計
ユースケーステスト
- ユースケース記述(ビジネスシナリオやシステムの使い方)に基づいてテストケースを設計
- ユースケースとは、アクター(ユーザーや他のシステム)とサブジェクト(テスト対象のシステム/ソフトウェア)の相互作用を記述したもの
- （ビジネスユースケースとは、顧客と企業との相互作用を記述したユースケース。システムユースケースは、ユーザーとテスト対象のシステムの相互作用を記述したユースケース)
ホワイトボックステスト技法
ステートメントテストとカバレッジ
- コード内の実行可能ステートメント(命令文)に注目してテストケース設計をする
デシジョンテストとカバレッジ
- コード内の判定とその判定結果に注目してテストケース設計をする
ステートメントテストとデシジョンテストの価値
- 100%のデシジョンカバレッジは、100%のステートメントカバレッジを保証する
- 100%のステートメントカバレッジは、100%のデシジョンを保証できない
-
ではどんなときに、価値を持つのか？
- ステートメントテストは、処理が実行されることで期待と異なる結果をもたらすような欠陥を見つけるのに役立つ
- デシジョンテストは、判定結果の真偽によって、期待と異なる結果をもたらすような欠陥を見つけるのに役立つ
経験値ベースのテスト技法
- 経験ベースのテスト技法は、テスト担当者のスキル、直観をベースにテストケースを設計する
- 経験ベースのテスト技法は、ブラックボックステスト技法とホワイトボックステスト技法と組み合わせて使う。
- 形式的なテストの補完として有効
- 仕様にない「暗黙の仕様」は、欠陥に繋がりやすい。また、ブラックボックステスト技法でテストするのが困難である。ということで経験値ベースのテスト技法で補完すると効果的である。
- 経験値ベースのテストは、担当者に依存する
- テスト担当者のテストの進め方と経験に依存し、有効性にばらつきがある。
- カバレッジ計測自体が困難であり、カバレッジによる評価が難しい。
エラー推測
- テスト担当者の知識を基に、誤り、欠陥、故障の発生を予測する
- 過去の情報を基に、「この作業は、開発者の誤りが起きやすいかも？」「この作業は欠陥が入り込みやすいかも？」「この製品、昔、こんな故障があったかも？」 を予測しながらテストを考える
- テスト担当者のスキルに依存させないために、組織は、起きやすい「誤り」「欠陥」「故障」をリスト化するとよい
- 開発担当者にも共有することで、設計、実装の早い段階で、欠陥の予防ができる
- エラー推測の例
- 数値「0」
- NULL値
- 要素が0や1つのリスト
- 特殊な日付(2/29(うるう日)
探索的テスト
- 探索的テストは、テスト設計、実行、記録、評価を平行に行うテスト
- 特徴は、形式的ではない(テストケースを事前に準備しない)こと。
- (何も準備せずにテストをするわけではない)
- セッションベースドテストでは、テストケースの代わりにテストチャーター(テスト目的がかかれている)をテスト実行のガイドにしながらテストを行う。
- あらかじめ決められた時間枠内(セッション)で行う
- 実行した手順や発見した事象をテストセッションシートに記録する
- セッションベースドテストでは、テストケースの代わりにテストチャーター(テスト目的がかかれている)をテスト実行のガイドにしながらテストを行う。
- どんなときに効果的か
- 仕様が十分でない場合
- テストケースの事前準備ができない場合
- スケジュールに余裕がない場合
- 準備作業の省力化(テスト設計と実行を同時並行に効率よく行える)
- 形式的なテスト技法の補完として
- 仕様漏れや仕様の誤りに基づく欠陥を検出できる
- (形式的なテスト技法は仕様に依存するため仕様の漏れや誤りに基づく欠陥を検出しづらい)
- 形式的なテスト技法で見つけるべきだった欠陥が探索的テストで見つかるような場合は、テストプロセスの見直しが必要
- 探索的テストは、重大な欠陥を検出するのに有効だが、担当者のスキルや知識に依存する
チェックリストベースドテスト
- チェックリスト(テスト条件のリスト)を使用してテストケースを設計する
- チェックリストは、テスト対象に合わせて、テスト担当者の経験を基にテスト分析の一環として作成する
- 以下の情報を使うこともある
- ユーザー観点で重要とされる知識
- ソフトウェアが不合格となる理由と仕組み
- チェックリストがガイドラインになり、テスト設計の一貫性を実現する
- チェックリストを用いて、直接テストを実行する場合(テスト設計を行わない場合)、メリット・デメリットがある
- メリット
- 広範囲のテストができる
- デメリット
- テスト条件は抽象度が高いため、担当者の解釈によるテストにばらつきがでる
- 再現性が低い
- メリット
以上 第4章.テスト技法
参考になれば幸いです。