組み込みハードウェアで直接テストを自動化して成功した人はいますか?
具体的には、ハードウェア層モジュールの単体テストを自動化することを考えています。ハードウェア層のコードにもっと自信を持つ必要があります。私たちのプロジェクトの多くは、割り込み駆動型タイマー、ADC、シリアル IO、シリアル SPI デバイス (フラッシュ メモリ) などを使用しています。
これは努力する価値がありますか？
通常、以下を対象としています。
プロセッサー: 8 ビットまたは 16 ビットのマイクロコントローラー (一部の DSP 要素)
言語: C (場合によっては c++)。
もちろん。自動車業界では、ハードウェアとソフトウェアが正しく動作していることを確認するために、新製品ごとに10万ドルのカスタムビルドテスターを使用しています。
ただし、開発者は、USB I / O、A / D、PWM入出力などを多数含み、ワークステーションでスクリプトを使用するか、専用のHIL / SILテストソフトウェアを使用する、より安価な（1,000ドル未満の）テスターも構築します。 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メッセージ）の開発に成功しました。
ただし、開発が完了すると、必要に応じて、ビルドごとにテストを実行できます。それは間違いなくあなたがより良い品質の製品を届けることを可能にするでしょう。
目標が製造テスト (モジュールが適切に組み立てられていること、不注意によるショート/オープンなどがないことの確認) である場合は、最初にケーブルとコネクタのテストに焦点を当て、次にソケット接続とはんだ付け接続、次に PCB 自体のテストに集中する必要があります。これらのアイテムはすべて、個々のラインを高くし、隣接するラインを低くするアクセス パターンを見つけて、ラインの値を読み戻すことにより、ショートとオープンをテストできます。
ハードウェアの詳細を知らなければ、特定することは困難ですが、ほとんどの組み込みプロセッサは、この種のテストを簡素化する GPIO モードに I/O ピンを設定できます。
PCA でベッド オブ ネイル テストを実行していない場合、このテストは、新しく製造されたボードの必須の最初のステップと見なす必要があります。