情報処理学会論文誌

Vol.62 No.4 1019–1028 (Apr. 2021)

Java テストコードの再利用による自動生成に向けた移植可能なテストメソッドの調査
西浦 生成1,2,a),b)

水野 修1,c)

崔 恩瀞1,d)

受付日 2020年8月3日, 採録日 2021年1月12日

概要：ソフトウェアの品質を高く保つため，ソフトウェアテストがさかんに行われている．テストコードを用いた自動テストは，テスト実行の労力を軽減するが，テストコードの作成には労力が必要となる．既存のテストコード自動生成技術は，入力として何らかの文書を必要とするか，でなければ非常に単純な単体テストのみしか作成できない．一方，既存のテストコードを再利用することで，使用されていた実績があり人手で作られたものに近い高品質なテストコードを手軽に生成できる可能性がある．我々は新たなJava テストコード自動生成技術の開発に向け，その第 1 歩として，あるテストメソッドを実行可能性を保ちつつ自動的に移植する手法およびそれが可能となる条件を構想した．さらにオープンソースの Java プ
ロジェクトを調査し，テストコードの再利用元として使用できるリポジトリが 1,862 件存在することや，
大半のテストメソッドはテスト対象コードにたかだか 2 つの依存を持つこと，そうした依存関係を保つ移植によって本来必要なテストメソッドの平均 83%を生成できる可能性を実証的に示し，既存テストコードの再利用による自動生成手法が現実的かつ有益であることを示した．
キーワード：ソフトウェアテスト，リポジトリマイニング，ソースコード解析

An Investigation of Transplantable Test Methods toward AutomaticJava Test Codes Generation by Reusing Existing Test Codes
Kinari Nishiura1,2,a),b)

Osamu Mizuno1,c)Eunjong Choi1,d)Received: August 3, 2020, Accepted: January 12, 2021

Abstract: Software developers test their software products. Automated testing with test codes lightens theireﬀorts to test. However, writing appropriate test codes manually is diﬃcult and a time-consuming activity.
Several existing automatically create test codes techniques require to prepare some documents, otherwise,
they can create only very simple unit tests. Reusing existing test code may easily generate high-quality test
code. Toward the technique, we propose the transplantable condition for that a test method can keep its
feasibility after transplanting. We investigate open source Java projects in GitHub. As the results, we haveshown that there are available 1,862 repositories with test codes, and that most test methods have at most
2 dependencies on the code under test. We have empirically demonstrated the possibility that porting thatmaintains such dependencies can generate an average of 83% of the originally needed test methods. From
the results, an automatic generation method by reusing existing test code is realistic and useful.
Keywords: software testing, repositories mining, source code analysis

1
2

a)
b)
c)
d)

京都工芸繊維大学
Kyoto Institute of Technology, Kyoto 606–8585, Japan
産業技術総合研究所
National Institute of Advanced Industrial Science and Technology, Ikeda, Osaka 563–8577, Japank-nishiura@se.is.kit.ac.jp
k-nishiura@aist.go.jp
o-mizuno@kit.ac.jp
echoi@kit.ac.jp

c 2021 Information Processing Society of Japan

1. はじめにソフトウェアの品質を高く保つことは広く要求されている．そのため，リリース前にソフトウェアの不具合を検出することを目的としたソフトウェアテストが広く行われている．かつては手動による入力および出力の目視確認に

1019

情報処理学会論文誌

Vol.62 No.4 1019–1028 (Apr. 2021)

よってテストが行われていたが，この労力を軽減すべく，を含み，一定の品質基準をクリアした GitHub リポジ

自動的にテストを行うためのプログラムであるテストコー

トリは全体で 1,862 件存在した．これらは合計約 40 万ドが作成されるようになった [1]．テストコードには通常，ファイルのテストコードを含む．またドメインで分類

テスト対象プログラムへの入力あるいは操作とその期待出

すると，多いもので約 300 件のリポジトリが同ドメイ力が記述され，実際の出力と期待出力を照合することで，動作が正しく行われているかを確認できる．テストコードンに属している．

RQ2 テストメソッドは他の参照先にどれほど依存してを実行することで，テストを素早く繰り返し行うことがでいるか？

き，ソフトウェアテストの実行にともなうコストを軽減で

動機：テストメソッドが他の参照先，特にプロダクト

きる．

コードで定義された参照先にどれほど依存しているか

一方で，テストコードは基本的に手動で記述されるため，によって，その移植に要する条件は厳しくなる．こう

作成には相応の作業コストが要求される．この作業コスト

した依存の大きさの傾向を把握することで，移植可能は自動テスト導入への障害となるほか，開発者の過労働やであるために要求される条件の傾向を示す．

テストの作成不足による不具合発生を誘発する可能性があ

結果：テストメソッドは，その実行にともなってテスる．この問題に対し，テストコードの自動生成技術によるトのための補助的な呼び出しを平均 1.8 種類実行する緩和が期待されている．しかし，既存のテストコード自動ため，それらをともに移植する必要がある．また平均生成技術 [2], [3], [4] は入力として何らかのドキュメントを4.0 種類の呼び出しを通してプロダクトコードに依存必要とするか，でなければ非常に単純な単体テストのみししており，移植可能であるためにはそうした依存を移か作成できないという問題点を持つ．

植先でも保つ必要がある．

そこで，我々は新たに，既存のテストコードを再利用す

RQ3 既存のテストコードには，テスト対象への依存関係ることで Java テストコードの自動生成を行う手法を構想すが生成対象であるテストメソッドと共通するテストメ

る．既存のテストコードを再利用することで，過去に人手

ソッドはどれほど存在するか？

によって作られ使用されていた実績のある，高品質なテス

動機：特定のリポジトリをテストコードの移植先およトコードを手軽に生成できる可能性がある．本研究ではまび移植元とした場合に，移植先において本来必要となず，ある既存のテストメソッドを別のプロジェクトに 1 つるテストメソッドが，移植元における移植可能なテスのテストコードとして移植する方法を提案する．この方法

トメソッドにどれだけ含まれるかを把握することで，では，テストメソッドおよびそれに関連する部分コードを既存テストコードの移植によるテストコード生成手法

抽出し，テンプレートを埋める形で移植用のテストコードが達成できる効果の上限を示す．

を新しく作成した後，プロジェクト固有のプロダクトコー

結果：99 件の同ドメインの OSS からの移植を仮定しドにアクセスする識別子を移植先のプロダクトコードに由た場合，移植先リポジトリが本来必要とするテストメ

来する識別子に置換することで，対象のテストメソッドがソッドのうち平均 83%は，事前に定義した移植条件を持つすべての依存を保持し実行可能性を保つ．さらに，こ満たすものが移植元に 1 つ以上存在するため，移植す

うした識別子の置換が可能となる条件を提示することで，ることで同様のテストメソッドを生成できる可能性が

テストメソッドが移植可能となる条件を示す．

ある．一方，残りの平均 17%では，移植による生成が本研究ではさらに，我々が目標とする既存テストコード

そもそも不可能である．

の再利用によるテストコード自動生成手法の実現可能性を

本論文の以降の構成を示す．2 章ではテストコードの自探るため，再利用の素材となる既存テストコードを調査す

動生成に関連する先行研究について説明する．3 章ではテる．調査対象には GitHub 上に存在するテストコードを持

ストメソッド単位での移植によるテストコード自動生成手

つ Java オープンソースソフトウェア（以下，OSS）プロ法の構想を述べる．4 章ではそれぞれの研究設問についてジェクトを用いた．これらの有用性および手法の実現可能調査し，調査結果を述べる．5 章ではそれをもとに再利用性を調査するために，以下に示す 3 つの研究設問（Researchによるテストコード自動生成技術の実現可能性について考Question，RQ）を設定する．

察する．6 章では妥当性への脅威について述べる．最後に，RQ1 テストコードの移植元として利用できる OSS はど

7 章で結言と今後の課題を述べる．

の程度存在するか？
動機：再利用の素材として，テストコードを含む既存

2. 関連研究の OSS が多く必要となる．そうした OSS がどれほどテストコードの自動生成を目的とした研究がいくつか行存在するかを把握することで，テストコード再利用のわれている．EvoSuite はいくつかの選択可能な基準で最現実性を示す．

適化された関数単位での Java テストコードを自動的に生

結果：JUnit または TestNG を使用するテストコード

成することができる [2], [5]．しかし，テストコードの質がc 2021 Information Processing Society of Japan

1020

情報処理学会論文誌

Vol.62 No.4 1019–1028 (Apr. 2021)

低いことが指摘されている [6]．また，ごく簡単な単体テストにしか対応していない．関数単位での回帰テスト用のコードを自動生成する Randoop [7] も同様の問題をかかえている．ほかにも，JavaDoc などの構造化された自然言語で書かれた仕様書からテストコードを自動生成する手法 [3], [8], [9] や，振舞い駆動開発における製品の振舞いを独自の記法で記述したファイルからテストコードを自動生成する手法 [4], [10], [11] がいくつか提案されている．しかし，これらの手法はテストコードの原型となる文書の準備を要するため，純粋な自動生成とはいい難い．また，深層学習などによるプログラム合成手法は，研究用に定義されたドメイン固有言語を対象としているものが多く，ある
いはコード生成の精度が十分でないなど，実用的なテスト
コード生成には至っていない [12]．このように，結合テストなどの複雑なテストコードを高精度かつ手軽に自動生成

図 1

する手法はいまだ実現されていない．

Fig. 1 Template of test code.

テストコードテンプレート

一方，既存のコードを再利用することで開発効率や信頼性が向上することが知られている [13]．したがって，既存• 移植を試みるテストメソッドは，移植元プロジェクトのテストコードを再利用するアプローチにも一定の効果に存在する (A) 関連テストコード，(B) テスト対象でが期待できる．テストコードではないが実際に，既存のあるプロダクトコード，およびインポートして使用すソースコード片を再利用することでコード生成を実現するる (C) サードパーティ製のライブラリにそれぞれ依存

いくつかの方法が提案されている [14], [15]．また Sondhiを持ちうる．こうした依存を移植前と移植後で適切にら [16] は，数種類の Java および Python の OSS のテスト保つことで，移植したテストメソッドの実行可能性がコードの再利用性について調査し，類似した機能へのテス保たれる．

トコードが存在することや，テストコードを移植すること
で同様のテストが行える可能性を示した．ただし，あるラ– 上記のうち (A) をすべて抽出し，1 つのテストコード
T にパッケージングする．

イブラリのテストコードを別のライブラリに移植する際に– 上記のうち (B) に関する T 内の識別子をすべて，移は，内容の書き換えを手動により行っている．このように，

植先プロジェクトのプロダクトコードにおける適切テストコードを自動的に移植する手段についてはいまだ開な識別子に置換する．

拓されていない．

3. テストコード自動移植方法の構想– 上記のうち (C) に関するすべてのインポート宣言文
を T に記述し，移植先プロジェクトでもそれらが利用できるよう整備する．

本章では，ある Java プロジェクトに存在するテストメ
ソッドを別のプロジェクトに実行可能なテストコードとし

3.2 前提て自動的に移植する方法，および，そうした移植が可能と

テストメソッドの移植は，以下を前提とする．

なる条件について構想する．

• 移植を試みるテストメソッドは，移植元プロジェクト

3.1 移植の方針• 移植元プロジェクトと移植先プロジェクトの両方におにおいて正しく動作している．
移植方法の方針を以下にまとめる．

いて，テストコードに依存するプロダクトコードは存• テストの移植は，テスト機能の最小単位であるテスト

在しない．

メソッドごとに行うこととし，1 つのテストメソッド• 必要な設定を行うことで，移植元プロジェクトにおいにつきそれを実行するための独立した 1 つのテストてテストメソッドの実行のためにインポートされていコードを作成する．

るサードパーティ製のライブラリを，移植先プロジェ• 図 1 に示すテストコードテンプレート（以下，T）を用いる．T 中の点線で囲まれた各部分を移植元プロジェ

クトでも同様にインポートし使用することがつねに可能である．

クトから抽出したコードで埋め，また特定の変更を施• 移植を試みるテストメソッドを定義するクラスは，継すことで，移植先で動作する新たなテストコードを作

承（extends）や実装（implements）を使用していない

成する．

一般的なクラスである．

c 2021 Information Processing Society of Japan


1021

情報処理学会論文誌

Vol.62 No.4 1019–1028 (Apr. 2021)• 移植を試みるテストメソッドおよびそれに関連するテある．このように置き換え可能な識別子の組が移植先

ストコードは，テスト対象となるプロダクトコードにプロジェクトに存在している場合に限り，M は移植可

対して，メンバメソッド呼び出し，メンバ変数へのア

能となる．

クセス，インスタンス生成，データ参照型宣言の参照
先，のいずれかの形でのみ依存を持ちうる．

( 6 ) 手順 ( 5 ) で置換した移植先プロジェクトの識別子に基づいて，必要な import 文を T 中の (a) に追加する．

3 番目の前提については，たとえば Eclipse や Maven な( 7 ) 最後に，他に移植するテストコードと重複しない public

どのビルドツールを使用して依存パッケージ管理を行った

クラス名を設定し，それに応じたファイル名を設定すとしても，現実的には必要な外部ライブラリの使用に何らる．また配置する場所に応じたパッケージ名を設定

かの理由で失敗する可能性が考えられるが，議論の簡素化

する．

のため，本論文ではつねに利用できるとするものである．

以上の操作によって，テストメソッド M を対象に移植し

また下 2 件の前提も同様に本研究における議論を簡素化す

たテストコードが得られる．このテストコードは，3.1 節るための制限であり，今後の発展としてこれらの前提外ので述べた (A) から (C) の 3 種類の依存を保っているため，対象への拡張を制限するものではない．

3.2 節の前提のうえで，移植先プロジェクトにおいても実行可能であることが期待される．

3.3 移植手順
移植を行う際の具体的な手順を説明する．移植元プロ3.4 移植可能条件

ジェクトから移植を試みるテストメソッドを M とする．ま

移植を試みるテストメソッドが移植先で実行可能性を保た，M を定義しているクラスを C とし，M および C が記

つことができる場合，移植が可能であると考える．ここま述されているソースコードファイルを F とする．

での議論から，テストメソッドが実行可能性を保つために( 1 ) T 中の (c) に M を移植する．

は，3.3 節の手順 ( 5 ) における，プロダクトコードへの依存( 2 ) M が依存する C 内の要素をすべて T 中の (b) またはを保つ適切な識別子の置換が行える必要がある．したがっ(d) に移植する．ここには，メソッド，内部クラス，変て，置換可能な識別子を提供するプロダクトコード中の参数宣言文が含まれる．またここには，M 内で直接使用

照先が移植先プロジェクトにすべて存在していることが移されるもののほか，何らかの要素を通じて間接的に使植可能条件となる．

用するものも含まれる．たとえば，M が直接呼び出

テストコード側から見ると，プロダクトコードの各参照

すプライベートメソッドがさらに呼び出す他のプライ

先はブラックボックスとして振る舞う．したがって，テス

ベートメソッドなどが該当する．また加えて，JUnit

トコードがアクセスするプロダクトコード内の各参照先ににおける Before メソッドなど，M の実行に際してフ対する入出力の関係が移植元と移植先で保たれてさえいれ

レームワーク固有の暗黙的な依存を持つ要素も含まば，動作上の問題はない．

れる．

ここで，以下の場合に入出力が保たれると考える．メン( 3 ) M が依存する，F 内かつ C 以外のクラス，および，F

バ変数へのアクセスの場合，そのメンバ変数のデータ型が以外のテストコードで定義されたクラスをすべて T に一致する．メンバメソッドへのアクセスの場合，メソッド

おける public クラスの内部クラスとして移植する．こにおける引数のデータ型とその並び，および返り値のデーの依存は手順 ( 2 ) の場合と同様に，直接と間接を問わタ型が一致する．インスタンス生成の場合，コンストラク

ない．またこのとき，移植する各クラスはそのすべて

タメソッドにおける引数のデータ型とその並び，および作のメンバ，メソッド，および内部クラスを含める必要成されるインスタンスのデータ型が一致する．データ型のはなく，M が依存するものだけでよい．

一致について，プリミティブ型や，標準ライブラリおよび( 4 ) F，および，手順 ( 3 ) で移植したクラスを本来定義してサードパーティ製のライブラリのクラスを参照する参照型

いたテストコードから，T が依存するサードパーティ

は，完全一致する場合に限り一致と見なす．一方，移植元

製のライブラリの import 宣言文を T 中の (a) にそれ

プロジェクトで定義された固有クラスへの参照型は，移植ぞれ移植する．

先プロジェクトで定義される任意の固有クラスへの参照型( 5 ) T には移植前プロジェクトにおけるテスト対象であるプロダクトコードへの依存がいまだ存在しているたに一致すると見なす．ただし，こうした固有クラス間の依存関係が移植元と移植先で保たれる必要がある．

め，現段階の T を移植先プロジェクトに配置しても実固有クラス間の依存関係について，具体例を用いて詳述

行することはできない．したがって，T 中の識別子のする．あるテストメソッドを中心として関連参照先を抽出

うち，移植前プロジェクトにおけるプロダクトコードし作成した移植用テストコード（3.3 節の ( 4 ) 終了時に相に由来するものをすべて，実行可能性を保ちつつ，移当）を考える．表 1 は，このテストコードに存在する移植先プロジェクトにおける識別子に置き換える必要が植元プロジェクトのプロダクトコードへの依存を表していc 2021 Information Processing Society of Japan

1022

情報処理学会論文誌

Vol.62 No.4 1019–1028 (Apr. 2021)

表 1 移植用テストコードにおけるプロダクトコードへの呼び出し例

Table 1 Example of call for product codes in test code.

実的かを調べる．またテストコードの移植において，共通のドメインに属するプロジェクトからの移植が有効である

クラス名

メソッド名

引数のデータ型

返り値のデータ型と考えられるため，得られたリポジトリのドメイン分類を

ClassA

convert[long]

int

行う．

ClassA

setBtoA[ClassB]

void

ClassB

getValue[]int

4.1.2 調査対象
GitHub [17] に存在するすべてのリポジトリを対象として，リポジトリ情報を保管するサービスである GHTor-る．すなわち，2 種類のクラスに属する 3 種類のメソッド

rent [18]，および GitHub が提供する GitHub API (v3) [19]呼び出しを通じて依存している．また下線は，移植用テスを用いて絞り込む．また本実験で扱うテストコードは，テ

トコード中に存在する置換すべき識別子であることを表

ストフレームワークとして JUnit4，JUnit5，TestNG を使している．ここで，ClassB は引数を持たず int 型を返すメ用したものに限定する．これらのフレームワークでは，メ

ソッド getB を有している．したがって，移植先にも同様のソッドに@Test アノテーションを付することがテストメ

入出力を持つメソッドを有するクラスが存在する必要があ

ソッドの識別ルールとなる*1 ．GHTorrent のダンプデータ

る．加えて，ClassB は ClassA の持つメソッド setBtoA のは実験開始時に最新であった 2019 年 6 月登録のものを使引数に含まれる参照型に参照されている．したがって実際用した．API による情報取得は 2019 年 9 月 2 日，リポジに移植先プロジェクトに要求されるのは，こうした ClassA

トリのダウンロードは 2019 年 11 月 15 日に実施した．

と ClassB 間の関係と同じ関係を持つ 2 クラスの組合せと4.1.3 手法
調査 1-A から調査 1-C を順に行う．

なる．

調査 1-A：GHTorrent を用いて，GitHub に登録されて3.5 利用者とのインタラクション
本技術は利用者が開発するプロジェクトの情報をもといるすべてのパブリックなリポジトリのうち，以下を満たすものを抽出する：(1) 主な言語が Java，(2) 削除済みでなに，適用可能なすべてのテストメソッドを既存プロジェク

い，(3) フォークによって作られたものでない，(4) スター

ト群から検索し自動的にテストコードを生成することを目を 100 以上持つ．(3) と (4) の条件は，低品質なプロジェ的とする．そのため必ずしも利用者が事前にテスト仕様をクトを除外する目的で設定した．次に GitHub API を用い決定する必要はない．ただし，あらかじめテスト仕様をイて，これらのリポジトリの master ブランチにおける Tree

メージしておくことで生成されたうち不必要なテストコー

オブジェクトファイル*2 を参照することで，「test ディレドを除外することができる．また，場合によっては膨大なクトリ下に存在する拡張子が．java のファイル」の数を取数のテストコードが生成されることも考えられる．この場得する．最後に，このファイル数が 20 以上であるリポジ

合，利用者は候補として提示されたうち適切なテストコー

トリをダウンロードし，ブランチが master でないものはドを選択して使用することになる．将来的には生成数の上master に切り替える．

限を定めたり，よりテストしたい箇所をあらかじめ選択し調査 1-B：得られたリポジトリ内のファイルを静的に構て重み付けしたりすることも考えたい．また，ただ実行可文解析することで実際のテストコードを特定し，以下の条能であるだけで意味的には適切でないテストが生成される

件のいずれかを満たすリポジトリを除外する．

場合もある．現状の提案内容では利用者の目視判断によっ• プロダクトコードが存在しない．ここでプロダクトて選択する必要があるが，将来的には 5.2 節で述べるようコードとは，テストコードではない*.java ファイルすな改善が考えられる．

べてを指す．

4. 調査• テストメソッドが存在しない．ここでテストメソッドとは，テストコード中に存在する@Test アノテーショ
ンが付与されたメソッドを指す．また，@Ignore アノ

前章で述べた移植手法の開発に向け，その実現可能性をテーションの有無は関与しない．

評価するため，以下に述べる 3 つの調査を行った．

• org.junit または org.testng を名称に含むライブラリを
4.1 RQ1：テストコードの移植元として使用できるプロ
ジェクトはどの程度存在するか？

1 度もインポートしていない．
• 構文解析を行ううえで，デコードおよびパースが失4.1.1 動機

敗し解析できなかった Java ファイルの割合が全体の5%を上回る．あるいはこうした Java ファイルが 20

テストコードからの移植を行う素材として，テストコー
ドを含む既存のプロジェクトが多く必要となる．そうしたJava プロジェクトがどれほど存在し利用できるかを把握することで，テストコードを再利用する手法がどれほど現c 2021 Information Processing Society of Japan


*1
*2

JUnit5 ではより細かいルールも存在するが，本研究では簡単のため主たるものに統一した．
リポジトリ内のディレクトリ構造が記されたファイル1023

情報処理学会論文誌

表 2

Vol.62 No.4 1019–1028 (Apr. 2021)

表 3

絞り込みで得られた 1,862 リポジトリの情報

Table 2 Information of 1,862 extracted repositories.
（単位：個）

ドメイン分類結果

Table 3 The classification result of the domain of repositories.

最小値

平均値

中央値

最大値

ドメイン

スター数

100

1,121.6

329

81,817Development

339

Multimedia

100

全 Java ファイル

22

898.3

338

57,851

Data

304

Testing

92

テストコード

10

216.3

63

4,508

Web

256

Security71

プロダクトコード

1

676.7

233

57,372

Network

201

Document

65

Distribution

159

Performance46

Database

157

OS

44

Programing

137

Financial

41

Operation

135

Geospatial

31

Android119

Middleware

30

Utility

104

Game

29

Science101

No Category

54

以上存在する．

• テストメソッドを含む Java ソースファイル数が 10 以下である．
上記の条件のうち最後の条件は，テストコードが極端に少ないリポジトリは移植元として明らかに不適なため，以リポジトリ数ドメイン

リポジトリ数降の調査から除外することを目的に設定した．静的解析には JavaParser の Python ラッパである javalang パッケー

定義された参照先にどれほど依存しているかによって，そジを使用した．

の移植に要する条件は厳しくなる．こうした依存の大きさ

調査 1-C：得られたリポジトリのそれぞれに対して著の傾向によって，移植可能であるために要求される条件の者がドメインのラベル付けを手動で行う．ラベルには，全体的な傾向を示す．

GitHub 上の優れた Java プロジェクトを紹介する Awe-4.2.2 調査対象

some Java *3 で用いられている 66 種類のドメインを参考

RQ1 の調査で得られた 1,862 件のリポジトリのうち，上に，著者の判断で 21 種類のドメイン（表 3）を使用す

位 6 つのドメインに属するリポジトリを，それぞれスター

る．各リポジトリの GitHub ページの description 文およ

数の多い順に 100 件選択し，調査対象とする．これは，調び README.md を目視で確認することで，それが属する査の規模と労力を抑えるため，再利用される可能性が高いと思われるドメインラベルを 3 つまで選択する．ドメイン

リポジトリを代表させるという意図による．このとき，1につながる情報が得られないものや判断がつかないものは度選択された中でファイル数が突出して多い 3 件のリポジ

No Category とする．

トリ*4 は，調査結果の妥当性を損ねると判断し，これらを4.1.4 結果
調査 1-A：全工程完了時，2,124 件のリポジトリが得ら除外して再選択した．ドメイン間にリポジトリの重複があるため，選択されたリポジトリは合計で 509 件となった．

れた．
調査 1-B：全工程完了時，1,862 件のリポジトリが得ら

これらのリポジトリに含まれるテストコードからテスト
メソッドを抽出する際，3.2 節に示した前提のうち下 2 件れた．これらのリポジトリの情報を表 2 に示す．リポジの前提を満たさないものは調査範囲から除外した．その結トリに含まれるテストコードの合計は 402,751 ファイルと果，合計 348,045 個のテストメソッドが調査対象として得

なった．

られた．

調査 1-C：ドメイン分類の結果を表 3 に示す．各ドメ

4.2.3 手法

インごとにそのラベルが貼られたリポジトリ数を示してい

静的な構文解析によって，調査対象のテストメソッドがるため，数字の合計が総リポジトリ数と異なっている．ソ

依存するテストコード内の参照先をすべて特定し，集計す

フトウェア開発に用いられることを示す Development ドる．その後，同じく構文解析を行うことで，それらの持つメインに属するリポジトリが最も多く，次いで，データのプロダクトコードの参照先，あるいは，プロジェクト固有

処理や規格を扱うことを示す Data ドメインや，Web アプ

ではないライブラリへの依存をすべて特定し，集計する．

リケーションであることを示す Web ドメインが多かった．

4.2.4 結果

したがって，これらのドメインに属するソフトウェアには，

テストメソッドの依存先を集計し分類した結果を表 4 に

既存 OSS のテストコードを再利用しやすいと期待できる．

示す．平均として，1 つのテストメソッドは合計 13.9 個の4.2 RQ2：テストメソッドは他の参照先にどれほど依存しているか？

4.2.1 動機
テストメソッドが他の参照先，特にプロダクトコードで*3

https://github.com/akullpp/awesome-java

c 2021 Information Processing Society of Japan

参照先への依存を有している．そのうち，テストコード中の参照先に対しては平均 1.8 個の依存を有している．これは，これは，あるテストメソッドを移植する際に，自身のほかに平均 1.8 個の参照先を同時に移植させる必要がある*4

aliyun/aliyun-openapi-jaba-sdk，JetBrains/MPS，aws/awssdk-java1024情報処理学会論文誌

Vol.62 No.4 1019–1028 (Apr. 2021)

表 4 各テストメソッドが依存する参照先の集計および定義場所の分類結果

Table 4 Dependencies and references of each test method.

はプロダクトコードに対して単一の依存を持つ．これはEvoSuite などのツールで作成可能な単純な単体テストに相当する．また，約 17%のテストメソッドはプロダクトコー

平均値

平均値の割合中央値

ドへの依存を持たない．これらのテストメソッドは標準ラ

（個）

（%）

（個）

イブラリやサードパーティ製ライブラリで実現できる機能

13.9

100.0

9

テストコード

1.8

12.9

1

プロダクトコード

4.0

28.8

2

外部ライブラリ

8.1

58.3

5

参照先
すべて

のテストのみを行っていると考えられる．
最後に，テストメソッドはプロジェクト固有ではないラ
イブラリに対して平均 8.1 種類の呼び出しによる依存を有する．これらは，たとえば JUnit の提供するアサーション
用メソッドや，String クラスなどの標準ライブラリが持つメソッドが多く該当した．依存量の平均的な割合は最も高い．移植先でもこれらのライブラリを使用できるよう設定できる前提のもとでは移植可能性に影響しないが，こうした依存量は設定作業にかかる労力の目安となる．

4.3 RQ3：既存テストコードには，テスト対象への依存関係が生成対象のテストメソッドと共通するテスト
メソッドはどれほど存在するか？

4.3.1 動機
移植元となるプロジェクトにおけるテストメソッドが持
図 2 各定義場所への参照数が特定の個数であるテストメソッド数の累積割合グラフ

Fig. 2 Cumulative percentage graph of the number of test
methods whose number of references to each definition
location is a specific value.

つプロダクトコードへの依存と，移植先のプロジェクトが本来必要とするテストメソッドが持つプロダクトコードへの依存が同一であるならば，テストメソッドを移植することで移植先で本来必要となるテストコードを生成できる可能性がある．特定のリポジトリを移植先および移植元としことを示している．また，プロダクトコード中の定義ファた場合に，そうしたテストメソッドがどれだけ存在するかクタに対して平均 4.0 個の依存を有している．これは，テを調べることで，移植によるテストコードが達成できる効ストメソッドの移植を行う際に移植元プロジェクトと移植果の上限を示す．

先プロジェクトの間で平均 4.0 個のプロジェクト固有の識

4.3.2 調査対象
RQ2 への調査で使用した 6 ドメインの各 100 件のリポ

別子の対応づけを行う必要があることを示している．
より詳細な分析のため，それぞれの依存先への依存が各ジトリのうち，テストメソッド数が中央値をとるものを移個数をとるテストメソッドの個数の累積割合グラフを図 2

植先リポジトリとして，また他の 99 件を移植元リポジトに示す．たとえば，緑のグラフで表されるプロダクトコー

リとして用いる*5 ．各ドメインにおける移植先リポジトリ

ド中の参照先への依存の個数 N が 1 のとき，テストメソッのテストメソッド数，および移植元リポジトリの合計テス

ド数の累積割合は約 47%であることが読み取れる．これ

トメソッド数を表 5 に示す．

は，調査対象としたテストメソッドのうち約 47%が，プロ

4.3.3 手法
テストメソッドの移植先として選ばれたリポジトリが保ダクトコード中の参照先への依存をたかだか 1 個しか持たないことを意味している．

有しているテストメソッドを，そのプロジェクトが必要

この図から次の結果が観察できる．

とするテストメソッドの正解データ（以下，正解テストメ

テストコードへの依存について．約 40%のテストメソッソッド）として用いる．構文解析によって，それらのテス

ドは他のテストコード中の参照先への依存を持たず，それ

トメソッドが持つプロダクトコードへの依存を抽出する．

単体で機能することが分かる．他のテストコード中の参照

次に，移植元として扱うリポジトリ群の各テストメソッド

先への依存が 4 つ以下のテストメソッドが全体の約 90%をについても同様に依存を抽出し，正解テストメソッドのい占めており，大部分のテストメソッドは少量の補助コード

ずれかと依存が一致するものを集計する．この依存の一致をともなって移植用のテストコードを構成できる．

判定は 3.4 節で示したように，依存する参照先の入出力のプロダクトコードへの依存について．プロダクトコード
中の参照先への依存が 2 個以下であるテストメソッドが全体の約半数を占める．特に，約 20%のテストメソッド

c 2021 Information Processing Society of Japan*5

同ドメイン内で移植を行うことは移植条件において必須ではないが，少ないリポジトリから最大の効果が得られることが期待でき
る．

1025

Vol.62 No.4 1019–1028 (Apr. 2021)

情報処理学会論文誌

表 5

RQ3 での調査に用いる調査対象

Table 5 Target repositories of RQ3.
ドメイン

移植先リポジトリ

テストメソッド数

移植元の合計テストメソッド数

Development

FreeTymeKiyan/LeetCode-Sol-Res

202

95,919Data

plutext/docx4j

321

99,869Web

apache/nutch

242

62,258

Network

mitreid-connect/OpenID-Connect-Java-Spring-Server

251

63,519Distribution

alibaba/Sentinel

319

70,435

Database

xetorthio/jedis

213

60,481

表 6 各ドメインの移植先リポジトリに存在する，プロダクトコード

別のメトリクスを併用することで高品質なテストコードを，および，そへの依存を 1 つ以上持つテストメソッド数（Ta ）含む他のリポジトリを選定できる余地が残されている．まのうち依存関係が一致するテストメソッドが移植元リポジトリ，またその割合（Tb /Ta ）に 1 つ以上存在するものの個数（Tb ）Table 6 The number of test methods having one or more de-た，時間とともに再利用に適したリポジトリが増えていくことも考えられる．したがって，本調査で得られた数を下

pendencies on product code in repositories of each do-

限として，実際にはより多数の再利用素材の確保が見込め

main (Ta ), the number of test methods having one or

る．こうした事実は，再利用によるテストコード自動生成

more matching dependencies in the repository amongの実現可能性を高める一因となる．

them (Tb ), and the percentage (Tb /Ta ).

RQ2 の結果から，約半数のテストメソッドはプロダクト

ドメイン

#Ta

#Tb

割合

コードにたかだか 2 種類の依存を有しており，これらを適Development

147

140

0.95

切に保つような移植元と移植先の間の識別子の対応関係を

Data

317

285

0.90

探すことで，実行可能性を保ったまま移植が可能であると

Web

236

206

0.87

いえる．この結果は，テストコードの再利用の間口が広く

Network

240

154

0.64

Distribution

304

209

0.69

Database

208

191

0.92

種類以上とプロダクトコードへの複雑な依存を持つテスト

-

-

0.83

メソッドも約 1 割程度存在している．

平均

設けられていることを示している．一方で，呼び出しが 9

RQ3 の結果から，移植先プロジェクトに本来必要とな
一致，およびそれらのクラス間が持つ関係に基づく．

るテストメソッドについて，プロダクトコードへの依存の4.3.4 結果形が同一であるようなテストメソッドが既存プロジェクト

結果を表 6 に示す．移植先における正解テストメソッド

群に高い割合で存在している．ただし，平均 17%，最も高のうち，平均して 83%，最も高いものでは 95%の割合で，いもので 36%のテストメソッドは，用意した同ドメインにプロダクトコードへの同一の依存関係を持つものが，移植

属する 99 件の既存 OSS からは再利用によって生成されえ元とした 99 件のリポジトリに 1 つ以上存在している．しないことが示された．こうしたテストメソッドを再利用にたがって，プロダクトコードへの依存関係が同一であるこ

よって生成するには，用意するプロジェクトを増やすか，れらのテストメソッドは，適切に識別子を改変することであるいは識別子の変更のみに限定しない再利用方法を考え

移植先プロジェクトでも実行可能であることから，移植先る必要がある．

リポジトリが本来必要とするテストメソッドを作成するこ以上 3 つの RQ の結果から，再利用の対象となりやすいとができると考えられる．一方，残りの平均 17%では，プ

既存テストコードが多く存在しており，また目的のテスト

ロダクトコードへの依存関係が一致するテストメソッドがコードを得られる可能性も高い．したがって，既存テスト

移植元に存在しないため，移植による生成がそもそも不可

コードの再利用による自動生成手法の構想は現実的かつ有能である．

益であると考えられる．

5. 議論
5.1 RQ への回答から得られる再利用によるテストコー
ド自動生成の実現可能性への考察

5.2 自動生成に向けて解決すべき課題あるテストメソッド T が移植条件を満たすかを判定する
場合，T の持つプロダクトコードへの依存に関して，移植

RQ1 の結果から，1,862 件とけっして少なくない数の元と移植先で代替可能な識別子の有無を判定する必要があJava OSS リポジトリがテストコードの再利用素材としてる．これは，移植先の全プロダクトクラス間の依存グラフ

利用できる．また今回の調査では，スター数が 100 以上とに，T が依存するプロダクトクラス間の依存グラフが含ま

やや厳しい基準を設けているが，より少ないスター数でもれるかという，部分グラフ同型判定としてのアプローチがc 2021 Information Processing Society of Japan


1026

情報処理学会論文誌

Vol.62 No.4 1019–1028 (Apr. 2021)

考えられるが，具体的なアルゴリズムへの落とし込みは今後の課題である．

6.3 構成概念妥当性
今回提案した内容は構想段階であるため，我々が定義しまた現段階での提案内容では，移植したテストメソッド

た移植条件を満たすことで実際に移植先で実行可能性が保の実行可能性のみを議論の対象としており，意味的に適切たれるかを実際に検証することはできておらず，我々の認なテストが移植できるか否かを問題としていない．そのた識していない条件がさらに存在する可能性は否定できな

め，意味的に適切なテスト操作を提供できるよう，テスト

い．そうした検証も今後の課題であり，本論文では構想にメソッド中の識別子の対応づけ方法を改善する必要があとどまった提案内容をより洗練できる可能性がある．

る．ここで，テストメソッドが依存する参照先について，識別子名の意味的な類似度や，構文木の形状などを利用し

7. おわりにた処理内容の類似度などを算出し，候補を順位づけること

本研究では，既存プロジェクトからの再利用による Javaで，より意味的に類似した識別子を探し出し，書き換えのテストコードの自動生成手法の提案に向け，移植後の実行対象とすることができる．こうすることで，移植元と移植可能性に焦点を当てたテストメソッドの移植方法の構想に先の間で意味的な類似性を保ちつつ適切なテスト操作手順

基づいて，GitHub 上の OSS における既存テストコードのを提供できると期待できる．そうした中で，どのような方移植可能性について調査した．その結果，既存テストコー

法が最も効果的かを今後明らかにする必要がある．

ドを再利用素材として使用できるリポジトリが GitHub 上

また，移植したテストコードが適切なテスト操作手順をに 1,862 件存在することや，大半のテストメソッドはテス提供できる場合であっても，結果を照合するための適切なト対象のプロダクトコードにたかだか 2 つの依存しか持た

期待値を備えていない場合も考えられる．テスト期待値のないこと，この依存関係を保つ移植によって本来必要なテ

適切さを評価することは難しいため，利用者によって複数

ストメソッドの平均 83%が生成できる可能性があることなの候補から適切なものを選択したり，期待値部分を容易にどを実証的に示し，既存テストコードの再利用による自動変更できたりするような仕組みを整えることが求められる．

生成手法が現実的かつ有益であることを示した．

さらに将来的には，本手法によって適切なテスト操作を，

今後の課題として，現実的な移植を試みるテストメソッ

また他の手法によって適切なテストオラクルを検索し，両ド対象を拡大することや，意味的な要素を考慮した適切な者を合成させることで自動的に適切なテストコードを作成

識別子の対応づけ手法を考案し，動作可能なテストコードすることも考えられる．

を作成するツールを実際に開発することなどがあげられる．

6. 妥当性への脅威

謝辞 本研究は JSPS 科研費 JP19K20240，JP18H04094の助成を受けた．

6.1 内的妥当性
本論文で実施した調査実験の大部分を，著者の作成したプログラムによって行っている．そのため，意図しないプ

参考文献
[1]

ログラムの動作不備が存在し実験結果に影響を与えている可能性は否定できない．また，RQ1 におけるリポジトリの[2]

ドメイン分類は著者の判断かつシングルチェックで行われたため，理想的なドメイン分類とは異なっている可能性がある．また RQ3 の結果について，テストコード実行に必[3]

要な外部ライブラリのインポートが必ず成功するという前提のもとでの結果であり，この前提が事実と異なる場合には合致するテストメソッドが示された結果よりも少なくな[4]

る可能性がある．

6.2 外的妥当性[5]

RQ1 の調査はある時点での GitHub 上のすべての Java
リポジトリを対象としたため，外的妥当性への懸念は少ない．一方で，RQ2 での調査は特定の基準で選択された 509
個のリポジトリのみを，また RQ3 での調査は移植元と移植先のパターンとして各ドメインで 1 組のみを対象としているため，この調査結果をすべてのリポジトリに対して一般化することは難しい．

c 2021 Information Processing Society of Japan[6]

Orso, A. and Rothermel, G.: Software Testing: A Research Travelogue (2000–2014), Proc. Future of Software
Engineering (FOSE ), pp.117–132 (2014).
Fraser, G. and Arcuri, A.: Whole Test Suite Generation, IEEE Trans. Softw. Eng., Vol.39, No.2, pp.276–291(2013).
Tan, S.H., Marinov, D., Tan, L. and Leavens, G.T.:@tcomment: Testing javadoc comments to detectcomment-code inconsistencies, Proc. IEEE 5th International Conference on Software Testing, Verification andValidation (ICST ), pp.260–269 (2012).
Li, N., Escalona, A. and Kamal, T.: Skyﬁre: ModelBased Testing with Cucumber, Proc. 9th International
Conference on Software Testing, Verification and Validation (ICST ), pp.393–400 (2016).
Almasi, M.M., Hemmati, H., Fraser, G., Arcuri, A. andBenefelds, J.: An Industrial Evaluation of Unit Test
Generation: Finding Real Faults in a Financial Application, Proc. 39th International Conference on Software
Engineering: Software Engineering in Practice Track(ICSE-PT ), pp.263–272 (2017).
Shamshiri, S., Rojas, J.M., Galeotti, J.P., Walkinshaw,
N. and Fraser, G.: How Do Automatically Generated
Unit Tests Inﬂuence Software Maintenance?, Proc. 11th
International Conference on Software Testing, Verifi-

1027情報処理学会論文誌

[7]

[8]

[9]

[10]
[11]
[12]

[13]

[14]

[15]

[16]

[17]
[18]

[19]

Vol.62 No.4 1019–1028 (Apr. 2021)

cation and Validation (ICST ), pp.250–261 (2018).
Pacheco, C. and Ernst, M.D.: Randoop: FeedbackDirected Random Testing for Java, Proc. 22nd ACM
SIGPLAN Conference on Object-Oriented Programming Systems and Applications Companion (OOPSLA), pp.815–816 (2007).
Goﬃ, A., Gorla, A., Ernst, M.D. and Pezzè, M.: Automatic Generation of Oracles for Exceptional Behaviors,
Proc. 25th International Symposium on Software Testing and Analysis (ISSTA), pp.213–224 (2016).
Motwani, M. and Brun, Y.: Automatically Generating
Precise Oracles from Structured Natural Language Speciﬁcations, Proc. 41st International Conference on Software Engineering (ICSE ), pp.188–199 (2019).
JBehave (online), available from https://jbehave.org
(accessed 2020-07-30).
Cucumber (online), available from https://cucumber.
io (accessed 2020-07-30).
Balog, M., Gaunt, A.L., Brockschmidt, M., Nowozin, S.
and Tarlow, D.: DeepCoder: Learning to Write Programs (2016).
Kapser, C.J. and Godfrey, M.W.: “Cloning consideredharmful” considered harmful: patterns of cloning in software, Empirical Software Engineering, Vol.13, No.6,
pp.645–692 (2008).
Hummel, O., Janjic, W. and Atkinson, C.: Code Conjurer: Pulling Reusable Software out of Thin Air, IEEE
Software, Vol.25, No.5, pp.45–52 (2008).
Lu, Y., Chaudhuri, S., Jermaine, C. and Melski, D.: Program Splicing, Proc. 40th International Conference on
Software Engineering (ICSE ), pp.338–349 (2018).
Sondhi, D., Rani, D. and Purandare, R.: Similarities
Across Libraries: Making a Case for Leveraging Test
Suites, Proc. 12th International Conference on Software
Testing, Validation and Verification (ICST ), pp.79–89(2019).
GitHub (online), available from https://github.com
(accessed 2020-07-30).
Gousios, G.: The GHTorent dataset and tool suite, Proc.
10th Working Conference on Mining Software Repositories (MSR), pp.233–236 (2013).
GitHub API (v3) (online), available from https://developer.github.com/v3/ (accessed 2020-07-30).

水野 修 （正会員）
平成 11 年大阪大学大学院基礎工学研
究科助手．平成 13 年博士（工学）大阪
大学．平成 22 年京都工芸繊維大学大学院工芸科学研究科准教授．平成 29
年同情報工学・人間科学系教授．主にソフトウェアのバグ検出手法，ソフト
ウェアリポジトリのマイニングに関する研究に従事．IEEE
会員．

崔 恩瀞 （正会員）
平成 27 年大阪大学大学院情報科学研
究科博士後期課程修了．同年同大学院
国際公共政策研究科助教．平成 28 年
奈良先端科学技術大学院大学情報科学研究科助教．平成 30 年より同大学先端科学技術研究科助教（改組による）．
平成 30 年より京都工芸繊維大学情報工学・人間科学系助教．博士（情報科学）．コードクローン管理やリファクタ
リング支援手法に関する研究に従事．

西浦 生成 （学生会員）
平成 30 年京都工芸繊維大学大学院工芸科学研究科博士前期課程情報工学専
攻修了．修士（工学）．同大学院工芸科学研究科博士後期課程設計工学専攻
在学中．平成 28 年より国立研究開発
法人産業技術総合研究所リサーチアシ
スタント．ソフトウェアのテスト・不具合局所化に関する研究に従事．

c 2021 Information Processing Society of Japan

1028