Java ソースコードの CDI(Code Inspection) ツールの開発〜コードインスペクションツールに対するテストプロセスの改善〜
M2008MM024 二宮剛史
指導教員：野呂昌満

はじめに本研究のメタ技術は CDI ツールの開発および，テストデータ作成カタログの作成に用いた PLSE である．
ソフトウェアを実行しないで検証する静的検証の 1 つ
ベース技術は，ソフトウェアテスト方法 [1]，プログラとしてインスペクションがある．プログラムコードに対ム解析技術である．
するインスペクションをコードインスペクションと呼ぶ．
専用手法は CDI ツールに対するテストプロセスの改善
我々の OJL(On the Job Learning) では，これまでのである．
OJL で開発されたコードインスペクションツール [3, 4](以下，CDI ツール) を引き継ぎ，開発した．CDI ツールの 2 関連技術
開発は，プロダクトラインソフトウェアエンジニアリン
2.1 PLSE
グ [2](以下，PLSE) に基づきおこなわれた．開発を通して生み出された核資産は，アーキテクチャ，抽象構文木， PLSE とは系統的に再利用をおこない，ソフトウェアをフローグラフ，検査項目の開発プロセスなどである．我々 開発する方法論である．
PLSE は 3 つの活動によって構成される．3 つの活動をの開発では CDI ツールに対して機能の改善および品質の図 1 に示す．
向上をおこなった．

1

CDI ツールの各検査項目に対するテストでは，入力となるテストデータはソースコードである．ソースコードが抽象構文木や制御フロー，データフローに変換され，そのツリー表現やグラフ表現をもとに検査がおこなわれる．
テスト担当者は，テスト対象の検査の仕様をもとに様々なツリー表現やグラフ表現となるソースコードを多数作成する必要がある．
図 1 PLSE の 3 つの活動
CDI ツールの開発は PLSE に基づきおこなわれている
ので，開発時に作成されたテストデータやテストデータPLSE では核資産をもとに部品を組み合わせて製品開の作成からテストの実施までのテストプロセスも核資産 発をおこなう．
である．検査項目は，抽象構文木や制御フロー，データフ
核資産開発は，開発の成果である要求分析の結果やアーローを利用して検査をおこなうので，テストデータとな キテクチャなど，製品系列で再利用可能な部品を構築するソースコードは抽象構文木の構文要素や，制御フロー， る活動である．製品開発は，核資産を利用して実際の製データフローについて考慮し，これらを組み合わせて作 品を開発する活動である．管理は，核資産開発や製品開成する必要がある．組み合わせの数が多数存在すること 発の活動をどのようにおこなっていくかを決定する活動
から，テストデータ作成に労力が掛かる．本研究では，核 である．
資産の品質向上を目的として，テストプロセスの改善を3 つの活動がお互いに関連しながらソフトウェアの開発おこなった．
がおこなわれる．
テストプロセスを改善することで，テストデータ作成に
2.2 ソフトウェアテスト方法掛かる労力の削減をおこない，テストデータの生産性をソフトウェアテストはソフトウェアに求められる要求向上させる．テストデータ作成の労力削減やテストデーに対する動作や機能の保証が目的でおこなわれる．テスタの生産性を向上させる目的で，テストデータ作成方法を定義した．今まで作成してきたテストデータからテス ト対象やテストをおこなう目的により，実施するテストトデータとなるソースコードの固定部分と変動部分を整 の種類 (単体テストやシステムテストなど)，テスト方法
理し，変動部分の変更方法をテストデータ作成方法のカ (ホワイトボックステスト，ブラックボックステストなど)タログとして一覧化をおこなった．テストデータ作成カ を選択する．テスト設計において，ソフトウェアの特徴
タログとは，検査項目の仕様をテストデータ用にカスタ を把握し，適切なテスト方法を選択することでソフトウェマイズするために，テストデータとなるソースコードを アの品質保証をおこなう．
テストは要求に対する保証と欠陥の検出が目的である．
作成するために必要とする着目対象，分類，詳細な内容
ソフトウェアに欠陥が含まれていないことを保証するこを一覧化したものである．テストデータ作成方法のカタログを作成し，テストデータ作成カタログを用いたテス とは出来ないが，欠陥を検出することで欠陥が存在するトプロセスを構築することでテストプロセスの改善をお ことを示すことが出来る．ソフトウェアテストでは，テストケースの数を削減しながら効率的に欠陥を検出するこなった．
ことが求められる．

3

CDI ツールに対するテスト

3.1

現在おこなわれているテスト方法

現在のテストプロセスでは，CDI ツールの検査項目に対するテスト方法はブラックボックステストが実施されている．図 2 にテストデータとなるソースコード作成において，テストデータ作成者が考慮している要素を示す．
図 3 テストデータ例 1

図 4 テストデータ例 2

null 以外の値を代入した後に，変数 s を使用した場合のテストデータである．
図 4 では，テストデータ例 1 の場合に制御フローを追加し，オブジェクト変数 s のデータフロー上で null 値が格納されているときに変数 s を使用するという関係を表現したテストデータである．

4

テストデータ作成カタログ

テストデータ作成カタログとは，検査項目の仕様をテストデータ用にカスタマイズするために，テストデータテスト対象である検査項目は，抽象構文木や制御フロー， となるソースコードを作成するために必要とする着目対データフローを利用して検査をおこなう．テストでは， 象，分類，詳細な内容を一覧化したものである．
CDI ツールにテストデータとなるソースコードを入力し， テストデータ作成には，今までの開発の中で作成してCDI ツールから出力される検査結果が期待する結果と同 きたテストデータからテストデータをどのような基準でじ結果となるかどうかを確認する．期待する結果とは，欠 作成したら良いかまとめたテストデータ作成カタログを陥の可能性がある箇所が検出される，または検出されな 作成することで，労力の削減が見込める．
い結果のことである．
我々は今までの開発を通して幾つものテストデータを
検査項目はソースコードを表現する抽象構文木や制御 作成してきた．テスト対象の検査項目の仕様から直接テフロー，データフローの情報を組み合わせて，欠陥の可 ストデータを自動生成することは難しいが，今までのテ能性がある箇所を発見することから，検査項目のテスト ストデータ作成経験を整理，一覧化することで，新たなに用いるソースコードは，検査項目の仕様から考慮され テストデータ作成時に役立てることが出来る．
る構文要素全てや制御フロー，データフローを組み合わ今までに作成されたテストデータ群をテストデータとせて作成される．
して変動していく部分に着目して整理することで，テストデータ作成カタログに記載する情報を一覧化する．テ
3.2 テストデータ作成における問題点
ストデータ作成カタログには着目対象，分類，詳細を記
検査項目に対するテストのテストデータ作成における載する．着目対象には追加，変更する対象を記述する．分
問題は，構文要素や制御フロー，データフローを組み合類には，制御フロー，データフロー，型検査のどれに属わせることで，多数のテストデータを一から作成する点するのかを記述する．詳細には，拡張方法の実現例を記である．CDI ツールの検査項目に対するテストデータは述する．テストデータ作成カタログの例を図 5 に示す．
ソースコードである．ソースコード上には構文要素や制御構造，データの流れが表現されている．テスト担当者
はテストデータを作成する際に，ソースコード上で制御フローを考え，その制御フローにおいて変数の定義や使用といったデータフローを考える必要がある．さらに，制御フロー上に出てくる構文要素についても考える必要がある．これらの情報が組み合わさってテストデータとなるソースコード群を作成するので，テスト担当者の労力が大きい．作成したテストデータはテスト対象の検査に特化したものになっており，他の検査のテストデータとして再利用することは難しく，検査ごとにテストデータ
図 5 テストデータ作成カタログの例を作成する必要がある点も労力が大きい原因である．
テストデータは構文規則や制御フロー，データフロー
オブジェクト変数に null 値が格納されている場合にオを考慮して作成するので，テストデータ作成カタログにブジェクト変数を参照していないか調べる検査についてはこの 3 つのうちのどれについての作成方法なのかといのテストデータ例を図 3，図 4 に示す．
図 3 では，オブジェクト変数 s について，変数 s の値に う情報が必要になる．新しいテストデータとなるソース
図 2 ブラックボックステストにおけるテストデータ作成

コードは，既にテストデータとして作成したソースコードに記述されている文や式が変化したものなので，文に着目した作成方法なのか，式に着目した作成方法なのかという情報も必要である．
カタログを用いたテストデータの自動生成かは，ソースコードの意味だけでなく，検査項目の仕様まで考慮しなければいけない．よって，制御フローやデータフローに関するテストデータ作成方法は，テスト対象に取って意味のあるテストデータの自動生成が不可能であると考える．

カタログ化したテストデータ作成方法のうち，テスト 5 テストプロセスの再構築
データの自動生成が可能なテストデータ作成方法と不可
テストデータ作成カタログを用いたテストプロセスを能なテストデータ作成方法を分類する．
現在のテストプロセスをもとに構築した．
テストデータとなるソースコードの自動生成は，生成す新しいテストプロセスを図 7 に示す．
るソースコードの雛形となるソースコード，雛形のソースコードの変更箇所，変更後のソースコード片が揃っていれば可能である．雛形となるソースコード内の記述のうち，変更する記述を指定し，別の記述に置き換えることで新たなソースコードを作成することができる．テス
トデータ作成カタログにはテストデータの拡張方法が記載されている．テストデータ作成カタログに記載されている情報を元にすることで，テストデータとなるソースコードの自動生成が可能なテストデータ作成方法がある．
図 6 に自動生成可能なテストデータ作成方法と不可能なテストデータ作成方法の例を示す．

図 7 新しいテストプロセス

図 6 自動生成が可能なテストデータ作成方法と不可能なテストデータ作成方法の例

テストデータの作成は，テスト対象の CDI ツールの検査項目の仕様からテストデータの雛形を作成し，その雛形をテストデータ作成カタログを用いて変更していくことで様々なテストデータを作成する．改善前のテストプロセスとの違いは，テストデータ作成カタログを参照しながら，テストデータを作成する部分とテストデータ作成カタログを更新する部分が追加されたことである．テ
ストデータ作成においてカタログを参照しながらテストデータを作成することで，テスト担当者個人以外が考えたテストデータの変更方法をテストデータ作成に応用出来る．

自動生成可能なテストデータ作成方法は，拡張するソースコードに既に記述されている構文要素を別の構文要素に変更していく作成方法である．例えば，オブジェクト変数の参照として，オブジェクト変数に格納される値の参照やオブジェクト変数に対するフィールドアクセス，メソッド呼び出しがある．新しいテストデータは，テストデータとなるソースコードの雛形を元にして作成される．
6 考察
この雛形となるソースコードにオブジェクト変数の参照の記述があれば，別のオブジェクト変数の参照方法へと 6.1 構築したテストプロセスの有用性の考察構築したテストデータ作成カタログを用いたテストプ変換することが出来る．
自動生成不可能なテストデータ作成方法は，制御フロー ロセスの妥当性を確認するために，検査項目の仕様が変やデータフローに関する作成方法である．開発対象の CDI 更された場合に，テストデータ作成カタログを用いたテツールでは，制御フローやデータフローはフローのノー ストプロセスの有用性について考察した．我々の OJL でドが文単位で扱われているので，文を変更箇所として指 は CDI ツールの機能の改善をおこなっているので，新し定し，他の制御フローやデータフローに置き換えることで い検査項目の追加だけでなく，既存の検査項目の修正も入力となったソースコードの制御フローやデータフロー おこなわれる．既存の検査項目の修正では，既存の検査とは異なる制御フロー，データフローが作成できる．し 項目に対して追加される仕様が存在する．
テストデータ作成カタログとして，テストデータの作成
かし，作成できた制御フローやデータフローがテスト対象である検査項目にとって，有効なテストデータとなる 方法を整理してあるので，検査項目の仕様が変更された

検査項目に対してのテストデータ作成がおこないやすい． る必要がある．字句解析器や構文解析器モジュールに対
図 8 に仕様が変更された検査項目に対するテストデータ するテストデータ作成カタログを用いたテストプロセス作成の手順を示す．
を図 9 に示す．

図 8 仕様が変更された検査項目のテストデータ作成

図 9 字句解析器や構文解析器モジュールに対するテストデータ作成テストプロセス

仕様が変更された検査項目から，追加や変更された検査の仕様が制御フロー，データフロー，型検査のどれに入力となるテストデータの作成に，テストデータとして関するものなのか，文または式に関するものなのか判断 どのようなソースコードを作成したらよいかという指針することで必要とするテストデータの作成方針が決まる． として，テストデータ作成カタログを用いることで，網作成方針が決まった後は，テストデータ作成カタログに記 羅的に作成する必要があるテストデータの作成が効率的載されているテストデータの拡張方法で，既存のテスト におこなえる．
データであるソースコードや新たに作成したテストデー
よって，他の言語処理系へもテストデータ作成カタロタの雛形として作成したソースコードを拡張していくだ グを用いたテストプロセスの適用可能性がある．
けで，テストに必要なテストデータが作成できる．テスト
7 おわりに対象である検査の仕様に変更があった場合にも，テスト本研究は，CDI ツールの開発に対するテストプロセスデータの作成がおこないやすいので，テストデータ作成の改善をおこなった．テストプロセスの改善では，テスカタログを用いたテストプロセスは有用であると言える．
トデータ作成カタログを用いたテストプロセスを構築し6.2 他のドメインへのテストデータ作成カタログを用た．構築したテストプロセスに対しての妥当性の考察といたテストプロセスの適用可能性の考察
他のドメインへのテストデータ作成カタログを用いたテ
構築したテストプロセスの他のドメインへの適用可能 ストプロセスの適用可能性について考察をおこなった．
性を考察した．
本研究のメタ技術は CDI ツールの開発および，テストCDI ツールの入力となるデータの特徴として，ツール データ作成カタログの作成に用いた PLSE である．
への入力データがプログラミング言語で記述されたソーベース技術はテストデータ作成のために必要とするプスコードである点があげられる．同じ意味を持つソース ログラム解析技術，テストプロセス構築のために必要なコードの表現方法が無数に存在することから，テストデー ソフトウェアテスト方法である．
タとなるソースコードの作成方法を一覧化したカタログを用いたテストプロセスが CDI ツールには有効である． 参考文献
他の言語処理系として，コンパイラを例として考える． [1] B. Boris, Software Testing Techniques, Second Ediコンパイラは，ある規則に従って記述された文字列 (あるtion, Van Nortrand Reinhold, 1990.
言語で記述されたソースコード) を入力として，字句解 [2] L. M. Northrop,
SEI s Software Product Line析，構文解析処理をおこなう．構文解析処理をおこなっ
Tenets, IEEE Software, vol.19, no.4, pp. 32-40,た後に中間系を生成し，中間系をもとにして別の規則に2002.
従って記述された文字列 (入力されたソースコードの記[3] 後藤洋， Java ソースコードの CDI(Code Inspection)
述に使用された言語とは異なる言語で記述されたソースの開発 〜アーキテクチャの構築〜， 南山大学大学院
コード) を出力する．
数理情報研究科 2008 年度 修士論文要旨集，pp.130コンパイラに対するテストでは，字句解析器や構文解析133，March 2009．
器といったコンパイラを構成するモジュールに対するテストがある．字句解析器や構文解析器といったモジュール [4] 立枩将輝， Java ソースコードの CDI(Code Inspection) の開発 〜フローグラフとその処理の設計実現の動作をテストするには，実際にソースコードを入力し〜， 南山大学大学院 数理情報研究科 2008 年度 修て確認する必要がある．入力となるソースコードは，字士論文要旨集，pp.144-147，March 2009.
句解析器や構文解析器で扱うべき要素を網羅して作成す