demoプロジェクトのソースコードのメトリクスを計測し、レポートを生成します。生成されたレポートを参照し、メトリクスを確認します。
ここでは、メトリクスの計測のために「builtin://Metrics」テストコンフィギュレーションを使用します。
・準備
Gradleを使用する場合、メトリクスの計測のための準備は特に必要ありません。
・静的解析の実行
1. demoプロジェクトディレクトリに移動します。
>cd %JTEST_HOME%\examples\demo |
2.Gradleを起動し、Jtest DTPによる静的解析を実行します。次のコマンドを実行します。
>gradle jtest -Djtest.config="builtin://Critical Rules" |
3.実行が終了すると、%JTEST_HOME%\examples\demo\build\reports\jtestディレクトリにレポートが生成されます。
(report.html, report.xml) が生成されます。
Jtest がDTP Serverに接続するように設定されている場合、Jtest の解析結果をアップロードすることができます。
Jtest の解析結果をアップロードするには、Gradleの起動引数に「-Djtest.publish=true」を追加します。
・解析結果の確認
1.%JTEST_HOME%\examples\demo\build\reports\jtestディレクトリに生成されたhtmlを開きます。
2.「すべての指摘事項 カテゴリごと」では静的解析ルールごとに検出された違反の件数を確認します。
3.「ファイルごとの指摘事項」では、プロジェクト、パッケージおよびファイルごとに検出された違反の件数や違反の詳細を確認します。
● コーディング規約チェックの結果
demo/src/main/java/examples/eval/Simple.javaの24行目で、map()メソッドのcase文においてcase 10ではなくcase10(空白なし)を使用していることが示されています。
これは単純な入力ミスですが、値として10が渡された時にクラスは不正な結果を生成します。
● フロー解析の結果
demo/src/main/java/examples/flowanalysis/AlwaysCloseGSS.java の 29 行目で「”context” は null の可能性がある」ことが示されています。レポートでは29 行目の指摘に至るまでのパスとして以下の流れを確認することが出来ます。
19 行目: “context” に null 値の代入
21 行目: GSSException がスローされる
25,26 行目: 例外処理
29 行目: null 値の “context” に対して context.dispose() の呼出しでNullPointerException が発生する可能性がある
4.「アクティブなルール」では、コーディング規約のチェックに使用されたコーディングルールを確認します。
5.「テスト パラメーター」では、Jtest 実行オプションを確認できます。