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++言語を使用する場合、呼び出しツリーには、構造体、解析関数、再ロード演算子、コピー構造、変換関数のすべてのタイプの関数（メソッド）も含める必要があります。すべての関数ポインタも解析する必要があり、呼び出された関数は解析に含まれます。