what is cyclomatic complexity learn with an example
循環的複雑度は、開発コミュニティで非常に一般的な流行語です。この手法は主に、コードまたは機能の複雑さを判断するために使用されます。
この手法はMaCabeによって開発され、プログラム/機能に関する以下の3つの質問を特定するのに役立ちます。
- 機能/プログラムはテスト可能ですか？
- 機能/プログラムは誰もが理解していますか？
- 機能/プログラムは十分に信頼できますか？
QAとして、この手法を使用して、テストの「レベル」を特定できます。循環的複雑度の結果が多かれ少なかれ多い場合、その機能は複雑な性質のものであると見なし、テスターとして結論を下すのが慣例です。コード/機能の一部には詳細なテストが必要であること。
一方、循環的複雑度の結果が小さい場合は、QAとして機能の複雑度が低いと結論付け、それに応じて範囲を決定します。
ステップバイステップで行きましょう： 最初にそれがどのように計算されるかを理解し、次にテストのレベルがどのように決定されるかを理解することに移ります。
学習内容：
循環的複雑度を計算する方法は？
CCの計算は、2つの概念を中心に展開されます
コンピュータの温度をチェックするための最良のプログラム
- ノード
- エッジ
プログラム内のステートメントはノードとして表され、あるステートメントから別のステートメントへの制御パスはエッジで表されます。
循環的複雑度の式
CCの計算式は次のとおりです。
CC = E〜N + 2
どこ：
E =エッジの数
N =ノードの数。
（それを計算するためのショートカットがありますが、今はありません……後で…）
循環的複雑度の例
それを理解するために、以下の例を見てみましょう。
以下の制御フローグラフを検討してください。
私は配置しました ネット ノードを識別するためのドットと 青い エッジを識別する線：
したがって、この例では次のようになります。
ノード数（赤い点）= 14
エッジの数（青い線）= 15
したがって、循環的複雑度= N〜E + 2 =（14-15）+2 = 3
テスターはどのようにそれを使用できますか？
実際には、テスターは開発者と一緒に座って、特定のコードの制御フローグラフを導き出すことができます。グラフができたら、この式を使用して複雑さを導き出すことができます。しかし、テスターの話はここで終わりではありません。–ここでの要点は–テストチームにとってこの番号の使用は何ですか？
テスターはこの数値を利用して、テストのレベルを判断できます。
実際には、2つのレベルのテストがあります。
- 長さテスト
- 幅テスト
モジュールのさまざまな機能について、以下のマトリックスを検討してください。-
長さテストは、各機能の重要なテストケースを選択することにより、スコープ全体をカバーしようとする方法です。 例えば 、この場合、長さテストを暗示することを選択したとすると、次のように選択できます–
- 機能1のサブ機能1.1およびサブ機能1.3
- 機能2のサブ機能2.2
- 機能3のサブ機能3.3
- 機能4のサブ機能4.2およびサブ機能4.3
- 機能5のサブ機能5.3
したがって、ここでは、サブ機能の詳細に立ち入ることなく、機能全体に触れています。
CCの結果が大きい場合は、幅テストを選択します。実際には、すべての機能とすべてのサブ機能をテストします。
他の電話をスパイできるアプリ
したがって、現在のプロジェクト要件、環境の信頼性に基づいて、テスターは開発チームと協力して、テストのレベルと範囲を特定するための標準を作成できます。例えば -
- CCの場合<=15 – Basic sanity test
- CCが16〜30の場合–長さテスト
- CCが31から50の間の場合–幅テスト
- CC> 50の場合–それは混沌とした機能であり、さらに分解する必要があります
今ショートカットが来る-
閉じた領域の数を数えて、それに1を加えるだけです。
上記の例では、閉じた領域の数= 2（黄色で塗りつぶされている）なので、CC = 2 + 1 = 3
実際の作業では、次のようなステートメントを与えたときに結果を結論付けることは非常に困難です。
- 「…..この機能を実装するのは非常に困難です」
難しいとはどういう意味ですか？それは複雑ですか、複雑ですか、それとも混沌ですか？
これは難しいとどのように結論付けましたか？
- 「…これは一日の終わりまでに利用可能になるはずです」
一日の終わりは何ですか？あなたの一日の終わりは午後7時です、おそらく私のものは午後6時ですか？
- 「…これについては詳細なテストを行う必要があります」
詳細なテストとは何ですか？ 「詳細テスト」と呼ばれるテスト手法はありません
- 「…QAにデプロイする前に、コードは高品質である必要があります」
良い品質をどのように測定しますか？
代わりに、次のように言い換えると–
コードの循環的複雑度は75と計算され、標準に従って計算されます。この機能はカオス的な性質のものです。したがって、さらに分解することをお勧めします。
以上
- 「…..この機能を実装するのは非常に困難です」
この機能は、中部標準時午後5時までにQA環境に導入されます。
以上
- 「…。これは1日の終わりまでに利用可能になるはずです」
循環的複雑度は48と計算されるため、標準に従って、機能の統合テストと回帰テストとともにシステムテストを実行します。
以上
- 「…。これについては詳細なテストを行う必要があります」
Sonarによると、CCは現在102です。CCを10に設定するように標準化されています。コードを改善して、CCを10未満にするときに、コードをデプロイします。
以上
- 「…。QAにデプロイする前に、コードは高品質である必要があります」
2つのステートメントの違いは何ですか？
さて、ここでの違いは測定です。私は、利害関係者が私が言いたいことを正確に知るのに役立つ適切な測定で、私の各ステートメントをサポートしました。
同様に、ソフトウェアテストで循環的複雑度を使用して、テスト作業の正確な測定値を決定します。これを使用して、テストの範囲だけでなく、実行する必要のあるテストのタイプも特定できます。
推奨読書
- コンポーネントテストまたはモジュールテストとは（例を使用して学習）
- 比較テストとは（例を使って学ぶ）
- ソフトウェアテストキャリアパッケージeBook
- システム統合テスト（SIT）とは：例を使って学ぶ
- 最高のソフトウェアテストツール2021 (QAテスト自動化ツール)
- PrimereBookダウンロードのテスト
- テスターが使用方法を学ぶ必要がある5つの重要な図
- TestRailレビューチュートリアル：エンドツーエンドのテストケース管理を学ぶ