　ソフトウェアエラーの深刻度が高いほど、ソフトウェア品質に対する要求が高くなり、必要なカバレッジレベルが上がります。テストケースによって達成されるコードカバレッジ率が高ければ高いほど、期待されるソフトウェアの品質は向上するといわれていますので、ソフトウェアの品質を向上させるためにはコードカバレッジ測定が非常に有効です。

　また、ISO 26262では、プログラムが稼働する実環境にできるだけ近い環境で統合テストケースを実行することを強く推奨しています。

　ISO 26262には、自動車の安全関連プロジェクトに使われるソフトウェアツールの認定に関する要求が含まれています。ツールの適正な扱いを定めるために、以下の2ステップのアプローチが使われます^（※2）。

ステップ1：分類
- 発生する可能性のある安全目標侵害、および発生する可能性のあるフォールトを検出できる確率に基づき、信頼水準を決定する
ステップ2：認定
- 要求される信頼水準に基づき、ツールを認定するための方策を定義する

（※2）ベクター・ジャパン資料「ベクターのツールと機能安全ISO 26262；2019年8月5日」より抜粋

　各ソフトウェアツールでは、要求される信頼水準（Tool Confidence Level；TCL）を分析することが求められています。もし、単体テストツールに対してツール認証が必要と判断された場合でも、機能安全認証を取得している単体テストツールを使用すれば、あらためてツール認証を取得する必要はありません。

　あくまで、機能安全はベストプラクティスであり、ツール認証を取得していないツールで単体テストを行っていたり、クロスコンパイルしていない環境でテストを行っていたりする場合もあります。しかし、ベストプラクティスとしては認証を取得している単体テストツールの使用が推奨されます。

2　なぜ単体テストが必要なのか？

2.1　なぜ単体テスト工程は飛ばされてしまうのか

　自動車のソフトウェア開発に携わっていて、ISO 26262に準拠した開発を行っている方々は単体テストを実施していると思いますが、ほかの組み込み業界では単体テストを行っていない会社が多いのが現状です。なぜ、単体テスト工程は飛ばされてしまうのでしょうか。

　その要因として考えられるのは、単体テストには非常に時間がかかるという点です。また、単体テストが実施されていない膨大なレガシーコードに対してテストをするためのコストを試算すると、余りにもコストが高く、結局は単体テストを行わないという判断になってしまうことも考えられます。

　単体テストに時間がかかっている場合は、古典的な単体テストを行っている可能性があります。例えば、テストドライバーやスタブのコードを書いていたり、無償のテストツールを使用していたりすることにより自動化が進んでいないことが背景にあるのかもしれません。

　こうした、工数が掛かるという問題に対しては、自動化をサポートする有償の単体テストツールの使用が有効な解決法だといえます。ツールを導入したうえで、まずは新しく追加する機能に対して単体テストを行っていくことが重要です。さらには、システムの中で複雑だと思われる部分に対して単体テストを行うことも効果的です。いずれにしても、まずは小さい範囲から単体テストツール導入の効果を測定していくことをお勧めします。

　多くの開発者が「単体テストを行いたい」という気持ちを持ってはいるものの、単体テストを行うためには開発のワークフロー自体を変えていく必要があり、そのことが単体テストツール導入の妨げになっているようです。また、開発しなければならないソフトウェアが増えていく一方で、社内のソフトウェア開発者数は増えないといった問題もあるでしょう。社内のリソース不足の問題が、新たなツール導入の妨げとなっているとも考えられます。

　開発のワークフローという点で見ると、日本では開発部門と評価部門が分かれている企業が多く、実装を全て終えた後に単体テストフェーズへ移行するという会社が多いのですが、効率的なテストを行うためには、実装してすぐにテストを行うことが理想的です。海外の自動車メーカーでは、実装後に細かい単位で単体テストを行うことが求められるケースも出てきています。

　自動車の開発現場では、ソフトウェアの評価を専門に行う部署を立ち上げている先進的な企業もあります。このようなソフトウェアのテストを行う仕組みを会社として作っていくことが必要になってきていることがうかがえます。

なぜ単体テストを行うべきなのか

前のページへ 1|2|3|4|5 次のページへ