Web サイド PHP コード関数カバレッジテストソリューション_PHP チュートリアル-PHPチュートリアル-php.cn

WebサイドのPHPコード関数カバレッジテストソリューション

1. コードカバレッジについて

コードカバレッジの測定には、行カバレッジ、関数/メソッドカバレッジ、クラスカバレッジ、ブランチカバレッジなど、さまざまなレベルがあります。コードカバレッジは、テストの品質を測定するための重要な基準でもあります。ブラックボックステストの場合、テストケースがシステム内のコードのすべての行を実際に実行したかどうかがわからない場合は、常にテストの整合性を無視する必要があります。。したがって、業界には、ほぼすべてのプログラミング言語に対して独自のコードカバレッジソリューションセットがあります。世界で最も美しい言語である PHP も例外ではありません。 PHPUnit と Spike PHPCoverage は、xdebug に基づいたコードカバレッジテストソリューションのセットを提供します。この記事では、私が遭遇した特定のビジネスシナリオに基づいて、PHP コード関数カバレッジテストのための私独自のソリューションについて説明します。

2. 事業背景

オンラインで Web サイトを開発し、それを機能テストのためにビジネステストの同僚に引き渡すとします。では、どうやってテストしたのでしょうか?通常、開発者が Web サイトを展開し、その後テスターが異常な使用状況を含むすべてのオンライン機能を試します。ビジネステストの場合、すべての機能ポイントをテストし、異常な使用状況をすべて検出できれば完了です。しかし、開発に関しては、私が書いたすべてのコードが実行されたかどうかのほうが気になります。非常に特殊な状況でのみトリガーできるコードがあり、そのような状況を測定したことがないのでしょうか?この時点で、コードカバレッジが役立つ必要がある場合があります。

実際、私は最初にカバレッジをテストするために xdebug を考えましたが、これには次のように 2 つまたは 3 つの関数しか必要としません:

xdebug_start_code_coverage(); // コード行カバレッジの収集を開始します

xdebug_get_code_coverage(); //これまでに実行されたコードファイル名と行番号を取得します

xdebug_stop_code_coverage(); // コード行カバレッジの収集を停止します

xdebug が提供するインターフェイスは、ラインカバレッジをテストするために使用できます。これは要件を満たしていますか?実際、行カバレッジの粒度は、実際のプロジェクトでは、開発者がコードを微調整する可能性があります。たとえば、このテストでは A.php ファイルの 10 行目までを実行しましたが、ある日、A.php を微調整して、A.php の 9 行目と 10 行目にさらに 2 行のコードを追加しました。その結果、元の10行目は12行目になってしまい、xdebugの行カバレッジ情報には行番号しか記録されていませんでした…前のデータは不正確ではないでしょうか？。。慎重に検討した結果、機能範囲は適切な粒度であると思います。比較的成熟したプロジェクトでは、大規模な機能変更が行われることはほとんどありません。しかし、問題は、xdebug が関数カバレッジのためのインターフェイスを提供していないことです。

それで、私たちが今遭遇しているシーンは次のとおりです:

1] 特定のテストでカバーされているすべての機能のリストを測定し、このプロジェクトにいくつの機能があるかを知り、カバー率が十分に高いかどうかを計算したいと考えています。

2】テストが完了したら、コードカバレッジを視覚化するためにカバレッジレポートを生成する必要があります。

3】完全なテストプロセスは次のとおりです:

インストルメンテーションとは、テスト実行前の準備作業を意味します。

3. 機能カバレッジソリューション

1) 原則

xdebug は本質的にラインカバレッジのサポートを提供するため、関数カバレッジを自分で計算する必要があります。関数カバレッジには 2 つのデータが必要です。1 つは実行される関数、もう 1 つはファイル内の関数の総数です。

ファイル内の関数の総数。すべての関数を実行することは不可能であるため、この部分はコードの静的スキャンによってのみ実現できます。 C++ や Java の場合は、字句解析ツールが必要になるかもしれませんが、最も美しい言語である PHP の前では、それほど複雑なことはまったく必要ありません。 PHP 4.3 以降、PHP Zend Engine には、開発者がソースコードの字句解析を実行できるようにするトークナイザー機能が組み込まれています。 PHP で関数を定義するときに、対応する字句規則を見つけるだけでよく、指定された PHP ファイル内のすべての関数を簡単に取得できます。

トークナイザーによって定義されたインターフェースも非常にシンプルです:

配列 token_get_all (string $source)

この関数はファイル解析を実行し、PHP ソースコードをトークンで構成される配列に分割します。

文字列 token_name (int $token)

整数形式のトークンを文字列形式に変換します。 C言語のstrerror関数に似ています。トークナイザーを使用すると、PHP 関数で定義されたルールと形式に従って有限状態マシンを設計し、すべての関数の分析を完了できます。コードのこの部分の比較的単純なバージョンを作成し、参照用に別に取り出しました: PHPFunctionParser

関数カバレッジを見つける際のもう 1 つの困難は、実行された関数のリストを取得することです。この場所は私たちをいくつかの回り道に連れて行きました。最初の最も単純な方法は、xdebug を通じて実行された行を取得するので、行番号を使用してこの行がどの関数に属しているかを推測することです。ただし、1 回のリクエストで取得する行番号情報は非常に多く、1,000 行のリクエストを実行すると 1,000 回の判定が行われることになり、効率が悪くなります。調べてみると、xdebugにはリクエスト内の関数呼び出し関係を取得できる関数トレース機能が用意されていることが分かりましたが、関数名は取得できただけで、それが置かれているファイルは取得できませんでした。そこで、再度調べた結果、メソッド名とクラス名があれば、それがどのファイルに定義されているかが推測できることが分かりました。そこで、関数トレースを使用して関数の呼び出し関係を一時ファイルに一時的に保存し、そのファイルを解析して実行された関数名を取得します (クラスメソッドの場合、「クラス名::関数名」の形式になります)。 ) を使用して、リフレクションメカニズムを使用します。この関数を定義するファイルをエクスポートするだけです。世界で一番美しい言語の力を改めて実感しました。

2) 計測

利用の敷居を下げるために、PHPのソースコードの変更は最小限に抑えます。 xdebug の情報収集の原理は、xdebug_start_code_coverage と xdebug_stop_code_coverage をそれぞれ呼び出してカバレッジ情報収集の開始と終了を制御することであるため、ソースコードの変更は避けられません。ここでの解決策は、PHP プログラムが終了する前に実行する必要があるプログラム (C 言語の atexit 関数と同様) として register_shutdown_function を介して xdebug_stop_code_coverage を登録し、それをファイルにカプセル化し、ソースの最初の行でこのファイルを要求することです。コードそれです。 PHP フレームワークが CodeIgniter のようなフレームワークで、すべてのリクエストに統一されたエントリ Index.php がある場合、この 1 つのファイルを変更するだけで済み、ソースコードも 1 行変更するだけです。実際、基本的に現在のすべての PHP フレームワークは、すべてのリクエストのエントリポイントとしてindex.php ファイルを使用します。

ソースコードに加えた唯一の変更は、エントリファイルindex.phpの最初の行に次の文を追加することでした。リーリー

phpcoverage.php のコアコードロジックはおおよそ次のとおりです:

リーリー

3) 情報ストレージ

関数カバレッジテストのアイデアとして、xdebug の関数トレースを使用して、リクエスト内のすべての関数の呼び出し関係を取得し、実行された関数をすべて取得してファイルに出力し、実行された関数名とファイルを介して関数名を取得します。解析とリフレクションが行われるファイル。この情報をデータベースまたはファイルに保存するだけです。

以前 Spike を試したとき、情報は XML 形式でファイルに保存されており、データの冗長性が非常に高いことがわかりました。その結果、いくつかのテストの後、ファイルはすでに非常に大きくなっていました。これは明らかに私たちが見たいものではありません。そのため、データを保存する際には、データを直接 json 形式でシリアル化し、文字列形式でファイルに保存することで、ファイルサイズを大幅に削減します。同時に、リクエスト元のIPと日付を区切りとして、異なるファイルを別々に保存します。これにより、各マシンからの毎日のリクエストデータが一目でわかるようになり、「精度」がさらに向上し、テスターの各リクエストを正確に監視できます。下の写真は、ビジネス実務で収集したいくつかのデータファイルのスクリーンショットです:

このようにして、任意の IP からのすべての Web リクエスト、それがカバーする行と機能情報がファイルに記録されます。一般的なプロジェクトのテストでは、少数のテスターだけがそれを使用しているため、パフォーマンスの問題を考慮する必要はありません。

4. レポートの生成

カバレッジデータの生成原理は上で説明しましたが、これまでに取得したのはデータファイルだけです。それらを完全なレポートにまとめるにはどうすればよいでしょうか。そのためには、生成されたデータファイルを解析するためのスクリプトを自分で記述する必要があります。私たちのアプローチは、オープンソースツールのスパイク phpcoverage のテンプレートから教訓を引き出し、独自のコードロジック、特にこのツールにはない関数カバレッジ統計を追加することです。私たちがテストした Web ページによって生成されたレポートは次のとおりです:

画像では、各ファイルの行カバレッジ、関数カバレッジ、および合計カバレッジ統計を確認できます。より正確なデータが必要な場合は、ファイルのリンクをクリックして、どのコード行がカバーされているかを確認できます (青はカバーされていることを意味し、赤はカバーされていないことを意味します):

5. 概要

ビジネステストでWebテストを行う場合、コードカバレッジはテスト品質の重要な指標です。テストの実行後に、コードのどの行が実行され、どの行が実行されなかったのかを正確に確認できるように、この方法を使用したいと考えています。テストケースが実行されなかった原因を分析し、テストケースを改善します。このツールを使用するプロセスも非常に簡単です。インストルメンテーション => テスト => データの収集 => レポートの作成です。また、このソリューションはビジネスコードへの影響を最小限に抑え、コードを 1 行変更するだけで済みます。途中で問題が発生しても、すぐにコードを元の状態に戻すことができます。テストを安心して行うことができ、開発も安心して行えます。

ただし、最後に強調しなければならないのは、すべてのコードをカバーしてもテストが完了したことを意味するわけではないということです。しかし、それがカバーされていない場合、それは不完全でなければなりません。したがって、このソリューションの最大の意義は、テスト中に欠落しているコードを発見し、問題を発見できることです。実際、これは新入社員がプロジェクトのコード構造全体を理解するのにも役立ちます。ブラウザー要求ごとにサーバー上のどのコードが実行されているかを明確に知ることができます。