はじめに
- 社内の新卒向けに、単体テストのイメージがつかめるようにまとめました。
- 間違っている箇所があればご指摘願います。
目次
-
テスト概要
1-1. 開発工程とテスト工程の対応関係（V字モデル）
1-2. テストの概略
1-3. テストの分類（ホワイトボックステスト／ブラックボックステスト） -
単体テスト概要
2-1. 単体テストとは
2-2. 制御フローテスト
2-3. 網羅（カバレッジ）
2-4. データフローテスト
2-5. テスト自動化
2-6. テストツールの例
1. テスト概要
1-1. 開発工程とテスト工程の対応関係（V字モデル）
ウォーターフォール型開発では、要件定義、設計、コーディング、テストといったように、各工程の活動内容を明確に区分けしてプロジェクトを進める。日本のITプロジェクトの約9割がウォーターフォール型開発を採用している。
V字モデルは、ウォーターフォール型開発における各工程を開発工程とテスト工程に分類したうえで、各開発工程の成果物の内容について、どのテスト工程で検証するかを対応付けたものである。
1-2. テストの概略
| 単体テスト | 結合テスト | 機能テスト | システムテスト | |
|---|---|---|---|---|
| 確認事項 | モジュール内の論理構造 | モジュール間のインターフェースや処理順序 | 各機能がシステム要件を満たすこと | システム全体がユーザの要求事項を満たすこと |
| 対応する開発工程※ | 詳細設計 | 詳細設計・基本設計 | 基本設計 | 要件定義 |
1-3. テストの分類（ホワイトボックステスト／ブラックボックステスト）
| ホワイトボックステスト | ブラックボックステスト | |
|---|---|---|
| 確認事項 | ソフトウエアの内部構造（論理構造） = 入力に応じて期待通りの順序で処理が行われること。各モジュールが正常動作しているか確認する。 | ソフトウエアの出力結果 = 入力に応じて期待通りの出力が得られること。プログラムの冗長性などは確認しない。 |
| テスト技法 | 制御フローテスト、データフローテスト | 同地分割、境界値分析 ※ |
| 対応するテスト工程 | 単体テスト | 機能テスト、結合テスト、システムテスト |
※こちらのQiita記事がわかりやすいです。
2. 単体テスト概要
2-1. 単体テストとは
- ソフトウエアの最小単位である「モジュール」ごとに実施するテスト
- 目的：作成したプログラムの論理構造が正しいか（詳細設計書の記載通りに動作するか）を確認すること
- 担当者：プログラムを作成した本人が実施するのが一般的
2-2. 制御フローテスト
モジュールの構成要素である「判定文」「（判定の拠り所となる）条件」「命令文」に着目して、
処理内容をフローチャートにまとめたものを制御フローと呼ぶ。
制御フローテストでは、ある「判定文」に対して、ある「条件」を与えたとき、ある「命令文」を実行すること／しないことを検証する。これらの３要素を「カバレッジ基準」と呼ぶ。単体テストを実施する際、全てのカバレッジ基準（組み合わせ）のうち、プロジェクトの状況に応じて、どれだけ網羅するか（= 網羅率）を規定する。
2-3. 網羅（カバレッジ）
命令網羅（C0）：全命令を最低１回実行
判定条件網羅（分岐網羅）(C1)：分岐判定が真の場合、偽の場合を最低１回実行
条件網羅（C2）：分岐判定の各条件について、真の場合と偽の場合の組合せを実行
複数条件網羅（MCC）：分岐判定の各条件について、全組合せを実行
2-4. データフローテスト
モジュール内で扱われる各データ（≒変数）について、「定義」「使用」「消滅」のタイミングをフローチャートで示したものをデータフローと呼ぶ。
データフローテストでは、各データが「定義」→「使用」→「消滅」の順に扱われるかを検証する。
2-5. テスト自動化
従来、人手で行なわれていたテストをソフトウェアに実施させること。ここで用いるソフトウェアをテスト自動化ツールという。テスト工数および開発工数の削減を目的に導入を検討する。
導入検討の観点
| 観点 | 説明 |
|---|---|
| 期待する結果 | どの部分を、どの程度まで自動化できればよいのかを定義する。ツール選定（= 手段）が先行すると、導入・保守のコストが想定以上に高くなったり、テスト対象を正しく評価できなかったりするリスクがある。各種テストツールを部分的に導入することで、それぞれの導入メリットを事前に評価するのが望ましい。 |
| テスト対象の性質 | 同様のテストを複数パターンで実行したり、基本機能の非退行確認を繰り返し実施したりする場合、テスト自動化の対象となりうるが、画面レイアウトの崩れや外部システムによる認証など、期待値をスクリプトで定義することが難しいた部分については、人力で実行する方が効果的である。こうした事情を踏まえて、扱うシステムがテスト自動化の対象となりうるかを検討する。 |
| 工数削減の程度 | 人手で実施する場合と自動化する場合の工数を比較すること。自動化に当たっては、ツールのインストール、学習、スクリプト作成など、テスト実施までに必要なプロセスがあることを考慮する。 |
| 保守コスト | システム開発状況に応じてテストスクリプトもメンテナンスが必要となる。一般に、テスト自動化の導入およびスクリプト作成に要したコストの数％程度の工数を見込んでおく。 |
| 教育コスト | メンバーへの教育資料の準備、教育の実施、QA対応の仕組みなど、テスト自動化ツールの導入に向けて教育計画を策定することが望ましい。 |
テスト設計フロー
2-6. テストツールの例
インデックスとして、こちらのQiita記事が有用。
最近のテスト自動化ツールとして、処理の速さが売りのVitestが気になる。。。