structural testing tutorial what is structural testing
この包括的な構造テストチュートリアルでは、構造テストとは何か、そのタイプ、制御フローテストと制御フローグラフ、カバレッジレベルなどについて説明します。
最も高価なソフトウェアのバグのいくつかをグーグルですばやく検索したところ、5000億ドルという頭がおかしくなりました。はい、それはバグがどれほどコストがかかるかです。ソフトウェアのバグが原因で運輸業界や医療業界で失われた命に関連するものを読むことも恐ろしいことです。
コードのエラーは、多額のお金と人命の損失を伴う場合、必ずしも極端ではありませんが、ここで伝えようとしている唯一の重要なポイントは、テストを見逃すことはできないということです。
SDLC全体でテストを頻繁に行うと、製品の出荷後に修正するのにはるかに長い時間がかかるバグを見つけることができます。
重要なのは、私たちが選択するソフトウェアテストの種類です。これらには、機能テスト、構造テスト、変更ベースのテストなど、いくつかあります。
このチュートリアルでは、構造テストの種類についても説明します。例と説明を使用して、ミューテーションテスト、スライスベースのテスト、データフローテストを行う方法を詳しく学びます。
学習内容：
ソフトウェアテストが重要な理由
お金を節約し、上記のような災害を回避することに加えて、テストの重要性を正当化する他のいくつかの理由があります。
以下に参加する理由はいくつかあります。
＃1）規定された要件が満たされていることを確認する プロジェクトの構築を開始する前に。利害関係者（たとえば、開発者やクライアント）は、プロジェクトの構築に必要なソリューション/製品/ソフトウェアのすべての側面に同意する必要があります。
テストには、ソフトウェア要件が満たされているかどうかの検証が含まれます。ソリューションの構築に関与する開発者または企業も、eclatコードによって実行されるこのような高品質のソリューションを設計することで高い評価を得ています。
＃2）コード関数が意図したとおりに機能していることを確認します。 テストには、ソフトウェアの機能の検証も含まれます。誤動作が発生した場合は、SDLC（ソフトウェア開発ライフサイクル）の初期段階で修正する必要があります。
＃3）パフォーマンスをチェックします：たとえば、 コードの実行中に経過した合計時間を識別します。複数使用する場合 Forループ 私たちのコードでは、意図した出力を取得するのに長い時間がかかり、時にはタイムアウトすることさえあります。
＃4）より良いユーザーエクスペリエンスを実現するのに役立ちます。 ユーザーは、誤動作、バグ、または「遅すぎる」ソフトウェアの使用を楽しむことはできません。ユーザーは、ソフトウェアを使用して焦り、立ち寄る可能性があります。テストにより、ユーザーが当社の製品を簡単に使用できることを確認するためのより良いショットが得られます。
＃5）スケーラビリティをチェックします。 開発者は、拡張可能なソフトウェアの構築を目指す必要があります。
＃6）コードの脆弱性をチェックします。 テストにより、セキュリティの脆弱性を探す機会が得られます。 例えば、 妥協する可能性のあるコード PII GDPRの優先度が高い（個人を特定できる情報）。
この記事では、1つのタイプのテストに焦点を当てます。 構造試験 。名前が示すように、それはコードの構造と関係があります。これは、テストがコードのパフォーマンス、機能、セキュリティなどの側面を判断するのに役立つという前述の内容とは異なります。
構造試験と他の試験タイプ
ソフトウェアテストには多くの種類があります。 しかし やめる （International Software Testing Qualifications Board）は、4つの主要なソフトウェアテストタイプを定義しています。
- 機能的
- 機能しない
- 構造
- 変更ベース
違いは次のように説明できます。
機能テスト： これには、規定された要件に照らしてソフトウェアの機能を検証することが含まれます。テストデータが入力として使用されます。また、与えられた出力が期待どおりであることを確認します。
非機能テスト ：これには、ソフトウェアの動作を分析するためのテストプロセスが含まれます。 例えば、 同時に処理できるユーザーの数。
構造試験： このタイプのテストは、コードの構造に基づいています。 例えば、 コードが配列内の偶数の平均を計算することを意図している場合、構造ベースのテストは、最終出力が正しい数値であるかどうかではなく、「平均が計算されるまでのステップ」に関心があります。
偶数と奇数を区別するコードを定義したかどうかを確認する必要があるとします。ここに条件文があるかもしれません。たとえば、配列要素が余りなしで2で割り切れる場合、 if（arr (i)％2 === 0） そうすれば、その数は偶数と言えます。
構造テストは、コードを最もよく理解しているのと同じ人がコードを作成することによって実行されます。
変更ベースのテスト ：これには、コードに変更を加えた場合の影響をテストし、加えた変更が実装されていることを確認することが含まれます。また、コードへの変更によってコードが破損しないようにします。
構造試験とは
構造ベースのテストはコードの構造を参照することを前述しました。ここでは実際のコードを扱っていることに注意してください。要件をチェックしたり、期待される出力に対して入力をテストしたりすることはありません。現時点では、機能、ユーザーエクスペリエンス、さらにはパフォーマンスについては考慮していません。
構造試験とは
したがって、構造ベースのテストは、コードの構造と目的のフローをテストする一種のソフトウェアテストとして定義できます。 例えば、 条件ステートメントの正しい実装などの側面について実際のコードを検証し、コード内のすべてのステートメントが正しく実行されているかどうかを確認します。構造ベースのテストとも呼ばれます。
この種のテストを実行するには、コードを完全に理解する必要があります。これが、このテストが通常、コードを最もよく理解しているコードを作成した開発者によって行われる理由です。
構造試験の実施方法
コードのさまざまな側面をテストするには、最初に制御フローを理解する必要があります。
制御フローテスト
これは、コードの制御フロー（ステートメント、関数、およびコードのさまざまな側面が実装される順序）からテストを導き出します。
制御フローテストプロセス：
制御フローグラフ
制御フロープロセスは、実行中にたどることができるパスを定義するのに役立つコードのさまざまなセクションの視覚的表現を作成することから始まります。
これらの視覚的表現は制御フローグラフ（CFG）と呼ばれ、ノード、エッジ、パス、ジャンクション、決定点などのいくつかのコンポーネントがあります。グラフは手動または自動で作成でき、ソフトウェアを使用してソースコードからグラフを抽出します。
以下のこれらのコンポーネントを見てみましょう。
＃1）プロセスブロック
この部分は、順次実行されるコードのセクションを表すために使用されます。これは、毎回同じ方法で実行され、実行する必要のある決定や「分岐」がないことを意味します。これは、1つの入口パスと出口パスを持つノードで構成されています。
プロセスブロックの例：
(画像 ソース )
プロセスブロックは制御フローの本質的な部分ではないため、テストする必要があるのは1回だけです。
＃2）決定点
これらは、コードの制御フローのいくつかの重要なコンポーネントです。これらのノード内で、決定が行われます。これは通常、比較によって行われ、決定に応じて制御フローが変化します。 CFGのこの部分は、少なくとも2つの出力を持つ1つのノードで構成されています。
ここで行われる決定は、if-elseステートメント（2つの可能な出力を持つ）やcaseステートメント（3つ以上の出力を持つ可能性がある）のような条件ステートメントである可能性があります。
(画像 ソース )
上の図には、（条件付きの「age = 18」からの）決定ポイントがあり、その後に「はい」または「いいえ」のオプションが続きます。
＃3）ジャンクションポイント
上の図から、決定ポイントが結合する場所に関するジャンクションポイントを簡単に特定できます。ジャンクションポイントには多くの入口パスを含めることができますが、出口パスは1つだけにすることができます。
制御フローグラフのベストプラクティス：
制御フローグラフを作成する際に注意すべき点がいくつかあります。
- CFGを単純に保つために、可能な限り努力してください。 「それほど重要ではない」と見なされる可能性のある部分を組み合わせることで、これを行うことができます。 例えば、 プロセスブロック。
- 決定ポイントで、1つの決定のみが行われるようにします。より複雑なCFGでは、決定が下された後に生じる「結果」があります。上記の例では、個人が18歳以上の場合、資格があり、チケットの支払いが必要であることを追加することもできます。そうでない場合、エントリーは無料です。 「else」の決定では、いくつかのノードを「スキップ」する必要があり、それらすべてのステップをCFGに表示する必要があります。
CFGを定義したら、制御フローテストプロセスの次のステップに進みます。つまり、コードをテストする範囲を定義します。
テストする量の定義：
どのくらいのソースコードをテストする必要がありますか？考えられる各パスをテストする必要がありますか？テストですべてのパスをカバーしようとすることは事実上不可能です。実行できるテストの量を決定するには、中間点を見つける必要があります。
コードの50％をテストすることを目的としている場合、これは、すべての実行可能コードステートメントを定義し、それらの少なくとも半分をテストすることを目的としていることを意味します。ただし、ここで発生する問題は、「次に、考えられるすべての実行可能パスを定義する必要があるか」ということです。
どのプログラムがPDFファイルを編集できるか
これも事実上不可能かもしれません。より良いアプローチは、コードの各セクションで識別できるパスの50％をテストすることを目的としている可能性があります。
カバレッジには、ステートメント、ブランチ、パスのカバレッジというさまざまなレベルがあります。それらについては後で簡単に説明します。
テストケースの作成：
次のステップは、使用するテストケースを作成することです。構造ベースのテストのテストケースは、次の要因に基づいています。
- 実行可能ステートメント。
- 行う必要のある「決定」。
- たどることができる可能なパス。
- 満たす必要のある条件（これらは複数またはブール値の場合があります）。
上記の要素から、作成する必要のあるテストケースの種類がわかります。構造テスト生成ツールを使用することもできます。コードがCプログラミング言語の場合、PathCrawlerを使用してテストコードを生成できます。使用できるもう1つのツールはfMBTです。
テストケースの実行：
ここで、テストを実行します。入力またはデータを入力して、コードがどのように実行するかを確認し、期待どおりの結果が得られるかどうかを確認できます。 例えば、 関数呼び出しに配列を入力して、配列をループした後に得られる結果を確認するか、決定ポイントが正しい決定を行っているかどうかを確認します。
結果の分析：
この部分では、実行後に正しい結果が得られるかどうかを確認するだけです。 例えば、 すべての値が18を超える配列を入力すると、すべての決定ポイントが「適格」になるはずです。
制御フローの仮定
制御フローテストを実行するには、いくつかの仮定が行われることに注意することが重要です。 これらには以下が含まれます：
- 存在する唯一のバグは、制御フローに影響を与える可能性のあるバグです。
- すべての変数、関数、および要素は正確に定義されています。
制御フローのカバレッジレベル
先に述べたように、制御フローテストにはさまざまなレベルのカバレッジがあります。
それらを簡単に見てみましょう。
＃1）ステートメントカバレッジ
構造テストでは、実行可能なコードステートメントは、テストの設計方法を決定する際に重要な役割を果たします。
100％のカバレッジを達成することを目指しています。つまり、すべての実行可能ステートメントが少なくとも1回はテストされています。カバレッジが高いほど、バグやエラーを見逃す可能性が低くなります。
ここではテストケースを使用する必要があります。必要なデータは、コードブロック内のすべての実行可能ステートメントが少なくとも1回実行されるようにすることです。
＃2）ブランチカバレッジ
このカバレッジレベルには、CFGブランチ（決定が行われる場所）のポイントのテストが含まれます。結果はブール値です。 switchステートメントが使用され、複数の結果がある場合でも、本質的に、各ケースブロックは値のペアの比較です。
ステートメントカバレッジと同様に、100％のブランチカバレッジを目指す必要があります。これを達成するには、各決定レベルで各結果を少なくとも1回テストする必要があります。ブール値の結果を扱っているので、コードのセクションごとに少なくとも2つのテストを実行することを目指す必要があります。
＃3）パスカバレッジ
このレベルのカバレッジは、決定およびステートメントのカバレッジと比較すると、より徹底的です。ここでの目的は、考えられるすべてのパスを「発見」し、少なくとも1回はテストすることです。これには非常に時間がかかる場合があります。ただし、コードのバグやエラー、さらには定義する必要のある側面を発見するのに役立ちます。 例えば、 ユーザー入力。
構造試験の種類
(画像 ソース )
ミューテーションテスト
ミューテーションテストは、ソフトウェアアプリケーションのさまざまなバリエーションがテストデータセットに対してテストされる障害ベースのテスト手法です。
>>詳細については、このチュートリアルを参照してください ミューテーションテスト。
スライスベースのテスト
スライスベースのテスト（SBT）は、に基づくソフトウェアテスト手法として定義できます。 スライス –プログラムの実行可能部分、またはプログラムの特定の関心ポイントでいくつかの値に影響を与えるステートメントのグループ。 例えば、 変数が定義されている部分、またはステートメントのグループの出力。
スライスする方法
SBTでのスライス例： 偶数と奇数を出力するコード（Python）
num_list = range(1,12) even_nums = () odd_nums = () for var in num_list: if var%2==0: even_nums.append(var) print(f'Even numbers: {even_nums}') elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}') 
スライスを見るには2つの方法があります。 対象の変数または出力に影響を与えるコードの一部のパスをたどることによって。
この例では、奇数の出力を見ると、この出力につながるコードの部分をトレースできます。
Mark Weiser（SBTを導入した）によって与えられたスライス基準では、スライスは次の式を使用して定義されます。 S（v、n） 、 どこ、 v 問題の変数を参照します（ 例えば、 変数が定義されている場所）、および n 関心のある声明です（ 例えば、 出力が与えられる場所）、および S スライスを表します。
上記の例では、スライスを取得するために、10行目の出力から開始します。 n 。私たちの変数は どこ 。
したがって、スライス基準は次のとおりです。
S(v,n) = S(var,10)私たちの懸念は、私たちをアウトプットに導くステートメントです。
これらは：
10,9,8,4,3,1
したがって、このコードのスライスは次のとおりです。
num_list = range(1,12) odd_nums = () for var in num_list: elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')
スライスベースのテストタイプ
SBTには、静的と動的の2つのタイプがあります。
＃1）動的スライスベースのテスト
上で説明した奇数の印刷に影響を与えるステートメントを調べたSBTの例は、動的SBTです。私たちの懸念は非常に具体的です。特定の出力に直接影響するものにのみ焦点を当てます。
コードを実行し、テストデータを使用して、想定どおりに機能することを確認します。範囲をrange（1,50）に増やすことができます。 例えば、 それでも奇数のみが生成されるかどうかを確認します。動的SBTは、検証テストとも呼ばれます。
＃2）静的スライスベースのテスト
動的SBTとは異なり、静的テストの焦点は特定の変数にあります。上記の例の出力を次のように考えると どこ 、それに影響を与えるスライスをトレースできます 10,9,8,7,6,5,4,3,2,1
基本的にはコードブロック全体です！ここでは、コードが構文と要件に関して正しいことを確認し、実行しません。静的SBTは、検証テストとも呼ばれます。
動的SBTは、静的SBTと比較して「小さい」ことに注意することが重要です。また、より具体的です。
スライスベースのテストのベストプラクティス/ガイドライン
スライス基準は、次の方法で決定する必要があります。
- 値が定義または割り当てられたステートメント、および再割り当てされた値。
- プログラムの外部から値を受け取っているステートメント、 例えば、 ユーザー入力を介して。
- 出力を出力する/出力を返すステートメント。
- プログラムの最後の声明、 例えば、 値を定義したり、引数に値を提供したりできる関数呼び出し
スライスベースのテストの利点は次のとおりです。
- SBTでは、特定の関心領域のみを処理するため、テストスイートを効果的に生成することが容易になります。
- パスはコード内の依存関係によって定義されます。これは、使用するよりも優れています パスカバレッジ。
- SBTを使用すると、ソースコード内のエラーを簡単に見つけることができます。
スライスベースのテストの欠点は次のとおりです。
- 大規模なコードベースをテストするときに動的テストを使用する場合、多くの計算リソースが必要になります。
- 静的テストを使用すると、エラーを見逃す可能性があります。
データフローテスト
データフローテストは、データ値とプログラムでの使用法に基づくソフトウェアテスト手法として定義できます。データ値が適切に使用され、正しい結果が生成されることを確認します。データフローテストは、特定の実行パス上のデータ値間の依存関係を追跡するのに役立ちます。
データフローの異常
データフローの異常は、ソフトウェアプログラムの単なるエラーです。それらはそれぞれタイプ1、2、および3に分類されます。
以下でそれらを詳しく見ていきましょう。
タイプ1： 変数が定義され、値が2回割り当てられます。
サンプルコード：Python
lst_1 = (1,2,3,4) lst_1 = (5,6,7,8) for var in lst_1: print(var) 
Lst_1 が定義され、2つの異なる値が割り当てられます。最初の値は単に無視されます。タイプ1の異常によって、プログラムが失敗することはありません。
タイプ2： 変数の値は、定義される前に使用または参照されます。
サンプルコード：Python
for var in lst_1: print(var) 
上記のループには、繰り返す値がありません。タイプ2の異常により、プログラムは失敗します。
Javaでリストをインスタンス化する方法
タイプ3：A データ値は生成されますが、使用されることはありません。
サンプルコード：Python
lst_1 = (1,2,3,4) lst_2 = (5,6,7,8) for var in lst_1: print(var) 
変数 lst_2 参照されていません。タイプ3の異常は、プログラムの失敗を引き起こさない場合があります。
データフローテストプロセス
データ値間の依存関係を定義するには、プログラムでたどることができるさまざまなパスを定義する必要があります。これを効果的に行うには、次のような別の構造テストタイプから借用する必要があります。 制御フローテスト 。
ステップ1） 制御フローグラフを描く
プログラムでたどることができるパスをグラフィカルに表現した制御フローグラフを描画する必要があります。
サンプルコード：Python
cost = 20 y = int(input('How many visitor seats did you reserve? ')) x = int(input('How many member seats did you reserve? ')) if y>x: bill = cost -1 else: bill = cost print(bill) 
上記のコード例では、メンバーが訪問者を招待した場合、メンバーは割引を受ける必要があります。
制御フローグラフ（CFG）：
ステップ2） 変数とデータ値の定義と使用法を調べてください。
プログラム内の変数は、定義または使用されます。 CFGでは、各ノードに変数があります。各ノードには、格納されている変数タイプに従って名前が付けられます。変数が特定のノードで定義されている場合、それは定義ノードを作成します。変数がノードで使用される場合、それは使用ノードを作成します。
CFGの変動費を考慮すると、これらは定義ノードと使用ノードです。
| ノード | タイプ | コード |
|---|---|---|
| 1 | ノードの定義 | コスト= 20 |
| 5 | 使用ノード | 請求書=コスト-1 |
| 7 | 使用ノード | 請求書=コスト |
ステップ3） 定義-使用パスを定義します。
定義-使用パスには2つのタイプがあります。 duパスとdcパス。 duパスは、定義ノードで始まり、使用ノードで終わる定義パスです。これは、上記の変動費を参照するパスの場合です。
決定クリアパスであるDCパスの例は、以下のように請求変数に関するパスです。
| ノード | タイプ | コード |
|---|---|---|
| 5 | ノードの定義 | 請求書=コスト-1 |
| 7 | ノードの定義 | 請求書=コスト |
| 8 | 使用ノード | 印刷（請求書） |
DCパスには、使用ノードで終了している場合でも、複数の定義ノードがあります。
ステップ4） テストスイートを作成します。
これは入力を追加しています。変数ごとに異なるテストスイートが必要であることに注意してください。テストスイートは、データフローの異常を特定するのに役立ちます。
データフローテストの種類
2つのタイプがあります– 静的および動的 。
静的とは、コードとCFGを調べて、実行せずにデータの異常を特定することを意味します。動的とは、実際に特定のパスを特定し、静的テスト中に見逃した可能性のある異常を「キャッチ」するために、テストスイートを作成してテストすることを意味します。
データフローテストの長所と短所：
- データフローテストは、データフローの異常を特定するのに理想的であり、非常に効果的な構造テスト方法になります。
- その欠点は、データフローテストを使用するためのコードの記述に使用される言語に精通している必要があることです。また、時間がかかります。
構造試験の長所と短所
ここで、構造テストが優れたアプローチである理由を見つけ、その欠点のいくつかも調べてみましょう。
利点：
- 徹底的なコードテストを可能にし、エラーを最小限に抑えます。 構造ベースのテストでは、ソフトウェアを徹底的にテストする余地があります。さまざまなレベルのカバレッジ–ステートメントごと、すべての決定ポイント、およびパスは、100％のカバレッジを達成することを目的としており、エラーが検出されなくなる可能性を大幅に減らします。
- 自動化する機能 。テストを自動化するために使用できるツールがいくつかあります。これにより、手動でテストを行う場合と比較して、最大のコードカバレッジを短時間で達成できます。
- それはより高品質のコードをもたらします 。開発者は、コードの構造と実装を研究し、エラーを修正するだけでなく、これらの側面を改善する機会があります。これにより、コードの後続の部分を記述したり、残りの機能を実装したりするときに、優れた構造を念頭に置くことができます。
- SDLCの各フェーズで実行できます –構造テストは、開発が100％完了するのを待たずに、SDLCの各フェーズで実行できます。これにより、初期段階でエラーを簡単に特定できるため、開発完了後のテストと比較して多くの時間を節約できます。
- デッドコードを取り除くのに役立ちます 。これは、「余分な」または不要なコードと見なすことができます。 例えば、 結果を計算しますが、次の計算では使用しないコード。
- 効率 –コードを作成する開発者は、コードをテストする開発者と同じであるため、QAのような他の人を巻き込む必要はありません。
短所：
- 構造ベースのテストを実行する開発者は、言語を完全に理解している必要があります 。言語に精通していない他の開発者やQAは、テストを手伝うことができません。
- 時間とお金の面でかなり高価になる可能性があります 。テストを効率的に行うには、多くの時間とリソースが必要です。
- 機能の提供が遅れる原因になります 。これは、開発者がテストを行うためのソフトウェアの構築から引き離されているためです。
- スケーリングは、特に大規模なアプリケーションが関係する場合に問題になります 。大規模なアプリケーションは、カバーするルートの数が多すぎることに相当します。 100％のカバレッジを達成することは不可能になります。
- 見逃されたケースやルートがあるかもしれません 、 例えば、 機能が完全に開発されていないか、まだ開発されていない場合。これは、要件テスト（構築する必要のある指定された機能と照合する）などの他のテストタイプと組み合わせる必要があることを意味します。
構造テストのベストプラクティス
構造ベースのテストを実行する際に注意が必要な要素のいくつかは次のとおりです。
- テストに明確にラベルを付け、名前を付けます 。他の誰かがテストを実行する必要がある場合、彼らはそれらを簡単に見つけることができる必要があります。
- コードを拡張する前に、つまりコードをリファクタリングし、さまざまな環境で使用できるように最適化する前に、コードの構造とフローが理想的であることを確認してください。
- テストを個別に実行する 。このようにして、バグを特定して修正するのは簡単です。一方、コードセクション、ブロック、またはパスの重複の結果として、バグやパスを見逃す可能性は低くなります。
- 変更を加える前にテストを生成する 。テストは期待どおりに実行する必要があります。このように、何かが壊れた場合、問題を追跡して修正するのは簡単です。
- コードの各セクションまたはブロックのテストを別々に保つ 。このように、将来的に変更があった場合でも、多くのテストを変更する必要はありません。
- テストに進む前にバグを修正する 。バグを特定した場合は、次のセクションまたはコードブロックのテストに進む前に、バグを修正することをお勧めします。
- QAが「とにかくテストを実行する」ことを前提として、構造テストをスキップしないでください。 バグが最初は取るに足らないように見えても、累積的には、意図した目的を達成できないバグのあるコードになる可能性があります。
構造ベースのテストに関するFAQ
ここでは、構造ベースのテストに関してよくある質問について説明します。
Q＃1）機能テストと構造テストの違いは何ですか？
回答： 機能テストは、SRS（ソフトウェア要件仕様）に規定された要件に基づくソフトウェアテストの一種です。これは通常、SRSの仕様とコードの動作の違いを見つけるために行われます。構造テストは、コードの内部構造とその実装に基づいています。コードを完全に理解する必要があります。
Q＃2）構造試験の種類は何ですか？
回答： タイプは次のとおりです。
- データフローテスト
- ミューテーションテスト
- 制御フローテスト
- スライスベースのテスト
Q＃3）構造試験の例は何ですか？
回答：ステートメントカバレッジを示す例を次に示します。
const addNums = (num) => { let sum = num.reduce ((a,b) => a+b); if (sum > 0) { alert(sum); } else { alert(‘please enter positive numbers’); } }; addNums(); 取得するカバレッジの量は、入力として提供するテストデータによって異なります（合計> 0の条件を満たすかどうか）。
Q＃4）データフローテストと制御フローテストの違いは何ですか？
回答： データフローテストと制御フローテストはどちらも、制御フローグラフを使用します。唯一の違いは、制御フローテストでは、コードから生成されたパスに焦点を当てるのに対し、データフローテストでは、プログラム内で識別されたパス内のデータ値、その定義、および使用法に焦点を当てることです。
Q＃5）データフローテストは何に使用されますか？
回答： データフローテストは、制御フローグラフのパス内のデータ値の使用における異常を特定するのに理想的です。 例えば、 値が2回割り当てられた1つの変数、定義されて使用されていない変数、または使用または参照されて定義されていない変数。
Q＃6）ソフトウェアテストでのスライスとダイシングの違いは何ですか？
回答： スライスとは、プログラムの特定の関心のあるステートメントに焦点を合わせ、残りを無視することを意味します。ダイシングとは、入力が間違っているスライスを特定し、それをさらにスライスして正しい動作を追跡することです。
Q＃7）ミューテーションテストとコードカバレッジの違いは何ですか？
回答： ミューテーションテストでは、殺されたミュータントの数をミュータント全体のパーセンテージと見なします。コードカバレッジは、単にプログラムでテストされたコードの量です。
結論
このチュートリアルでは、構造テストについて詳しく説明しました。構造テストとは何か、そうでないもの、その方法、カバレッジタイプ、長所と短所、ベストプラクティス、さらにはこのソフトウェアテストタイプに関するいくつかのFAQです。
構造ベースのテストについて学ぶことができることはまだまだたくさんあります。将来のチュートリアルでは、コードカバレッジ（ステートメント、決定、ブランチ、パス）、構造テストタイプ（ミューテーション、データフロー、スライスベース）、さらにはこれらのテストプロセスを自動化するために使用できるツールについても説明します。
100％効率的なソフトウェアテストの種類やアプローチはないことに注意することが重要です。さまざまなテストタイプとアプローチを組み合わせることを常にお勧めします。
例えば、 構造ベースのテストが実行されていた時点では開発されていなかった可能性がある機能があるため、構造テストは要件テストによって大幅に補完されます。
構造テスト手法は、人間のプログラマーがコードを書くときに発生するエラーに基づいています。プログラマーは専門家であり、コーディング内容を知っているが、時々誤りを犯すことが前提です。
私たちが調べたさまざまな構造テストの種類–ミューテーションテスト、スライスベースのテスト、データフローテストは、間違った演算子の使用（ミューテーションテスト）や使用前の変数の参照（データフローテスト）などのエラーにまでさかのぼることができます。 。