組み込み環境またはテストを自動化する可能性が非常に限られている他の状況で回帰テストを実行するための優れたプラクティスと戦略は何ですか。
私の経験では、多くのテストを手動で実行する必要があります。つまり、テスターは一連のボタンを押して、マシンが正しく動作することを確認する必要があります。開発者として、あなたの変更が他の何かを壊さないことを自分自身に保証することは本当に難しいです。
適切な回帰テストがないと、大規模なリファクタリングなどで状況がさらに悪化します。
誰かが問題を認識していますか？この種の問題に対処するための良い解決策またはプロセスを見つけましたか？
個人的には、組み込みコードをターゲットハードウェアと自分のコンピューターの両方でコンパイルするのが大好きです。たとえば、8086をターゲットにする場合、8086ハードウェアでリセットするようにマップするエントリポイントとDOSエントリポイントの両方を含めました。ハードウェアは、すべてのIOがメモリマップされるように設計されています。次に、ハードウェアシミュレーターで条件付きでコンパイルし、ハードウェアメモリの場所をシミュレートされたハードウェアメモリに条件付きで変更しました。
x86以外のプラットフォームで作業する場合は、代わりにエミュレーターを作成する可能性があります。
もう1つのアプローチは、ハードウェアのすべての入力と出力がソフトウェアを介して制御されるテストリグを作成することです。これは、工場でのテストでよく使用されます。
ある時、IOハードウェアにシミュレーターを組み込みました。そうすれば、CANを介していくつかのコマンドを送信し、ハードウェアをシミュレーションモードにすることで、システムの残りの部分をテストできます。同様に、適切に因数分解されたソフトウェアには、ソフトウェアコマンドに応答してIOがシミュレートされる「シミュレートモード」があります。
組み込みテストの場合、開発プロセスの非常に早い段階でこれから抜け出す方法を設計することをお勧めします。埋め込みコードをサンドボックス化してPCプラットフォームで実行すると、非常に役立ちます。その後、モックを作成します:)
これにより、ほとんどの場合、完全性が保証されますが、後でシステムと受け入れのテストを手動で行う必要があります。
誰かが問題を認識していますか？
確実に。
この種の問題に対処するための良い解決策またはプロセスを見つけましたか？
テクニックの組み合わせ：
PCコンパイラでのコンパイルに関して：これは、高レベルのモジュール、およびテストに適したハーネスを備えた低レベルのモジュールにとって確かに理にかなっています。
たとえば、複数のソースからのリアルタイム信号を処理する必要があるコードの部分に関しては、エミュレーションを開始するのは良い場所ですが、それだけでは十分ではないと思います。多くの場合、可能な限り現実的な環境で、実際のハードウェアでコードをテストすることに代わるものはありません。
これまでのほとんどのレスポンダーとは異なり、私はデスクトップシステムにまったく似ていない組み込み環境で作業しているため、デスクトップ上の組み込みシステムをエミュレートできません。
優れたテストシステムを作成するには、フィードフォワードとフィードバックを備えたテストシステムが必要です。JTAGは、デバイスを制御するための最も一般的なフィードフォワード方法です。デバイスの完全な状態（運が良ければボード全体でも）を設定してから、実行するテストコードを設定できます。その時点でフィードバックを受け取ります。JTAGはフィードバックデバイスとしても機能します。ただし、この状況では、ソフトウェアAPIを備えたロジックアナライザが最適です。ピンの特定のレベルを探したり、パルスをカウントしたり、ストリーミング周辺機器からのデータストリームを解析したりすることもできます。
個々のサブシステム、およびプロジェクト全体に対して、ターゲット環境をエミュレートするテストハーネス/サンドボックス/モックアップを提供します。
これにより、実際の環境でのテストの必要性がなくなるわけではありませんが、シミュレーションでほとんどの問題が検出されるため、テストの数が大幅に減ります。すべての問題に合格し、高価な人間主導のテストを実行するまでに、最初に合格することを合理的に確信できます。時間。
アプリが通常のPCでビルドおよび少なくとも部分的にテストできることを確認するためのこれまでの提案（Valgrindなどのツールの使用にも役立ちます）とは別に、ソフトウェアの設計について考えます。
私が取り組んだプロジェクトの1つには、ハードウェアを駆動するためのコンポーネント、管理タスクを処理するためのコンポーネント、およびネットワーク管理のコンポーネントがありました。ネットワーク管理はSNMPによって処理されたため、ハードウェアを駆動して何かを実行するためにリモートで実行されるスクリプトを簡単に作成できました。
低レベルのハードウェアテストを実行するために、テストスクリプトを解析し、ドライバーのIPCにコマンドを挿入する簡単なスクリプトリーダーを作成しました。出力はビデオベースであるため、目で確認する以外に処理の検証を自動化することは困難でしたが、RSIを確実に節約できました。また、バグが再発しないように、既知の障害状態をストレステストまたはシミュレートするスクリプトを生成する場合にも非常に役立ちました。
もう一度やり直すとしたら、おそらくテストハーネスで使用される共有ライブラリと、コアメッセージを送信するための実際のコードを実装するでしょう。次に、libをpython（または同様のもの）でラップして、テストを少し「スクリプト化」できるようにします。
自動化されたハードウェアが必須であると言うすべての人に同意します。私たちはそのアプローチを使用して、一部のユニットで組み込みソフトウェアをテストしています。ハードウェアシミュレータでいっぱいの大規模な2ラックテストステーションを構築し、Labview VI、C＃コード、ベンダーDLLなどを組み合わせたNITestStandを使用してすべてを管理しています。多くのハードウェアをテストする必要があります。そのため、すべてのがらくたがあります。ソフトウェアをテストしているだけの場合は、必要最低限のものにスケールバックできます。シリアルインターフェースをテストしますか？シリアルトラフィックをシミュレートするデバイスを構築し、すべてのメッセージ（およびいくつかの無効なメッセージ）を実行して、ソフトウェアが正しく応答することを確認するだけです。DIOをテストしますか？それは簡単です-DIOをシミュレートするためのUSB周辺機器や組み込みデバイスがたくさんあります。タイミングが重要な場合は
重要なのは、何をテストしているのかを常に把握し、それ以外のものをテストしないことです。ソフトウェアの場合は、テストがハードウェアから可能な限り独立していることを確認してください。波形生成などをD/Aでテストしている場合は、タスクを分離します-組み込みデバイス上で特別なビルドのソフトウェアを使用してD / Aハードウェアをテストします。これは、事前に準備されたシーケンスを吐き出す以外は何もしません。電圧レベル。次に、参照がオフになっているかどうか、フィルターが間違った周波数に設定されているかどうかなどを確認できます。次に、ハードウェアに関係なくソフトウェアをテストできるはずです。開発ボードを使用してソフトウェアをテストし、プロセッサーでの動作を確認します。ピンは正しいです。
私が働いている場所で使用されているソリューションは、自動化されたナイトリービルドとテスト手順です。
ある種の通信プロトコルを使用している場合、テストスクリプトは簡単に実行できます。これは、内部ユニットテストに適しています。状況をより面白く（そして徹底的に）するのは、外部IOをシミュレートするためにボードに接続するワイヤーハーネスを作成することです。
エミュレートは開発と基本的な初期テストに適していますが、実際の物理的な動作時間は、システム検証のための唯一の信頼できる方法です。物理的な操作により、電圧低下、ノイズ、グリッチ、デバウンスの問題、競合状態など、コーディング以外の問題（コーディング方法によって引き起こされる）を見つけることができます。
長期にわたるシステムテストも重要です。システムを数日/数週間連続して悪用する自動テストを設定することは、現場で数か月後まで発生しない可能性のある問題を強制的に排除するための良い方法です。物事がおかしな行動を開始するたびに電源を入れ直すように顧客に指示することは、すべての業界が楽しませる贅沢ではありません。
私の経験では、自動化されたハードウェアテストが重要でした。--PCとターゲットの両方でデュアルコンパイルに投資することは「あると便利」な機能ですが、選択肢があれば、自動化されたハードウェアテストに投資したいと思います。製造部門はとにかく障害分析のための機能を必要とするため、最終的にはより費用効果の高いソリューションになります。