正しいテストは正しい品質のプログラムを生む
テストさえきっちりと行われていれば、そのテスト範囲の動作は確実に保証される。
正しい品質のシステムを提供する重要な作業だ。
テストの流れ
部品（モジュールなど）単位の信頼性は確保するところから始まる。
単体テスト、結合テスト、結合テストの流れでテストを行う。
単体テスト
各モジュールごとにテスト行う。
手法はブラックボックステストやホワイトボックステストがある。
ブラックボックス
モジュールの内部構造は意識せず、入力に対して適切な出力が仕様通りなっているかを検証する。
気づき
処理内容は確認せず、出力は適切かを確認。
ホワイトボックス
モジュールの内部構造が正しく作られているかを検証する。
気づき
どんな処理が行われているかを確認する。
結合テスト
単体テストが終われば結合テストをする。
複数のモジュールをつなぎ合わせて検証を行う。
システムテスト
さらに検証の範囲を広げて、システム全体のテストを行う。
その中でも
- 要求された機能がちゃんと動くか
機能テスト - 高い負荷の下でも問題ないか
負荷テスト - 処理能力は十分か
性能テスト
テストデータの決め事
テストを行うときの入力の値を何を検証するのかをしっかり明確にして与えるデータを考えなければならない。
テストデータを作成する基準として用いられるのは同値分割、限界値（境界値)分析がある。
同値分割
データ範囲を種類ごとのグループを分けて、それぞれから代表的な値を剥き出してテストデータに用います。
気づき
場合ごとのデータを与えるのか。
限界値（境界値)分析
グループの境目部分を重点的にチェックする。
気づき
ギリギリの値を入力して判定が誤っていないかを発見していくのか。
ホワイトボックスの網羅基準
どこまでテストを徹底するを決める方針のこと
出典 https://wa3.i-3-i.info/word15878.html
命令網羅（C0）
全ての処理を通ればいい。
出典 https://wa3.i-3-i.info/word15878.html
判定条件網羅（分岐網羅/C１）
- 全ての分岐を最低一回させる。
- 「処理が枝分かれしたときの行き先を全部1回は確認するぜ！」になるようにテストを設定すること
- 「枝分かれの行き先（分岐）」に注目してテストするのが分岐網羅です
出典 https://wa3.i-3-i.info/diff325test.html
気づき
真偽の行き先を意識しているのか。
条件網羅
- 個々の条件が真と偽の値を最低一回は満たすようにするテスト
- 「条件によって分岐する処理が出てきたとき、それぞれの条件のYes/Noを全部1回は確認するぜ！」になるようにテストを設定すること
- 「枝分かれの行き先が変わる要素（条件）」に注目してテストするのが条件網羅です。
出典 https://wa3.i-3-i.info/diff325test.html
気づき
条件を意識して網羅させるのか。
複数条件網羅
複数の条件がとりうる、真偽値全ての組み合わせを網羅するテスト
気づき
入力の真偽のパターンを全て行うのか。
トップダウンテストとボトムアップテスト
結合テストでモジュール間のインタフェースを確認する方法。
トップダウンテストやボトムアップテストなどがある。
トップダウンテスト
上位モジュールから、先にテストを済ましていく。
上位モジュールは個々のモジュールが持つ機能を使って、より複雑な機能を実現する。
下位のモジュールはテストをしていない場合があるのでスタブ（仮のモジュール）をくっつけてインタフェースを確認を行います。
気づき
上位モジュールは下位モジュールを統合した結果を出力するからなのか。
ボトムアップテスト
下位モジュールからテストを行う。
ドライバ（仮の上位モジュール）を使ってインタフェースの確認を行う。
その他
トップダウンテストとボトムアップテストを組み合わせて行う折衷テストがある。
全てモジュールをつなげて一気につなげてテストをするビックバンテストがある。
リグレッションテスト
修正内容がこれまでに正常に動作していた範囲に悪影響を与えていないかを確認するためのテスト
気づき
修正内容が別のモジュールかどこかでそれが原因でエラー/悪影響が起きないかをテストしてるのか。
バグ管理図と信頼度成長曲線
バグを修正を繰り返すたびにシステムの完成度が上がっていく。
しかし
いつまでもバグの修正をしていては提供できない。
そのために
ある基準を作る。
それに用いるのがバグ管理図だ。
バグ管理図
バグは途中から加速度的に発見される。最終的にバグ件数は頭打ちになって収束する。
縦軸が累積バグ件数、横軸がテスト項目消化件数や時間になる。
この線を信頼度成長曲線という。
p４９９の図を見る。
管理図の要素
テスト消化予定
テスト消化予定の推移。
テスト項目は日々消化されていくため、右下がりのグラフになる。
グラフの数値には過去のテスト結果やテストマネージャーの経験による数値を反映する。
テスト消化実績
テスト消化実績の推移。
テスト消化実績にはテストに合格した項目の数を反映するため、不合格の場合はカウントしない。
「テスト消化予定」と同様で、テスト項目は日々消化されていくため、右下がりのグラフになる。
バグ検出推定
バグ検出数推定の推移。
テストの実施によってバグは日々検出されるため、右上がりのグラフになる。
グラフの数値には過去のテスト結果やテストマネージャーの経験による数値を反映する。
バグ検出実績
バグ検出の実績数。
バグ検出の累計数をカウントするため、検出したバグが解消しても実績数はマイナスしない。
「バグ検出推定」と同様で、テストの実施によってバグは日々検出されるため、右上がりのグラフになる。
気づき
積み重なるのか。
未解決バグ
未解決バグの検出数。
日々の未解決バグの数をカウントする。
未解決バグは解消することがあるため、他の線と違って数値が増えたり減ったりする。
気づき
検出数は増減するのか。
出典 https://q-media.jp/bug-control-chart/#i-2
問題を解いたときの気づき
モジュールが呼び出すの意味はモジュールが引数を渡すということなのか。