155
175

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

テストって深いんだなぁと思ったのでまとめてみた

Last updated at Posted at 2023-07-28

初心者タグっていつまで使えるんやろう?
最近コードを書くより、テストをすることが多い元高校教師のエンジニアです。

品質チェックは下流工程において重要な過程となります。
品質チェックのためのテストといっても目的も手法もさまざまです。
違いがわかるかどうかはテスト実施において重要です。

そんなテストについてまとめてみました。
これであなたもテストマスター!!

単体テスト・モジュールテスト

1. 単体テスト

ユニットテストともいわれます。プログラム単体、メソッド単体など、個々にテストできる最小単位のテストとなります。そのためコード作成時など早い段階で行われることが多いテストとなります。
単体テストのホワイトボックステストでは、カバレージ(網羅率) を測定するツール(テストカバレージ分析ツール)を使うこともあります。
※網羅率:ソフトウェアの品質やテスト妥当性を評価する際の指標

2. 結合テスト

単体テストを終えた各モジュールを結合して行うテストです。
「単体テストで問題なければOK」
と思うかもしれません。しかし世の中は厳しく、モジュールを組み合わせることによって予期せぬ不具合が生じることがよくあります。それを解決するための重要なテストとなります。
モジュール同士を結合した際の挙動が、仕様書通りに機能しているか等を確認するためにも、様々なパターンの結合テストを繰り返す必要があります。
大別すると 「非増加(一斉結合)テスト」「増加(順次増加結合)テスト」 の2つとなります。

2.1.非増加(一斉結合)テスト

2.1.2. ビッグバンテスト

ビッグバンテストとは、単体テスト済みのモジュールを一度に結合してテストする方法です。別名で 「一斉テスト」、「一斉結合テスト」 ともいわれます。一斉にテストを行うため、不具合が発生した箇所の特定が難しいデメリットがあることから、小規模や単純なシステムに適している手法であるといえます。

2.2. 増加(順次増加結合)テスト

2.2.1. トップダウンテスト

トップダウンテストとは、上位モジュールから順次テストを行う方法です。下位モジュールが完成していない中でテストをしなければならない場合には 「スタブ」 というモジュールを利用してテストを進めていきます。
※スタブ:下位モジュールの機能を代替するモジュール
image.png

2.2.2. ボトムアップテスト

ボトムアップテストとは、下位のモジュールからテストを行う方法です。未完成の上位モジュールの代わりに 「ドライバ」 というテストモジュールを利用します。早くからテストが実施できることや、テストモジュールの作成が必要という特徴はトップダウンテストと同じになります。
※ドライバ:上位モジュールの機能を代替するモジュール。下位モジュールの動作に必要な値を出力させてテストを進めるためのもの。

image.png

2.2.3. サンドイッチテスト

サンドイッチテストとはトップダウンとボトムアップの両方向からテストを進める方法です。トップダウンテスト、ボトムアップテストの両方の利点を活かすことができます。しかし「スタブ」「ドライバ」の両方を用いるため、準備に必要な時間やコストが他のテスト手法に比べて多くなりがちです。

システムテスト

システムテストは、要求定義で合意された機能、性能、信頼性、障害対策、使いやすさなどを確認するテストです。システムテストには以下のようなテストがあります。

1.機能テスト

要求仕様書通りかどうかを確認するテスト。ブラックボックステストの方法でテストケースを設定する。

2.性能テスト

レスポンスタイム、スループットのテスト

3.負荷テスト

通常よりも大きな負荷をかけて、システムが正常に作動するかどうか、性能が確保されるかどうかをテストする。

4.回復テスト(リグレッションテスト)

プログラムエラー、データベース破壊、ハードウェア障害など想定される障害を実際に起こし、そこから回復力をテストする。効率よく効果的な回帰テストを実施するためにテスト自動化ツールを用いる場合がある。

5.信頼性テスト

システムとしての稼働率をテストする。

6.UIテスト(ユーザーインターフェーステスト)

ユーザにとっての使いやすさをテスト(確認)する。

テストケース設計技法

テストが重要なのは理解できるが、テストばかりに時間を割けないのも事実だと思います。
そのため、いかに効率よく、最大限の効果を発揮するかがポイントとなります。
このポイントを実現するためにテストケース設計技法が重要となります。

1.ブラックボックステスト

ブラックボックステストとは、テスト対象の内部構造を把握せずに、入力に対して正しい出力が得られるかを確かめるテストです。そのため実装者でなくても実施することができます。顧客が行う受入テストも原則このテストになります。

1.1. 同値分割

同値分割は、入力値の範囲をいくつかのクラスに分割しクラスごとの代表値をテスト値にします。
例えば「整数で年齢を入力して未成年かどうかを判断する」というシステムのテストケースを作る場合、システムファ正常に動く 有効同値クラス は「0~19」の値グループ、正常に動かない 無効同値クラス は「20以上」の値グループと「-1以下」の値グループとなります。

同値分割では各値グループから1つテストケースを選びます。
すなわち前述の例では、以下のようにテストケースを選びます。

①有効同値クラスである「0~18」の値グループから「10」
②無効同値クラスである「19以上」の値グループから「23」
③無効同値クラスである「-1以下」の値グループから「-3」

これによって例えば①では0~18の19通りテストをしなければならないところを1つのテストで済むことができます。そのため少ないテストケースで効率よく行うことができます。ただし同値クラスの境界線の不具合が発見できません。

1.2.限界値分析

限界値分析は同値分析のように「クラスごとの代表値」ではなく、「クラスごとの境界値」をテスト値とします。上記の例で言うと以下のテストケースとなります。

①有効同値クラスである「0~18」の値グループから「0」と「18」
②無効同値クラスである「19以上」の値グループから「19」
③無効同値クラスである「-1以下」の値グループから「-1」

テストケースは同値分割よりも増えてしまいますが、より精度の高いものとなります。

1.3.原因結果グラフ(因果グラフ)

システムの 入力(原因)出力(結果) の関係を原因結果グラフで記述することで“組み合わせ論理回路”として表現し、有効なテストケースを抽出する手法です。仕様の不備やあいまいさを判別する副次効果もあり、複数の入力項目の組み合わせで複雑な論理判定を行うシステムにおいて有効となります。

1.4.エラー推測

エラーの発生確率の高いテストケースを推測してテスト値とする手法です。

2.ホワイトボックステスト

ホワイトボックステストとはすべてのプログラムが意図したとおりに動作しているかを確認するためのテストです。そのため「内部仕様に基づいたテストケース」を設定します。

2.1.命令網羅

命令網羅は、すべての命令を1回通ればOKとするテストケース設計技法です。例えば命令1、命令2、命令3を実行できれば良いので、a=真,b=真のテストケース1つで十分となります。

  • (a= 真, b= 真)
    image.png

2.2.分岐網羅(判定条件網羅)

命令網羅では考慮しなかった分岐に着目したテストケースとなります。すべての分岐経路を網羅する必要があります。下図のように経路が2つならテストケースは2つとなります。

  • (a= 真, b= 真)
  • (a= 真, b= 偽 )or ( a= 偽, b= 真 )or (a= 偽,b= 偽)
    image.png

2.3.条件網羅

分岐網羅とは異なり、分岐の条件に着眼したテストケースとなります。それぞれの値の真偽を満たすようにテストケースを設計する必要があります。しかし分岐網羅のようにすべての分岐を網羅する必要はありません。

  • (a= 真, b= 真 )and ( a= 偽, b= 偽 )※そのほかも考えられうる
    image.png

2.4.分岐/条件網羅

分岐網羅と条件網羅の両方を満たすテストケースとなります。

  • (a= 真, b= 真 )and ( a= 偽, b= 偽 )
    image.png

2.5.複数条件網羅

分岐条件の全組み合わせのテストケースとなります。

  • (a= 真, b= 真 )and ( a= 偽, b= 偽 ) and (a= 真, b= 偽 )and ( a= 偽, b= 真 )
    image.png

テストと品質

色々調べていると上記で紹介したもの以外にも手法がありました。
まとめ作業に力尽きたので、ここで止めておきます。

テスト実施によって発生したバグ摘出率が低いと高品質のものと判断しがちです。しかし必ずしも良いものというわけではありません。下記リンク先で示す表をプログラム1〜3を整理した品質評価グラフに当てはめて考えてみます。プログラム3のようにテスト密度が低いことで品質が担保できるテストとならない場合もあります。上部だけの数字で判断するのではなく、しっかり数字を分析して高品質のものを目指しましょう。

image.png

最後までお読みいただきありがとうございました!!感謝!!

155
175
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
155
175

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?