図表1： システム構成要素としてDevice、Server、In-Carの３つに大きく分類できる

【対策前環境】

テスト対象となるTCUへの電源操作は専用の設備で制御し、対向するECUはシミュレーターによる模擬で実現。また接続先のサーバーは試験用のメインサーバーへとつながっています。
テスト環境はすべて試験場に配置され、手動によりテスト実行していましたが、コロナ禍に対応するため、自宅からでもテスト実行できるリモート環境の構築が求められました（図表2）。

図表2：試験場に配置されていたテスト環境がリモートコントロールにより在宅で実施可能になった

【対策】

TCU操作・計測を1台の制御用PCで管理し、これを自宅からでもリモートコントロールできるよう環境構築を行いました。ポイントは既存の設備・汎用ソフトを活用したことで、環境構築を低コスト化できた点です。

TCUのようにGUIを持たない車載ECUは、主要な通信インターフェースのほとんどが容易に機械的制御でき、技術的にも費用的にも環境構築しやすいメリットがあります。
また、テスト実行者が直接機器を操作する必要がなく、ディスプレイなどの周辺機器の設置も不要なため、電源さえ確保できれば狭いスペースに複数の試験環境を用意すること（省スペース化）が可能になります。さらにテスト対象がTCUであれば、環境を海外拠点に設置することで、他国キャリア通信下でのテストを日本にいながら実施することも可能です。

【対策前環境】

こちらは事例1とは異なり、対策前の時点でTCU自動テストの環境が実現しています。 この自動テストで実現できているTCUのインターフェースはCAN、電源をはじめとした主要なインターフェースのみで、対向ECUの模擬も最低限の数だけ対応しているという状況でした。これに対して顧客からは、自動テスト対応可能なインターフェースや模擬をする対向ECUを増やし、より市場に近い環境での自動テストを実現することが求められました（図表3）。

図表3：自動テスト可能なインターフェースや対向ECUは増加したが、一方でコスト増などの課題も発生

【対策】

そこでテスト環境に対し、TCUのジカ線制御のためのハード機器、GPSシミュレーター、そしてTCUに物理的に干渉する装置を追加しました。さらにこれらを自動テストシステム上で制御できるロジックを開発することで、自動テストの対応範囲を拡張させました。模擬をする対向ECUの数についても、より実際の車両に近づくようその対象を広げました。
しかしその一方で、新規インターフェースに対応した設備購入に伴うコスト増、テストスクリプトを作成するための工数増といったような課題も生じました。

【TIPS】TCU自動テストの難しさ

TCUに対するテスト自動化は、Web系／アプリ系の自動テストと比較して非常に難易度が高いのが実状です。要因も以下のようにさまざまです。

ここで重要なのは、自動テストを行う目的を明確にすること、そして自動テストでなければならない必然性を検討し、開発すべきテスト環境を見極めることです。品質、コスト、納期など、自動テストを行う動機はさまざまですが、プロジェクトの状況によっては、全てを自動テストで対応することが最善とは限りません。

【対策前環境】

実車両を用いるので、In-Carの要素は対向ECU含め全て実機となります。車両内のCAN※5通信は、各CANバスに計測機器をつなぎ、テスト結果判定に用います。サーバー側は試験用のメインサーバーを利用しますが、車両およびTCUが海外向けの場合が多いため、TCUとメインサーバーの間に回線シミュレーターを立て、疑似的にインターネット通信を成立させています。この環境におけるテスト実行では、図表4に示した通り3名の実行者が必要になります。

ここでの最大の課題は、テスト実行者に高い経験値が求められる点です。特に通信データを確認する実行者Bには、テスト対象に対する仕様理解だけではなく、シミュレーターや計測機器の取り扱いも求められます。
また、テスト結果の詳細データは後日のチェックとなるため、「通信レベルでの異常にその場で気付けない」という課題もあります。さらに、後日不具合が判明した場合、テスト再実施のためのテスト車両再手配といったデメリット（多大な工数やコスト）まで生じます。

図表4：実車両による手動テストには、テスト実行者に高い経験値が求められる、通信の異常にその場で気付けないなど課題が多い

【対策】

これに対し当社では、車両評価向けの自動テストシステムを開発し、テスト実行者の一部作業を自動化させる取り組みを行いました。新たに構築した環境では、テスト実行者はテスト項目ごとに用意されたテストスクリプトを選択・実行するだけとなり、細かなデータ判定やサーバーへのリクエストなどは自動テストシステムが代行するようになりました。これにより、テスト実行者の減員を実現し、さらにテスト実行者の経験値に依存しないテスト実行体制を構築できました（図表5）。

また、評価実行中に自動テストシステムがデータ異常を検知するため、その場で手順の見直しや再現試験の実施ができるようになり、結果的に車両テストの再実施頻度を減少させる効果もありました。
ポイントは、自動化システムの制御対象を「制御がしやすいもの（シミュレーターの設定やデータの判定、実行記録など）」に絞り込んだことです。結果として、テストの効率性向上につながりました。

図表5：自動化によりテスト実行者を減員。車両テストの再実施頻度も減少

【対策前環境】

ここでは、車両から送信されるデータを変換し、スマホアプリへ連携するサーバーがテスト対象となります。テスト実行者は車両シミュレーターからテストデータを入力し、スマホシミュレーター上に表示された情報をもって、テスト対象の出力値を判定していました。しかし、テストデータの入力や、出力値の判定に時間や経験値を要する点が課題となっていました（図表6）。

図表6：キーワード駆動方式の採用により、専門スキル無しでテストスクリプト作成が可能に

【対策】

当社ではその対策として、各シミュレーターの入出力の制御・判定を行う自動テストシステムの開発を行いました。 ここでの最大のポイントは、自動テストシステムへのインプットとなるテストスクリプトの作成方法として、キーワード駆動方式を採用した点です。キーワード駆動方式採用の利点は、テストスクリプト作成に必要な技術的ハードルが下がり、（極端に言えば）誰でも簡単にテストスクリプトが作成できるところにあります。

【TIPS】キーワード駆動試験

キーワード駆動試験とは、ISO/IEC/IEEE 29119-5で規格化された技術であり、自動テストシステムの効率化に活用できるものです。

本来、自動テストを行う際のコマンドは、プログラミング言語で作成された自動テストスクリプトで表現される必要がありました。しかし、キーワード駆動試験では、繰り返し行う操作や判定（コマンドの集合体）を自然言語ベースのキーワードで定義し、その組み合わせによって自動テストスクリプトを作成します（図表7）。

図表7：定義されたキーワードを入力すると、自動的にテストスクリプトが作成される

図表8：テスト環境を1つの自動テスト実行基盤に集約し、環境開発工数をカット

図表9：DevOpsの考えに基づき、開発環境を運用フェーズでも継続利用する

このテストでは、DAの最新ソフトに対し、２つのテストを行っています。1つはリグレッションテストです。こちらはデグレードの早期発見を狙ったもので、ソフトウェアの更新の度に自動テストを行う環境が用意されています。
もう1つはスマートフォン接続に対する互換性テストです。各社・各OSのスマートフォン実機を用意し、DAとスマホ間の連携多様化を想定した互換性テストを行っています。
これらのテストはテスト実行ができるような環境や仕組みが整備されており、テストの効率化につながっています。またこの環境を用いて、市場からの指摘に対する再現試験環境としての活用も期待されています。

当事例のポイントはテスト環境そのものではなく、テスト環境の運用方法にあります。従来、製品の開発段階で使われていた環境を、運用フェーズでも継続利用するという「DevOps」の考えに基づき開発されていることが特徴です。

【TIPS】運用フェーズにおけるテスト環境の課題（DevOps）

これまでの事例で見てきたように、製品の開発（Dev）段階においては、開発・テストをより正確・効率的に行うさまざまな取り組みがなされてきました。一方で、これらの取り組み（資産）が製品リリース後の運用（Ops）フェーズにおいて流用されることなく、運用側がコストと時間をかけて別個のテスト環境を新規開発するケースが見られます。テスト環境の視点においては、テスト環境開発の初期段階から製品リリース後のOTA、市場指摘に対する対応を視野に入れ、技術・運用の両面から継続的に利用可能なテスト環境を開発することが重要だと考えます。