組み込みソフトウェアテスト準備_8 ソフトウェアテスト

ソフトウェアテスト

テスト: 指定された条件下でプログラムを動作させ、エラーを検出し、ソフトウェアの品質を評価します。

オブジェクト: プログラム、データ、ドキュメント。

目的: エラーを発見し、ユーザーのニーズを満たしているかどうかを確認し、エラーの原因を究明します (品質分析はできません)。

組み込みハードウェアは通常、特別なテスト機器を使用してテストされ、ソフトウェアは論理的な正確さに加えて、システムのパフォーマンスと堅牢性、リアルタイム パフォーマンス、およびソフトウェアとハ​​ードウェアの組み合わせの分析にも重点が置かれます。

試験方法

動的: ブラック ボックス、ホワイト ボックス、グレー ボックス。

• ブラック ボックス: プログラムの機能をテストし、プログラムをブラック ボックスとして扱います。

• ホワイト ボックス: 透明なホワイト ボックス。コードの特定のロジックをテストします。

• 灰色のボックス: 2 つの組み合わせで、システム テストでよく使用されます。

静的: フロントデスク検査、コードレビュー、コードウォークスルー。

• 店頭チェック: 開発者自身がレビューします。
• コードレビュー: 開発者とテスターに​​よる人によるレビュー。
• コードのウォークスルー: テスト ケースの検査を提供します。

等価クラスの分割: たとえば、プログラムが 1 _{1000 を入力した場合、実際には 2} 10 が等価なので、典型的なものをテストするだけです。

境界値分析: 境界。

間違った推測: 何かが間違っている可能性があります。

因果関係: 制約や組み合わせなどの複雑なプログラム入力関係の場合、同値クラスや境界値で表現するのは困難です。

論理カバレッジ テストでは、各カバレッジとそれに必要なテスト ケースの数を理解する必要があります。

ここでのさまざまな判断の理解については、次の記事を参照してください:動的ホワイト ボックス テスト - ロジック カバレッジ テスト方法_Deep Autumn Honfeng のブログ - CSDN ブログ

例：

ステートメント カバレッジ sc: すべてのステートメント (正方形のもの) が 1 回実行されますが、すべてのケースが 1 回実行されるわけではありません。したがって、2 つの判定は TT FF または TF FT、つまり 2 つのテスト ケースになる可能性があります。

判定カバレッジ/分岐カバレッジ (DC): 各判定は 1 回実行されるか、TT FF または TF FT を満たすことができます。

条件カバレッジ: すべての論理的判断 (つまり、単一の論理条件) が少なくとも 1 回満たされています。つまり、x>0 x<0 y>0 y<0 magic>0 magic<0 が少なくとも 1 回発生しました。

条件決定カバレッジ: 条件と決定カバレッジの両方が満たされています。

条件の組み合わせの適用範囲: 各条件ステートメントで考えられるすべての状況が出現する必要があります。つまり、x>0 y>0、x>0 y<0、x<0 y>0、x<0 y<0、および magic> の組み合わせです。 0 magic<0 が使用されており、異なる条件付きカバレッジのステートメントを組み合わせる必要はありません。

パス カバレッジ: フローチャート内のすべての可能なケースが発生している限り。つまり、2つのifがTT、TF、FT、FFの場合です。しかし、図からわかるように、x y>0 の場合、magic=x+y+10 も >0 でなければならないため、x>0 y>0 magic<0 は TF が不可能であることを意味します。したがって、ケースは 3 つだけです。

修正された条件判定範囲:

1. 考えられるすべての出力結果が表示されます。
2. 多くの条件のうちの 1 つを変更すると、判定結果に影響を与える可能性があります。

例：プログラム

{
    
    
    if(A&&(B||C))
        return true;
}

まず、条件の組み合わせはすべての可能性をカバーします。ABC は 000,001,010,011,100,110,111 です。

ステートメント カバレッジ: true である限り、すべてのステートメントを実行できます。1 つのユースケースで十分です。

すべての可能性をカバーし、0 件の結果のうち 1 つと 1 件の結果のうち 1 つだけが必要です。ただし、別の要件は、テスト ケース内の 1 つの入力のみを変更するユース ケースがあり、このユース ケースを変更すると結果が変わる可能性があるということです。

000 を変更しても結果は変わりません。

001を101に変えるだけで26個取り出せます。

等々。

A を変更すると、結果が 26、37、48 に変わります。

B を変更すると、結果が 57 に変わります。

C を変更すると、結果が 56 に変わります。

したがって、少なくとも 5、6、7、3 を含める必要があります。

テストフェーズ、テストレベル

単体テスト: ホワイト ボックス テストなどのコード テスト。

結合テスト: モジュールの組み合わせテスト。インクリメンタル グループ アセンブリでは、最初に部品をテストし、次に最上層または最下層から始めて新しいモジュールを徐々に統合します。ホワイトボックステストなど。

• ドライバー モジュール: ドライバーのテスト用に開発されました。
• スタブ モジュール: テスト対象のモジュールによって呼び出されるように一時的に開発および提供されます。

確認テスト：

• 受け入れテスト: ユーザーは、プロジェクトがソフトウェア要件仕様書に準拠しているかどうかを確認するために、プロジェクトの受け入れテストを実施します。
• アルファ テスト: 開発環境でテストし、ベータに渡します。
• ベータテスト：ユーザーの実使用環境テスト。合格後にのみ公開可能です。

システムテスト: システムを実際の環境に置き、そのパフォーマンスをテストします。グレーボックステストなど。

デバッグ

クロスデバッグは不可欠です。デバッガと Hojo のプログラムは別のマシン上にあり、接続を確立するための通信方法があり、通常はターゲット マシン上にデバッガの実行を支援するエージェントが存在します。

デバッグでは、プログラムの実行を制御し、メモリ、レジスタ、変数などの情報を変更できます。

直接テスト: ホスト-ターゲット

デバッグモニタ方式：ホストマシン上のデバッガをJTAG等を介してターゲットマシンのモニタにダウンロードします。

ROM エミュレータの方法: ターゲット マシンに挿入し、読み取り専用 ROM をエミュレートし、ホスト マシンに接続します。

オンラインエミュレータの方法：CPUをシミュレートします。

オンチップデバッグ方法: マイクロコントローラー上の一部のレジスタ値は、JTAG インターフェイスを通じて取得できます。通常、デバッグと実行の 2 つのモードがサポートされるようになりました。

シミュレータ方式: すべては開発プラットフォーム上にあり、ハードウェアを完全にシミュレートします。

デバッグとテストの違い: テストはエラーを見つけること、デバッグはテスト後にエラーを特定し、期待される結果が得られるようにプログラムを変更することです。

ソフトウェアのレビュー

検証と確認

プロセスと結果に焦点を当てます。