品質を維持するためのPL/SQL基本ブロック・カバレッジの使用

16 品質を維持するためのPL/SQL基本ブロック・カバレッジの使用

PL/SQL基本ブロック・カバレッジのインタフェースを使用して、テストがコードをどれだけ適切にテストするかを評価することで、品質、予測可能性および整合性が保証されます。

コード・カバレッジの測定テストは、通常テスト環境で実行され、本番データベースでは実行されません。目的は、複数のPL/SQLコード・リリースのライフサイクルにおいて回帰テスト・スイートの品質を維持して改善することです。PL/SQLコード・カバレッジは、次に示す疑問に答えを出す上で役立ちます。

テスト・スイート開発は新しいコードの開発に追いついていますか。
テストはさらに必要ですか。

PL/SQLの基本ブロック・カバレッジ・インタフェースは、テスト実行時に実行されるPL/SQLユニットのカバレッジ・データを収集します。

トピック:

PL/SQL基本ブロック・カバレッジの概要

DBMS_PLSQL_CODE_COVERAGEパッケージは、基本ブロック・レベルでデータを収集できるようにします。PL/SQL開発者およびテスト・エンジニアはコード・カバレッジのテスト結果を標準品質保証メトリックの一部として使用します。

コード・カバレッジは、自動テストによってカバーされるコードの割合の尺度です。コード・カバレッジの高いプログラムでは、コード・カバレッジの低いプログラムよりバグ保有の可能性が下がります。最も重要なのは、テスト・スイートによって実行される基本ブロックの割合です。基本ブロックはブランチのないコードの線形セグメントです。基本ブロックには、単一のエントリ・ポイント(基本ブロック内にコードがない場合はジャンプ命令の宛先です)および単一の終了ポイント(最後の命令のみ、または例外で、実行のポイントを異なる基本ブロックに移動できます)があります。基本ブロックの境界は、コードを目で見て調査しても予想できません。コンパイラは、実行時に実行されるブロックを生成します。

ユニット・レベルのカバレッジ情報は、基本ブロック・レベルでカバレッジを収集することで正確に導出できます。ユーティリティを生成して、テスト・カバレッジの結果をレポートおよび視覚化できます。また、コードがテストでカバーされているか、部分的にカバーされているか、カバーされていないかを判別するために役立ちます。

基本ブロックを練習するためにテスト・ケースを書くことが常に可能なわけではありません。これらのブロックは、COVERAGEプラグマを使用してマーク付けすることにより、カバレッジ計算から除外できます。ソースコードは、単一の基本ブロックまたは基本ブロックの範囲のいずれかで、カバレッジが不可であるとマーク付けされる可能性があります。

PL/SQLコード・カバレッジ・データの収集

この例は、DBMS_PLSQL_CODE_COVERAGEパッケージを使用したPL/SQL基本ブロック・コード・カバレッジ・データを収集して分析する、基本的なステップを示します。

デフォルトでは、すべてのユニットのカバレッジ・データ(ラップされたユニットを除く)が収集されます。

次のステップを実行して、DBMS_PLSQL_CODE_COVERAGEパッケージを使用したPL/SQL基本ブロック・コード・カバレッジ・データを収集し、分析します。

プロシージャCREATE_COVERAGE_TABLESを実行し、パッケージに必要な表を作成して、カバレッジ・データを格納します。このステップはセットアップの一環として一度のみ実行する必要があります。
EXECUTE DBMS_PLSQL_CODE_COVERAGE.CREATE_COVERAGE_TABLES;

カバレッジ実行を起動します。

DECLARE    testsuite_run NUMBER;
BEGIN
   testsuite_run :=  DBMS_PLSQL_CODE_COVERAGE.START_COVERAGE(RUN_COMMENT => ’Test Suite ABC’);
END;
/

テストを実行します。
カバレッジの収集を停止して、データを収集表に書き込みます。
EXECUTE DBMS_PLSQL_CODE_COVERAGE.STOP_COVERAGE;
カバレッジ表を問合せ、結果を調査します。

PL/SQLコード・カバレッジ表の説明

次の表はPLSQL_CODE_COVERAGE.CREATE_COVERAGE_TABLESプロシージャによって作成され、コード・カバレッジ・データを収集します。

DBMSPCC_RUNS表には、DBMS_PLSQL_CODE_COVERAGE.START_COVERAGE関数の実行ごとに1つの行が含まれています。主キーは RUN_ID。

表16-1 DBMSPCC_RUNS表の列

列名	列データ型	説明:
`RUN_ID`	`NUMBER(38)`	`DBMS_PLSQL_CODE_COVERAGE.START_COVERAGE`のこの実行で自動的に生成された一意の識別子
`RUN_COMMENT`	`VARCHAR2(4000)`	実行を判断するユーザーのコメント
`RUN_OWNER`	`VARCHAR2(128)`	実行を開始したユーザー。
`RUN_TIMESTAMP`	`DATE`	実行が開始される日時のタイムスタンプ。

DBMSPCC_UNITS表には、実行時に実行されるPL/SQLユニット情報が含まれています。主キーはRUN_IDとOBJECT_IDです。OBJECT_IDとLAST_DDL_TIMEにより、静的データ・ディクショナリ・ビューALL_OBJECTSの内のオブジェクトLAST_DDL_TIMEと比較することで実行が開始された後にユニットが変更されたかどうかを判断できます。

表16-2 DBMSPCC_UNITS表の列

列名	列データ型	説明:
`RUN_ID`	`NUMBER`	`DBMSPCC_RUNS`表の`RUN_ID`列を参照します。
`OBJECT_ID`	`NUMBER`	ユニットの一意の識別子。
`OWNER`	`VARCHAR2(128)`	ユニットの所有者。
`NAME`	`VARCHAR2(128)`	ユニット名
`TYPE`	`VARCHAR2(12)`	ユニット・タイプ
`LAST_DDL_TIME`	`DATE`	実行時に取得されたDDL文で生じたユニットに対する変更の最新日時のタイムスタンプ。

DBMSPCC_BLOCKS表は、ユニット内のすべてのブロックを識別します。ブロックの場所は、ソースコード(LINE, COL)内の開始位置によって示されます。主キーはRUN_ID、OBJECT_IDおよびBLOCKです。1つのブロックは、暗黙的に次の文字の開始位置の直前の文字位置で終了します。同じ場所で複数のブロックを開始できます。実行の開始後にユニットが変更されていない場合は、静的データ・ディクショナリ・ビューALL_SOURCEからソース・コードの行を抽出できます。

表16-3 DBMSPCC_BLOCKS表の列

列名	列データ型	説明:
`RUN_ID`	`NUMBER(38)`	`DBMSPCC_UNITS`表の`RUN_ID`列を参照します。
`OBJECT_ID`	`NUMBER(38)`	`DBMSPCC_UNITS`表の`OBJECT_ID`列を参照します。
`BLOCK`	`NUMBER(38)`	基本ブロックの番号
`LINE`	`NUMBER(38)`	基本ブロックの先頭行の番号
`COL`	`NUMBER(38)`	基本ブロックの先頭列の番号
`COVERED`	`NUMBER(1)`	基本ブロックがカバーされている場合は1、それ以外の場合は0に設定します
`NOT_FEASIBLE`	`NUMBER(1)`	基本ブロックがNOT_FEASIBLEとしてマーク付けされている場合は1、それ以外の場合は0に設定します