テスターは皆、絵を描くのが得意です。コード図の使い方を知らない人がいるでしょうか?

オープンソースの中国コミュニティチームは、共有の名のもとに、オープンソースの中国コミュニティの背後にあるストーリーを伝える初のライブブロードキャストを行いました。」

これが何なのか、みんなに30秒考えてもらいませんか?

あるシステムのログインモジュール機能の初期クラス図

これは、あるシステムのログインモジュール機能の初期クラス図です。

最新のソフトウェアはますます複雑になるため、コードグラフは、複雑なコードロジックを理解しやすくする直感的な方法をテスターに提供します。この記事では、コードグラフについて詳しく説明し、視覚的なコードグラフがソフトウェアテスターの能力をどのように強化できるか、発掘された現実のシナリオと実用的な例を通じてテストを実施する方法を示します。

1. コード図とは何ですか?

コード図は、コード構造、クラス間の関係、またはコード要素間の相互作用を表すために使用されるグラフィカルツールを指します。一般的なタイプには、クラス図、シーケンス図、アクティビティ図、コンポーネント図などが含まれます。

コードマップは次の 2 つの部分で構成されます。

ノード ( Nodes ) は、クラス、オブジェクト、アクティビティなどのコード要素を表します。
エッジは、関連付け、継承、依存関係などのノード間の関係を表します。

組み合わせ関係のクラス図を例として挙げます。

組み合わせ関係のクラス図

2. コード視覚化の利点

コードの視覚化により、コードの構造と関係がグラフィカルに表示され、チームメンバーはソフトウェアテストプロセス中にコード図を使用することで、相互のコミュニケーションとコラボレーションの向上、効率と集中力の向上など、多くのメリットを得ることができます。これにより、ソフトウェアテスターはコードのロジックと関係をより迅速に理解できるようになり、コードを読んで理解するための時間コストが削減されます。

1 コミュニケーションとコラボレーションの向上

コード図の重要な役割は、技術者と非技術者の間のギャップを埋めるのに役立つことです。テスターは、コードに不慣れなマネージャー、顧客、またはメンバーにコードフローを簡単に説明できます。

元シーメンスのソフトウェアエンジニアであるStelios Manioudakis は、コミュニケーションとコラボレーションの向上におけるコード図の役割を詳しく説明するために、自分自身を例に挙げました。

ソフトウェアテスターとしての初期の頃、彼は新しいフィットネストラッカーアプリを開発するプロジェクトに取り組みました。睡眠追跡アルゴリズムを通じてセンサーデータを分析し、睡眠段階 (浅い睡眠、深い睡眠) を決定し、睡眠レポートを生成します。しかし、アルゴリズムをテストする過程で多くの困難に直面しました。技術者以外の人がコードだけでアルゴリズムのロジックを理解するのは難しいからです。

ここでコード図が役に立ちます。さまざまなセンサーの読み取り値や睡眠パターンの計算に視覚的なアルゴリズムフローと意思決定ポイントを使用することで、プロダクトマネージャーやUIデザイナーは、不安定な睡眠パターンやセンサーデータの欠落など、コード図を通じてテストする必要がある潜在的なシナリオを理解できるようになります。

これに加えて、コードマップにより開発者とのコラボレーションが容易になります。コードレビュー中に、テスターと開発者は、コードマップを参照することで、意図したロジックと実際の実装の間の潜在的な差異をより適切に特定できます。最終的に、フィットネス追跡アプリケーションの睡眠追跡アルゴリズムはテストに合格し、コード図が重要な役割を果たしました。

2 効率と集中力の向上

テスターは、コード図を通じてテストをより効率的に計画、作成、実行できるため、反復作業が減り、テストのカバレッジと品質が向上します。

ニュースプッシュアルゴリズムを例に挙げます。このアルゴリズムは、ユーザーの興味やインタラクションに基づいてパーソナライズされた推奨を行います。最初は、テスターはコードを 1 行ずつ注意深く調べる必要がありますが、これは時間と労力のかかるアプローチであり、考えられるすべてのテストシナリオを特定することが困難になります。しかし、コード図には、ユーザーの好み、インタラクション後の操作、コンテンツの鮮度などの影響要因が直感的な方法で表示されます。それだけでなく、コード図は明確な意思決定ポイントと分岐パスを提供します。

ホットトピック:ユーザーが人気のコンテンツを見逃さないように、ホットトピックが情報ストリームの最初に表示されるテストシナリオに重点を置きます。
パーソナライズされた推奨事項:アルゴリズムが関連コンテンツを正確に推奨するかどうかを検証するために、さまざまな興味やインタラクションを持つさまざまなユーザープロファイルのテストを優先します。
エッジケース:非アクティブなユーザーや対話が制限されているユーザーなど、潜在的なエッジケースが強調表示されます。テスターは、特定のテストケースを設計して、このような状況でアルゴリズムが失敗しないことを確認できます。

コード図を使用する方が、コードを 1 行ずつ検査するよりもはるかに高速であることは明らかです。これにより、テスターはアルゴリズムの主要な領域に優先順位を付けることができ、徹底的なテストを保証し、より信頼性の高いパーソナライズされたニュースフィードエクスペリエンスをユーザーに提供できます。

3 文書の保守性の向上

ドキュメントは、コードのリファクタリング後、または新しいチームメンバーがコードをレビューする必要があるときに、チームメンバーがプログラムフローと潜在的なテストポイントをより迅速に理解するのに役立ちます。

たとえば、電子商取引プラットフォームの在庫管理システムは何年も前に確立されましたが、現在ではメンテナンスがますます複雑になり、新しい機能の実装がますます困難になっています。複雑な在庫管理ロジックに直面するシステム調整プロセスにおいて、商品の追加や更新から注文処理、在庫レベルの管理までをコード図で直感的に表示します。

このようにして、テスターは調整された在庫管理システムが効率的に維持されていることを確認でき、コード図の役割は自明です。

より明確にコミュニケーションする:コード図を使用して、新しいチームメンバーにシステムの機能を説明します。これらの図はコードコメントとともに明確かつ簡潔な概要を提供し、システムのロジックとテストの考慮事項をより迅速に把握できるようにします。
効率的なコードレビュー:コードレビュー中にコード図とコードコメントを参照すると、潜在的な問題を早期に特定するのに役立ちます。プロセス全体に対する変更の影響を視覚化することで、チームは変更がシステムの他の部分に意図しない副作用を及ぼさないことを保証できます。
将来を見据えたメンテナンス:システムが進化し、新しい機能が追加されると、コード図は貴重な参照点として機能します。プロジェクトに参加したことのないテスターでも、既存のロジックと潜在的な影響領域を簡単に理解できるため、より効率的で的を絞ったテスト作業が可能になります。

4. 問題を早期に発見する

コード図は、プレーンテキストのコードレビューでは見逃される可能性のある問題を明らかにする可能性があります。これは、コード図が乱雑であるほどコードが複雑になり、エラーが発生しやすくなることを示すためです。

たとえば、病院の予約スケジュールシステムは、更新プロセス中に新機能を導入し、患者がオンラインで予約を変更できるようにしました。コードのレビューとテストケースの設計後、大きな問題が見つからなければ、新しい機能を使用できます。

ただし、競合する予定の特定部分の処理が複雑であることを考慮して、テスターはさらなる検査と検証のためにコード図を採用することにしました。コード図は、テキストのみのレビューでは見落とされる可能性のある潜在的な問題を示しています。

複数の決定ポイント:既存の予約、医師の空き状況、時間の制約などのさまざまな要因に基づく多数の決定ポイントは、テスト中に考えられるすべてのシナリオを考慮することが難しいため、エラーのリスクが高くなります。
隠されたロジック:図の複雑な性質により、コードロジックを視覚的に理解することが非常に困難になります。これにより、コード内に隠れた条件や予期しない動作が発生する可能性があるという懸念が生じます。

その結果、テスターはコード図に基づいて新しい関数を再調整しました。

テストの優先順位付け:日付が矛盾するシナリオのテストを優先します。複雑なロジックの潜在的なエラーを明らかにする可能性のあるエッジケースとその組み合わせに焦点を当てます。
開発者とのコラボレーション:視覚的表現を利用して、テスターは発見された複雑さについて開発者と話し合います。このコラボレーションにより、コードのリファクタリング作業が行われ、ロジックが簡素化され、循環的な複雑さが軽減されました。

テスターはコードマップを使用して潜在的な問題を積極的に特定し、開発者と協力して問題を解決します。これにより、病院の予約スケジュールシステムの完全性と信頼性が保証されます。

5 構造化されたプログラミング接続

コード図は、構造化プログラミングの原則 (シーケンス、選択、繰り返し) にシームレスに適合します。これらの基本構造は特定のグラフィックスパターンに直接マッピングされ、これらの共通構造のテストが簡素化されます。

(1)簡素化されたテスト設計: 構造化プログラミングは、シーケンス、選択 ( if-else)、繰り返し (ループ)など、明確に定義された構造を重視しますコードマップは、これらの構造を特定のパターンに直接マッピングします。

シーケンス:あるステートメントに続く別のステートメントを表す直線ノード

選択:単一のエントリノード、条件ノード、および 2 つの出力エッジ (1 つは true、もう 1 つは false) を備えた分岐構造で、別個のステートメントのシーケンスにつながります。

繰り返し:エントリノード、条件ノード、条件ノードを返すエッジ、およびループ本体 (ステートメントのシーケンス) を指すエッジを含むループパターン

(2)テストケースの視覚化の容易化: これらのよく知られたパターンをコード図で識別することで、テスト担当者はプログラムの流れと対応するテストケースをすぐに理解できます。たとえば、図のループパターンは、境界条件や予想される動作など、ループのさまざまな反復をカバーするテストケースの必要性を表しています。

6 複雑さの測定の詳細

サイクル数は、コードグラフの複雑さに基づく尺度で、プログラムのテストの難しさを評価するのに役立ちます。複雑さが増すほど (パスが増えるほど)、テストはより徹底的になります。さらに詳しく見てみましょう。

ループ数:このメトリクスはコードグラフの構造から導出され、プログラム内の独立した実行パスの数を推定するために使用されます。ループ数が増えると、通常、ネストされたループ、複数の決定点、または GOTO ステートメントなどの要因により、複雑さが増します。
スマートなテスト計画:サイクル番号はテスターにとってガイドとして機能し、包括的なテストに必要な労力を示します。ループ数が多いプログラムは、ループ数が少ないプログラムよりも、すべての潜在的な実行パスをカバーするためにより多くのテストケースを必要とします。これにより、テスターは作業に優先順位を付け、複雑なセクションを包括的にカバーできるようになります。

簡単な例として、2 つの連続するif-elseステートメントを含む単純なプログラムを考えてみましょう。

if condition1:
  # statements for if condition1 is true
else:
  if condition2:
    # statements for if condition2 is true
  else:
    # statements for both conditions false

2 つの連続する if-else ステートメントを含む単純なプログラム

ノード：

ノード1 :プログラムの開始点。コード実行の開始を表します。
ノード 2 :決定ノードの条件 1 。このノードは条件を評価し、結果 (true または false) に基づいて実行フローを決定します。
ノード 3 :ステートメントブロックの条件 1が true の場合に実行されます。このノードは、condition1の「if」ブロック内のすべてのコードを表します。
ノード 4 : condition1に関連付けられた「else」ノード。このノードは、条件 2がチェックされていない場合(つまり、条件 1が偽の場合) の代替パスを表します。
ノード 5 :条件 2の決定ノード。このノードは条件を評価し、結果 (true または false) に基づいて実行フローを決定します。
ノード 6 :条件 2が true の場合に実行されるステートメントブロック。このノードは、condition2の「if」コードブロック内のすべてのコードを表します。
ノード 7 :条件 2に関連付けられた「else」ノード- このノードはプログラムの終了を表し、条件 1と条件 2の両方が false の場合に実行されるコードを表します。

側：

エッジ 1 :ノード 1 とノード 2を接続し、開始点から最初の決定点までの初期フローを表します。
エッジ 2 (true):条件 1 はノード 2 とノード 3を接続し、true の場合に実行されるプロセスを示します。
エッジ 3 (偽):条件 1 はノード 2 とノード 4を接続し、偽の場合は代替フローが採用されることを示します。
エッジ 4 :ノード 4 とノード 5を接続し、「else」ブロックから条件 1 の 2 番目の決定点までの流れを示します。
エッジ 5 (true):条件 2 はノード 5 とノード 6を接続し、true の場合に実行されるプロセスを示します。
エッジ 6 (偽):条件 2 はノード 5 とノード 7を接続し、偽の場合のエンドポイントを示します。

対応するコードグラフには、3 つの決定点と複数の実行パスを持つ分岐構造が含まれます。このグラフのサイクル数は 4 (ノード - エッジ + 2 ) です。これは、ロジックがより複雑で、より単純な構造のプログラムよりも多くのテストケースが必要になる可能性があることを示しています。

これらの利点を理解することで、ソフトウェアテスターはコード図を活用してプログラムロジックを効果的に操作し、効果的なテストケースを設計し、高品質のソフトウェアを提供できるようになります。

円番号4の導出方法を詳しく説明します。

循環的複雑さは、プログラム内に独立したパスがいくつあるかを示します。パスが多いほど、テストは複雑になります。
このコードには 2 つの決定があります ( condition1とcondition2を確認します)。それぞれの決定により、パスに分岐点が生じる可能性があります (真または偽)。
ただし、elseブロックの条件 1は決定条件 2を直接指しているため、そこには実際の分岐はありません。それは、別の決定点につながる一方通行のようなものです。
したがって、独立した決定点 (初期点、条件 1 (真または偽)、条件 2 (真または偽)) のみをカウントします。

決定点は3 つありますが、開始点のため 1を追加するのが循環複雑度を計算する一般的な方法であるため、最終的な数値は 3 + 1 = 4になります。

覚えて：

循環的複雑度が高いことは必ずしもコードが悪いということを意味するわけではありませんが、より多くのテストシナリオを考慮する必要がある可能性があることを示しています。
複雑度が 4であるため、このコードスニペットはそれほど複雑ではありませんが、決定の数と条件の入れ子が増加するにつれて、循環的な複雑さとテストの労力が大幅に増加します。

3. コード図の制限

コード図には、コミュニケーションとコラボレーションを改善し、効率と集中力を高めるという利点がありますが、テスターは次の点にも注意する必要があります。

1 要素を実行できません

コメントと宣言を無視する:コード図は主に、実行可能ステートメントで表されるプログラム内の制御の流れに焦点を当てています。コメントやデータ宣言などの実行不可能な要素は、コードの実行に直接影響しないため、通常は無視されます。
誤解の可能性:これらの要素を省略すると図が簡略化されますが、誤解が生じる可能性があります。テスターは、データの初期化、ロジックコメント、またはその他の実行不可能なコードセクションに関連する潜在的な問題を見落とさないように、これらの無視された要素を認識し、テスト中にそれらの要素が考慮されていることを確認する必要があります。

2 パスの実現可能性を区別する

意味のあるパスを特定する際の課題:コードグラフ内のすべてのパスが、有効または意味のある実行シーケンスを表すわけではありません。特定のパスは、グラフ構造に応じて技術的に実現可能 (トポロジー的に実現可能) ですが、プログラムロジックのコンテキストでは非論理的または無意味 (意味的に実現不可能) です。
テストの労力の増加:実行可能なテストパスを特定して優先順位を付けるのは困難な場合があり、テスターの追加の労力が必要になります。有効なパスと無効なパスを区別するためにプログラムロジックとコンテキストを分析する必要があるため、テストケースの設計と実行時間が追加になる可能性があります。

3 これらの制限を緩和する

他のテスト手法と組み合わせる:コードダイアグラムは、コードレビューやデータフロー分析などの他のテスト手法と組み合わせると最も効果的に機能します。これらの手法は、実行不可能な要素とその潜在的な影響を特定するのに役立つと同時に、プログラムのロジックを理解してパスの実現可能性をより適切に評価するのにも役立ちます。
クリティカルパスに焦点を当てる:テスターは、コードグラフ内の高リスクパスまたはクリティカルパスのテストを優先できます。これには、ループ条件、予想されるユーザー入力、潜在的なエラーシナリオなどの要素を考慮して、テストに最も大きな影響を与えるパスを決定することが含まれます。

これらの制限を理解し、回避することで、テスターはコードグラフを効果的に利用できます。包括的で効率的なテストは、その固有の制限と他のテスト方法と組み合わせる必要性を認識しながら実施できます。

4.最後に書く

ZenTao ソフトウェアチームが独自に開発したエンタープライズIMソフトウェアには、チャットとコラボレーションを有機的に組み合わせたオープンソースアプリケーションdraw.oiが統合されています。この記事のコード図はすべてこの機能を使用して完成します。コード図を利用することで、ソフトウェアテスターはプログラムロジックをより深く理解できます。より効果的なテストケースを設計し、高品質のソフトウェアの提供に貢献できます。

うるさい

ソフトウェアの状況が進化し続けるにつれて、コード図はアプリケーションの信頼性と堅牢性を確保するための重要なツールであり続けることを認めざるを得ません。

※参考： Code Graphs: A Guide for Testers by Stelios Maniooudakis