ユニットテストについて説明する前に、まずは、開発プロセス内で検出される欠陥についてふれておきましょう。
欠陥の検出は、品質保証プロセスの最大の目的ですが、一口に欠陥と言っても、その原因や影響力はさまざまです。
検出された欠陥は、”他に同じような欠陥が無いか”、”これからこのような欠陥を作り込まないためにはどうしたらいいのか”、”どうしたらもっと効率よく検出できるだろうか”などを考えるための大切な材料となるのです。
本カリキュラムで利用する欠陥分類を下表に示します。
種類 | 意味 | 対応 |
---|---|---|
論理 | 設計の欠陥 (処理に抜けがある、処理の順番間違い、処理ロジックに誤りがある欠陥) | 修正 |
インターフェイス | 設計の欠陥 (外部へのアクセス、関数の引数の誤り等、インターフェイスに誤りがある欠陥) | 修正 |
単純 | if文の真偽判定の誤り コーディング規約違反 初期化漏れなどの欠陥 基本的に、詳細設計に記述されているにも関わらず、実装者のミスにより作り込んだ欠陥は、全て単純ミスによる欠陥 | 修正 |
冗長 | 処理的に問題はないが、無駄な処理がシステム性能に影響する可能性がある欠陥 | 修正 |
コメント | コメントに不備がある欠陥 コメントに誤りがあると、ソースコード解析で間違った判断をする | 修正 |
その他 | 上記以外の問題がある欠陥 例:拡張性がない | 検討 |
種類別に、その欠陥が作り込まれる工程を見てみましょう。
基本設計 | 詳細設計 | コーディング | ユニットテスト | 統合テスト | |
---|---|---|---|---|---|
論理 | ○ | ○ | ○ | − | − |
インターフェイス | ○ | ○ | ○ | − | − |
単純 | − | − | ○ | − | − |
冗長 | − | − | ○ | − | − |
コメント | − | − | ○ | − | − |
※実際にはテスト工程でも欠陥を作り込む可能性はある。
また、どの欠陥がどの工程で検出されるのか、下の表にまとめます。
これには、テスト(動的テスト)だけではなく、レビュー(静的テスト)を含めています。
基本設計 (レビュー) | 詳細設計 (レビュー) | コーディング (レビュー) | ユニットテスト | 統合テスト | |
---|---|---|---|---|---|
論理 | ○ | ○ | ○ | ○ | ○ |
インターフェイス | ○ | ○ | ○ | ○ | ○ |
単純 | − | − | ○ | ○ | − |
冗長 | − | − | ○ | − | − |
コメント | − | − | ○ | − | − |
欠陥の分析については、第10章で詳しく説明します。
ここでは、どの工程でどのタイプの欠陥が作り込まれるのか、また、検出されるのかを知っていただければ十分です。