JP2010134643A - テストケースの選択方法及び選択システム - Google Patents

Abstract

【課題】継続的インテグレーションにおけるテストを効率的に実施することができるようにテストケースの選択を行うこと。
【解決手段】情報処理装置内のリポジトリ104にテストケースの属性として重要度及び実行実績時間を保持させ、情報処理装置内に継続的インテグレーションツール102とテストケース選択部103とを備える。テストケース選択部103は、開発者からソース登録を受けたソース構成管理ツール101から継続的インテグレーションツール102にソース変更の通知があったときに、継続的インテグレーションツール102から渡された変更ファイルの解析を行い、解析結果を前記リポジトリに格納し、継続的インテグレーションツール102から渡された実施重要度及び実施時間閾値と、前記リポジトリに格納されたテストケースの重要度及び実行実績時間とから実行すべきテストケースを選択する。
【選択図】図１

Description

本発明は、プログラムのテスト時のテストケースの選択方法及び選択システムに係り、特に、プログラムの開発に継続的インテグレーションを用いた場合におけるプログラムのテストの際に、効率的なテストの実施を可能とするテストケースの選択方法及び選択システムに関する。

プログラムの開発手法の１つとして、継続的インテグレーションと呼ばれる手法が知られている。この継続的インテグレーションと呼ばれる開発手法は、所謂アジャイル手法に代表される反復型開発の特徴の１つである「常に動くものを作る」という考え方をプログラムの製造に応用したものである。そして、この手法は、マスタソースの管理を一箇所に集めた上で、１日に何度もコンパイル、ビルド、配置を行い、自動テストを行うというサイクルを繰り返すことにより、常にプログラムを動作する状態に置くというものである。

継続的インテグレーションと呼ばれる手法は、前述により、統合のコストを下げることが可能となり、また、不良の混入や修正による機能のデグレード等に早く気づかせることが可能となり、結果として、プログラム開発途上の修正のコストを大幅に下げることが可能となる。

通常、継続的インテグレーションの手法を用いたプログラムの開発は、マスタソースの管理にソース構成管理ツールを利用した上で、継続的インテグレーションツールを用いて行われている。一方で、プログラムの自動テストは、様々な言語やシステムに対応したテストフレームワークを使用して行うのが一般的である。

なお、継続的インテグレーションの手法は、あくまでもプログラムの開発手法であり、品質保証の観点から行うテスト手法ではない。すなわち、継続的インテグレーションの手法は、大きな手戻りを防ぐためのものであり、開発の明らかな後退を防ぐものであるため、ここで必要となる自動テストは、アプリケーションを厳密に網羅するものである必要のないものである。

継続的インテグレーションを行う大きな目的には、不良の作り込みの排除と、デグレードの防止とがある。この目的を最大限達成するためには、ソースに変更がある度にインテグレーションを行うことが望ましい。実際、継続的インテグレーションツールには、ソース構成管理ツールが管理しているソースの構成変更を検知して動作する仕組みが装備されているのが普通である。

しかし、前述の継続的インテグレーションツールを実際に利用すると、コンパイル、ビルド、配備にもいえることではあるが、自動テストに非常に多くの時間が費やされてしまうという問題を生じる。この理由は、１つの機能に対するテストが、通常数個、機能によっては数十個以上にもなる場合があるためであり、また、外部リソース（データベース等）を用いてテストを行わなければならない場合、基本的に時間がかかるためである。

前述したようなテストに多くの時間を要するということを意識せずに、プログラムの開発を進めると、前のテストが終わらないうちにソースに新たな変更が入る状態が頻発し、テストの結果が不調に終わった場合に、どこが悪かったのかが判りずらくなり、開発の停滞を招くこととなるという問題を生じさせる。

前述したような問題を回避するために、変更の入った部分を発見し、それに関係したテストケースのみ実施することによりテストケースの数を絞るという手法が種々提案されている。例えば、特許文献１には、プログラム開発途上に修正が行われた場合におけるテストケースに独自の重み付けを行うことにより、テストケースの数を絞る技術が、また、非特許文献１には、コールツリーを作成して影響調査を行うことにより、テストケースの数を絞る技術が提案されている。
特開２００８−１２９６６１号公報 「仮想マシンの中間言語に基づく回帰テスト選択手法」、情報処理学会論文誌 Vol.45, No.8(20040815) pp. 2043-2054、社団法人情報処理学会 ISSN:03875806

しかし、前述した特許文献１、非特許文献１に記載された技術は、変更が入らなかった部分に関するテストケースをスキップするためには有効であるが、テストケース自体の重要度や実行時間について考慮していないものであり、テストを効率的に実施することができないという問題点を有している。

本発明の目的は、前述した従来技術の問題点を解決し、テストケース自体に付与した重要度や実行実績時間を用い、継続的インテグレーション手法を用いてプログラムの開発を行う際に実施するテストを効率的に実施することができるようにテストケースを選択することを可能としたテストケースの選択方法及び選択システムを提供することにある。

本発明によれば前記目的は、継続的インテグレーション手法を用いてプログラムの開発を行う際に実施するテストを効率的に実施することができるようにテストケースを選択するテストケースの選択方法において、情報処理装置内のリポジトリにテストケースの属性として重要度及び実行実績時間を保持させると共に、前記情報処理装置内に継続的インテグレーションツールとテストケース選択手段とを備え、前記テストケース選択手段は、開発者からソース登録を受けたソース構成管理ツールから継続的インテグレーションツールにソース変更の通知があったときに、継続的インテグレーションツールから渡された変更ファイルの解析を行い、解析結果を前記リポジトリに格納し、その後に継続的インテグレーションツールから渡された実施重要度及び実施時間閾値と、前記リポジトリに格納されたテストケースの属性として重要度及び実行実績時間とから実行すべきテストケースを選択することにより達成される。

本発明によれば、テストケース自体に付与した重要度や実行実績時間と、テスト実行時に設定する重要度、実行時間閾値とを用いて、継続的インテグレーションにおけるテストを効率的に実施することを可能とするようにテストケースの選択を行うことができる。

以下、本発明によるプログラムテスト時のテストケース選択方法及び選択システムの実施形態を図面により詳細に説明する。

図１は本発明の一実施形態によるプログラムのテスト時にテストケースの選択を行うテストケースの選択システムの構成を示すブロック図である。

図１に示すシステムは、ソース管理マシンとテストマシンとにより構成される。ソース管理マシンとテストマシンとは、それぞれ、少なくとも、ＣＰＵ、メインメモリ、ＨＤＤ等の記憶装置を備えて構成される情報処理装置であり、本発明の実施形態で必要とする各種の機能がプログラムとして記憶装置に格納されていて、それらのプログラムがメインメモリにロードされ、ＣＰＵにより実行されることにより、本発明における各種の機能が構築される。

前述において、ソースマシン内に備えられるソース構成管理ツール１０１は、対象アプリケーションのソースと、テストケースのソースとの構成管理を行う機能を有する。また、テストマシン内の継続的インテグレーションツール１０２は、継続的インテグレーションを行うためにソース構成管理ツール１０１との接続を持ち、テスト対象アプリケーションコンパイルし、あるいは、図示しないコンパイラにコンパイルを行わせたりし、また、テストケース選択部１０３を起動したりする。

なお、前述において、テストケースとは、ある引き数を与えてメソッドをコール（実行）したときに、ユーザが望んだ結果と実際に返った結果とを照合する単位となるものであり、例えば、複数のプログラムステップの集合である。

テストケース選択部１０３とリポジトリ１０４とについては、図２を参照して後述するが、テストケース選択部１０３とリポジトリ１０４とが本発明の中心をなす構成である。

テストマシン内の自動テストフレームワーク１０５は、自動テストを記述したり実行したりするのを支援するライブラリである。また、テスト対象アプリケーション１０６は、継続的インテグレーションツール１０２によってビルドされるものである。

端末１０７は、開発者が使用している開発用マシンであり、作成したソースをチェックインするものである。端末１０８は、テスト実行時のパラメータ（実施重要度と実施時間閾値）の設定を行うものである。この端末１０８から延びる矢印は、継続的インテグレーションツール１０２を通ってテストケース選択部１０３に達しているが、このことは、パラメータ自体は継続的インテグレーションツール１０２に登録するが、テスト実行時にはテストケース選択部１０３にわたされるということを意味している。また、端末１０９は、テストの実行実績時間一覧を表示するものである。

前述した端末１０７〜１０９は、ＰＣに代表される情報処理装置であり、端末１０８、１０９は、１つの端末であってもよい。

図２はテストケース選択部１０３の内部構造を示すブロック図である。テストケース選択部１０３は、解析部２０１、更新部２０２、テスト部１０３から構成されている。

解析部２０１は、対象ソースやテストケースのコードを解析し、使用しているクラスやメソッドの情報を取得する機能を有する。

更新部２０２は、解析結果や、実行結果の時間等をリポジトリ１０４に書き込む機能を有する。

テスト部２０３は、継続的インテグレーションツール１０２から渡された実施重要度・実施時間閾値と、リポジトリ１０４から読み込んだ重要度・実行実績時間を比較し、実行するテストケースを決定する。

次に、図３〜図５を参照して、リポジトリ１０４に格納する情報のレコードについて説明するが、ここで示す例は、理解しやすいように、言語としてJava（登録商標）、テストフレームワークとしてJUnit を使用する例である。もちろん、他の言語、他のツールでも、相応の読み替えをすればよい。

図３はテスト対象アプリケーションクラス使用情報が格納されるリポジトリ内のレコードについて説明する図である。このレコードには、対象クラス名３０１と、使用クラス名３０２とが格納される。

対象クラス名３０１には、テストされるアプリケーションのクラス名が、ＦＱＣＮ（Fully Qualified Class Name、完全修飾クラス名）で格納される。図示例では、具体的なアプリケーションのクラス名として、「org.example.TestedClass 」を例示している。

使用クラス名３０２には、前述の対象クラスの内部で直接使用しているクラスのクラス名が、ＦＱＣＮで格納される。この項目には、複数個のデータが格納されてよい。図示例では、具体的なクラス名として、「net.example.utils.Util.checkMyTest」、「org.example.testing.Dollers 」を例示している。

図４はテストケース実行情報が格納されるリポジトリ内のレコードについて説明する図である。このレコードには、テストケースクラス名４０１と、テストケースメソッド名４０２と、使用対象クラス名４０３と、重要度４０４と、実行実績時間４０５とが格納される。そして、テストケースクラス名４０１とテストケースメソッド名４０２との２つで、テストケースに付与されたテストケース名となる。

テストケースクラス名４０１には、テストケースのメソッドが格納されているクラス名が、ＦＱＣＮで格納される。図示例では、具体的なテストケースクラス名４０１として、「org.example.ci.TestSample」を例示している。

テストケースメソッド名４０２には、テストケースのメソッド名が格納される。図示例では、具体的なテストケースメソッド名４０２として、「TestSample.Test 」を例示している。

使用対象クラス名４０３には、テストケースメソッド内部で使用される対象アプリケーション内部のクラス名が、ＦＱＣＮで格納される。この使用対象クラス名４０３の項目には、複数個のデータが格納されてよい。図示例では、具体的な使用対象クラス名４０３として、「org.example.TestedClass 」及び「net.example.utils.Util」を例示している。

重要度４０４には、当該テストケースを実行するか否かを判断するための整数値が格納される。この値は、１〜５程度とされるのが普通であるが、より詳細に重要度を設定したい場合、重要度の値の範囲をより広くとることも可能である。そして、この重要度は、小さい値程重要であり、テストの実行が行われるべきものであるとする。図示例では、具体的な重要度４０４として、「１５」を例示している。

実行実績時間４０５には、当該テストケースが実際に実行された際の時間が、単位ミリ秒で格納される。この実行実績時間４０５の項目には、複数個のデータが格納されてよい。図示例では、具体的な実行実績時間４０５として、１回目〜３回目の実行実績時間「１０ミリ秒」、「１５ミリ秒」、「１２ミリ秒」を例示している。

図５はテストケース更新情報が格納されるリポジトリ内のレコードについて説明する図である。このレコードには、テストケースクラス名５０１と、テストケースメソッド５０２と、メソッドのチェックサム５０３とが格納されている。

テストケースクラス名５０１及びテストケースメソッド５０２は、図４により説明したレコードのものと同一のものである。メソッドのチェックサム５０３は、テストケースメソッドの内容から導き出されるチェックサムである。ここでは、ＭＤ５によるメッセージダイジェストを使用している。そして、このチェックサム５０３の情報は、テストケースの変更が行われたかどうかを示しており、テストのときに比較される情報である。

図６は本発明の実施形態での全体の処理動作を説明するシーケンスチャートであり、次に、これについて説明する。なお、図６において、ＳＣＭはソース構成管理ツール１０１を、ＣＩは継続的インテグレーションツール１０２を、テストＦＷはテストフレームワーク１０５をそれぞれ示している。また、図６に太い黒枠で囲んだ部分が、本発明の実施形態での独自の動作である。

（１）開発者からソース登録を受けたソース構成管理ツール１０１から継続的インテグレーションツール１０２に変更通知があったことをトリガーとして、テストケース選択部１０３は、継続的インテグレーションツール１０２より実行される。このとき、継続的インテグレーションツール１０２から選択部１０３に変更となったファイルの名称が渡される（ステップ６０１〜６０３）。

（２）選択部１０３は、渡されたファイルの名称に基づいて、ソース構成管理ツール１０１からそのファイルを取得し、取得したファイルを解析する。このファイルの解析の詳細については、図７を参照して後述する（ステップ６０４、６０５）。

（３）解析した結果は、図３により説明したリポジトリのテスト対象アプリケーションクラス使用情報に格納される（ステップ６０６）。

（４）テストケース選択部１０３で全てのファイルの解析が終了した後、テストの実行を開始する。このため、まず、継続的インテグレーションツール１０２は、ソース構成管理ツールからファイルを取得して、対象アプリケーションを、テスト対象アプリケーション１０６としてビルドする（ステップ６１１、６１２）。

（５）その後、テストケース選択部１０３は、継続的インテグレーションツール１０２より実行される。このとき、実施重要度と実施時間閾値とが継続的インテグレーションツール１０２からテストケース選択部１０３に渡される。渡される実施重要度は、テストケースの重要度がこれよりも低いもののみを実施候補とするというものである。また、実施時間閾値は、テストケースの実行実績時間の平均がこれを超えるものは実施しないというものである（ステップ６２１）。

（６）テストケース選択部１０３は、先程渡されたファイル名と、テストケース実行情報の使用対象クラス名とが一致するレコードをリポジトリから取得し、取得したテストケースの中から、実行するテストケースを選択する。この実行するテストケースを選択する処理の詳細については、図８を参照して後述する（ステップ６２２、６２３）。

（７）テストケース選択部１０３は、選択したテストケースメソッド名をテストフレームワーク１０５に渡してテスト実行を指示し、テストフレームワーク１０５は、実際のテストケースメソッドをテスト対象アプリケーション１０６から呼び出してテストを実行する（ステップ６２４〜６２６）。

（８）テストの結果とテストに要した時間との情報は、テストフレームワーク１０５からテストケース選択部１０３に渡され、テストケース選択部１０３は、成功したテストケースの実行実績時間を、リポジトリのテストケース実行情報に追記する（ステップ６２７、６２８）。

図７は図６に示して説明したシーケンスにおけるステップ６０５での選択部１０３が行うファイル解析の処理動作を説明するフローチャートであり、次に、これについて説明する。

（１）一般に、ソース構成管理ツール１０１には、対象アプリケーションのファイルと共に、テストコードが格納されているので、テストケース選択部１０３は、ソース構成管理ツール１０１から取得したファイルの解析を行うに際して、まず、取得したファイルが対象アプリケーションであるか、テストコードであるかを判定する（ステップ７０１）。

（２）ステップ７０１の判定で、取得した解析対象のファイルが対象アプリケーションであった場合、選択部は、ソースを解析し、そのファイルが直接使用しているクラスの名前を取得する。このとき、対象アプリケーション内のクラスのみ取得する（ステップ７０２）。

（３）そして、そのファイルの情報が図３に示して説明したテスト対象アプリケーションクラス使用情報にすでに格納されているか否かをチェックし、格納されていた場合に、一旦その情報を全て消去する。次に、テスト対象アプリケーションクラス使用情報に今回取得した情報を格納して、ここでの処理を終了する（ステップ７０３）。

（４）ステップ７０１の判定で、取得した解析対象のファイルがテストケースであった場合、ファイル全体と各メソッドのチェックサムとを取得し、次に、図５に示して説明したテストケース更新情報からテストケースクラスの情報を取得して比較を行う（ステップ７０４）。

（５）ステップ７０４でのチェックサムの比較からメソッドに変更があったか否かを判定し、メソッドに変更があった場合は、テストケース更新情報の当該情報を消去し、新しい情報を設定して、ここでの処理を終了する。また、メソッドに変更がなかった場合、何もせずにここでの処理を終了する（ステップ７０５、７０６）。

図８は図６に示して説明したシーケンスにおけるステップ６２３での選択部１０３が行うテストケース選択の処理動作を説明するフローチャートであり、次に、これについて説明する。

（１）テストケース選択部１０３は、テストケース選択の処理を開始すると、まず、リポジトリの図４に示して説明したテストケース実行情報から、対象となるテストケースの情報を取得し、起動時に渡された実施重要度と取得したテストケースの重要度とを比較する（ステップ８０１、８０２）。

（２）ステップ８０２での比較の処理で、テストケースの重要度が、起動時に渡された実施重要度より小さかった場合、起動時に渡された実施時間閾値と取得したテストケースの実績時間の平均とを比較する（ステップ８０３）。

（３）ステップ８０２での比較の処理で、テストケースの重要度が、起動時に渡された実施重要度と等しいか、大きかった場合、あるいは、ステップ８０３の比較で、テストケースの実績時間の平均が、起動時に渡された実施時間閾値と等しいか、大きかった場合、そのテストケースをテスト実行対象とはしないとして、ここでの処理を終了する（ステップ８０４）。

（４）ステップ８０３での比較の処理で、テストケースの実績時間の平均が、起動時に渡された実施時間閾値より小さかった場合、すなわち、テストケースの重要度が、起動時に渡された実施重要度より小さく、かつ、テストケースの実績時間の平均が、起動時に渡された実施時間閾値より小さかった場合、そのテストケースをテスト実行対象とするとして、ここでの処理を終了する（ステップ８０５）。

前述した本発明の実施形態での各処理は、プログラムにより構成し、情報処理装置に実行させることができ、また、それらのプログラムは、ＦＤ、ＣＤＲＯＭ、ＤＶＤ等の記録媒体に格納して提供することができ、また、ネットワークを介してディジタル情報により提供することができる。

本発明の一実施形態によるプログラムのテスト時にテストケースの選択を行うテストケースの選択システムの構成を示すブロック図である。 テストケース選択部の内部構造を示すブロック図である。 テスト対象アプリクラス使用情報が格納されるリポジトリ内のレコードについて説明する図である。 テストケース実行情報が格納されるリポジトリ内のレコードについて説明する図である。 テストケース更新情報が格納されるリポジトリ内のレコードについて説明する図である。 本発明の実施形態での全体の処理動作を説明するシーケンスチャートである。 図６に示して説明したシーケンスにおけるステップ６０５での選択部が行うファイル解析の処理動作を説明するフローチャートである。 図６に示して説明したシーケンスにおけるステップ６２３での選択部が行うテストケース選択の処理動作を説明するフローチャートである。

符号の説明

１０１ ソース構成管理ツール
１０２ 継続的インテグレーションツール
１０３ テストケース選択部
１０４ リポジトリ
１０５ 自動テストフレームワーク
１０６ テスト対象アプリケーション
１０７〜１０９ 端末
２０１ 解析部
２０２ 更新部
２０３ テスト部

Claims (3)

1. 継続的インテグレーション手法を用いてプログラムの開発を行う際に実施するテストを効率的に実施することができるようにテストケースを選択するテストケースの選択方法において、
   情報処理装置内のリポジトリにテストケースの属性として重要度及び実行実績時間を保持させると共に、前記情報処理装置内に継続的インテグレーションツールとテストケース選択手段とを備え、
   前記テストケース選択手段は、開発者からソース登録を受けたソース構成管理ツールから継続的インテグレーションツールにソース変更の通知があったときに、継続的インテグレーションツールから渡された変更ファイルの解析を行い、解析結果を前記リポジトリに格納し、その後に継続的インテグレーションツールから渡された実施重要度及び実施時間閾値と、前記リポジトリに格納されたテストケースの属性として重要度及び実行実績時間とから実行すべきテストケースを選択することを特徴とするテストケースの選択方法。
2. 前記テストケース選択手段は、渡された実施重要度と取得したテストケースの重要度とを比較し、渡された実施時間閾値と取得したテストケースの実績時間の平均とを比較し、テストケースの重要度が、起動時に渡された実施重要度より小さく、かつ、テストケースの実績時間の平均が、起動時に渡された実施時間閾値より小さかった場合、そのテストケースをテスト実行対象とするとしてテストケースを選択することを特徴とする請求項１記載のテストケースの選択方法。
3. 継続的インテグレーション手法を用いてプログラムの開発を行う際に実施するテストを効率的に実施することができるようにテストケースを選択するテストケースの選択システムにおいて、
   情報処理装置内のリポジトリにテストケースの属性として重要度及び実行実績時間を保持させると共に、前記情報処理装置内に継続的インテグレーションツールとテストケース選択手段とを備え、
   前記テストケース選択手段は、開発者からソース登録を受けたソース構成管理ツールから継続的インテグレーションツールにソース変更の通知があったときに、継続的インテグレーションツールから渡された変更ファイルの解析を行う解析部、解析の結果を前記リポジトリに格納する更新部、及び、その後に継続的インテグレーションツールから渡された実施重要度及び実施時間閾値と前記リポジトリに格納されたテストケースの属性として重要度及び実行実績時間とから実行すべきテストケースを選択するテスト部を備えて構成されたことを特徴とするテストケースの選択システム。

Images