1.はじめに
- 基本的にGPTで調べたことを自分の言葉に置き換えているので精度は保証しない
- テーマは、プログラムのテスト方法
ホワイトボックステストとブラックボックステストについて書く
2.本文
- ホワイトボックステスト（内部）とブラックボックステスト（外部）の違い
| ホワイトボックス | ブラックボックス | |
|---|---|---|
| テスト対象へのアプローチ | ソフトウェアの内部構造やコードの実装に焦点を当てる。 ソースコードを見ることがあり、コードの特定のパスや条件をテストする。 制御フロー、ループ、例外処理などプログラムの内部構造テストする。 | ソフトウェアの内部構造を無視し、外部の振る舞いに焦点を当てる。 ソースコードを見ずに、ソフトウェアの仕様や要求仕様に基づいてテストケースを設計する。 機能や振る舞いが正確であることを確認する。 |
| テストケースの設計 | コードの内部知識を必要とするテストコードを設計する。 条件分岐やコードカバレッジを使用して、どの部分のコードを実行したか、どのパスを通過したか追跡する。 ユニットテスト（関数やメソッドのテスト）に適している。 | ユーザがソフトウェアをどのように使用するかを考え、ユーザ視点でテストケースを設計する。 ソフトウェアの利用者が必要な操作を模倣し、ソフトウェアの機能や振る舞いをテストする。 システムテスト、統合テストなど、ソフトウェア全体のテストをするのに適している。 |
| テストの焦点 | コードの正確性や内部ロジックのテストに焦点を当てる。 通常、単体テストに使用され、ユニット内の個別なコンポーネントや関数の振る舞いに当てられる。 | ソフトウェアの外部振る舞いや機能をテストする。 ユーザがソフトウェアを操作する際の期待される動作を確認し、ソフトウェアが要求事項を満たすかどうかを評価する。 |
| 主に使うテスト | 単体テスト（ユニットテスト） | システムテスト、統合テスト |
一般的にユーザからの視点のテスト（ブラックボックステスト）とコードからのテスト（ホワイトボックステスト）の両方がプロジェクト全体で行われることが多い。
ゲームで例えると、ゲームユーザーからのバグ報告はブラックボックス側のテストで、開発者側で内部のコードをいじってバグ対策するのがホワイトボックス側のテストかな。
- ホワイトボックステスト（内部）
・内部コンポーネントを考慮するテスト方式
・内部を考慮するので値を副作用で変更しないことを保証できる。
| 特徴 | 説明 |
|---|---|
| テスターがソースコードを見る | ソースコードやプログラムの内部構造を調査し、コードの特定のパスや条件をテストする。 |
| 条件分岐とコードカバレッジ | 条件分岐やコードカバレッジの情報を使用して、どのコードを実行したか、どのパスを通過したかの確認をする。 |
| 制御フローのテスト | 制御フロー、ループ、例外処理などのプログラムの制御構造のテストをする。 |
| ユニットテストに適している | ユニットテスト（個別のコンポーネントのテストや関数のテスト）に適している。 |
| テストケースの設計が技術的 | テストケースの設計がソフトウェアの内部知識を必要とするため、技術的スキルが必要。 |
・例
white_box.py
"与えられる整数リストから最大値を見つける関数のテスト（ユニットテスト）"
def find_max(numbers):
if not numbers:
return None
max_val = numbers[0]
for num in numbers:
if num > max_val:
max_val = num
return max_val
"ホワイトボックステストをするために以下のテストケースを作成する。 正しければ最大値を返すはず。"
"空のリストを与えた場合のテスト"
def test_empty_list():
assert find_max([]) is None
"正の整数を与えた場合のテスト"
def test_positive_numbers():
assert find_max([1, 3, 5, 2, 4]) == 5
"負の整数を含むリストを与えた場合のテスト"
def test_negative_numbers():
assert find_max([-1, -3, -5, -2, -4]) == -1
"重複した最大値を含むリストを与えた場合のテスト"
def test_duplicate_max():
assert find_max([1, 3, 5, 5, 4]) == 5
- ブラックボックステスト（外部）
・プログラムの全体の入力と出力に焦点を当てている。
・内部コンポーネントを考慮しないテスト方式
・内部を考慮しないので値を副作用で変更する可能性がある。
| 特徴 | 説明 |
|---|---|
| ソースコードを見ない | テスターは、ソースコードを見ない。代わりに、ソフトウェアの仕様や要求仕様に基づいてテストケースを設計する。 |
| 機能と動作のテスト | ソフトウェアが要求された機能や振る舞いを満たしているかどうかを確認する。 |
| ユーザ視点のテスト | ユーザがソフトウェアをどのように操作するかを模倣し、ユーザ視点からテストをする。 |
| テストケースの設計がドメイン知識に基づく | ソフトウェアの利用者が必要な操作を考え、テストケースを設計するため、ドメイン知識が必要。 |
| 統合テストやシステムテストに適している | ソフトウェアの様々なコンポーネントやシステム全体のテストに適している。 |
・例
電卓アプリケーションのブラックボックステスト
アプリには加算ボタンがあり、２つの値を入力し、その合計値を表示する機能がある。
テストケースの設計：
1.正の整数の加算：
・入力：2,3
・期待される結果：５
・テストの目的：アプリは正の整数を正しく加算できるかどうかを確認する。
2.負の整数の加算：
・入力：-2,-3
・期待される結果：-５
・テストの目的：アプリは負の整数を正しく加算できるかどうかを確認する。
3.少数の加算：
・入力：2.5, 3.7
・期待される結果： 6.2
・テストの目的：アプリは少数を正しく処理できるかどうかを確認する。
4.ゼロを含む加算：
・入力：0, 5
・期待される結果：５
・テストの目的：アプリはゼロを正しく処理できるかどうかを確認する。
5.エラーケース：無効な入力：
・入力："abc", 3
・期待される結果：エラーメッセージ
・テストの目的：アプリは無効な値を正しく処理し、エラーメッセージを表示できるかどうかを確認する。
3.所感
・調べるまでは両方ともコードを書くだけだと思っていた。
・説明だけではイメージしにくかったが例を出せばイメージしやすくなった。
ex.参考資料
ChatGPT-3.5
Recursion