PCB技術 - PCB設計中にソフトウェア欠陥を発見する方法

PCB設計中に隠れているが一般的なソフトウェア欠陥エラーを回避する方法と、エンジニアがPCBボード（www.pcbwork.net）ソフトウェアの隠れているエラーを見つけるのを支援するいくつかの技術を紹介します。ほとんどのソフトウェア開発プロジェクトは、コードチェック、構造テスト、機能テストの組み合わせに依存してソフトウェア欠陥を識別します。これらの従来技術は非常に重要であり、ほとんどのソフトウェア問題を発見することができますが、現在の複雑なシステムで多くの一般的なエラーを検出することはできません。

構造テストまたはホワイトボックステストは、コード内の論理、制御フロー、計算、およびデータエラーを効果的に検出することができます。このテストでは、ソフトウェア構造の詳細を理解するために、ソフトウェアの内部作業の概要（「ホワイトボックス」または「ガラスボックス」と命名）が必要です。各条件式、数学演算、入力、出力をチェックします。テストが必要な詳細が多いため、構造テストはソフトウェアユニットを一度にチェックします。通常は関数やクラスです。

コードレビューにも、欠陥や潜在的な問題発見を実現するのと同じ複雑な技術が使用されています。ホワイトボックステストと同様に、有効なレビュープロセスには集中的で詳細なチェックが必要なため、ソフトウェアの各ユニットをレビューするのが一般的です。

レビューやホワイトボックステストとは異なり、機能テストやブラックボックステストの仮定はソフトウェアの実現について何も知らない。制御された入力によって駆動される出力をテストします。機能テストは、テスターまたは開発者が作成したテストプログラムで構成されています。これらは、特定のプログラム入力のセットに対応する予期されるプログラム出力を指定します。テストが実行されると、テスト担当者は実際の出力と予想される出力を比較して問題を発見します。ブラックボックステストは、プログラムの最も一般的な機能で満たされていないニーズ、インタフェースの問題、パフォーマンスの問題、エラーを効果的に検出することができます。

これらの技術を組み合わせると、特定のソフトウェアプログラムに隠されているほとんどのエラーを発見することができますが、それらには限界があります。コードレビューとホワイトボックステストは、コードのほんの一部に対してのみ行われ、システムの残りの部分は無視されます。ブラックボックステストは通常、システムを全体として扱い、実装の詳細は無視します。いくつかの重要な問題は、システム全体における相互作用の詳細に注目することでしか発見できません。従来の方法では、これらの問題を確実に識別することはできません。特定の問題の具体的な原因を特定するためには、ソフトウェアシステム全体をチェックする必要があります。通常、プログラム内の各詳細とコードの他のすべての部分との相互作用を完全に分析することはできないため、分析は既知の問題の原因となるプログラムの特定の側面に対応する必要があります。

本文は3つの潜在的な問題領域を検討する：

*スタックオーバーフロー

*競争条件

*膠着状態

読者は本文の第2部をオンラインで読むことができ、その中で以下の問題を検討する：

*時間の問題

*条件への再入場

これらのすべての問題は、マルチタスクリアルタイム設計技術を使用したシステムでよく見られます。

スタックオーバーフロー

プロセッサはスタックを使用して一時変数を格納したり、呼び出された関数にパラメータを渡したり、スレッドの状態を保存したりします。システムが仮想メモリを使用していない場合（言い換えれば、メモリスペースを解放するためにメモリページをディスクに転送できない場合）、スタックは出荷時に製品のサイズに固定されます。何らかの理由でスタックがプログラマ割り当ての範囲を超えている場合、プログラムは不確定になります。この不安定性は、深刻なシステム障害を引き起こす可能性があります。したがって、システムが最悪の場合に十分なスタックを割り当てることができるようにすることは非常に重要です。

スタックオーバーフローが決して起こらないようにする唯一の方法は、可能な限りプログラムがスタック使用量を最大にし、十分なスタックが割り当てられているかどうかを確認するためのコードを解析することです。このテストでは、瞬時に入力された特定の組み合わせがトリガされ、システムが最悪の状態になる可能性はあまりありません。

スタック深度解析の概念は比較的簡単：

1.独立スレッドごとに呼び出しツリーを作成します。

2.呼び出しツリー内の各関数のスタック使用状況を決定します。

3.各呼び出しツリーをチェックして、ツリーのルートから外部の「リーフ」への呼び出しパスが最も多くのスタックを必要とするかを決定します。

4.各スタンドアロンスレッド呼び出しツリーの最大スタック使用量を追加します。

5.各割り込み優先度における各割り込みサービスルーチン（ISR）の最大スタック使用量を決定し、合計を計算する。ただし、ISR自体がスタックされておらず、割り込みスレッドのスタックを使用している場合は、ISRが使用する最大スタック数を各スレッドのスタックに追加する必要があります。

6.PCBレイアウトと設計の優先度ごとに、割り込みが発生したときにプロセッサの状態を保存するためのスタック数を追加します。

7.RTOSを使用している場合は、RTOS自体の内部使用に必要な最大スタック数を追加します（ステップ2に含まれるアプリケーションコードによるシステムコールとは異なります）。

また、2つの重要なことを考える必要があります。まず、高度な言語ソースコードから構築された呼び出しツリーだけが不完全である可能性があります。ほとんどのコンパイラはランタイムライブラリを使用して、大きな整数の乗算や除算、浮動小数点演算など、一般的な計算タスクを最適化します。これらの呼び出しは、コンパイラが生成するアセンブリ言語でのみ表示されます。ランタイムライブラリ関数自体は大量のスタックスペースを使用する可能性があるので、解析に含める必要があります。C++言語を使用している場合、呼び出しツリーには、構造化、解析、再ロード演算子、コピー構造、変換関数のすべてのタイプの関数（メソッド）も含まれている必要があります。すべての関数ポインタも解析されなければならず、呼び出された関数も解析に含まれています。