JSTQBFL4章まとめ

おなかすいた

2023年5月23日 21:31

シラバスの文章が長いので引用して大事だと思うところ、テス友で出題された部分を太字にしてまとめてみます。

🐰JSTQBFL1章まとめ
🐱JSTQBFL2章まとめ
🦊JSTQBFL3章まとめ
🐶JSTQBFL4章まとめ
🐧JSTQBFL5章まとめ
🐷JSTQBFL6章まとめ

✔ テスト技法

テスト技法のカテゴリ

テスト技法の目的は、テスト条件、テストケース、テストデータを決定することである。

テスト技法を選択する際は、以下を含むさまざまな要因を検討する。

コンポーネントまたはシステムの複雑さ
規制や標準
顧客または契約上の要件
リスクレベルとリスクタイプ
入手可能なドキュメント
テスト担当者の知識とスキル
利用できるツール
スケジュールと予算
ソフトウェア開発ライフサイクルモデル
コンポーネントまたはシステムで想定される欠陥の種類

✔ テスト技法のカテゴリと特徴

シラバスでは、テスト技法を、
・ブラックボックス
・ホワイトボックス
・経験・経験ベース
に分類する。

■ ブラックボックステスト技法

★振る舞い技法 または 振る舞いベースの技法と呼ぶこともある

【特徴】
適切なテストベース（形式に沿った要件ドキュメント、仕様書、ユースケース、ユーザーストーリー、ビジネスプロセス）の分析に基づく。
これらの技法は、機能テストと非機能テストの両方に適用できる。
ブラックボックステスト技法は、テスト対象の入力と出力に着目し、その内部構造は参照しない。

■ ホワイトボックステスト技法

★構造技法 または 構造ベースの技法と呼ぶこともある

【特徴】
アーキテクチャー、詳細設計、内部構造、テスト対象のコードの分析に基づく。ホワイトボックステスト技法はブラックボックステスト技法と異なり、テスト対象内の構造と処理に重点を置く。

■ 経験ベースのテスト技法

【特徴】
テストケースの設計、実装および実行のために、開発担当者、テスト担当者、ユーザーの経験を活用する。この技法では、ブラックボックステスト技法やホワイトボックステスト技法と組み合わせて使用する。

◆ ブラックボックステスト技法に共通する特徴は以下のものを含む。

テスト条件、テストケース、テストデータは、ソフトウェア要件、仕様、ユースケース、ユーザーストーリーなどのテストベースから導出する。
テストケースは、要件と実装との間の相違、および要件からの逸脱を検出するために使う。
カバレッジは、テストベース内のテスト済みアイテムと適用した技法に基づいて計測する。

◆ ホワイトボックステスト技法に共通する特徴は以下のものを含む。

テスト条件、テストケース、テストデータは、コード、ソフトウェアアーキテクチャー、詳細設計、ソフトウェア構造に関する他の情報などのテストベースから導出する。
カバレッジは、選択した構造（例えば、コードやインターフェース）内のテスト済みアイテムとテストベースに適用した技法に基づいて計測する。

◆ 経験ベースのテスト技法に共通する特徴は以下のものを含む。

テスト条件、テストケース、テストデータは、テスト担当者、開発担当者、ユーザー、その他のステークホルダーの知識や経験などのテストベースから導出する。

✔ ブラックボックステスト技法（種類）

■ 同値分割法

＊同等に処理されると想定したデータすべてを同じパーティション（これを同値クラスとも呼ぶ）に振り分ける技法。
有効な値と無効な値の両方に対して同値パーティションがある。

有効な値は、コンポーネントまたはシステムに受け入れられる値である。有効な値の同値パーティションを「有効同値パーティション」と呼ぶ。
無効な値は、コンポーネントまたはシステムに拒否される値である。無効な値の同値パーティションを「無効同値パーティション」と呼ぶ。
入力、出力、内部値、時間関連の値（例えば、イベントの前後）などのテスト対象に関連するあらゆるデータ要素、およびインターフェースのパラメーター（例えば、統合テスト時にテスト対象となる統合コンポーネント）に対するパーティションが識別できる。
パーティションは、必要に応じてさらに細かく分割される場合がある。
各値は、必ず1つの同値パーティションだけに属する必要がある。
無効同値パーティションをテストケースで使用する場合、複数の故障が同時に起き、1つの故障のみが表面化した場合、他の故障を隠してしまい見逃す恐れがある。
故障を隠してしまわないようにするため、他の無効同値パーティションとは組み合わせず単独でテストすべきである。

この技法を使用して100%カバレッジを達成するには、すべての識別された有効同値パーティションと無効同値パーティションのそれぞれから、少なくとも 1つの値をテストケースでカバーする。

カバレッジは、1つ以上の値を使用してテストした同値パーティションの数を、識別された同値パーティションの合計数で除算して計測する。

同値分割法はすべてのテストレベルで適用できる。

良い点！
テスト工数が縮小できる。

注意点！
イレギュラーな不具合を見逃してしまいやすい。
同値分割法でテストする値はあくまでも「※代表値」のため、すべての値をテストしたということにはならない。
※同値パーティションの「代表値」は境界値や中間値などが選ばれることが多い

■ 境界値分析（BVA）

＊同値パーティションの境界上の値に対する多くの欠陥が潜んでいる。それを効率よく検出するための技法

パーティションの最小値および最大値（または最初の値と最後の値） が、境界値である
境界値分析はすべてのテストレベルに適用できる。
この技法は、数値（日付や時間を含む）の範囲を必要とする要件に対するテストケースに使用する。
あるパーティションに対する境界カバレッジは、テストした境界値の数を識別した境界値の合計数で除算して計測する。

■ デシジョンテーブルテスト

＊入力データや入力条件に対する出力結果(処理や動作)を表にまとめたもの

システムが実装すべき複雑なビジネスの規則を表現するのに有効。
デシジョンテーブルの規則(入力条件の組み合わせに対する結果)を用いて、テストケースを設計する。

**条件：**
• Y：条件が真であることを意味する（T または 1 とも記述する）
• N：条件が偽であることを意味する（F または 0 とも記述する）
• -：条件の値は判定に影響しないことを意味する（N/A とも記述する）

**アクション：**
• X：アクションが発生することを意味する（Y、T、または 1 とも記述する）
• 空白：アクションが発生しないことを意味する（-、N、F、または 0 とも記述する）

条件とアクションは表の行となり、条件を上部、アクションを下部に
記述する。
各列は判定の規則に対応している。
規則は条件の一意な組み合わせとその結果として実行するアクションを表す。
条件とアクションの値は、ブール値（真か偽）または離散値（例えば、赤、緑、青）で表現することが多いが、数値や数値の範囲で表現することもある。
複数の異なった条件とアクションを同一のデシジョンテーブルに記述するのが一般的。
デシジョンテーブルテストの標準的なカバレッジの最小単位は、デシジョンテーブル内の判定の規則ごとに1つ以上のテストケースを含めることである。これにより、条件のすべての組み合わせがカバーされる。
カバレッジは、1つ以上のテストケースでテストした判定の規則の数を、判定の規則の合計数で除算して計測する。
ソフトウェアの振る舞いが条件の組み合わせに依存する状況で適用可能であり、すべてのテストレベルに適用可能。

【利点】

見逃される可能性がある組み合わせを含めて、条件の重要な組み合わせのすべてを識別できること。
要件の中にあるいくつかの相違点も見つけることができる。

■ 状態遷移テスト

状態遷移テストは、状態遷移図/状態遷移表を用いてテストケースを設計する※システムは、「状態」によって、同じ入力データに対し複数の異なる出力結果となる場合がある。

状態遷移図
＊ソフトウェアの取り得る状態、ソフトウェアが開始および終了する方法、ソフトウェアが状態間で遷移する方法を示す。
↓わかりやすく
- システムの「状態」が「イベント」によってどのように遷移するのかを表現した図
- システムが持つ状態の種類、システムの開始/終了、状態間の遷移、イベントが表現される
- 状態遷移図は、無効な遷移を除外し、有効な遷移のみを表現する

状態遷移表
＊状態間の有効な遷移と無効だと思われる遷移のすべてと、イベント、有効な遷移の際のアクションを示す。
↓わかりやすく
- システムの「状態」と「イベント」のマトリクスで表現したものが状態遷移表という
- 状態遷移図に比べ、状態とイベントの組み合わせを漏れなく検討できるため、無効な組み合わせも明確にできる
- 状態遷移表を作成するだけで、仕様の不備や誤りを検出することができることがある

状態遷移表テストでのテストケース設計方法
- 典型的な状態遷移の順序をカバーするように設計
- すべての状態を網羅するように設計
- すべての遷移を網羅するように設計
- 特定の順序で遷移するように設計
- 無効な遷移を確認するように設計

状態遷移テストは、

メニューベースのアプリケーションのために使われる。
組込みソフトウェア業界にて幅広く使われている。
特定の状態を持つビジネスシナリオのモデリング、および画面遷移のテストをするためにも適している。
カバレッジは、テストをした状態または遷移の数を、テスト対象の識別した状態または遷移の合計数で除算して計測するのが一般的である

■ ユースケーステスト

ユースケースには、ソフトウェア機能の要件が盛り込まれている。
ユースケースは、サブジェクトとアクターをつないでいる。

📝サブジェクト
ユースケースが適用されるコンポーネントまたはシステム
📝アクター
ユーザー、外部ハードウェア、その他のコンポーネントやシステム
📝ユースケース
システムを使う人の目線で「このシステムは、こんなことができる」を表現してみることで、どんなシステムになるかのイメージをつかむやり方

各ユースケースは、1つのサブジェクトと1つ以上のアクターとの相互作用による振る舞いを明確にする。
ユースケースには、基本的な振る舞いのバリエーションである、例外的な振る舞いおよびエラー処理を含むことができる。
エラー処理には、プログラミング、アプリケーションおよびコミュニケーションのエラーに対するエラーメッセージの表示といった、システムの応答や回復の処理がある。
テストは、定義した振る舞い（基本、例外または代替処理、およびエラー処理）を実行するように設計する。
カバレッジは、テストしたユースケースの振る舞いをユースケースの振る舞いの合計数で除算して計測する。

！）ビジネスユースケースとは、顧客と企業との相互作用を記述したユースケース。
！）システムユースケースは、ユーザーとテスト対象のシステムの相互作用を記述したユースケース

ここで疑問が‥🤔
ユースケーステスト　と　シナリオテスト　ってなにがちがう❔❔❔
↓　↓　↓　↓
両テストには類似点も多く見られるが、厳密には、それぞれ異なる特徴を持つ。

■ユースケーステストは、「ユースケース」と呼ばれる、アクターとテスト対象のシステムの相互のやり取りを定義したものをもとに、テストの設計が行われる。
※アクターはテスト対象のシステムを利用する存在の総称のため、システム利用者だけでなく、別のシステムなどがアクターとなることもある

つまり、ユースケーステストは、アクターとテスト対象の間で、特定の動作を行った際の応答を確認するテスト。

■シナリオテストは、状況設定や業務の流れの一例（シナリオ）を用意して、そのシナリオ通りにシステムを動かし、問題が発生しないかを確認するテスト設計技法。
シナリオテストに用いられるシナリオのもとになるのは、ユースケースとは限らない。

・・・💡

両者の違いは、テストベースとするものが違う（＝ユースケースの有無）

・「ユースケーステスト」-> ユースケースをテストベースにテスト設計
・「シナリオテスト」-> ユースケースに限らず色々なものをテストベースにテスト設計

つまり、ユースケーステストよりもシナリオテストのほうが、自由度が高いテストということになる。理解ー！

✔ ホワイトボックステスト技法

＊テスト対象の内部構造を基にしたテスト

ホワイトボックステスト技法は、すべてのテストレベルで使用できるが、以下のコード関連の技法は、一般的にコンポーネントテストレベルで使用する。

■ ステートメントテストとカバレッジ

＊ステートメントテストはコード内の実行可能ステートメントをテストする。

コード内の実行可能ステートメント(命令文)に注目してテストケース設計をする

■ デシジョンテストとカバレッジ

＊デシジョンテストはコード内の判定をテストし、実行したコードを判定結果に基づいて評価する。

コード内の判定とその判定結果に注目してテストケース設計をする

構造カバレッジ
 |
 |　※コードカバレッジだけでなく、モジュールやコンポーネントなどその他の構造を単位としたカバレッジも含む
 |
 +-- ■ステートメントカバレッジ
     |
     +-- ■ブランチカバレッジ (■デシジョンカバレッジとほぼ同義)
         |   |
         |   +-- ■条件カバレッジ (condition coverage)

✔ ステートメントテストとデシジョンテストの価値

100%のデシジョンカバレッジは、100%のステートメントカバレッジを保証する　←これの逆は成立しない

100%のステートメントカバレッジは、100%のデシジョンを保証できない

【それぞれ何に役立つ❔】

ステートメントテストは、処理が実行されることで期待と異なる結果をもたらすような欠陥を見つけるのに役立つ
デシジョンテストは、判定結果の真偽によって、期待と異なる結果をもたらすような欠陥を見つけるのに役立つ

✔ 経験ベースのテスト技法

経験ベースのテスト技法を適用する場合、テスト担当者のスキルと直感の他、同様のアプリケーションや技術における経験からテストケースを導出する。
この技法は、他の体系的な技法では容易に識別できないテストを識別するのに役に立つ。

■ エラー推測

エラー推測は、エラー、欠陥、故障の発生をテスト担当者の以下の知識に基づいて予測する技法である。

アプリケーションの過去の動作状況
起こしやすいエラーの種類
他のアプリケーションで発生した故障

エラー推測技法に対する系統的アプローチは、起こりえるエラー、欠陥、故障のリストを作り、それらの故障やそれらを引き起こす欠陥を検出するテストケースを設計する。

エラー、欠陥、故障のリストは、テスト担当者の経験、欠陥や故障のデータ、ソフトウェアが不合格となる理由に関する一般的な知識に基づいて作成できる。

エラー推測の例）『フォールト攻撃』という体系的アプローチがある

テストするタイミングは❔
一般に形式的な仕様ベースや構造ベースのテストを行ったあとに、テスト担当者の経験・知識・直感にもとづいてエラーになりやすい箇所を重点的にテストする。

■ 探索的テスト

探索的テストは、形式的ではない（事前定義されていない）テストであり、テスト実行時に動的に設計、実行、ログ記録、および評価をする。
テスト結果を使用してコンポーネントまたはシステムについての理解を深め、さらにテストを行わなければならない領域のテストケースを作成する。

探索的テストでは、活動を体系的にするためにセッションベースドテストを使用する場合がある。
セッションベースドテストでは、探索的テストをあらかじめ決められた時間枠内で行う。テスト担当者はテスト目的を含むテストチャーターに従ってテスト実行をする。
テスト担当者はテストセッションシートを使用して、実行した手順や発見した事象を文書化する場合がある。

📝セッションベースドテスト
テストを一定の時間 (セッション) ごとに区切って管理するテスト技法

探索的テストは、仕様がほとんどなかったり、不十分であったり、テストのスケジュールに余裕がなかったりする場合に最も効果が大きい。他の形式的なテスト技法を補完する場合にも効果が大きい。
探索的テストは対処的テスト戦略と密接に関連付けられている。
探索的テストは、他のブラックボックス、ホワイトボックス、経験ベースの技法と併用できる。

■ チェックリストベースドテスト

チェックリストベースドテストでは、チェックリストにあるテスト条件をカバーするように、テストケースを設計、実装、および実行する。

テスト担当者は、新しいチェックリストの作成、もしくは既存のチェックリストの拡張をテスト分析の一環として行う。
チェックリストは、経験、ユーザーにとって何が重要であるかという知識、もしくはソフトウェアが不合格となる理由と仕組みについての理解に基づいて作成する。
チェックリストは、機能テストや非機能テストを含むさまざまなテストタイプのために作成できる。
詳細なテストケースがない場合、チェックリストベースドテストがガイドラインとなり、ある程度の一貫性を実現する。

【注意】
チェックリストはハイレベルのリストであるため、実際にテストをする際には複数の解釈が発生しうる。その結果、広範囲に網羅できるが、記載された内容のまま同じテストを再現するのは困難になる。

✔ 個人めも

わかりやすくまとめ📃

■経験ベースのテスト技法の概要

経験ベースのテスト技法は、テスト担当者のスキル、直観をベースにテストケースを設計する
- 経験ベースのテスト技法は、ブラックボックステスト技法とホワイトボックステスト技法と組み合わせて使う。

形式的なテストの補完として有効
- 仕様にない「暗黙の仕様」は、欠陥に繋がりやすい。また、ブラックボックステスト技法でテストするのが困難である。ということで経験値ベースのテスト技法で補完すると効果的である。

経験値ベースのテストは、担当者に依存する
- テスト担当者のテストの進め方と経験に依存し、有効性にばらつきがある。
- カバレッジ計測自体が困難であり、カバレッジによる評価が難しい。

■ エラー推測について

テスト担当者の知識を基に、誤り、欠陥、故障の発生を予測する
過去の情報を基に、「この作業は、開発者の誤りが起きやすいかも？」「この作業は欠陥が入り込みやすいかも？」「この製品、昔、こんな故障があったかも？」を予測しながらテストを考える
テスト担当者のスキルに依存させないために、組織は、起きやすい「誤り」「欠陥」「故障」をリスト化するとよい
開発担当者にも共有することで、設計、実装の早い段階で、欠陥の予防ができる

【エラー推測の例】

数値「0」
NULL値
要素が0や1つのリスト
特殊な日付(2/29(うるう日))

■ 探索的テストについて

探索的テストは、テスト設計、実行、記録、評価を並行して行うテスト
特徴は、形式的ではない(テストケースを事前に準備しない)こと。
(何も準備せずにテストをするわけではない)
- セッションベースドテストでは、テストケースの代わりにテストチャーター(テスト目的がかかれている)をテスト実行のガイドにしながらテストを行う。
  - あらかじめ決められた時間枠内(セッション)で行う
  - 実行した手順や発見した事象をテストセッションシートに記録する
どんなときに効果的か
- 仕様が十分でない場合
- テストケースの事前準備ができない場合
- スケジュールに余裕がない場合
  - 準備作業の省力化(テスト設計と実行を同時並行に効率よく行える)
- 形式的なテスト技法の補完として
  - 仕様漏れや仕様の誤りに基づく欠陥を検出できる
  - (形式的なテスト技法は仕様に依存するため仕様の漏れや誤りに基づく欠陥を検出しづらい)
  - 形式的なテスト技法で見つけるべきだった欠陥が探索的テストで見つかるような場合は、テストプロセスの見直しが必要
探索的テストは、重大な欠陥を検出するのに有効だが、担当者のスキルや知識に依存する

■ チェックリストベースドテスト

チェックリスト(テスト条件のリスト)を使用してテストケースを設計する
チェックリストは、テスト対象に合わせて、テスト担当者の経験を基にテスト分析の一環として作成する
以下の情報を使うこともある
- ユーザー観点で重要とされる知識
- ソフトウェアが不合格となる理由と仕組み
チェックリストがガイドラインになり、テスト設計の一貫性を実現する
チェックリストを用いて、直接テストを実行する場合(テスト設計を行わない場合)、メリット・デメリットがある
- メリット
  - 広範囲のテストができる
- デメリット
  - テスト条件は抽象度が高いため、担当者の解釈によるテストにばらつきがでる
  - 再現性が低い

この記事が気に入ったらサポートをしてみませんか？

JSTQBFL4章 まとめ