組み込みハードウェアによるテストの自動化

https://stackoverflow.com/questions/115115

02-07-2019
|

質問

組み込みハードウェア上で直接テストを自動化することに成功した人はいますか?

具体的には、ハードウェア層モジュールの一連の単体テストを自動化することを考えています。私たちはハードウェア層のコードにもっと自信を持つ必要があります。私たちのプロジェクトの多くは、割り込み駆動タイマー、ADC、シリアル IO、シリアル SPI デバイス (フラッシュメモリ) などを使用しています。

これでも努力する価値はあるでしょうか？

通常、次のことをターゲットとします。

プロセッサ:8 または 16 ビットのマイクロコントローラー (一部の DSP のもの)
言語：C (場合によっては C++)。

解決

もちろん。自動車業界では、新製品ごとに 10 万ドルをかけて特注のテスターを使用して、ハードウェアとソフトウェアが正しく動作していることを確認しています。

ただし、開発者は、多数の USB I/O、A/D、PWM 入出力などを備えた安価な (1,000 ドル未満の) テスターも構築し、ワークステーション上のスクリプトを使用するか、専用の HIL/SIL テストソフトウェアを使用します。 MxVDev など。

おそらくハードウェアインザループ (HIL) テストのことを指します。これには、デバイスの I/O に接続された USB ハードウェア I/O と、それに対してテストを実行するコンピュータ上のソフトウェアが含まれるだけです。

それに価値があるかどうかは、次第です。

高信頼性業界 (航空機、自動車など) では、顧客は非常に広範なハードウェアテストを指定するため、入札を獲得するためにはテストを実施する必要があります。

消費者業界では、複雑でないプロジェクトの場合、通常は価値がありません。

ただし、複数のプログラマーが関与するプロジェクトでは、 本当に ハードウェアで毎晩回帰テストを実行できるのは素晴らしいことです。ソフトウェアテストで十分であると満足するのに必要な程度までハードウェアを正しくシミュレートするのは困難です。

テストでは、ビルドに問題が発生したことを即座に示します。

一般に、ブラックボックステストとホワイトボックステストの両方を実行します。デバイス上で診断コードを実行すると、ハードウェア内の信号とメモリをスパイできるようになります (これは単なるデバッガである場合もあれば、ハードウェア上のメッセージに反応するように作成したコードである場合もあります)。たとえばバス）。これは、内部で何が起こっているかを確認できる (さらには、自分でエラーを導入しないとテストできない重大なメモリエラーなど、いくつかの事態が発生することさえある) ホワイトボックステストになります。

また、診断パスが無視され、I/O のみが刺激/読み取りされる、一連の「ブラックボックス」テストも実行します。

はるかに安価なセットアップの場合は、デバイスに接続して基本テストを実行できる、USB および/またはイーサネット (Atmel UC3 ファミリなど) を備えたマイクロコントローラーボードを 100 ドルで入手できます。

これは製品のメンテナンスに特に役立ちます。プロジェクトが完了したら、いくつかの作業ボード、テスター、およびソフトウェアの完全なセットを CD に保存します。問題を変更したりデバッグする必要がある場合、主要な機能が変更の影響を受けていないことを (テスト後に) 知っていれば、すべてをバックアップして作業するのは簡単です。

-アダム

他のヒント

はい。私は成功を収めてきましたが、解決するのが簡単な問題ではありません。簡単に言うと、私のチームがやったことは次のとおりです。

自家製の C 単体テストフレームワークを使用して、さまざまな単体テストを定義しました。基本的には、多くのマクロだけであり、そのほとんどには名前が付けられています TEST_EQUAL, TEST_BITSET, TEST_BITVLR, 、など。
これらのコンパイルされたテストを実行環境に統合するブートコードジェネレーターを作成しました。これは通常のスタートアップルーチンを実行する単なる小さなドライバーですが、制御ループに入る代わりにテストスイートを実行します。完了すると、実行する最後のスイートがフラッシュメモリに保存され、CPU がリセットされます。その後、次のスイートが実行されます。これは、スイートが停止した場合に隔離を提供するためです。(ただし、モジュールが確実に連携できるようにするために、これを無効にすることもできます。ただし、これは単体テストではなく統合テストです。)
個々のテストでは、シリアルポートを使用して出力を記録します。シリアルポートが空いていたため、これは私たちの設計では問題ありませんでした。すべての IO が消費された場合は、結果を保存する方法を見つける必要があります。

出来た！そしてそれは素晴らしかったです。カスタムデータロガーを使用すると、[テスト] ボタンを押すと、数分後にすべての結果が得られます。ぜひお勧めします。

更新しました テストドライバーがどのように動作するかを明確にするため。

はい。

難易度は、テストしようとしているハードウェアの種類によって異なります。他の人が以前に述べたように、問題は、適用する必要がある外部刺激の複雑さになります。外部刺激は、おそらく外部テスト装置を使用するのが最も効果的です (Adam Davis が説明したように)。

ただし、考慮すべき点が 1 つあります。 その通り 何を確認しようとしているのか。

ハードウェアとファームウェアの相互作用を検証するには、外部刺激を直接適用する以外に選択肢はないと思いがちです。すべての ADC 入力に DAC を適用するなど)。ただし、このような場合、本当にテストしたいコーナーケースはタイミングの問題にさらされることがよくあります (例:関数 foo()) の実行中に割り込みが発生しますが、これを有意義な方法でテストするのは非常に困難であり、有意義な結果を得るのはさらに困難です。(すなわち。このテストを実行した最初の 10 万回は問題ありませんでした。前回実行したときは失敗しました。なぜ？！？）

ただし、ハードウェアの検証は個別に行う必要があります。これが完了すると、(ダウンロード可能な fpga イメージなどを通じて) 定期的に変更されない限り、ハードウェアが動作していると想定して、純粋にファームウェアをテストできるはずです。

したがって、この場合は、外部刺激の処理に使用されるアルゴリズムの検証に集中できます。たとえば、あたかも ADC から直接送信されたかのように、固定値を使用して ADC 変換ルーチンを呼び出します。これらのテストは再現可能であるため、有益です。ただし、特別なテストビルドが必要になります。

デバイスの通信パスのテストは比較的簡単で、特別なコードのビルドは必要ありません。

組み込みシステムの自動テストで良好な結果が得られました。当社では、専用のテストマシンで実行できる高級 (プログラムとデバッグが容易な) 言語でテストを作成しています。これらのテストは通常、健全性チェックを行うか、デバイスへのランダム入力を生成して、正しい動作をチェックします。これらのテストを生成して維持するには、多くの作業が必要です。私たちはフレームワークを設計し、インターン自身がテストに取り組めるようにしました。

これは完璧な解決策ではなく、テストでは確かにエラーが発生しやすいですが、最も重要なのは、既存のカバレッジホールを改善することです。最大の穴を見つけて、たとえそれが完璧ではない場合や機能全体をカバーできない場合でも、自動的にそれをカバーするように何かを設計します。後ですべての内容がある程度カバーされたら、戻って最悪のカバー範囲または最も重要な機能に対処できます。

考慮すべき点:

ファームウェアのバグによるペナルティは何ですか?現場でのファームウェアのアップデートがいかに簡単になるか。
私のテストはどのような範囲をカバーしますか?単純な健全性チェックですか？多くの異なるシナリオをテストできるほど十分に構成可能ですか?
テストが失敗した場合、デバッグするためにその値をどのように再現しますか?できるだけ多くの変数を排除できるように、すべてのデバイスとテストの設定を記録しましたか?デバイス構成、ファームウェアのバージョン、テストソフトウェアのバージョン、すべての外部入力、観察されたすべての動作?
何に対してテストを行っていますか?仕様は、テストしているデバイスの予想される動作について十分に明確ですか? それとも、コードが行うべきと考えている動作を検証していますか?

低レベルのドライバーコードをテストすることが目的の場合は、ループバックケーブルまたは複数の相互接続されたユニットを使用して、各ドライバーを実行できるように、ある種のテストフィクスチャを作成する必要があるでしょう。既知の正常なソフトウェアを備えたボードと開発ビルドを実行しているボードをペアリングすると、通信プロトコルなどのリグレッションをテストできます。

具体的なテスト戦略は、テストするハードウェアによって異なります。たとえば、ADC は、既知の波形を提示して一連のサンプルを変換し、適切な範囲、周波数、平均値などをチェックすることによってテストできます。

私はこれまで、この種のテストが非常に価値があることに気づきました。これにより、既存のアプリケーションを壊すことを恐れることなく、自信を持ってドライバーコードを変更および改善できるようになります。

はい、これを行っていますが、テスト I/O 用にシリアルポートを常に用意していました。

ユニットから離れることが困難になることがよくある 完全に 無修正。一部のテストでは、行をコメントアウトするか、呼び出しを追加する必要があります。番犬に対処するため。

私の意見では、これは単体テストをまったく行わないよりは良いです。そしてもちろん、完全な統合/システムテストも行う必要があります。

組み込みプロジェクトの単体テストは、通常、外部刺激と外部測定が必要となるため、非常に困難です。

私たちは、エラー状態やわずかに異常な状態 (特に制限チェック用) を探す低レベルドライバーでデバッグログを使用してハードウェアを実行するための基本的なコマンドを備えた外部シリアルプロトコル (rs232、udp、または tcpip メッセージのいずれか) の開発に成功しました。

ただし、開発が完了すると、必要に応じてビルドごとにテストを実行できます。間違いなく、より高品質な製品を提供できるようになります。

これはもう古いことは承知していますが、役立つかもしれません。はい、実行できますが、必要なソリューションにどれだけ投資したいかによって異なります。私は 2 年以上、AUTOSAR の MCAL 層のテストと検証に取り組んできました。これは、ソフトウェアテストに関しては最低の水準です。それは一種のコンポーネントレベルのテストでした。これをユニットレベルと呼ぶ人もいるかもしれませんが、MCAL コンポーネントの API をテストしていたため、それよりわずかに高かったです。次のようなもの:ADC、SPI、ICU、DIOなど。

使用されたソリューションには次のものが含まれます。- ターゲットマイクロで実行されていたテストフレームワーク - 必要に応じてターゲットに送信して読み取るためのDSPACEボックス - ベクターカナッペを介したXCPアクセステスト実行と結果コレクションをトリガーする - テストコントロールを実行するPythonフレームワーク結果の検証

テストケースは C で記述され、テスト対象のソフトウェアとともにターゲット上でフラッシュされました。MCAL の実装をまったく変更しなかったため、これはブラックボックステストでした。そして、起動シーケンスさえも触れられていなかったと思います。アイドルタスクは、テストの実行開始の合図となるフラグの状態を継続的にチェックするために使用されました。実際のテストの実行には 10 ミリ秒のタスクが使用されました。テストケースは実際にはスイッチケースでした。この切り替えのすべてのケースはテストステップでした。Python はテストステップレベルでテスト実行をトリガーしていました。このアプローチの良い点は、異なるパラメーターを使用してステップを再利用できることです。このテストコントロール (何をどのように実行するか) は、テスト実装とテストのトリガーおよび評価メカニズムの間で API として機能するテストコントロールデータ構造を通じて Python によって実行されました。これが CANape が使用された目的です。実行するテストを設定し、テストの結果を読み取ります。テストステップで取得されたすべての値は、データ構造の配列部分に格納されました。ターゲットはテスト環境の信頼できないコンポーネントとみなされたため、テストステップ自体は検証に関与しませんでした。検証はテスト仕様書に基づいて Python によって行われました。Python はこれらの仕様を解析し、すべてのテストステップの検証基準を含むテストトリガースクリプトを自動的に作成できました。すべてのテストケースの仕様は、一連のテストステップの説明とその検証基準でした。これらの手順の一部は dSPACE 関連の手順でした。例として、1 つのステップでは何かを初期化し、すでに設定されているチャネル上のいくつかのエッジをキャプチャするよう要求し、次のステップでは dSPACE 機器に命令を出してそのチャネルに信号を適用しました。

より安価なソリューションには、dSPACE 機器の代わりに社内ボードを使用することが含まれます。プログラマブル信号発生器でもある程度は使用できますが、ターゲットが出力する信号を検証する必要がある場合には役に立ちません。

目的が製造テスト (モジュールが適切に組み立てられていること、不注意による短絡/断線などがないか確認すること) である場合は、まずケーブルとコネクタのテストに重点を置き、次にソケットとはんだ付け接続、次に PCB 自体のテストに重点を置く必要があります。これらの項目はすべて、個々のラインを High にし、隣のラインを Low にするアクセスパターンを見つけて、そのラインの値を読み戻すことによってショートとオープンをテストできます。

ハードウェアの詳細がわからないと、より具体的にすることは困難ですが、ほとんどの組み込みプロセッサは、この種のテストを簡素化する GPIO モードに I/O ピンを設定できます。

PCA でベッドオブネイルテストを実行していない場合、このテストは新しく製造された基板に対する必須の最初のステップと見なす必要があります。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow