やぼったい開発 > ウォータフォールモデルによる開発手法の基礎 > 単体試験の基礎(UT)

単体試験の基礎(UT)

--

このページでは、ウォーターフォールモデル工程の中で、単体工程のポイントを説明します。

ウォーターフォールモデル下工程の役割

ウォーターフォールモデルでは、ここから下工程になります。 つまり、作り込みがなくなるのでここ以降はバグは作られません。 正しく動作し、品質が保たれているのかを証明するのが目的です。 (あくまで、バグを出すのはその一環です)

上工程と下工程のバランスはもちろん開発によってばらつきがあります。50:50もあれば、100:20もあるのです。極端に言えば、下工程が無い開発もあります。

単体試験の目的

試験工程概要で言ったとおり積み上げの観点から言うと、DDやPD工程での内容が正しく実装されているかを保証する工程です。
次の機能試験とある程度何を分担するかを試験計画書などにより、決めておく必要もあります。

そうしないと、UT試験者は、FT試験で試験すると思っていたが、FT試験者は、UT工程で実施済みのつもりであって、試験されてない部分があったなどということがよくあります。逆に、2度テストするのはお互いに工数の面でもったいないです。

ある程度 CDレビューで品質が担保されていることが前提です。

注意点

UTは詳細設計またはプログラム設計レベルを保証するため、ソースを精査する工程ではありません。
もちろん単純に、ホワイトボックス試験ということでもありません。

その他例外な開発パターン

詳細設計を担保すると言っても、DD書を省く開発もあるので、その時はDD書から単純には試験項目を作成できません。
DD書がないときは、現実的にはFDやソースを参考にするときもあります。 その時は、多少頭を使ってどう動くのか、UTとして何を担保するのかをイメージする必要があります。


ただ、小規模開発やゲーム開発では、レビューが各個人の裁量で任されることもあるため、その分品質は高くありません(そのバグが大勢に影響しない様な場合はコストを重視してそのように行う場合がある)。

レビューを説明しているレビュー談義のコーナーはこちら




例えば、GoogleやMicrosoftのように、必ずソースレビューを行うことをルールとしているところもあります。

Googleのコードレビュー(Mondrian Code Review On The Web :YouTube)
ソースインスペクションを真面目にやるGoogle、MS

それでは、次の章から説明します

この単体テスト工程は大きく分けて2ステップあります。 それは関数内と、関数間の観点です。これから順に説明します。

1:関数内試験

ソースコードイメージ図

観点

  • 関数内の動作が正しく動作することを確認する。
  • 関数の中を精査し、全ての分岐や条件を網羅する。
    • 必要で在れば、分岐網羅だけでなく、条件網羅もココで行う。
    • もちろん「条件網羅まで必要ない」という理由をもって、分岐網羅で済ませることもできる。
    • utで分岐網羅(制御パス)を通さないことはあり得ない。なぜなら、異常系のテストは、結合してくればするほど(試験工程が進むほど)難しくなるので、現段階のutの方が工数を削減できるから。

*dd工程などで適切に関数を切り分けておくと、utの複雑度が上がらなくテストしやすい。

もう少し、上記で言っている「条件網羅」を具体的に説明すると
よく言われる、ソースレベルの境界値条件テスト、文字列やfor文などのパターン試験もこの工程で行う。
switch文や if文は 「分岐網羅」の方になるが、単体試験で行うことには変わりはない。
つまり、パラメータや引数等のパターン確認を単体試験で行う。

それらについては以下の本が分かりやすいと思う。


※ここでよく陥りがちなミスとして、ソースからそのまま ut試験を作成するホワイトボックス試験を作成してしまうことがあります。確かに詳細設計やプログラム設計がない場合、ソースから作成することはあります。しかしあくまでも、utは詳細設計またはプログラム設計レベルを保証するために行います。

そして、その場合特に気を付けなければいけない点は、ソースの意図をくみ取った試験項目を作成するということです。もし仮にソースからそっくりそのままの内容で試験しても、utの意味はありません。それでは、ソース自体が見たままの動きがなされていることは証明されても、ソースの間違っている(間違った内容のまま動作が正しい)部分が無いとはいいきれず、また詳細設計などから処理がごっそり不足している部分もこの工程で検知することができなくなってしまいます。

そういう意味で、「ソースを見て作成するようなホワイトボックス試験」は間違いと思っています。



perl などのデバッガで直接動かせるところが utで試験するイメージに近いです。

試験の仕方補足:関数呼び出し箇所について

  • 関数から 関数へ呼び出す処理をテストするときは、呼び出すことだけをテストすればよい。
    • 正しい引数で呼び出されることを確認する。
    • 呼び出し先は、正規版でなくても良い(呼び出し元は正規版、いっさいソースの変更は認められない(プリントデバッガも))。
    • モック、スタブなどで対応する。

単体試験(ut)概念図



試験項目はどのように作るか?

全体的には

たとえば、ある関数があってそこの試験項目を作るとします。

全体的な考え方として あくまで、 in/outをチェックすればよいので、そういう観点でut項目を端折る(はしょる)ことができると思います。outは戻り値だけでなく、大域変数などの共有する値、dbやファイル、通信等も含みます。

基本は一行一行を試験で担保することですが 担保すればよいので、まとめて複数の観点を試験一項目にすることは”あり”です。 ただ、バカの一つ覚えのように機械的にプログラムの一行に対して、一項目を作る必要ないです (ちなみに、ここで想定外の変数を変更してしまっているなどの観点はまた難しい問題で、utでは無理に近い)



関数のはじめの部分

ここから 少し細かくプログラム・詳細設計レベルで話を進めてみます。

まず、引数の対応や、変数などの初期化ですね。


次に命令文一文一文を担保します。
もし、if文などの分岐があったら、通るケース、通らないケースなど 実行時にプログラムの通るルートをテストします(分岐網羅)。 場合によっては and or など複雑に絡み、変数も二,三使っている場合、 それぞれの変数パターンでif文をチェックすることになります(条件網羅)。 ただ、闇雲にパターンを網羅すると項目が膨大になるので、いろいろな試験項目テクニックがあります。 (何も考えずに、諦めるのだけはやめましょう〜〜)

途中で変数やオブジェクトの生成、関数呼びだしなどそれについても試験項目を作成します。

最後に メモリやオブジェクトの開放や戻り値、グローバル変数の変更などの確認になります。 場合によっては関数の途中にそれらがあることも、もちろんあります。

2:関数間試験

観点

関数間の連携を精査する。

  • 機能レベルまではテストしない(ft試験で行うため)。
  • 関数内と関数間を一緒に行うこともある。

※関数内試験と一緒に行うような試験紅藻を考えるのは、複雑度が増し、試験漏れが出やすくなる(一瞥で判断できない)ので、多少重複しても、分ける方がいいと思っている。

観点の特徴

  • ある関数を特定の条件で呼び出し、返値、出力ファイルなどをチェックする。
  • 呼び出し元と、呼び出し先は正規版の関数。
  • ややホワイトボックス
  • 関数内は終わっているのでテストしない(違いを切り分けておく)。
  • もちろん、(理由が在れば、)関数内と分ける必要がない場合もある。
  • あくまで,関数内試験と、機能試験で出てしまうギャップをテストする。

関数間試験概念図

試験項目はどのように作るか?

基本的には、機能試験にむけて、関数間の試験担保出来ていない部分の項目を作ることになります。

詳細に言うと、関数を呼び出すところと、受け取るところで想定どおりかどうか」だけをチェックします。 量的にはそれほどありません。ただ、呼び出す変数パターンや戻り値のパターンが多い場合もありますので そういう時は複雑でバグ混入率も高い傾向があるため、面倒ですがキッチリ確認しましょう。

あまり細切れに1関数ごと項目を作ると流れがみえづらくなるので、複数の関数をうまく確認できる試験項目をつくるかどうかは、そこは試験項目作成者の腕の見せ所です。でも独りよがりの項目はだめですよ。

試験作成について

試験工程 補足も参考にしてください。
試験項目作作成のコツ、試験作成アンチパターン、試験品質について

NEXT > 機能試験

類似コンテンツ

単体試験関連コンテンツ

早わかり Junit 30分講座
JUnitの概略を短時間で学べるかもしれません。

単体試験と機能試験の違い
よく疑問になる、UTとFTでの作業範囲分担の話です。

なぜ自動化するのか?
単体テスト自動化のメリットとデメリットを記事にしました。

JUnitの役割はどこまで?
試験工程内で 単体テストのできることとできないことを説明しています。そもそもUTでやるべき事を抑えることが大事です。

製造・単体試験ツール

これはすごい!? コード品質のカイゼン化プラグイン2種
JUnit Factory:テストケースを自動生成するという優れもの。
http://www.atmarkit.co.jp/fjava/rensai3/eclipseplgn24/eclipseplgn24_1.html

単体試験項目自動作成ツール『おじどうくんDR4』
C向けに、Excel表で 単体試験を自動的につくってくれるツール。GNU Licence.Perlで動作。ちょっとすごいかも
http://park.ruru.ne.jp/ando/work/autoUt/index_ja.html

http://findbugs.sourceforge.net/
find bugs本家のサイト。コンパイルされた classファイルを静的に解析し問題点を指摘してくれます。たまに鋭い指摘をもらってびっくりするときも。classファイルの解析なので、コードスタイルは指摘できません。
http://findbugs.sourceforge.net/
FindBugsの説明ページ(Eclips Plugin)
ソフトウェアの品質向上を支援するプラグイン
http://www.atmarkit.co.jp/fjava/rensai3/eclipseplgn02/eclipseplgn02_1.html

第2回 Eclipseで使える静的解析ツール
Checkstyle というソース向けの静的解析ツール。細かいコーディングスタイルを規定できる。
http://www.atmarkit.co.jp/fjava/rensai3/eclipsetst02/eclipsetst02_2.html

javaNCSS
複雑度や、非コメント行をチェックしてくれるツール。あまりに複雑なところは、気合入れてレビューするか、シンプルに作り直したほうが良いかも
http://www.kclee.de/clemens/java/javancss/

ウォーターフォールモデル工程の中の他の工程

結合試験とは

開発関連記事

ウォータフォールモデルではテストファーストは当たり前?

他のコンテンツ

博士と助手のレビュー談義

コード作法・設計作法 5つの視点

デバッグ〜ソフトウエア開発手法で身につける問題解決力

http://www2.ocn.ne.jp/~cheerful/develop/
since 2001/3/3
http://www2.ocn.ne.jp/~cheerful/develop/index.html