何でもかんでも白黒付ければいいってもんじゃない〜テストタイプ Part3

良い子のみんなー！
愛と平和を歌って笑顔を届ける愉快なピエロ、MR.SMILEだよー🤡

良い子のみんなは楽器弾いたりするかな？
色んな曲を弾けるように音階を覚えたりコードを覚えたり大変なんだよね。

今回はソフトウェア開発の中の「コード」に関連する話をするよ。
カタカナで書くと区別付かないけどchordが音楽で扱う和音、codeが今回の話に出てくるIT業界、ソフトウェア開発で使われるコードだよ。

そんなコード（code）が正しいかどうかをテストするホワイトボックステストのお勉強をしていこうね。

ホワイトボックステスト

ホワイトボックステストはソフトウェアの内部構造やコードの詳細に基づいて行われるテストタイプだよ。

ソフトウェアの内部構造だから、プログラムのロジックやワークフロー、データフロー、制御フロー、アーキテクチャー（設計の全体像や枠組み）が正しいかどうかをテストして行くんだ。

ホワイトボックステストの確認ポイント

ソフトウェアの内部構造が分かる各種資料、プログラムのコードそのものを元にしてテストケースを作ったり、テスト実施結果の正しさを確認することになるよ。

そう言ったコードや構造の知識が必要とされるからテスト分析、設計、実装、実行まで開発側で担当することが多いんだ。

どのテストレベルでやる？

ソフトウェアのコードの詳細はコンポーネントテストで処理の内容、判定の分岐とかを確認、ソフトウェアの内部構造をコンポーネント統合テストでアーキテクチャーやインターフェースの処理を確認するとされているよ。

基本的にソフトウェア開発の前半で実行するテストタイプと言うことになるね。
ただ、システム、製品によっては全てのテストレベルでも適用可能と言う場合もあるみたいだよ。

コードカバレッジと構造カバレッジ

機能テスト、非機能テストと同じくホワイトボックステストにも網羅率の計測方法があるよ。

コードカバレッジ
コードの色んな側面や要素（カバレッジアイテム）で計測する方法だよ。
コンポーネント内の実行可能ステートメント（命令文）や判定結果などがカバレッジアイテムでコンポーネントテストの網羅率計測に使われているんだ。

構造カバレッジ
システム構造（アーキテクチャー）に注目して実行済みのインターフェースに対する割合を計測するよ。
コンポーネント間のインターフェースなどを基準にコンポーネント統合テストの網羅率計測に使われているんだ。

White & Black

前回、前々回で機能テスト、非機能テストを作る際にブラックボックステスト技法を使うと書いたんだけど覚えてるかな？

今回、ホワイトボックステストの説明をしたので、何となく反対の考え方と言うイメージができたんじゃないかな？
コードや内部構造ではなく何に注目するかと言うと入力と出力に注目するのがブラックボックステストの考え方なんだ。

箱の中身はなんだろな？

例えば数字を二つ入力したら正しく計算結果が出力されることをテストする場合にホワイトボックステストではどんな順番でどんな処理をするかを確認するけど、ブラックボックステストでは入力に対して正しく計算結果が出力されるか確認できれば黒い箱の中で誰が何をしてても知ったこっちゃないと言うことになるよ。

JSTQB試験だとホワイトボックステストとブラックボックステストの違いは出てきそうなので覚えおこうね。

次回はソフトウェアの変更に対してのテストのお話をするよー

では、今回はこの辺で！
最後まで読んでくれた良い子のみんなー！
さんきゅーすまいる🤡