ホワイトボックステストのコードレビュー


テストは、井戸を掘って水を汲むのと少し似ています。ある場所にいる人もいれば、柔らかい土壌のために別の場所に水を汲む人もいます。

ホワイトボックステストは、コードレビューとユニットテストの2つのレベルに分かれています。

コードレビュー

ロジックを理解し、いくつかの問題を見つけることができます。これは、R&Dによって開始されたコードレビュー会議で検証の役割を果たす

コードレビュー範囲
認定されたコードには、正確性、明確性、標準化、一貫性、および効率性が必要です(効率性:コードはできるだけコピーコードが少なく、凝集度が高く、結合性が低い必要があります)
◆要約すると、コードレビュー作業は次の側面をカバーします

1.业务逻辑的审查
たとえば、アプリをAlipayに注文して支払いを行うとします。Alipayで問題が発生してクラッシュした場合、残業で支払いできない可能性があります。テスト中にこの問題が見つからない可能性があるため、ビジネスロジックを確認して問題を解決する必要があります
2.算法的效率(スペースの複雑さ) 、時間の複雑さの尺度)
3.代码风格
4.编程规则

コードレビュー方法
相互チェック:同じモジュールまたは類似のモジュールのプログラマ間で互いのコードをチェックすること(アジャイルでのペアプログラミング)
ウォークスルー:記述されたプログラムを最初から最後までもう一度チェックます
コードレビュー(会議、コードは、ミーティング中に特定のルールに従ってレビューされます)

コードレビュールール

◆Javaの最も基本的な文は使用します

オーバーロードされた関数のレビュー(オーバーロードについては、オーバーロードが正しいかどうかを確認してください)

◆**メモリの割り当てと管理:**メモリの割り当てと管理を行う場合、メモリを適時に解放し、バッファオーバーフローを回避することが非常に重要です。()(問題の後続の場所を容易にするために、コードなどで一部のメモリリサイクルを再生できます)

プログラムのパフォーマンスレビュー
1. 低下は、オブジェクトを作成する(毎回新しいオブジェクトの多数かどうか)
2. ループ減らすコード実行のボディを、コードは、インビトロサイクル配置しようとする体の外側循環に配置することができ
、処理改善3. 異常なエラーを効率
4. I / O操作時間を削減します(外界との相互作用が少なくなります)。

単体テスト

単体テストのロジックをカバーする方法

単体テスト
**ユニットテストはソフトウェアテストの最も基本的なテストです。統合テスト、機能テスト、およびシステムテストはすべてユニットテストに基づいています。**ユニットテストの目的は、パッケージなどのソフトウェア製品またはシステムを構成する最小の独立したユニットです。クラスまたはオブジェクト、独立した機能、プロセス、サブプロセス、コンポーネントまたはモジュールなど(ユニットテストの99%は開発によって行われます)
**ユニットテストは、ソフトウェア内の最小の検証可能なユニットをチェックおよび検証することです。**たとえば、Javaでのクラスとメソッドのテスト。

テストの原則:
1.可能な限り、テストケースが互いに独立していることを確認します(他のクラスのメソッドをテストケースで直接呼び出すことはできませんが、シミュレーションメソッドはテストケースで書き換える必要があります);
2.このステージは通常、ソフトウェア開発者が実装します。私のクイズから来てください。これは、開発されたコード関数が独自の設計要件を満たしていることを確認するために使用されます。

単体テストの利点:
1.できるだけ早く欠陥を見つける;
2.リファクタリングを容易にする;
3.統合を簡素化する;
4.ドキュメント;
5.設計に使用する。

ユニットテストの欠点:
1.すべての実行パスをカバーすることは不可能であるため、すべてのパスエラーを確実にキャッチすることは不可能です
。2.ユニットテストでは、コードの各行に3〜5行のコードが必要であり、入力と出力のバランスがとれています。

ユニットテストケースの設計

◆ユニットテストケースの設計とプログラムの実装プロセスでは、主にホワイトボックステスト方法に焦点を当て、以下のテスト要件を満たすように努めます

  1. プログラムモジュールのすべての独立した実行パスを少なくとも1回テストします。
    2.すべての論理的判断について、結果は少なくとも1回は真と偽です。
    3.プログラムの境界確認します(データの越境検査など)。
    4.内部データ構造の有効性を確認します。(データベースの設計構造が要件を満たすことができるかどうか)

ホワイトボックステスト法のロジックカバレッジ法

(コードを使用してコードの実行方法を確認する)
論理カバレッジメソッドは、ホワイトボックステストで最も重要なテストメソッドです
論理カバレッジは、ステートメントカバレッジ、判断カバレッジ、条件カバレッジ、判断条件カバレッジ、条件組み合わせカバレッジ、およびそのオリジナルさまざまなアイデア、さまざまなテストケース、さまざまなカバレッジ

ロジックオーバーレイメソッドを理解する方法の例を示します。
コードは次のとおりです。
ここに画像の説明を挿入
コードロジックはワイヤーフレームフローチャートで変換されます

ここに画像の説明を挿入

ステートメントカバレッジ(最も初期の論理カバレッジ方式)

◆基本的な考え方:複数のテストケースを設計し、テストしたプログラムを実行して、プログラム内の各実行可能ステートメントが少なくとも1回実行されるようにします。
上記の論理図によると、プログラムモジュールには4つの異なるパスがあります。
パスを決定するために、2つの異なる判定条件が真または偽です
ここに画像の説明を挿入

観察の結果、P1にはすべての実行可能なステートメントが含まれていることがわかりました。ステートメントでカバーされているテストケースの設計原則に従って、一連のテストケースがPIパスをカバーするように設計されている限り、要件を満たすことができます
。 1、c = 6

ステートメントのカバレッジが不十分
◆ステートメントカバレッジ方式を使用してテストケースを設計すると、実行されたすべてのステートメントをテストできますが、操作の論理的関係を正確に判断できません。
◆この例では、プログラムがMの条件「(a> 0 AND b> 0)」を「(a> 0 OR b> 0)」として書き込んだ場合、この時点のテストケースはすべての実行可能なステートメントをカバーできます。しかし、論理エラーを見つけることができません

決定カバレッジ

◆基本的な考え方:各判断に少なくとも1回は真と偽の値をとらせる
ここに画像の説明を挿入
ここに画像の説明を挿入

カバレッジ制限を決定する
たとえば、上記の例で、条件Nが「c> 1」ではなく「c <1」の場合、組み合わせ1のテスト結果に違いはありません。

条件付きカバレッジ

◆基本的な考え方:各条件の真偽値を少なくとも1回経験します。
ここに画像の説明を挿入
次に:
最初の判定条件Mについて、次の2つのタイプにさらに分類できます:
条件a> 0:真の場合、T1です。 F1偽のときの
条件b> 0:真のときT2、偽のときのF2
2番目の判定条件Nは、さらに次の2つのタイプに分類できます。
●条件a> 1:フェッチが真のときのT3、取るfalseの場合はF3
●条件c> 1:trueの場合はT4、falseの場合はF4

ここに画像の説明を挿入
◆各条件に少なくとも1つの真と偽(TI / FI、T2 / F2、T3 / F3T4 / F4)があり、条件カバレッジを満たしているが、同じパスP3をカバーしていることを確認します。つまり、条件カバレッジが達成されたとしても、すべてのパス(PI、P2、P3、およびP4)をカバーすることを保証することはできません。上記の値の条件は、判定条件が常にM、真がNであることがわかります。しかしを通じてより多くの単一パス
一見、より複雑で厳しい条件カバレッジを満たすために◆**テストケースは、実際には、デシジョンカバレッジ要件を満たすことができません。**ここで、各条件には少なくとも1つの真と偽があります(TI / FI、T2 / F2、T3 / F3、T4 / F4)。Mは偽値のみを取得し、Nは真値のみを取得しますが、すべての判定条件(MまたはN)が「真」であるとは限らず、「偽」値は少なくとも1回実行されます。

解決策:
ある種のカバレッジ条件を満たしているだけで、プログラムの論理パスを逃したり、間違った決定をしたりしていますが、依然として大きなリスクがあります。したがって、ホワイトボックステスト要件は、2つを超えるテストカバレッジ要件を同時に満たし、テストカバレッジレートは品質要件を満たし、リスクを非常に低いレベルに減らすことができます。

決定条件カバレッジ

基本的な考え方:判定条件のすべての条件の可能な値が少なくとも1回実行されると同時に、すべての判定の考えられる結果が少なくとも1回実行されるように、十分または精巧なテストケースが設計されていることを確認します。

ここに画像の説明を挿入

それぞれの判定条件は真です。同時に、すべての決定文は真であり、
すべての決定条件は偽です。同時に、各決定ステートメントも偽です
が、まだすべてのパスを完了していません

条件付き組み合わせカバレッジ

◆基本的な考え方:
**判定のすべての条件が少なくとも1回は現れ、各判定自体の判定結果も少なくとも1回は現れるように十分なテストケースを設計します。**条件付きカバレッジの判定との違いは、条件付き組み合わせカバレッジでは、各条件が「true」と「false」の結果を持っている必要があるだけでなく、これらの結果のすべての可能な組み合わせが少なくとも1回出現する必要があることです。

(条件判定との違いは、組み合わせの概念が追加されていることです。真または偽の2つの条件が4つの組み合わせを生成します)
ここに画像の説明を挿入

テストカバレッジの範囲を決定し、ロジックカバレッジの方法を決定します。(少なくとも判定条件の範囲)

公開された82元の記事 ウォン称賛7 ビュー4170

おすすめ

転載: blog.csdn.net/sunshine612/article/details/105420816