単体テストとは何か、なぜ必要なのか【後編】：はじめての単体テスト（1/4 ページ）

[ベクター・ジャパン，MONOist]

　前編では、単体テストと機能安全の関わり、単体テストの重要性と組み込み業界の現状、単体テストの自動化について解説しました。後編では、ソフトウェアの品質管理や単体テストの手法について解説します。

→連載「はじめての単体テスト」バックナンバー

4　ソフトウェアの品質管理

4.1　アジャイル型、DevOpsの開発への転換

　現代のソフトウェア開発はウオーターフォール型から、アジャイル型へと転換していますが、自動車業界ではまだ、古典的なウオーターフォール型の開発が一般的のようです。

　アジャイル型の開発は、イテレーションとよばれる、細かい単位に区切った開発を繰り返していくことで進められます。1イテレーションにつき2〜4週間という短い期間の中で「計画→設計→実装→テスト」を行います。例えば、Googleでは開発者が実装・テストを請け負っており、テストだけを担当するという人員は非常に少なくなっています。全ての開発者がテストツールを持ち、実装・テストの業務を、責任を持って請け負っています。自動車開発ではGoogleの例と違い、無償のツールを使用しているわけではないため、開発者全員にテストツールを割り当てることはなかなか難しい現状があります。しかし、米国の自動車サプライヤーでは、ベクターの「VectorCAST」を開発者全員に割り当てるという取り組みが始まっています。

　ソフトウェア規模の拡大は機能の増加を意味し、それはプロジェクトの途中での要求や仕様変更の増加をも意味します。現状のウオーターフォール型の開発では、プロジェクト途中での要件や仕様変更に弱いという問題点があります。特に、自動運転開発といった分野ではアジャイル型の開発を進めている企業がすでに見受けられ、他の分野の開発においても、アジャイル型の開発に移行していくことによってソフトウェアのリリース速度と品質を高めるという流れにつながっていくと考えられます。

　次に、単体テスト工程におけるDevOpsの考え方について考えてみましょう。

　自動車開発では、先行開発部署と量産部署が分かれています。会社の規模や開発規模が大きくなればなるほど、この傾向は大きくなります。新しい機能を追加しても、実際の量産開発ではその機能をうまく活用できないという問題が起きます。こうした問題に対処するためには、DevOpsの考え方が必要です。

　DevOpsとは、開発チーム（Development）と運用チーム（Operations）がお互いに協調し合うことで、開発・運用するソフトウェア／システムによってビジネスの価値をより高めるだけでなく、そのビジネスの価値をより確実かつ迅速にエンドユーザーに届け続けるという概念です。

　自動車開発における問題点として、先行開発部署でしっかりとしたテストがなされていないということがあります。望ましいのは、新しい機能を追加すると共に、そのソフトウェアに対して自動化できるテスト環境を構築することです。テストを行ったドキュメントを残すことで、量産部署との対立を少なからず減らすこともでき、また、量産時のテスト効率を上げることもできます。新しい機能を開発するだけでなく、そのソフトウェアをテストする環境の構築が求められているのです。

5　単体テストの手法

　前に述べたように、単体テストは手作業で実施すると非常に工数が掛かるため、その工程ごと飛ばされてしまうことがあるほど、とかく敬遠されがちな工程ではあります。しかし、厳密なソフトウェア品質が求められる自動車、医療、航空の分野では、ISOなどの国際規格で単体テストを実施することがルール化されており、このことがソフトウェアの品質安定に寄与しています。

　そして、単体テストはソフトウェアの開発工程において唯一、実装されたソフトウェアの全数試験（全数テスト）が行える工程であり、また最初のテスト工程でもあります。もちろん、文字通り"全数"のテストというのは開発工数上、現実的な話ではありませんが、単体テスト自体を避けていては、本当に高品質なソフトウェアの実現は望めません。

　ここからは、単体テスト（Unit Test）の手法について説明します。単体テストには大きく分けて、以下の2つの手法があります。

• ブラックボックステスト
  • ソフトウェアの内部構造を参照せず、仕様書に基づきテストケースを設計する手法
• ホワイトボックステスト
  • ソフトウェアの内部構造に着目し、テストケースを設計する手法

　簡単にいえば、仕様書通りに関数が実装されているかを確認することがブラックボックステストであり、関数の内部構造に問題がないかを確認することがホワイトボックステストです。