プログラム単体テスト

プログラムに対する最初のテストは、製作時点で行なわれるプログラム単体テストとなります。プログラム仕様書で定義されたプログラム単体での機能が過不足なくコーディングされているかをチェックする作業です。

単体テスト

システム開発V字モデルでは、プログラム設計に対応するテスト作業を単体テストと位置づけています。

プログラムの単体テストでは、次の2つの視点で確認する必要があります。
プログラムがプログラムとして記述されているかという視点と、プログラムに求められている機能が実装されているかという視点です。

私たちが文書を作成する時、たとえばそれが日報を作成するという目的であれば「日時・活動内容」などを社内で規定されたフォーマットに要求された内容を記述します。それと同じように、プログラムの作成でもプロジェクトで規定したコーディング基準に従って、そのプログラムに求められている機能を実装しなければなりません。

文書のレビューを上司にお願いした時、「これじゃレビューする以前のレベルだから、書きなおせ!」と怒鳴られた経験はありませんか。プログラムも同様です。プログラムを作成するPEは、そのプログラムをSEに提出(納品)しテストをしてもらうにあたり、テストに耐えうるレベルのプログラムとして出来上がっている必要があります。文書作成でいえば、作成者自身が行なう自己レビューに該当するものといえるでしょう。

プログラムの単体テストとしては、PE自身が作成物に対する成果物チェックとしてのテストと、SEが納品されたプログラムに対し作成依頼した内容で実装できているかを確認するテストという、2段階でテストが行なわれることとなります。
そこで、PE自身が行なうテストとSEが確認するテストに分割して考えていくこととし、PE自身が行なうテストを「プログラム単体テスト」と呼び、SEが確認するテストを「プログラム受入テスト」と呼ぶことにします。

プログラム単体テスト

ここでは、製作工程で行なわれるPE自身が実施するプログラム単体テストでの作業内容と注意点を確認します。

プログラミングをする場合、プログラム設計書の仕様内容を理解し、どのような実装をすべきかと考えますが、この時、どのようなテストを行なえば実装内容を確認できる、ということを明確にしておかなければなりません。成果物の品質は、テストをした結果がOKとなることによって担保されます。それは、プログラム設計書に記述されている仕様に対し、どのようなテストを実施すれば品質が担保されるのか、を理解しているということです。

XP:エクストリーム・プログラミング(extreme programming)では、テスト駆動型開発あるいはテストファーストといって、最初にテストコードを作成し、そのテストが動作するようにコーディングしていくプログラム製作を求めていますし、システム開発W字モデルでは、プログラム設計に引き続きプログラムテスト設計をするというモデルになっていますが、プロセスとしては同じようなスタイルになります。

プログラムの品質はテスト結果で評価されますから、プログラマーはロジックを組み立てる作業と並行して、どのようなテストで品質を確認するかを考え、プログラム単体テストのテスト項目を洗い出していく必要があります。そして、担当するプログラムの単体テスト項目が全て出そろった段階で、プログラム設計をしたSEにテスト項目をレビューしてもらい承認を受けてください。これにより、実装したプログラムに対し、承認を受けたテスト項目が全てOKとなれば、プログラムの単体品質は問題なしと判断することができます。

プログラム単体テストの項目

プログラムの単体テストとしては次の2つの技法があり、それぞれにおいて品質が十分である必要があります。

ホワイトボックステスト プログラムの構造に着目してデータの流れや制御が正しいかをコードロジックの視点からテストケースを作成する技法
ブラックボックステスト プログラムの構造やコードロジックは考慮せず(ブラックボックスとして扱い)、要求される仕様に着目してテストをする技法

上記の内、ホワイトボックステストは、プログラムを実装したプログラマーでないと実行が困難なテストといえます。プログラム設計を行なったSEとしては、プログラムがどのようなロジックであれ、要求した仕様が実現できていさえすれば問題視する必要はありません。
そうであれば、プログラムのロジックは、どうでもいいのかというと、そういうわけではありません。プログラムはシステムを構成する部品と位置づけることができますが、システムに対しては、そのシステムを利用するユーザなど外部からの要求により、仕様の変更を求められることがあります。システム仕様の変更は、それを構成するプログラムに対する変更要求になりますから、プログラムは将来的に変更がしやすい(仕様変更に耐えうる)ロジックで組まれていることが求められます。プログラムのロジック変更を担当するPEは、変動する可能性がありますので、誰でもが理解しやすいプログラムコードである必要があります。

可読しやすいロジックであることが、プログラムの可用性を高めます。コーディング基準も可用性を向上させる施策といえます。プログラムの成果物品質の一つとして、可読性の高さも挙げられます。

製作工程で実施すべきプログラム単体テストとしては、ロジックに主眼をおいたホワイトボックステストと、仕様実装を確認するためのブラックボックステスト、それにコーディング基準を満たしているかのチェックも必要となります。

ホワイトボックステスト

制御フローテストといって、ロジックの中で使用されている命令や分岐が正しく動作するかをチェックするテストがあり網羅度(coverage)で評価します。

C0:命令網羅(statement coverage)
プログラムに記述された命令の動作確認をするテストで、全ての命令のうちテストした命令の割合を命令網羅率といいます。
このC0テストは、全ての命令を必ず一度は実行すべきでものであるため、網羅率100%をテスト終了条件とします。
C1:分岐網羅(branch coverage)
プログラムに記述された条件分岐の動作確認をするテストで、全ての分岐のうちテストした分岐の割合を分岐網羅率といいます。
このC1テストも、全ての条件分岐を必ず一度は実行すべきでものであるため、網羅率100%をテスト終了条件とします。
C2:条件網羅(condition coverage)
プログラムに記述された条件分岐の組合せの動作確認をするテストで、全ての組合せ条件のうちテストした組合せ条件の割合を条件網羅率といいます。
C2テストでは、全ての組合せ条件を実行すると膨大なテスト数になってしまう可能性があるため、テストを終了する網羅率を事前に決めておく必要があります。
「a」「b」「c」と3つの分岐条件が10ある場合では、3×3×3×3×3×3×3×3×3×3=59049となります。

他にデータフローテストというのがあり、プログラムで使用するデータや変数が[入力定義」⇒[処理操作」⇒[消滅削除」の順番になっているかをチェックするもので、未定義のデータや変数の処理によるエラーなどの不具合を防止するものです。
これらのチェックは、人が行なうとモレやミスにつながりやすく網羅度の算出も難しいため、ツールを利用して行なうケースが一般的です。

ブラックボックステスト

ロジック部分はブラックボックスとして扱い、入力データと出力結果のみに着目して仕様通りに処理されているかを確認するテストです。

例えば、次のような条件で料金が決まる食べ放題のレストランがあるとします。

大人 子供
男性(性別フラグ=0) 2000円 1700円
女性(性別フラグ=1) 1800円 1500円

・入力データが大人(年齢=25)&男性(性別フラグ=0)の場合、「2000円」が出力結果です。
・入力データが子供(年齢=10)&女性(性別フラグ=1)の場合、「1500円」が出力結果です。

大人か子供かの判断は、「年齢>19 ⇒ 大人」であっても「年齢<20 ⇒ 子供」であっても出力結果が正しいのであれば問題ありません。
男性か女性かの判断も、「性別フラグ=0 ⇒ 男性 / ≠0 ⇒ 女性」であっても「性別フラグ≠1 ⇒ 男性 / =1 ⇒ 女性」であってもかまいません。
また、「大人か子供か」と「男性か女性か」のどちらを先に判断しても出力結果には影響しません。
このように内部的な処理(ロジック部分)はブラックボックスとして扱い、入力と出力の組合せが正しいか否かだけを調べるのが、ブラックボックステストです。

ブラックボックステストでは、プログラム仕様に記述されている条件に基づいて入力データを用意し、条件ごとに実行される処理内容を出力結果をチェックすることで、ロジックの正しさを確認するというスタイルになります。
入力データは「同値分割」と「境界値分析」を用いて用意します。

同値分割 仕様として定義されている条件に合致する正常データのグループ「有効同値クラス」と合致しないエラーデータのグループ「無効同値クラス」を抽出し、その同値クラスから代表となるデータを選んで正常処理とエラー処理をテストするという方法です。
境界値分析 同値クラスの中から境界となるデータを選んでテストをするという方法です。条件判定をするロジックの判断ミスやコーディング間違いを起こしやすい部分が境界値となる可能性が高いと考えられるため、実施されるテストとなります。

したがって、テスト対象となるデータは同値クラスの中から境界値となるものを選定することとなりますが、境界を設けることができない場合もあるので、その時は任意で代表となるデータを決めてください。例えば、消費税計算など、無条件に処理が行なわれるようなケースが該当します。

プログラム単体テストのチェックポイント

プログラム単体テストでは、ホワイトボックステストブラックボックステストを行なってください。

ホワイトボックステストでは、C0とC1は網羅率100%をテスト終了条件とし、C2はプログラムごとに事前に基準を設けた上でテストを実施しましょう。

ブラックボックステストでは、プログラム仕様として記述されている処理が問題なく実装されていることを確認してください。
テストの範囲は、プログラマーがロジックを組み立てる際に洗い出したテスト項目に対し、プログラム設計をしたSEが承認したものとなります。

 ブログランキング・にほんブログ村へ

シェアする

  • このエントリーをはてなブックマークに追加

フォローする