状態遷移表を使用したテスト手法【前編】：状態遷移表による設計手法（6）（1/4 ページ）

状態遷移表による設計手法について解説。今回は「状態遷移表を使用したテスト手法」の【前編】として、ホワイトボックステストとブラックボックステストについて詳しく解説する。

[塚田雄一　キャッツ，MONOist] PC用表示関連情報

LINE

Hatena

はじめに

　組み込みソフトウェアが抱える一番の課題は「設計品質の向上」です。本連載の主役「状態遷移表」であれば、“イベント”と“状態”の全ての組み合わせを捉えることができるため、「モレ」「ヌケ」のない品質の良い設計が可能です――。ということで、これまで状態遷移表設計手法について詳しく解説してきました。具体的には、“要求分析モデル”“設計モデル”“状態遷移表からの実装”などのテーマを中心に、その設計手法を見てきました。

　ご存じの通り、組み込みソフトウェア開発において、“手戻り作業”は非常にコストが掛かり、とても非効率なものです。そのため、前工程で不具合要因をきちんと抑えることが重要です。ただし、不具合が前工程で抑えられたからといって、テストが完全になくなるわけではありません。製品をリリースする際は、それが正しく動作することを確認しなければなりませんので、テストは絶対になくなりません。

　さて、このテストですが、非常に多くの工数（コスト）を要します。もしもテストにより何らかの不具合を発見した場合は、前工程に戻り、その原因を特定し、不具合を修正して、再度テストを行わなければなりません。テストは、これだけ手間の掛かる作業であり、不具合の発生が与えるテスト工数（コスト）への影響がいかほどのものか、容易に想像できると思います。

　本連載で取り上げている状態遷移表設計手法は、不具合要因を設計工程の段階で特定・解決できるため、テスト工数（コスト）の削減に寄与します。そして、状態遷移表で設計を行うことにより、有効なテスト項目の効率的な抽出、テスト効率の向上、テスト工数自体の削減という効果をもたらします。

　状態遷移表を使用したテスト手法には、状態遷移表のアクションセル部分に着目してテスト項目を考える「ホワイトボックステスト」と、イベント部分に着目してテスト項目を考える「ブラックボックステスト」、そして、状態遷移表の遷移部分に着目してテスト項目を考える「パステスト」があります。

　今回は、「状態遷移表を使用したテスト手法」の【前編】として、ホワイトボックステストとブラックボックステストについて解説し、次回【後編】でパステストについて取り上げたいと思います。

　なお、本連載では以下の6つのテーマを順番にお届けしてきました。

ソフトウェアテストとは

　これから、ソフトウェア開発におけるテストについて紹介していきますが、そもそも「ソフトウェアテスト」とは、どのようなものなのでしょうか。

　Wikipediaでひも解いてみると、図1のように記されています。ソフトウェアテストとは、ソフトウェアが正しく動作するかを確認するための作業のことであり、「プログラム中の欠陥（バグ）をできる限り多く発見することを目標として行われる」（Wikipediaより抜粋）とあります。さらに、「プログラム中の欠陥が存在することを示すことはできる」が、「欠陥が存在しないことを証明できない」（Wikipediaより抜粋）と記されています。

図1　「ソフトウェアテスト」とは（出典：Wikipedia）

　ソフトウェアテストの具体的な作業では、不具合を発見するために、テスト項目を考えて、それを基にテストを実行し、要求通りに動作するかを確認して、要求通りでなければ、“欠陥（バグ）あり”となります。しかしながら、テスト項目を考えるのは人間であり、全てのテスト項目を抽出することは現実的に不可能です。仮に、全てのテスト項目を抽出できたとしても、膨大な数のテストを全て実行するのは困難です。このため、一般的にテストには多くの人件費工数（コスト）が掛けられているのですが、製品出荷後に不具合が見つかってしまった……ということも珍しくありません。

製品出荷後における不具合の割合

　図2に、「製品出荷後に不具合を起こした製品数」と「製品出荷後の不具合原因比率」を記します。これは経済産業省による「2009年版組込みソフトウェア産業実態調査報告書：経営者・事業責任者向け調査」のデータです。

図2　「ソフトウェア品質の課題」／2009年版組込みソフトウェア産業実態調査報告書：経営者・事業責任者向け調査（https://sec.ipa.go.jp/download/files//report/200706/es07rALL.zip）（出典：経済産業省）

　図2左の「製品出荷後に不具合を起こした製品数」を参照してみると、実に約60％が製品出荷後に何らかの不具合を引き起こしていることが分かります。この結果は、“製品出荷前に不具合をなくすことがいかに困難であるかを示したもの”であるといえます。

　そして、製品出荷後に起こる不具合の主な原因ですが、図2右に示す通り、50％以上がソフトウェアによるものだということです。この結果から分かるのは、“ソフトウェアにより引き起こされる不具合を完全に取り除く（解決する）ことは難しい”ということです。

組み込み開発におけるテスト工数の割合

　不具合対策に必要不可欠なテストですが、一般的にどのように行われているのでしょうか。先ほどと同じく経済産業省のデータを基に見てみましょう。

　図3に、「開発工程ごとの投入人数の比率」を記します。この図から、国内の社内・グループ会社・グループ会社以外、海外のグループ会社・グループ会社以外の全てにおいて、ソフトウェアにおける単体テスト／結合テスト／総合テスト、システムにおける統合テスト／総合テストで、他の開発工数よりも非常に多くの人件費工数（コスト）を投入しており、“人海戦術”が主要な施策になっていることが見てとれます。

図3　「工程ごとの投入人数比率」／2009年版組込みソフトウェア産業実態調査報告書：経営者・事業責任者向け調査（https://sec.ipa.go.jp/download/files//report/200706/es07rALL.zip）（出典：経済産業省）

なぜテストには、多くの人件費工数（コスト）が掛かってしまうのか

　では、なぜテストには多くの人件費工数（コスト）が掛かってしまうのでしょうか。図4に、5項目のテストを実施し、「不具合が発生しなかった場合」と、「不具合発生＆修正バグが発生した場合」の2パターンを記します。

図4　なぜテストには工数（時間）が必要なのか？

　図4上段の通り、不具合が発生しなかった場合は、5項目のテストで全てが完了します。では、不具合発生＆修正バグが発生した場合はどうなるでしょうか（図4下段）。テスト項目4で不具合が見つかったとします。その不具合をきちんと修正できていれば、再試験で問題なくクリア！といくわけですが……。このケースでは、再試験で、先ほどは引っ掛からなかった不具合がテスト項目2で発生しています。そうです。この不具合はテスト項目4の修正により生み出された“修正バグ”です。この例では、次の修正、再試験で無事にテストをクリアしていますが、先の不具合が発生しなかった場合と比べて、どれだけ人件費工数（コスト）が余計に掛かったでしょうか。数えてみると分かる通り、何とトータル15項目のテストを実施したことになります。単純計算で3倍の人件費工数（コスト）が掛かることになります。

※注：ちなみに、状態遷移表設計手法で設計を行えば、不具合が減るため、テスト工程での人件費工数（コスト）が削減され、全体の開発工数（コスト）も削減できます。既にご理解いただいている通り、上流工程で不具合を発生させない開発手法になります。