Technical Information

車載ECUの開発現場から見たテストと自動化の現状

asset_approach_column_automotive-test01_hero.jpg

近年、CASE・MaaSと呼ばれる新しい領域で技術革新が進み、クルマの概念は大きく変わろうとしています。そんな中、車載ECU(電子制御ユニット)は先進技術の制御をつかさどる重要な要素であり、自動車の電動化・自動化を支えています。搭載数も年々増加傾向にあり、車載ECUに対する自動テストシステム開発のニーズが高まっています。リソース不足の解消やスケジュールの短縮など、その理由はさまざまです。一方で、車載ECUなどの組み込み系テストの自動化は、ウェブアプリやスマートフォンアプリのテスト自動化と比較すると難易度が高く、依然として大きなハードルとなっています。本講演では、自動テストシステム開発や自動テストスクリプトの運用を担う現場エンジニアの立場から、テスト自動化の現状と課題を振り返った上で、課題解決に向けたプロセスについてご紹介します。

※この記事は、『ベリサーブ オートモーティブ カンファレンス 2021』の講演内容を基にした内容です。

米谷 恵一

株式会社ベリサーブ
中部オートモーティブ事業部
第一ビジネスユニット
米谷  恵一 

車載ECUテストの現状

オートモーティブ分野におけるテストボリュームは拡大の一途をたどっています(図1)。中でも、情報セキュリティの重要性の高まりやユーザーサービスの拡大志向により、IoTに代表される情報系ECUの機能拡大は顕著です。こうした状況を背景としてテスト自動化プロジェクトが多数発足していますが、そこにはプロジェクトオーナーの「今よりも楽にテスト計画を完遂させたい」という漠然とした期待があるように思います。

ベリサーブにおける情報系ECUのテスト設計実績

図1:ベリサーブにおける情報系ECUのテスト設計実績

組み込み系テスト自動化の難しさ

冒頭で述べた通り、自動テストシステムの開発においてテスト対象を車載ECUとする場合の特徴は、ウェブ系やアプリ系を対象とする場合と比較して、開発面、運用面で非常に難易度が高いことです。チェックポイントが多岐にわたり、複雑さが群を抜いているためです。また、高額な自動テスト専用のハード機器が必要であったり、テスト対象にAPIが用意されていないため直接操作による振る舞いが確認できなかったりといった環境面での制約も多く、テスト自動化のハードルをいっそう高いものにしています。

テスト自動化の現場で起きていること

以下は、ベリサーブが携わった、あるいは直接話を聞いたテスト自動化プロジェクトの中で、品質、予算、納期目標を達成できなかった「失敗プロジェクト」の特徴です。

  1. 1.目的があいまい
  2. 2.Stand Aloneな(孤立した)プロジェクト体制
  3. 3.PoC(Proof of Concept※1)・スモールスタートの計画が無い

各特徴について説明します。

※1:新しい概念や理論、あるいはアイデアの実証を目的とした試作開発の前段階における検証、デモンストレーションのこと。

1.目的があいまい

「目的」とはエンドユーザーあるいはプロジェクト発注者の要求を指し、「目的があいまい」とは「要件は存在しているものの要求が見えていない」状態を言います。例えば「1000項目分のテストケースの自動テストが実行可能なシステムの開発」を成果物の目標とするケースを考えてみましょう。その目標を達成すると「誰が」「どういう理由で」うれしいのか、といった上位要求が共有できていないと、1000項目のテスト自動化を完了しても、いざふたを開けてみると、従来の手動テストの方がコスト面でも品質面でも良かったという残念な結果になる恐れがあります。要求を的確に見極めるためには、経験や知見が豊富なテスト技術者によってコストやテスト品質の十分な検討がなされなくてはなりません。

コストについては、長期的な計画を組むことができるかが重要なポイントとなります(図2)。テスト自動化の初期導入である新規プロジェクトでは、手動テストを上回る費用とリソースが必要になるのが一般的ですが、継続する派生プロジェクトでは大幅にコストダウンが見込めるからです。

テスト品質は、手動テスト/自動テストをいかに適切に配置できるかが重要です。手動テスト/自動テストにはそれぞれ目的に応じた適性があります。例えば、自動テストはパラメーターのバリエーションに関するテストや、長時間繰り返すといった単純なテストには非常に有効ですが、「探索的テスト」や「気付きを得る」という側面においては人に遠く及びません。こうした手動テスト/自動テストの適性を踏まえ、役割分担させることが大切です。

「目的」は、要求仕様書の作成により明確にすることが可能です。その後の要件定義プロセスで要求を詳細化・具体化していきます。テスト自動化の「目的」次第では、現状のスキル・予算などから実現が難しい場合や、むしろ実現しない方が要求にかなうという場合もあるでしょう。そのようなときは、要件定義プロセスで可能な限り具体的に要求の擦り合せをします。もちろん、要求仕様書は、テスト自動化プロジェクトチーム内だけでなく、テスト関係者全員と共有する必要があります。

ベリサーブにおける手動/自動テストコストの実績

図2:ベリサーブにおける手動/自動テストコストの実績

2.Stand Aloneなプロジェクト体制

自動テストシステムの開発はStand Aloneなプロジェクトになりやすい傾向があります。円滑なテストプロセスを達成するには、テスト自動化プロジェクトチームは手動テストチームとテスト計画完了まで常に連携し、同じ目線、同じ立ち位置でテストプロジェクト全体に関わる必要があります。
また自動テストスクリプトの運用を誰が行うべきかについては、議論が分かれるところかもしれません。スキルが不要で、誰でもテスト実行が可能な点はテスト自動化のメリットですが、数多くのプロジェクトを支援してきた立場としては、テスト自動化導入開始直後の開発プロジェクトでは、自動テストシステムを開発したプロジェクトチームが自ら運用することがベストだと考えています。自動テストシステムから発生したバグと製品から発生したバグの切り分け解析は難易度が非常に高く、専門的な知見が必須だからです。

3.PoC・スモールスタートの計画がない

手動で行われてきたテストを自動化する場合(既存あるいは派生プロジェクトのテスト自動化)に、PoCやスモールスタートの計画がないために弊害が生じるケースがあります。一例を挙げましょう。図3は、車載ECUのテストについてテスト対象とそれに関わるインターフェース(IF)の振る舞いを表したものです。テストケースは、テスト対象がこのシーケンスの図の仕様通りに振る舞うことを確認することとします。手動から自動テストにシフトする際、具体的に起こり得る問題に対処するために、考慮すべき三つのポイントがあります。いずれも、PoCやスモールスタートによりプロジェクトの初期段階で問題を洗い出し、対処しておくことが有効です。以下、考慮すべきポイントについて順に見ていきます。

車載ECUにおけるテスト対象と関連IFの処理の流れ

図3:車載ECUにおけるテスト対象と関連IFの処理の流れ

(1) 判定範囲(判定箇所)の見直し

一つ目は、テストを実施する上での操作に対する確認についてです(図4)。手動テストで必要な操作は手順に記載されており、テスターはその通りに操作して結果を判定します。操作が正しく行われているかは、テストケースに明記されていなくても目視で確認します。一方、自動テストでは、テストケースに記載されたことしか判定しません。もし何らかの要因によって正しい操作が行われなかった場合、確認したいテスト対象の振る舞いが正しく判定できず、誤りと判定される可能性もあります。操作の誤りとテスト対象の振る舞いの誤りを切り分けるには、テストの判定箇所以前の操作についても手順を明示する必要があります。

手動テストから自動テストへ切り替える際のポイント1

図4:手動テストから自動テストへ切り替える際のポイント1

(2) 判定内容の見直し

二つ目は、テスト設計時の記載内容、いわゆる「書きっぷり」についてです(図5)。例えば「○○が正しい動作であること」「仕様通りの振る舞いであること」など、一意に判断できない自然言語が期待値になっている場合があります。テスト自動化に当たっては、基本テスト設計のレベルで判定範囲を特定し、詳細テスト設計のレベルで判定内容を具体化する、いわば自動テストシステム用として期待値を再設計する追加プロセスが必須です。

手動テストから自動テストへ切り替える際のポイント2

図5:手動テストから自動テストへ切り替える際のポイント2

(3) 期待値の追記

三つ目は、仕様定義のない振る舞いの扱いについてです(図6)。車載ECUは単独で動作するわけではなく、ほとんどの場合、複数の車載ECUの処理の結果を受けシーケンシャルに処理します。その際、関連車載ECUそれぞれの通信間にはもれなく時間間隔が存在します。その時間間隔全てに仕様が定義されていることはまれで、むしろ非機能要件として対象となる各車載ECUの実力値に依存することの方が一般的です。このような振る舞いは、過去の動作からの慣習といったレガシー要因であることが多く、実際にそれ自体は製品品質においては問題とならないケースであることがほとんどです。

手動テストから自動テストへ切り替える際のポイント3

図6:手動テストから自動テストへ切り替える際のポイント3

ただし、テスト自動化においては、値を取る事象には全て許容か、非許容か、あるいは無視してもよいかというテストスクリプトの振る舞いを決める必要があるため、これらについてタイムアウト時間の設定など、テスト自動化設計目線での判断を追加しなければなりません。この検討は、テストミスに直結しかねない非常に重要なテスト自動化プロセスであるため、検討を実施する際には、テスト自動化プロセスを理解した上でのテスト設計スキルが必須です。

テスト自動化プロジェクトを成功に導くためには、PoCやスモールスタート計画の検討は必須です。さらにプロジェクトの状況に応じて、検討したスモールスタート計画を実施に移すことも推奨します。要件定義を通じてできる限りの事前検討を行うことはもちろん重要ですが、実際にやってみないと見つからない問題は必ずあるからです。それを改善するために、まずは小さく始めて水平展開していく。そうしてインプットの最適化を進めながら徐々に大きく転がしていく。車載ECUテストの自動化は、このように進めることをお勧めします。

プロジェクト管理者として考えるテスト自動化プロセス

現場での事例を踏まえ、プロジェクト管理者として考える最適なテスト自動化プロセスの一例をご紹介します。図7は、多くの車載ECUテスト自動化プロジェクトに見られる、既存の手動テストを自動化する場合のプロセスです。「テスト戦略」と「テスト設計」までは手動テスト用としてすでに構築されており、その一部を自動化する構図です。ここでは「自動化できる/できない」の検討をはじめ、手動テストと比較してコストはどうか、継続プロジェクトの中で採算が取れるのか、テスト自動化のコストが手動テストより下回るのは何回目のリリースからかなど、さまざまな角度からの検討によりテスト自動化プロジェクトの計画を策定し、テスト自動化範囲の擦り合せを行います。ここが最も重要なプロセスといえます。

次に既存プロジェクトの資産であるテスト設計を基に、インプットの最適化を行います。ここまでに必要なのは主にテスト関連スキルです。
この後のプロセスでは、テスト全体の役割分担とプロジェクト管理を行うためのシステムエンジニアスキル、実際の環境開発ではプログラミングに代表される開発スキルと、さまざまなスキルを駆使しながらテスト活動を推進していくことになります。

車載ECUテスト自動化プロジェクトにおけるテスト自動化プロセスの一例

図7:車載ECUテスト自動化プロジェクトにおけるテスト自動化プロセスの一例

おわりに

以上、数多くの実践現場から導き出されたテスト自動化プロジェクトの課題と改善ポイントについてご紹介しました。今回の内容が、車載ECUなど組み込み系テストの自動化に取り組む皆さまの参考になりましたら幸いです。