ソフトウェアテストを学ぶ その４．単体テストについてざっくり書いてみた

こんちは。ふっくら太郎(仮)です。

今回は単体テストについて「ざっくり」勉強したいと思います。

(ふっくら太郎は殆ど単体テストを経験したことが無いので)

単体テストとは？

単体テストとは・・・

• モジュールテストやユニットテストとも呼ばれる。
• 開発者が開発するもっとも小さい部品に対して行うテスト。
• プログラムの内部構造、論理構造を検証する。
• コーディングした開発担当者がテストする。

のようなテスト。

単体テストは「開発するもっとも小さい部品に対して行うテスト」

単体テストでは、プログラムのちっちゃな部品 (モジュール)が、設計図である詳細設計書やプログラム設計書の通り作られていることを検証する。

具体的には、プロセスやプログラムの最少単位 (クラスやメソッド、関数など)に対してテストを実行する。

• C言語の場合は、関数単位が単体テストの対象
• C++、C#、JAVAの場合は、クラスやメソッドが単体テスト対象
• 他の言語は・・・自分で調べて！ 

とは言うものの、実際、機能単位や画面単位など、企業毎にテスト対象の単位は様々。

(私がお世話になったメーカー様は皆バラバラでした)

個人的には、どの様な粒度で単体テストを行うかはそれほど重要では無く、プロジェクトに所属する開発者が皆、同じ認識、粒度で単体テストを行うことの方が重要と考えます。

個人任せで単体テストを実施するとテスト密度がバラバラになり、一部開発者の担当したモジュールから大量の欠陥が発生します。

単体テストは「プログラムの論理構造を検証するテスト」

単体テストは、プログラムの論理構造を確認するテスト。

以下の２つのテスト技法を用いて確認する。

• 制御フローテスト

　　　＝　テスト対象モジュールの「命令文」、「分岐処理」、「条件」の何れかの要

　　　　　素に着目し、処理上発生する経路(パターン)を網羅的に確認するテスト。

　　　　　着目する要素によってテスト網羅率が変わる。(下図参照)

• データフローテスト

　　　＝　ソフトウェアで使われているデータや変数が「定義」→「使用」→「消滅」

　　　　　の順番で正しく処理されることを確認するテスト。

テストの実行は・・・

• フローチャートを起こして、テスト項目(テスト条件の組み合わせ表)を作成し、手動テストする。
• テスト設計から実行、カバレッジ計測まで、有償、無償の自動テストツールを利用して自動テストする。

方法で行う。

実施コストや再利用性などの理由から、自動テストに対するニーズ・注目度は、年々高まっている。

単体テストは「開発者自身で実施するテスト」

単体テストは、コーディングした開発者自身がテスト設計から実施まで担当する。

開発者自身が単体テストを行うことで・・・

• ソースコードを一番理解している人物がテスト設計するため、妥当性が高いテスト項目を作成できる。
• 欠陥があった場合、早急に修正、再テストが行える。
• テストに必要なプログラム (スタブ・ドライバー)を自身で作成できる。

などの利点がある。

単体テストで考慮すべきこと！

単体テストの出来は開発者の能力に依存する

それゆえ、以下のような問題が頻繁に起こる・・・

• テストコードもプログラムなので、開発したモジュールに多くの欠陥を埋め込む開発者が作ったテストコードは欠陥が多数あり、テストの信頼性に欠ける。
• 単体テスト書を作成するためには、最低限のソフトウェアテストの知識、詳細設計書、プログラム設計書の読解記述力が必要になる。

なので・・・

• 開発者の能力差を埋めるため、テストフレームワークや自動テストツールを導入する。
• コーディング規約のように単体テストのルールを決めたり、ソフトウェアテストについての教育を行う。

などの改善策を実現することが、単体テストの成否を左右する。

開発遅延が発生した場合、単体テストは削られる (ことがありがち)

不完全な単体テストを補うため、結合テストを強化する等の代替案がよく検討される。

しかし・・・

• 結合テストは部品を組み合わせた状態で処理結果の整合性を確認するテストであり、 論理構造の確認をする単体テストの役割を兼ねることはできない。
• また、論理構造を網羅的に見ることでソフトウェアの妥当性を判断するため、テストが不完全になるとテストの意味が無くなる。

本来、単体テストで検出される欠陥が結合テストで検出された場合、原因の特定、修正が単体テストよりも困難になる。また、影響するモジュール全ての再テストが必要になり、更なる遅延の原因となる。

単体テストの時間を如何に省略するかでは無く、如何に確保するかが、とても重要。

まとめ

• 単体テストは定義上、プロセスやプログラムの最少単位 (クラスやメソッド、関数など)で実行するテスト。でも、プロジェクトごとにテスト単位はまちまち。
• 単体テストはソフトウェアの論理構造を確認するテスト。プログラムを作成した開発者自身でテストを行う。
• 単体テストはテストの内容・品質の粒度を揃えることが重要。テストの自動化や、プロジェクト内での意思統一、教育を行うことで実現ができる (はず)。
• 単体テストは開発遅延の煽りを受け、省略されることがよくある。ソフトウェアの品質を守るためには、単体テストを実施するための工数確保が重要。

今回は、一般知識よりも実務的な話が多かった気がする・・・

[参考]

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践