ソフトウェアテストについて

はじめに

ソフトウェアテストについて,その概要やどのようなテスト手法,
どのような効果があるのかをまとめる.

目次

• ソフトウェアテストとは
• ソフトウェア開発の流れ
• テスト工程について
• ホワイトボックステストとブラックボックステスト
• 同値分割テストと境界値テスト
• デシジョンテーブルテスト
• 状態遷移テスト
• 組み合わせテスト技法

ソフトウェアテストとは

ソフトウェアテストとは
欠陥を取り除き、ユーザーの要求を満たす、品質の良いソフトウェアを作ることである.

つまり,ソフトウェア開発者は以下の3点を考える必要がある

• 「誤作動(欠陥)を起こさないソフトウェア」
• 「ユーザーを求めているものは何か」
• 「自分たちが作った製品に満足してくれるのか」

ソフトウェアの品質

品質の良いソフトウェアとは、
「ユーザーの要求を満たし、ユーザーに価値を提供するソフトウェア」

ユーザーにとっての価値
→「使い勝手が良い」,「操作がわかりやすい」, etc.

「ソフトウェアの品質」の定義を非抽象的
→「ISO/IEC 25010」

ユーザー満足と品質の関係を示したモデル
→「狩野モデル」

ISO/IEC 25010（製品品質モデル)

ソフトウェアの品質特性規格.
以下の8つの特性に分類
さらに,各特性において副特性も定義されている(省略)

• 機能適合性
• 信頼性
• 性能効率性
• セキュリティ
• 互換性
• 保守性
• 使用性
• 移植性

狩野モデルにおける品質の分類

品質要素	充足	不充足
当たり前品質	当たり前	不満
一元的品質	満足	不満
魅力的品質	満足	仕方がない

• 当たり前品質
  • ユーザーの基本要求(ユーザーが絶対に満たしてほしいと考えるもの)を満たす品質
• 一元的品質
  • 充足されていると満足し,不充足の場合は不満に感じる機能
• 魅力的品質
  • 充足されていると満足し,不十分の場合は仕方ないと感じる機能

テストを行う際は、品質とユーザー満足度の関係を理解したうえで
対象ソフトウェアの各機能を狩野モデルの品質要素に分類しておくとよい

テストの視点

テスト担当者は、次の2つの視点を常に持つべき

• V&V (Verification & Validation, 検証と妥当性確認)
  • Verification(検証)
    • 開発仕様書の通りにソフトウェアが作成されているかの確認
  • Validation(妥当性確認)
    • ユーザーの要求通りにソフトウェアが作成されているかの確認
• Never, Must, Want
  • Never : あってはならないこと
    • 人の生命や財産に影響を及ぼすような事態(リスク)
  • Must : できなければならないこと
    • ユーザーが思った通りに要求を達成できること
  • Want : できたらよいこと
    • 製品に求める要望

ソフトウェア開発の流れ

ウォーターフォール型開発モデルやアジャイル開発などがある.
今回はウォーターフォール型のみまとめる.

ウォーターフォール型開発モデル

• 1つの工程が完了してから次の工程を開始
• コーディングまでの工程を「上流工程」、以降の工程を「下流工程」
• V字モデルによる開発工程とテスト工程の結びつき

ウォーターフォール型開発モデル

V字モデル

各工程の作業について

• 要求定義
  • 顧客のニーズや企画担当者が描く要望を、要求として定義
• 基本設計
  • 要求項目を実現するために必要なソフトウェアの機能や構成をまとめる
  • 「基本仕様書」と「機能仕様書」が作られる
• 詳細設計
  • 基本設計で定義した仕様をもとにコーディングの詳細な仕様を決定
• コーディング
  • 実際にコンピュータが人間の意図したとおりに動作するソフトウェアの作成

テスト工程について

各テスト工程の概要

• 単体テスト
  • モジュールごとに行うテスト
  • コーディングを行ったプログラマ自身が担当する場合が多い
• 結合テスト
  • 複数のモジュールを組み合わせて動作をテスト　
  • モジュールの動作順序やタイミングも確認する
• 機能テスト
  • 組み合わせたモジュールを1つの機能としてテスト
  • 機能として正しく役割を果たすかを確認
• システムテスト
  • モジュールや機能を結合した状態で、
    要求定義の内容が実現されているかを確認するテスト
  • 製品として出荷する状態、サービスとして提供する状態に近い形で行われる

様々なテストと分類

代表的なテストを以下の3つの軸で分類

• ソフトウェアの内部構造に注目する、しない
  • ホワイトボックステスト、ブラックボックステストで分類
• ソフトウェアを動作させる、させない
  • 静的テスト、動的テストで分類
• ソフトウェア開発の工程
  • 開発工程、テスト工程で分類

各工程で行うテストの概要

開発工程,テスト工程で行うテストの概要をまとめる

開発工程で行うテスト(レビュー)

種類	説明
インスペクション	プロジェクトメンバー以外の第三者が参加し、評価基準に基づいて仕様書やソースコードなどの成果物に問題点などがないか検証する会議。公式性が高い。
テクニカルレビュー	開発者や技術者が中心となり、成果物が技術的な観点で正しいかを検証するレビュー。正式な会議形式で行われることが多い。
非公式レビュー	非公式に行われるレビューで、特定のフォーマルな手順やルールに縛られない。開発者同士の意見交換や簡易的な確認として実施されることが多い。
ウォークスルー	開発チームが集まり、成果物を作成者が説明しながらメンバー全員で確認する形式。机上デバッグの一環として行われる。
机上デバッグ	実際にコードを実行せず、コードを目で追いながらエラーや問題点を発見する方法。プログラムの論理的な正当性を確認する際に有効。

テスト工程で行うテスト(単体テスト)

種類	説明
機能確認テスト	モジュールや関数が仕様通りに動作しているかを確認するテスト。主に機能要件を満たしているかを検証する。
制御フローテスト	プログラムの制御構造に基づき、条件分岐やループが正しく動作しているかを確認するテスト。カバレッジを重視する場合が多い。
データフローテスト	プログラム内のデータの流れに着目し、変数の値が適切に変更・使用されているかを確認するテスト。

テスト工程で行うテスト(結合テスト・機能テスト)

種類	説明
状態遷移テスト	システムやモジュールが異なる状態間で適切に遷移するかを確認するテスト。状態遷移図や状態遷移表をもとに実施される。
機能確認テスト	結合されたモジュールが、全体として要求された機能を正しく実現しているかを検証するテスト。ユーザー視点での確認も行われる。

テスト工程で行うテスト(システムテスト)

種類	説明
確認テスト	システム全体が要求仕様や設計通りに動作するかを検証するテスト。機能要件や非機能要件の確認が主な目的となる。
評価テスト	システムのパフォーマンスや使いやすさ、拡張性などを評価するテスト。ユーザーの期待や満足度を確認することが目的。
負荷テスト	システムに高負荷をかけた際の性能や安定性を確認するテスト。処理速度や応答時間、リソース使用量を測定する。
環境テスト	システムが実際の運用環境や異なる環境で正しく動作するかを確認するテスト。ネットワーク環境やOSの違いなども考慮して実施される。
機能確認テスト	システム全体が求められる機能を正しく実現しているかを確認するテスト。結合テストの延長として、より広い視点で機能を検証する。

テスト工程で行うテスト(その他のテスト)

種類	説明
アドホックテスト	特定の計画や手順を持たず、テスターが自由に操作しながら不具合を見つけるテスト。アイデアベースの手法。
探索型テスト	テスト計画を逐次変更しながら、システムの動作を探索的に検証するテスト。発見された問題をもとに次のテストを計画する。
リスクベーステスト	リスクの高い部分を優先的にテストし、重要な問題を早期に発見することを目的としたテスト。
モデルベーステスト	システムのモデルを使用してテストケースを生成し、それに基づいてテストを行う手法。設計の正確性を検証できる。
エラー推測テスト	テスターの経験や直感を活かして、エラーが発生しそうな箇所を重点的にテストする手法。
ミューテーションテスト	ソースコードに意図的に小さな変更を加え、その変更がテストケースで検出されるかを確認することで、テストの妥当性を評価する手法。
バックトゥバックテスト	既存のシステムと新しいシステムを並行してテストし、結果を比較することで新しいシステムの正確性を確認するテスト。
ローカライゼーションテスト	システムが異なる言語や地域の設定で適切に動作するかを確認するテスト。主に翻訳や地域特有の要件を検証するために実施される。

ユーザーによるテスト

種類	説明
受入れテスト	システムやソフトウェアがユーザーの要件を満たしているかを確認する最終テスト。ユーザーや顧客が主導で実施する。
運用テスト	実際の運用環境においてシステムが適切に動作するかを確認するテスト。インストール、設定、日常業務での利用状況を検証する。
アルファテスト	開発者の監視下で、限られた内部ユーザーが実施するテスト。システムの基本的な機能や不具合を早期に検出することが目的。
ベータテスト	実際のユーザーによって、実運用環境に近い状況で実施されるテスト。広範なユーザーからフィードバックを収集し、最終調整に役立てる。

テスト工程とテストフェーズ　

テスト計画には「テスト全体計画」と「個別テスト計画」がある

テスト計画、テスト設計の流れ

1. テストの目的を確認
　テスト範囲や、テストの概要、テストの方法を定める

2. 機能一覧表を作成
　テスト対象が持つすべての機能を洗い出す

3. テスト観点の抽出
　テスト対象に対して、表示や計算結果の正しさなどを確認する視点を抽出
　テストの目的を品質特性に変換し、品質特性に対応したテスト観点を抽出する方法がある

4. テスト観点を機能へ割り当て
　洗い出した機能に、どのテスト観点のテストを行うかを検討
　テストマップを作成し、テストが必要な機能とテスト観点の組み合わせに印をつける

5. テスト技法の検討と適用
　一つひとつの組み合わせに対して、テスト設計を進める
　最も効率的、効果的に不具合や欠陥を検出できるテスト技法を選定

6. その他の検討事項
　実現可能なテストのアプローチを定める
　(必要なリソース、スケジュール、テスト実施時の体制、必要な設備や環境など)

ホワイトボックステストとブラックボックステスト

• ホワイトボックステスト
  • ソフトウェアの中身を理解したうえでそれを意識しながら行うテスト
  • 「制御フローテスト」と、「データフローリスト」の2種類がある
  • フローチャートなどを使用してモジュールの論理構造を明示する
• ブラックボックステスト
  • ソフトウェアの中身を意識せずに行うテスト

制御フローテストの実施方法

制御フローテストでは、「命令文」「分岐した経路」「条件」のいずれかに着目し、
これらがすべて実行されるかを確認する
具体的な手順は以下の通りとなる

1. ソースコードをもとにして、フローチャートを描く
2. カバレッジ基準(網羅したい要素)を決める
3. カバレッジ基準を網羅する経路を抽出する
4. 抽出した経路を通るようにテストを行う
5. 結果を確かめる

カバレッジ基準

カバレッジ基準として以下の3種類が挙げられる

• ステートメントカバレッジ
  • 制御フローテストで着目する要素に「命令文」を選択した場合のこと
  • すべての命令文を最低一度は通るようにテストする
• デシジョンカバレッジ
  • 制御フローテストで着目する要素に「分岐した経路」を選択した場合のこと
  • すべての経路を最低一度は通るようにテストする
• 複合条件カバレッジ
  • 制御フローテストで着目する要素に「条件」を選択した場合のこと
  • 対象のモジュール内に論理積や論理和で設定された複合条件が設定時に利用

カバレッジ基準ごとに必要となるテストの回数は異なる
テストの回数が多いと、より詳細に確認していることを意味する
どれを採用するかはテストに投入できる工数やモジュールの重要度を考慮して決定

データフローテストの実施方法

データフローテストは、ソフトウェアの中で使われているデータや変数が
[定義]、[使用]、[消滅]の順に正しく処理されているかを確認するテスト

データフロー図を利用して、使用されていないデータなどを発見する

同値分割テストと境界値テスト

これらのテスト技法は主に、「機能確認テスト」および「負荷テスト」「機能確認テスト」などで使用可能

「ソフトウェアの動作が変わる条件の境目」に注目するテスト技法

同値分割テスト

同値分割テストは、
"同値パーティション(同じ動作をする条件の集まり)ごとにテストを行うテスト技法"

同値パーティションの例は以下のようなもの

• 同じ処理結果となる「入力値」の集まり
• 同じ処理結果となる「時間」の集まり
• 同じ入力値から処理される「出力結果」の集まり

パスワードの文字数の同値パーティション

パスワードに使える文字の種類の同値パーティション

同値分割テストの実施方法

各同値パーティションから最低1つの代表値を選んでテストを行う

代表値には、範囲の中間値を選ぶことが多い
その他には、デフォルトの設定値や入力される頻度の高い値を選ぶこともある

同値分割テストの考え方は以下のように表現できる

**"代表値でテストをした結果、欠陥が見つかれば
同値パーティション内のほかの値でも同じ欠陥が見つかるはず。
欠陥が見つからなければ
同値パーティション内のほかの値でも同じ欠陥は見つからないはず

境界値テスト

仕様条件の境界となる値とその隣の値に対してテストを行うテスト技法
境界値に着目するのは、欠陥が境界に潜む可能性が高いため
以下の2つが境界に欠陥が潜みやすい理由

• 境界を表す条件の誤解
  • 「以上」「以下」「未満」「より小さい」「と同じになった場合」など、様々な記述方法が誤解の要因となる
• コーディング時の条件の記述誤り
  • タイプミスやコピー＆ペーストのミスで異なる条件をコーディングすること

境界と境界値

境界値テストの実施方法

境界値テストは以下の手順で実施する
1.テスト対象の項目を確認

2.境界を見つける

3.境界値を決める

4.テストする値を決める
テストする値の候補は

• 境界値
• 境界値の一つ上の値(同値パーティションなら省略)
• 境界値の一つ下の値(同値パーティションなら省略)

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

デシジョンテーブル(意思決定表)とは
複数の条件によって決定されるソフトウェアの動作を一覧するための表
この一覧表を使用してテストすることを「デシジョンテーブルテスト」

デシジョンテーブルを作成する目的の一つは複雑な仕様を整理すること

このテストでは複数の条件に注目

表の上半分にはソフトウェアの動作を決める「条件」が網羅的に記述
表の下半分には上部の条件で生じる結果、処理、動作が「アクション」として記述

デシジョンテーブルの例

デシジョンテーブルの作り方

デシジョンテーブルの作り方は以下の流れ

1.条件とアクションの抜き出し
条件:各アクションを発生させる前提の条件
アクション:条件の組み合わせによって発生する動作結果

2.ルールの升目を埋める
Y/N, T/Fを記入

3.アクションを記入
条件を考慮してY/N, T/Fを記入

4.記入時に疑問を感じたら調べたり、尋ねる
結果が推測できない場合,悩んだ場合は気を付ける

デシジョンテーブルを見やすくする方法

• 矛盾している条件の削除
  • 実際に起こりえない条件は削除
  • アクション欄に「N/A」と記入
• 表の簡略化
  • ルールの項目をまとめて削減する
• 表の分割
  • 複数ある条件の中から、他との関連性が弱いものは分割
• 3値以上の答えを持つ条件の採用

状態遷移テスト

状態遷移図を用いたテスト、状態遷移表を用いたテストの総称
ソフトウェアの動作中に変化する状態に着目
状態は以下のいずれかのこと

• 一定の同じ動作を続けている様子
• 動作後に異なる動作を開始しない様子

状態遷移図を作成するメリットは、大きく以下の2点

• 状態遷移の流れを容易に把握
• 図示することで新たな発見がある

状態遷移表を作成するメリットは、大きく以下の2点

• 仕様があいまいな箇所に潜む欠陥を発見できる
• 状態遷移図の不備を見つけることができる

状態遷移図を用いたテスト

状態遷移図をもとに「テストケース」を作成する必要がある
状態遷移図は「状態遷移図を機能ごとに分割」するとよい

テストケースを作成する際は次の3つのポイントに注目

• すべての状態を1回は通る
• すべてのイベントを1回は発生させる
• すべての遷移を1回は通る

状態遷移図を作成する目的は、ソフトウェアの動きを網羅的に確認すること
できないはずのことが本当に実行できないことを確認する必要がある

状態遷移表の作り方

状態遷移表は、状態遷移を網羅的に表す二次元の表
縦軸は「状態」、横軸は「イベント」

「ー」はそのイベントが発生してもどこにも遷移しないということ

状態遷移表は、できることに加え、できないはずのことも確認できる
つまり、すべての遷移を網羅的に確認したい場合は状態遷移表が適する

組み合わせテスト技法

組み合わせテストは、複数の条件を組み合わせてソフトウェアの動作を確認するテスト技法
「単一の条件だけでは発生しないが、複数の条件が組み合わさった際に発生する欠陥」を
見つけるために行う

複数の設定を組み合わせた場合の動作確認をするために必要

例:炊飯器の操作の場合
ご飯の硬さ→「やわらかめ、普通、硬め」
炊飯時間→「通常、早炊き」
ご飯の種類→「白米、玄米」

「ご飯の硬さ」＋「炊飯時間」＋「ご飯の種類」のすべての組み合わせの場合の動作確認

2因子間網羅

2つの因子間の組み合わせをすべて網羅するという考え方
組み合わせを作成する手法は直行表やAll-Pairs法などがある

因子は、テスト対象の機能名や設定項目名など
水準は、因子が持つ選択肢や設定値など

組み合わせテストを有効に用いるには因子と水準の的確な抽出が必要

ソフトウェアのテストにおいては,
多くの欠陥は2因子間までで見つかるという定説があるので2因子間網羅で十分

All-Pairs法を使った組み合わせ表の作り方

Qumias(https://www.qbook.jp/info-qumias/) を使用して作成する方法
1. ダウンロードしたファイルからExcelのアドインを起動
2. 因子水準表を作成する
3. 範囲を選択して、Qumiasを起動する
4. 全体網羅度を設定して組み合わせを作成
5. 出力結果の確認と並び替え

出力結果を並び替える際は、最も時間がかかりそうな因子を中心に行うとテスト実施がスムーズになる

直行表を使った組み合わせ表の作り方

1. 因子水準表をもとに適切な直行表を選択する(直行表テンプレートはさまざまなウェブや書籍で公開されている)
2. 選んだ直行表テンプレートに、因子と水準を割り付ける

組み合わせテストを実施するまでの流れ

1. 各担当者間でテスト対象とテストの目的に関する認識を合わせる
2. テスト対象の因子とおおよその水準を洗い出す
3. 組み合わせ数を削減するかを検討する
4. 組み合わせる因子、水準を選ぶ
5. 使用する手法を決定する

組み合わせ表を作成する際の注意点

以下の3点があげられる

• 禁則を回避

  • 禁則:ソフトウェアの設計上で禁止になっている組み合わせや不可能な組み合わせ
  • 禁則回避方法は以下のいずれかの方法で回避する
    1. 2因子を1因子に見立てる方法
    2. 禁則行をコピーして置換する方法
    3. 禁則を除外した因子水準表で作成する方法

• 重要な組み合わせを追加

  • 組み合わせテストによって作成した組み合わせ表の中に、3因子間をまたぐじゅうような組み合わせが必ず含まれているとは限らない

• 無理して組み合わせテストを行わない

  • テストの期待結果を確認できない場合
  • 禁則が多すぎる場合

参考

ソフトウェアテストの教科書