(57)【要約】  【課題】新たに行った修正により再びエラーとなる可能性の高さを示し得る、テストケースの優先度を決定するための技術を提供【解決手段】情報処理装置は、過去の修正を特定する第１の修正識別子と、過去の修正により修正を行った、プログラムに含まれる関数を特定する第１の関数識別子とを関連付ける修正履歴表を格納する格納部と、新たな修正において修正を行った、プログラムに含まれる関数を特定する第２の関数識別子を取得する取得部と、格納部から読み出した修正履歴表内の第１の修正識別子の各々に対し、当該第１の修正識別子に関連付けられる１以上の第１の関数識別子と取得した１以上の第２の関数識別子のうち一致する関数識別子の数を求め、当該一致する関数識別子の数に基づいて、第１の修正識別子により特定される修正をテストするテストケースの優先度を決定する優先度決定部とを備える。  【選択図】  図１
2008129661.tif 000002
【特許請求の範囲】
【請求項１】
情報処理装置において、１以上の関数を含むプログラムの回帰テストにおいて実施すべきテストケースの優先度を決定する方法であって、
前記情報処理装置の格納部から、過去の修正を特定する第１の修正識別子と、前記過去の修正において修正を行った前記関数を特定する第１の関数識別子とを関連付ける修正履歴表を読み出すステップと、
新たな修正において修正を行った前記関数を特定する第２の関数識別子を取得するステップと、
前記修正履歴表内の前記第１の修正識別子の各々に対し、当該第１の修正識別子に関連付けられる１以上の前記第１の関数識別子と前記取得した１以上の前記第２の関数識別子のうち一致する関数識別子の数を求めるステップと、
前記求めた関数識別子の数に基づいて、前記新たな修正に対する、前記修正履歴表内の前記第１の修正識別子により特定される修正をテストするテストケースの優先度を決定するステップと、
を含む方法。
【請求項２】
前記第２の関数識別子を取得するステップは、前記情報処理装置の入力部を介して前記第２の関数識別子を取得する、請求項１に記載の方法。
【請求項３】
前記第２の関数識別子を取得するステップは、前記情報処理装置の入力部を介して前記新たな修正を特定する第２の修正識別子を受け取るステップと、前記第２の修正識別子に関連付けられるバージョンの前記プログラムのソースコードと、前記バージョンの１つ前のバージョンの前記プログラムのソースコードとを比較し不一致となる関数を検出することにより、前記第２の関数識別子を取得するステップとを含む、請求項１に記載の方法。
【請求項４】
前記一致する関数識別子の数を求めるステップは、一致した前記関数識別子により特定される関数の修正者が、前記新たな修正と前記過去の修正とで異なるかどうかを判定することにより前記特定される関数に重み付けするステップを更に含み、重み付けの結果を考慮して一致する関数識別子の数を求める、請求項１に記載の方法。
【請求項５】
前記一致した関数識別子により特定される関数の前記修正者が、前記新たな修正と前記過去の修正とで異なる場合、異ならない場合に比べて前記特定される関数に大きい重み付けをする、請求項４に記載の方法。  
【請求項６】
前記一致する関数識別子の数を求めるステップは、一致した前記関数識別子により特定される関数の前記新たな修正による修正量に応じて、前記特定される関数に重み付けをするステップを更に含み、重み付けの結果を考慮して一致する関数識別子の数を求める、請求項1に記載の方法。
【請求項７】
前記一致した関数識別子により特定される関数の前記新たな修正による修正量が多い場合、少ない場合に比べて前記特定される関数に大きい重み付けする、請求項６に記載の方法。  
【請求項８】
前記一致する関数識別子の数を求めるステップは、一致した前記関数識別子により特定される関数の過去における修正回数に応じて、前記特定される関数に重み付けするステップを更に含み、重み付けの結果を考慮して一致する関数識別子の数を求めることにより前記優先度を決定する、請求項1に記載の方法。
【請求項９】
前記一致した関数識別子により特定される関数の前記過去における修正回数が多い場合、少ない場合に比べて前記特定される関数に大きい重み付けする、請求項８に記載の方法。
【請求項１０】
前記情報処理装置の出力部を介して、決定された前記優先度の順に前記第１の修正識別子を並べた前記第１の修正識別子のリストを出力するステップを更に含む、請求項１に記載の方法。
【請求項１１】
１以上の関数を含むプログラムの回帰テストにおいて実施すべきテストケースの優先度を決定するための情報処理装置であって、
過去の修正を特定する第１の修正識別子と、前記過去の修正において修正を行った前記関数を特定する第１の関数識別子とを関連付ける修正履歴表を格納する格納部と、
新たな修正において修正を行った前記関数を特定する第２の関数識別子を取得する取得部と、
前記格納部から読み出した前記修正履歴表内の前記第１の修正識別子の各々に対し、当該第１の修正識別子に関連付けられる１以上の前記第１の関数識別子と前記取得した１以上の前記第２の関数識別子のうち一致する関数識別子の数を求め、当該求めた数に基づいて、前記第１の修正識別子により特定される修正をテストする前記テストケースの優先度を決定する優先度決定部と、
を含む優先度を決定するための情報処理装置。
【請求項１２】
１以上の関数を含むプログラムの回帰テストにおいて実施すべきテストケースの優先度を決定するためのプログラムであって、前記プログラムは、情報処理装置に、
前記情報処理装置の格納部から、過去の修正を特定する第１の修正識別子と、前記過去の修正において修正を行った前記関数を特定する第１の関数識別子とを関連付ける修正履歴表を読み出すステップと、
新たな修正において修正を行った前記関数を特定する第２の関数識別子を取得するステップと、
前記修正履歴表内の前記第１の修正識別子の各々に対し、当該第１の修正識別子に関連付けられる１以上の前記第１の関数識別子と前記取得した１以上の前記第２の関数識別子のうち一致する関数識別子の数を求めるステップと、
前記求めた関数識別子の数に基づいて、前記新たな修正に対する、前記修正履歴表内の前記第１の修正識別子により特定される修正をテストするテストケースの優先度を決定するステップとを実行させる、  
優先度を決定するためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はプログラムの回帰テストにおいて実施すべきテストケースの選択に関し、特に実施すべきテストケースが複数ある場合にそのテストケースの優先度を決定する技術に関する。
【背景技術】
【０００２】
プログラムに機能拡張や問題修正のための変更を加える場合、その変更により新たな問題が発生していないか、回帰テストを行うのが一般的である。回帰テストでは、変更の確認に加え、過去に実施済みのテストケースが再度実施される。しかしながら、変更を行うたび過去のすべてのテストケースを行うとなると膨大な工数を要してしまう。そこで、過去に行ったテストケースから実施すべきテストケースをいくつか選択し、工数を減らすことが従来から行われている。
【０００３】
過去に行ったテストケースから実施すべきテストケースをいくつか選択する従来技術として、例えば特許文献１がある。特許文献１は、プログラムを構成する各ソースファイルについて、ソースファイルに修正が施されたとき、当該修正を特定する修正ＩＤと修正されたソースファイルのソースファイル名と当該ソースファイルのテストに使用したテストケースとの対応関係を示す対応表を作成しておき、プログラムを変更した場合に、変更のあったソースファイルに関連付くテストケースを選択して再実行する技術を開示する。
【０００４】
しかし、特許文献１の技術は、変更のあったソースファイルに関連するテストケースのリストを提供するも、リストされた各テストケースの優先度に関する情報は提供しない。そのためプログラムの開発者は、リストされるテストケースのうちどのテストケースがよりエラーになる可能性が高いのか判断することができず、変更による新たな問題を効率的に発見することができない。
【０００５】
そこで、このような問題を解決するべく、実施すべきテストケースの優先度を決定する技術が開発された。例えば、特許文献２は、複数の状態間を遷移しながら動作するソフトウェアの各状態に関する修正回数を開発履歴情報として記憶しておき、状態間をトリガで連結してテストを行うテストケースを複数作成した場合に、開発履歴情報を用いて各テストケースに重みを付ける技術を開示する。特許文献２はまた、実機における使用実績の有無に応じて各テストケースに重み付けを行う技術、更にテストケースを実行した結果の合否に応じて重み付けする技術も開示する。
【０００６】
【特許文献１】特開２００３−９１４３１（第５−６頁、図２及び図９）
【特許文献２】特開２００４−５３９９（第１１−１４頁）
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献２が開示するテストケースの優先度は、信頼性の低い部分を重点的にテストすることを目的として求められるものであり、新しく行った修正とは無関係に単に過去の修正回数や使用実績、テストケースの合否に基づいて決定されるものである。従って、プログラムにどのような変更を加えようとも、常に同じテストケースが優先して選択されてしまう。
【０００８】
そこで本発明は、プログラムの回帰テストにおいて、プログラムの修正に伴って新たにテストを実施しなければならないテストケースを抽出するとともに、抽出したテストケースの各々に対し、新たに行った修正との関係から再びエラーとなる可能性の高さを示す優先度を決定するための情報処理装置、方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記の目的を達成する本発明は、次のような、情報処理装置において実行される、プログラムの回帰テストにおいて実施すべきテストケースの優先度を決定する方法によって実現される。ここでプログラムは１以上の関数を含む。この方法では、情報処理装置の格納部から、過去の修正を特定する第１の修正識別子と、過去の修正において修正を行った関数を特定する第１の関数識別子とを関連付ける修正履歴表が読み出される。また、新たな修正において修正を行った関数を特定する第２の関数識別子が取得される。そして、修正履歴表内の第１の修正識別子の各々に対し、当該第１の修正識別子に関連付けられる１以上の第１の関数識別子と取得した１以上の第２の関数識別子のうち一致する関数識別子の数が求められる。そして、修正履歴表内の第１の修正識別子に対し求められた一致する関数識別子の数に基づいて、その第１の修正識別子により特定される修正をテストするテストケースの優先度が決定される。
【００１０】
過去に修正されたことがある関数を修正すると、その過去の修正をテストする過去のテストケースは新規修正により再びエラーとなりやすい。そして、新規修正において修正する複数の関数と、過去の修正において修正した複数の関数との一致する数が多くなるほど、その過去の修正をテストする過去のテストケースが新規修正により再びエラーとなる可能性は高くなる。そこで本願発明では、新たな修正において修正される関数と、過去の修正において修正された関数の重なりの程度を、その過去の修正をテストする過去のテストケースの優先度とする。なお、一般に関数という用語は、引数と呼ばれるデータを受け取って、一定の処理を実行し結果を返す一連の命令群を意味する。しかし本願発明における関数は、引数を取らない関数や結果を返さない関数も含むものとする。
【００１１】
上記方法において、第２の関数識別子は、情報処理装置の入力部を介してユーザから直接取得してよい。これに代えて、ユーザからは、情報処理装置の入力部を介して新たな修正を特定する第２の修正識別子のみを受け取ってもよい。この場合、修正を特定する修正識別子とその修正において修正が行われたプログラムのバージョンを対応付ける対応表を参照して、第２の修正識別子に関連付けられるバージョンのプログラムのソースを得る。そして当該ソースと、上記バージョンの１つ前のバージョンのプログラムのソースとを比較し不一致となる関数を検出することにより、第２の関数識別子を取得する。  
【００１２】
好ましくは上記一致する関数識別子の数を求める際に、一致した関数識別子により特定される関数の修正者が、新たな修正と過去の修正とで異なるかどうかを判定することにより、特定される関数に重み付けを行う。そして、重み付けの結果を考慮して一致する関数識別子の数を求める。より具体的には、一致した関数識別子により特定される関数の修正者が、新たな修正と過去の修正とで異なる場合、異ならない場合に比べて特定される関数に大きい重み付けをする。
【００１３】
上述したように過去に修正されたことがある関数を修正すると、その過去の修正をテストする過去のテストケースは新規修正により再びエラーとなりやすい。しかし過去の修正が自分自身によって行われたものであれば、そのような可能性は、過去の修正が他人によって行われたものである場合よりも低い。そこで、本願発明では、新たな修正を行った修正者と、過去の修正を行った修正者が同一か否かで一致する関数に重み付けを行う。
【００１４】
また、好ましくは上記一致する関数識別子の数を求める際に、一致した関数識別子により特定される関数の新たな修正における修正量に応じて、特定される関数に重み付けを行う。そして、重み付けの結果を考慮して一致する関数識別子の数を求める。より具体的には、一致した関数識別子により特定される関数の新たな修正における修正量が多い場合、少ない場合に比べて特定される関数に大きい重み付けする。
【００１５】
上述したように過去に修正されたことがある関数を修正すると、その過去の修正をテストする過去のテストケースは新規修正により再びエラーとなりやすい。しかし、新たな修正により修正した量が少ない場合は、たとえ同一の関数が過去に修正されていたとしても、その過去の修正をテストする過去のテストケースが新規修正により再びエラーとなる可能性は低い。そこで、本願発明では、新規修正による修正量に応じて一致する関数に重み付けをする。
【００１６】
また、好ましくは上記一致する関数識別子の数を求める際に、一致した関数識別子により特定される関数の過去の修正回数に応じて、特定される関数に重み付けを行う。そして、重み付けの結果を考慮して一致する関数識別子の数を求める。より具体的には、一致した関数識別子により特定される関数の過去の修正回数が多い場合、少ない場合に比べて特定される関数に大きい重み付けする。
【００１７】
上述したように過去に修正されたことがある関数を修正すると、その過去の修正をテストする過去のテストケースは新規修正により再びエラーとなりやすい。そのエラーとなる可能性は、その関数が過去に修正されている回数が多いほど高くなる。そこで、本願発明では、過去の修正回数に応じて一致する関数に重み付けをする。
【００１８】
また好ましくは、上記方法は、情報処理装置の出力部を介して、決定された優先度の順に第１の修正識別子を並べた第１の修正識別子のリストを出力する。
【００１９】
以上、１以上の関数を含むプログラムの回帰テストにおいて実施すべきテストケースの優先度を決定する方法として本発明を説明したが、本発明は、そのような方法を情報処理装置に実行させるためのプログラムとして把握することもできる。また本発明は、１以上の関数を含むプログラムの回帰テストにおいて実施すべきテストケースの優先度を決定するための情報処理装置として把握することもできる。
【発明の効果】
【００２０】
本発明によれば、プログラムの回帰テストにおいて、再度テストすべき過去のテストケースが、新たに行った修正によりエラーとなる可能性の高さを示す優先度と一緒に提供される。そのため、再度テストすべき過去のテストケースが多数存在する場合でも、優先度の高いテストケースを重点的に検査することで、新たな変更による新たな問題を効率的に発見することが可能となる。また、求められた優先度に基づいて、新たに行った修正を承認することも可能となる。すなわち、新たな修正が重要性の低い問題を修正するものであるにもかかわらず、非常に重要な機能をテストする過去のテストケースの優先度が高く、新たな修正によりエラーとなる可能性が高いとされた場合は、その新たな修正を承認しないことも可能である。
【発明を実施するための最良の形態】
【００２１】
以下、本発明を実施するための最良の形態を図面に基づいて詳細に説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。なお、実施の形態の説明の全体を通じて同じ要素には同じ番号を付している。
【００２２】
図１は、本発明の一実施形態に係る、プログラムの回帰テストにおいて実施すべきテストケースの優先度を決定するための情報処理装置１００の機能構成の一例を示す。情報処理装置１００は、優先度決定部２００、新規修正関連データ２３５、修正履歴表２４０、第１の関数リスク表２４５、及び第２の関数リスク表２５０を格納する第１格納部２３０、並びにバージョン対応表２６０及び各バージョンのプログラムのソースコード２６５を格納する第２格納部２５５を備える。ここで優先度決定部２００は、テストケースの優先度を決定する機能を有し、カウント部２０５、第１重み付け部２１０、第２重み付け部２１５、及び第３重み付け部２２０を含む。
【００２３】
情報処理装置１００は更に、新規修正関連データ取得部２７０、修正履歴作成・更新部２７５、第１の関数リスク表作成部２８０、第２の関数リスク表作成部２８５、及びリスト作成・出力部２９０を備える。なお、第１格納部２３０及び第２格納部２５５は物理的に同一の記憶装置であってよい。また、第１格納部２３０及び第２格納部２５５に格納されるデータは、物理的に同一の記憶装置に格納されなければならないものではない。
【００２４】
新規修正関連データ２３５は、プログラムに対して新たに行われた修正に関するデータである。一例として、新規修正関連データ２３５は、問題修正や機能追加などの修正要因により新たに行った修正を特定する修正識別子、新たな修正が行われた関数を特定する関数識別子を含み、更に、新たな修正が行われた関数を含むファイルを特定するファイル識別子、及び新たな修正を行った修正者を特定する修正者識別子を含んでもよい。なお、本実施形態ではプログラムは複数のファイルから構成されるものとする。図２（ａ）に、新規修正関連データ２３５の一例を示す。図２（ａ）に示すように、本実施形態では、修正識別子として修正ＩＤ、関数識別子として関数名、修正者識別子として修正者名、ファイル識別子としてファイル名をそれぞれ利用する。
【００２５】
バージョン対応表２６０は、プログラムに対して行われた修正を特定する修正ＩＤと、当該修正が施されたプログラムのバージョンを対応付ける表である。図２（ｂ）に、バージョン対応表２６０の一例を示す。バージョン対応表２６０はマニュアルで作成してもよく、市販のソースコード管理ツールを利用して作成してもよい。例えばＩｎｔｅｒｎａｔｉｏｎａｌ  Ｂｕｓｉｎｅｓｓ  Ｍａｃｈｉｎｅｓ（ＩＢＭ、ＩＢＭは登録商標）社より入手可能なＲａｔｉｏｎａｌ（ＩＢＭ社の登録商標）ＣｌｅａｒＣａｓｅ（ＩＢＭ社の登録商標）ソースコード管理ツールは、プログラムに新たな修正を行うと、当該修正に対し自動的に修正ＩＤを振り、これを修正が施されたプログラムのバージョンと対応付けて記憶し管理する。なお、バージョン対応表２６０を格納する第２格納部２５５は、本実施形態では各バージョンのプログラムのソースコード２６５それ自体も格納する。
【００２６】
新規修正関連データ取得部２７０は、プログラムに対して新たに修正が行われた場合に、新規修正関連データ２３５を取得し、取得した新規修正関連データ２３５を一時的に第１格納部２３０に格納する。ここで、一時的に格納するとは、後述するカウント部２０５により使用され、また修正履歴表２４０を更新するために使用された後は削除してもよいことを意味する。新規修正関連データ取得部２７０は、一例として、情報処理装置１００の入力部を介してユーザから新規修正関連データ２３５を取得する。
【００２７】
あるいは、新規修正関連データ取得部２７０は、情報処理装置１００の入力部を介してユーザから新たな修正を特定する新規修正ＩＤを取得してもよい。この場合、新規修正関連データ取得部２７０は、バージョン対応表２６０を参照して、新規修正ＩＤに対応するプログラムのバージョンを得る。そして当該バージョンのプログラムのソースコードと、上記バージョンの１つ前のバージョンのプログラムのソースコードとを比較して不一致となる関数を検出することにより、新規修正関連データ２３５を取得する。  
【００２８】
修正履歴表２４０は、プログラムに対して行われた過去の修正に関するデータをまとめた表である。一例として、修正履歴表２４０は、修正を特定する修正ＩＤと、当該修正において修正を行った関数を特定する関数名とを関連付け、更に、修正者名、修正が行われた関数を含むファイルのファイル名を関連付けてもよい。図３（ａ）に、修正履歴表２４０の一例を示す。図３（ａ）を見ると分かるように、修正履歴表２４０の１つのエントリは過去の新規修正関連データ２３５である。
【００２９】
修正履歴作成・更新部２７５は、修正履歴表２４０を作成し、プログラムに対して新たな修正が行われると修正履歴表２４０を更新する。修正履歴作成・更新部２７５による修正履歴表２４０の更新は、修正履歴表２４０に新規修正関連データ２３５を追加することにより行われる（図２（ａ）、図３（ａ）、（ｂ）参照）。ここで修正ＩＤにより特定される修正の例を説明する。例えば、図３の修正ＩＤ「１」により特定される修正はスペルミスの訂正であり、Function1_2、Fuction2_1、 Fuction3_1において画面に表示させる文字として記載される文字のスペルミスが訂正される。また図３の修正ＩＤ「９」により特定される修正はループ数の修正であり、Function1_1、Fuction1_2においてループで回転させる回数が修正される。
【００３０】
カウント部２０５は、第１格納部２３０から新規修正関連データ２３５と修正履歴表２４０を読み出し、修正履歴表２４０内の修正ＩＤの各々に対し、当該修正ＩＤに関連付けられる１以上の関数名と新規修正関連データ２３５内の１以上の関数名を比較して、一致する関数名の数をカウントする。カウントされた数は、対応する修正ＩＤの修正をテストするテストケースの優先度として、各々優先度決定部２００により修正履歴表２４０に追加される。
【００３１】
このような過去のテストケースの優先度の決定方法は、次のような推論に基づく。すなわち、過去に修正されたことがある関数を修正すると、その過去の修正をテストする過去のテストケースは新規修正により再びエラーとなりやすい、という推論である。そして、新規に修正する複数の関数と、過去の修正において修正した複数の関数とが一致すればするほど、その過去の修正をテストするテストケースは新規修正により再びエラーとなりやすい、という推論である。
【００３２】
図４（ａ）、（ｂ）に、新規修正関連データ２３５と優先度を追加された修正履歴表２４０の一例をそれぞれ示す。図４（ａ）の新規修正関連データ２３５をみると、新規修正により、Function1_2、Function2_1、Function3_1の３つの関数が修正されている。そこで図４（ｂ）の修正履歴表２４０を検討する。過去の修正ＩＤ「１」では、Function1_1、Function1_2、Function2_1の３つの関数が修正されているが、そのうち新規修正ＩＤ「９」で修正された関数と同じ関数は、Function1_2とFunction2_1の２つである。そのため、新規修正ＩＤ「９」に対する過去の修正ＩＤ「１」の優先度は２となっている。
【００３３】
一方、過去の修正ＩＤ「５」では、過去の修正ＩＤ「１」と同じく３つの関数が修正されているが、新規修正ＩＤ「９」で修正された関数と同じ関数は、Function2_1の１つである。そのため、新規修正ＩＤ「９」に対する過去の修正ＩＤ「５」の優先度は１となっている。すなわち、新規修正において修正された関数との重なりの程度は修正ＩＤ「１」のほうが修正ＩＤ「５」よりも大きいため、新規修正により再びエラーとなる可能性は修正ＩＤ「１」のほうが高く、新規修正ＩＤ「９」に対する優先度は修正ＩＤ「１」のほうが大きい。
【００３４】
第１重み付け部２１０は、カウント部２０５が修正履歴表２４０内の修正ＩＤに関連付けられる関数名と新規修正関連データ２３５内の関数名とが一致すると判断した場合、一致した関数名により特定される関数の修正者が、新たな修正と修正履歴表２４０内の過去の修正とで異なるかどうかを判定することにより、特定される関数に重み付けをする。具体的には、第１重み付け部２１０は、一致した関数名により特定される関数の修正者が、新たな修正と修正履歴表２４０内の過去の修正とで異なる場合、異ならない場合に比べて特定される関数に大きい重み付けをする。
【００３５】
このような過去のテストケースの優先度の重み付け方法は、次のような推論に基づく。すなわち、過去に修正されたことがある関数を修正すると、その過去の修正をテストする過去のテストケースは新規修正により再びエラーとなりやすいが、過去の修正が自分自身によって行われたものであれば、そのような可能性は、過去の修正が他人によって行われたものである場合よりも低い、という推論である。
【００３６】
第１重み付け部２１０による重み付けの重みは、正の値であれば整数でも小数でもよくユーザによって設定される。第１重み付け部２１０により重み付けがなされる場合、カウント部２０５は、重み付けの結果を考慮して一致する関数名の数を求める。一例としてカウント部２０５は、一致する関数名の数に、第１重み付け部２１０による重み付けの重みをかける。カウント部２０５により求められた値は、対応する修正ＩＤの修正をテストするテストケースの優先度として、各々優先度決定部２００により修正履歴表２４０に追加される。
【００３７】
図５（ａ）、（ｂ）に、新規修正関連データ２３５と重み付けの結果に基づく優先度を追加された修正履歴表２４０の一例をそれぞれ示す。図５の例では、修正者が異なる場合の重みを「２」、修正者が同一の場合の重みを「１」としている。図５（ａ）の新規修正関連データ２３５をみると、新規修正の修正者は「ＰｅｒｓｏｎＢ」であり、Function1_2、Function2_1、Function3_1の３つの関数が修正されている。そこで図５（ｂ）の修正履歴表２４０を検討する。過去の修正ＩＤ「１」において、修正された関数のうち新規修正ＩＤ「９」で修正された関数と同じものは、Function1_2とFunction2_1の２つである。また、過去の修正ＩＤ「１」の修正者は「ＰｅｒｓｏｎＡ」であり新規修正の修正者と異なるため、これら関数に対する重みは２である。従って、新規修正ＩＤ「９」に対する過去の修正ＩＤ「１」の優先度は、一致する関数名の数２に重みの２を掛けて４となる。
【００３８】
一方、過去の修正ＩＤ「５」において、修正された関数のうち新規修正ＩＤ「９」で修正された関数と同じものはFunction1_2とFunction3_1であり、過去の修正ＩＤ「１」と同じく２つである。しかし、過去の修正ＩＤ「５」の修正者は「ＰｅｒｓｏｎＢ」であり新規修正の修正者と同一人であるため、これら関数に対する重みは１である。従って、新規修正ＩＤ「９」に対する過去の修正ＩＤ「５」の優先度は、一致する関数名の数２に重みの１を掛けて２となる。
【００３９】
すなわち、新規修正要より修正された関数との重なりの程度は、修正ＩＤ「１」と修正ＩＤ「５」で同じでありこの点だけに着目すれば、新規修正により再びエラーとなる可能性は、修正ＩＤ「１」も「５」も同じである。しかしながら、修正ＩＤ「５」による修正を行ったのは新規修正の修正者であるため、新規修正により再びエラーとなる可能性は低く、従って修正者を考慮した場合の新規修正ＩＤ「９」に対する優先度は修正ＩＤ「１」のほうが大きい。
【００４０】
第１の関数リスク表２４５は、新たな修正において修正した関数の修正量を示す表である。なお、修正により関数を新たに追加する場合もあるが、新規に追加された関数は過去の修正に影響を与えないと考えられるため、第１の関数リスク表２４５は、新規に追加された関数は含まないものとする。第１の関数リスク表作成部２８０は、第１の関数リスク表２４５を作成し、一時的に第１格納部２３０に格納する。ここで一時的に格納するとは、後述する第２重み付け部２１５により使用された後は、第１の関数リスク表２４５は削除してもよいことを意味する。第１の関数リスク表作成部２８０による第１の関数リスク表２４５の作成は、次のようにして行われる。
【００４１】
まず、第１の関数リスク表作成部２８０は対応表２６０を参照して、新規修正ＩＤに対応するプログラムのバージョンを得る。次に第１の関数リスク表作成部２８０は、新規修正関連データ２３５を参照して、変更のあった関数名を得る。そして、第２格納部２５５から取得したバージョンのプログラムのソースコードと、そのバージョンの１つ前のバージョンのプログラムのソースコードを読み出し、変更のあった関数を２つのバージョン間で比較することにより最終的に目的の修正量を得る。修正量は、関数に追加された行数、削除された行数、変更された行数の合計とする。ただし、コメントの追加、削除、変更は除く。図６（ａ）、（ｂ）は、それぞれ新規修正関連データ２３５と第１の関数リスク表２４５の一例である。
【００４２】
第２重み付け部２１５は、カウント部２０５が修正履歴表２４０内の過去の修正ＩＤに関連付けられる関数名と新規修正関連データ２３５内の関数名とが一致すると判断した場合、第１の関数リスク表２４５を参照して、一致した関数名により特定される関数の新たな修正における修正量が多いかどうかを判定することにより、特定される関数に重み付けをする。具体的には、第２重み付け部２１５は、一致した関数名により特定される関数の新たな修正における修正量が多い場合、少ない場合に比べて特定される関数に大きい重み付けする。
【００４３】
このような過去のテストケースの優先度の重み付け方法は、次のような推論に基づく。すなわち過去に修正されたことがある関数を修正すると、その過去の修正をテストするテストケースは新規修正により再びエラーとなりやすいが、新規修正による修正量が少ない場合は、たとえ同一の関数を過去に修正していたとしても、その過去の修正をテストするテストケースが新規修正により再びエラーとなる可能性は低い、という推論である。
【００４４】
第２重み付け部２１５による重み付けの重みは、修正量を反映する値であればよく、修正量そのものとしてもよい。第２重み付け部２１５により重み付けがなされる場合、カウント部２０５は、重み付けの結果を考慮して一致する関数名の数を求める。一例としてカウント部２０５は、一致する関数名があると、その関数に対して決定された重みを足し合わせていき合計値を求める。求められた合計値は、対応する修正ＩＤの修正をテストするテストケースの優先度として、各々優先度決定部２００により修正履歴表２４０に追加される。
【００４５】
図８（ａ）、（ｂ）、（ｃ）に、新規修正関連データ２３５、第１の関数リスク表２４５、重み付けの結果に基づく優先度を追加された修正履歴表２４０の一例をそれぞれ示す。図８の例では、重み付けの重みは関数の修正量そのものとしている。図８（ａ）の新規修正関連データ２３５を見ると分かるように、新規修正において修正された関数はFunction1_2、Function 2_1、Function 3_1の３つである。そのため、図８（ｂ）に示す第１の関数リスク表にもこれら３つの関数が含まれる。
【００４６】
そこで図８（ｃ）の修正履歴表２４０を検討する。過去の修正ＩＤ「１」において、修正された関数のうち新規修正ＩＤ「９」で修正された関数と同じものは、Function1_2とFunction2_1の２つである。ところでこれら関数のリスク値（修正量）は、それぞれ１０と２である。従って、新規修正ＩＤ「９」に対する過去の修正ＩＤ「１」の優先度は、一致する関数名のそれぞれの重み１０と２を足し合わせて１２となる。
【００４７】
一方、過去の修正ＩＤ「５」において、修正された関数のうち新規修正ＩＤ「９」で修正された関数と同じものは、Function1_2とFunction3_1の２つである。ところでこれら関数のリスク値（修正量）は、それぞれ１０と５０である。従って、新規修正ＩＤ「９」に対する過去の修正ＩＤ「５」の優先度は、一致する関数名のそれぞれの重み１０と５０を足し合わせて６０となる。
【００４８】
すなわち、新規修正において修正された関数との重なりの程度は、修正ＩＤ「１」と修正ＩＤ「５」で同じでありこの点だけに着目すれば、新規修正により再びエラーとなる可能性は、修正ＩＤ「１」も「５」も同じである。しかしながら、修正ＩＤ「５」では、Function1_2の他に新規修正において修正量の多い関数Function3_1が修正されているのに対し、修正ＩＤ「１」では、Function1_2の他に新規修正において修正量の少ない関数Function2_1が修正されている。そのため修正ＩＤ「１」に関連付けられるテストケースが新規修正により再びエラーとなる可能性は低い。従って新規修正による関数の修正量を考慮した場合、新規修正ＩＤ「９」に対する優先度は修正ＩＤ「５」のほうが大きい。  
【００４９】
第２の関数リスク表２５０は、関数の過去に修正された修正回数を示す表である。第２の関数リスク表作成部２８５は、第２の関数リスク表２５０を作成し、一時的に第１格納部２３０に格納する。ここで一時的に格納するとは、後述する第３重み付け部２２０により使用された後は削除してもよいことを意味する。第２の関数リスク表作成部２８５は、第１格納部２３０から修正履歴表２４０を読み出し、各関数について、修正履歴表２４０に表れる回数をカウントすることによりその修正回数を取得する。図７（ａ）、（ｂ）は、それぞれ修正履歴表２４０と第２の関数リスク表２５０の一例である。
【００５０】
第３重み付け部２２０は、カウント部２０５が修正履歴表２４０内の過去の修正ＩＤに関連付けられる関数名と新規修正関連データ２３５内の関数名とが一致すると判断した場合、第２の関数リスク表２５０を参照して、一致した関数名により特定される関数の過去における修正回数が多いかどうかを判定することにより、特定される関数に重み付けする。具体的には、第３重み付け部２２０は、一致した関数名により特定される関数の過去における修正回数が多い場合、少ない場合に比べて特定される関数に大きい重み付けする。
【００５１】
このような過去のテストケースの優先度の重み付け方法は、次のような推論に基づく。すなわち過去に修正されたことがある関数を修正すると、その過去の修正をテストするテストケースは新規修正により再びエラーとなりやすく、そのエラーとなる可能性は、その関数が過去に修正されている回数が多いほど高くなる、という推論である。
【００５２】
第３重み付け部２２０による重み付けの重みは、修正回数を反映する値であればよく、修正回数そのものとしてもよい。第３重み付け部２２０により重み付けがなされる場合、カウント部２０５は、重み付けの結果を考慮して一致する関数名の数を求め、テストケースの優先度を決定する。一例としてカウント部２０５は、一致する関数名があると、その関数に対して決定された重みを足し合わせていき合計値を求める。決定された優先度は、対応する修正ＩＤの修正をテストするテストケースの優先度として、各々優先度決定部２００により修正履歴表２４０に追加される。なお、第３重み付け部２２０とカウント部２０５による処理は、第１の関数リスク表の代わりに第２の関数リスク表を使用すれば、図８を参照して説明した第２重み付け部２１５とカウント部２０５による処理と同じであるため、具体例による説明は省略する。
【００５３】
リスト作成部２９０は、優先度が追加された修正履歴表２４０を第１格納部２３０から読み出し、修正ＩＤをその優先度の順に並べて、リストを作成する。
【００５４】
以上のように、本発明の実施形態に係る情報処理装置１００によれば、プログラムの回帰テストにおいて、新たに行った修正との関係から再度テストすべき過去のテストケースが、その優先度とともに提供される。そのため、テストすべき過去のテストケースが多数存在する場合でも、優先度の高い、従ってエラーの可能性が高い過去のテストを重点的に検査することが可能となり、新規修正により新たに起こる問題を効率的に発見することが可能となる。
【００５５】
次に、図９から図１５のフローチャートを参照して、本実施形態に係る情報処理装置１００の各部の動作を説明する。図９は新規修正関連データ取得部２７０による処理の流れの一例を示す。新規修正関連データ取得部２７０はまず、図２（ａ）に示す新規修正関連データ２３５の表を初期化する（ステップ１００）。そして、情報処理装置１００の入力部を介してユーザから新たな修正を特定する新規修正ＩＤと新たな修正を行った修正者の名前を受け取ると、新規修正関連データ取得部２７０はこれを修正関連データの表に設定する（ステップ１０５）。
【００５６】
次に新規修正関連データ取得部２７０は、バージョン対応表２６０を参照して、新規修正ＩＤに対応するプログラムのバージョンを取得する（ステップ１１０）。そして、新規修正関連データ取得部２７０は、取得したバージョンの１つ前のバージョンと取得したバージョンのソースコードを第２格納部２５５から読出し、これらを比較して不一致の関数を検出する（ステップ１１５）。新規修正関連データ取得部２７０は、新規修正関連データ２３５の表に、検出した不一致の関数の関数名と当該関数を含むファイルのファイル名をすべて設定する（ステップ１２０）。そして処理は終了する。このようにして、図２（ａ）に示されるような新規修正関連データ２３５が取得される。
【００５７】
図１０は、修正履歴作成・更新部２７５による処理の流れの一例を示す。新規修正関連データ取得部２７０から新規修正関連データ２３５取得の通知を受け取ることにより処理は開始し、修正履歴作成・更新部２７５はまず、第１格納部２３０から新規修正関連データ２３５を読み出す（ステップ１５０）。次に新規修正関連データ取得部２７０は、修正履歴表２４０が既に作成されているか判定し（ステップ１５５）、修正履歴表２４０が既に存在する場合（ステップ１５５：ＹＥＳ）、新規修正関連データ２３５を修正履歴表２４０に追加する（ステップ１６０）。修正履歴表２４０が存在しない場合（ステップ１５５：ＮＯ）、新規修正関連データ取得部２７０は新規修正関連データ２３５を修正履歴表２４０として新たに保存する（ステップ１６５）。そして、処理は終了する。このようにして、図３（ａ）に示されるような修正履歴表２４０が作成される。
【００５８】
図１１は、カウント部２０５による優先度決定の処理の流れの一例を示す。カウント部２０５はまず、第１格納部２３０から、新規修正関連データ２３５と修正履歴表２４０を読み出す（ステップ２００、２０５）。そしてカウント部２０５は、修正履歴表２４０にあるすべての修正ＩＤについて優先度を決定したかどうか判定する（ステップ２１０）。優先度が決定されていない修正ＩＤがある場合（ステップ２１０：ＮＯ）、カウント部２０５は修正履歴表２４０内の次の修正ＩＤを取得して現在の修正ＩＤとし、カウンタを０に初期化する（ステップ２１５）。
【００５９】
次にカウント部２０５は、現在の修正ＩＤに関連付けられるすべてのファイルについてファイル名を取得したかどうか判定する（ステップ２２０）。取得していないファイル名がある場合（ステップ２２０：ＮＯ）、カウント部２０５は修正履歴表２４０内の次のファイル名を取得する（ステップ２２５）。カウント部２０５は更に、取得したファイル名のすべての関数について関数名を取得したかどうか判定する（ステップ２３０）。すべての関数について関数名を取得している場合（ステップ２３０：ＹＥＳ）、処理はステップ２２０へ戻る。取得していない関数名がある場合（ステップ２３０：ＮＯ）、カウント部２０５は修正履歴表２４０内の次の関数名を取得する（ステップ２３５）。そして、取得したファイル名と関数名とを検索キーとして、新規修正関連データ２３５を検索し、一致するデータがあるかどうか判定する（ステップ２４０）。
【００６０】
一致するデータが見つかった場合（ステップ２４０：ＹＥＳ）、カウンタを１増加する（ステップ２４５）。ステップ２４０でＮＯの場合、すなわち一致するデータが見つからない場合又はステップ２４５から、処理はステップ２３０へ戻る。ステップ２２０でＹＥＳの場合、すなわち現在の修正ＩＤに関連付けられるすべてのファイルについてファイル名を取得した場合、現在のカウンタの値を現在の修正ＩＤに関連付けられる優先度として修正履歴表２４０に追加する（ステップ２５０）。そして処理はステップ２１０へ戻る。ステップ２１０でＹＥＳの場合、すなわち、すべての修正ＩＤについて優先度が決定された場合、処理は終了する。このようにして、図４（ｂ）に示されるような、優先度が追加された修正履歴表２４０が完成する。
【００６１】
図１２は、カウント部２０５が第１重み付け部２１０による重み付けの結果を考慮して優先度を決定する場合の処理の流れの一例を示す。図１２を見ると分かるように、全ファイルを調べた後の処理（ステップ３５０からステップ３６５）が異なるほかは、図１２は図１１に示す重み付けの結果を考慮しない優先度決定の処理のフローチャートと同じである。そこで、ここではステップ３２０でＹＥＳとなる場合の後の処理、すなわち現在の修正ＩＤに関連付けられるすべてのファイルについて調べた後の処理について説明する。なお、ステップ３２０でＹＥＳとなった時点におけるカウンタは、現在の修正ＩＤに関連付けられる関数のうち、関数名が新規修正関連データ２３５に含まれる関数名と一致する関数の数を示す。
【００６２】
カウント部２０５が現在の修正ＩＤに関連付けられるすべてのファイルについて調べ終え一致する関数名の数を数え終えると、第１重み付け部２１０は修正履歴表２４０から現在の修正ＩＤに関連付けられる修正者名を取得する（ステップ３５０）。そして第１重み付け部２１０は、取得した修正者名が、新規修正関連データ２３５に含まれる修正者名と一致するかどうか判定する（ステップ３５５）。一致しない場合（ステップ３５５：ＮＯ）、第１重み付け部２１０はユーザにより予め設定された１より大きい正の重み値（例えば「２」）をカウンタに掛け、その値をカウンタに代入する（ステップ３６０）。
【００６３】
ステップ３５５でＹＥＳの場合、すなわち修正者名が一致する場合、第１重み付け部２１０はユーザにより予め設定された１以下の正の重み値（例えば「１」）をカウンタに掛け、その値をカウンタに代入する（ステップ３６５）。ステップ３６０及びステップ３６５から処理は３７０へ進み、優先度決定部２００は、現在のカウンタの値を現在の修正ＩＤに関連付けられる優先度として修正履歴表２４０に追加する。そして処理はステップ３１０へ戻る。ステップ３１０でＹＥＳの場合、すなわち、すべての修正ＩＤについて優先度が決定された場合、処理は終了する。このようにして、図５（ｂ）に示されるような、修正者による重み付けが考慮された優先度を含む修正履歴表が完成する。
【００６４】
図１３は、第１関数リスク表作成部２８０による処理の流れの一例を示す。第１関数リスク表作成部２８０はまず、空の第１関数リスク表を作成する（ステップ４００）。そして第１関数リスク表作成部２８０は、第１格納部２３０から新規修正関連データ２３５を読み出し（ステップ４０５）、新規修正関連データ２３５にあるすべてのファイルについてファイル名を取得したかどうか判定する（ステップ４１０）。取得していないファイル名がない場合（ステップ４１０：ＹＥＳ）、処理は終了する。取得していないファイル名がある場合（ステップ４１０：ＮＯ）、第１関数リスク表作成部２８０は新規修正関連データ２３５内の次のファイル名を取得する（ステップ４１５）。そして第１関数リスク表作成部２８０は取得したファイル名が第１関数リスク表にあるかどうか判定し（ステップ４２０）、ない場合（ステップ４２０：ＮＯ）そのファイル名を第１関数リスク表に追加する（ステップ４２５）。
【００６５】
ステップ４２０でＹＥＳの場合、すなわち取得したファイル名が第１関数リスク表にある場合、およびステップ４２５から処理はステップ４３０へ進み、第１関数リスク表作成部２８０は更に、取得したファイル名のすべての関数について関数名を取得したかどうか判定する。取得していない関数名がない場合（ステップ４３０：ＹＥＳ）、処理はステップ４１０へ戻る。取得していない関数名がある場合（ステップ４３０：ＮＯ）、第１関数リスク表作成部２８０は新規修正関連データ２３５内の次の関数名を取得する（ステップ４３５）。そして第１関数リスク表作成部２８０は取得した関数名が第１関数リスク表にあるかどうか判定し（ステップ４４０）、ない場合（ステップ４４０：ＮＯ）その関数名を第１関数リスク表に追加する（ステップ４４５）。
【００６６】
ステップ４４０でＹＥＳの場合、すなわち関数名が第１関数リスク表にある場合、及びステップ４４５から処理はステップ４５０へ進み、第１関数リスク表作成部２８０は取得した関数名の関数の新規修正による修正量を得る。修正量は、新規修正による修正の後の関数とその修正前の関数とを比較することにより得られる。第１関数リスク表作成部２８０は、取得した修正量を、現在の関数名に関連付けられるリスクとして第１関数リスク表作成部２８０に設定する（ステップ４５５）。そして処理はステップ４３０へ戻る。このようにして、図６（ｂ）に示されるような第１の関数リスク表が完成する。
【００６７】
図１４は、第２関数リスク表作成部２８５による処理の流れの一例を示す。第２関数リスク表作成部２８５はまず、空の第２関数リスク表を作成する（ステップ５００）。そして第２関数リスク表作成部２８５は、第１格納部２３０から修正履歴表２４０を読み出し（ステップ５０２）、修正履歴表２４０にあるすべての修正ＩＤについて調べが終わったかどうか判定する（ステップ５０５）。全ての修正ＩＤについて調べが終わっている場合（ステップ５０５：ＹＥＳ）、処理は終了する。調べが終わっていない修正ＩＤがある場合（ステップ５０５：ＮＯ）、第２関数リスク表作成部２８５は修正履歴表２４０内の次の修正ＩＤを取得して現在の修正ＩＤとし、現在の修正ＩＤに関連付けられるすべてのファイルについてファイル名を取得したかどうか判定する（ステップ５１０）。取得していないファイル名がない場合（ステップ５１０：ＹＥＳ）、処理はステップ５０５へ戻る。
【００６８】
取得していないファイル名がある場合（ステップ５１０：ＮＯ）、第２関数リスク表作成部２８５は修正履歴表２４０内の次のファイル名を取得する（ステップ５１５）。そして第２関数リスク表作成部２８５は取得したファイル名が第２関数リスク表にあるかどうか判定し（ステップ５２０）、ない場合（ステップ５２０：ＮＯ）そのファイル名を第２関数リスク表に追加する（ステップ５２５）。ステップ５２０でＹＥＳの場合、すなわち取得したファイル名が第１関数リスク表にある場合、およびステップ５２５から処理はステップ５３０へ進み、第２関数リスク表作成部２８５は更に、取得したファイル名のすべての関数について関数名を取得したかどうか判定する。取得していない関数名がない場合（ステップ５３０：ＹＥＳ）、処理はステップ５１０へ戻る。
【００６９】
取得していない関数名がある場合（ステップ５３０：ＮＯ）、第２関数リスク表作成部２８５は修正履歴表２４０内の次の関数名を取得する（ステップ５３５）。そして第２関数リスク表作成部２８５は取得した関数名が第２関数リスク表にあるかどうか判定し（ステップ５４０）、ない場合（ステップ５４０：ＮＯ）その関数名を第２関数リスク表に追加する（ステップ５４５）。次に第２関数リスク表作成部２８５は、現在の関数名に関連付けられるリスクの値を０に設定する（ステップ５５０）。ステップ５４０でＹＥＳの場合、すなわち関数名が第２関数リスク表にある場合、及びステップ５５０から処理はステップ５５５へ進み、第２関数リスク表作成部２８５は、現在の関数名に関連付けられるリスクの値を１増加する。そして処理はステップ５３０へ戻る。このようにして、図７（ｂ）に示されるような第２の関数リスク表が完成する。
【００７０】
図１５は、カウント部２０５が第２重み付け部２１５による重み付けの結果を考慮して優先度を決定する場合の処理の流れの一例を示す。図１５を見ると分かるように、第１の関数リスク表を読み出す最初のステップ６１０を除いては、ステップ６００からステップ６４５の処理まで、図１５は図１１に示す重み付けの結果を考慮しない優先度決定の処理のフローチャートと同じである。そこで、ここではステップ６４５の後の処理、すなわち修正履歴表２４０から取得したファイル名と関数名とを検索キーとして新規修正関連データ２３５を検索し、一致するデータがあるかどうか判定した後の処理について説明する。
【００７１】
取得したファイル名と関数名とに一致するデータが新規修正関連データ２３５にあるとカウント部２０５が判定した場合（ステップ６４５：ＹＥＳ）、第２重み付け部２１５は第１の関数リスク表を参照して、一致した関数名の関数のリスク値を取得する（ステップ６５０）。そしてカウント部は第２重み付け部２１５が取得したリスク値をカウンタに足す（ステップ６５５）。そして処理はステップ６３５へ戻る。ステップ６３５において、取得したファイル名のすべての関数について関数名を取得したと判定された場合、処理はステップ６２５へ戻る。そしてステップ６２５で更に、現在の修正ＩＤに関連付けられるすべてのファイルについてファイル名を取得したと判定された場合、処理はステップ６６０へ進む。そして、優先度決定部２００は、現在のカウンタの値、すなわち、一致した関数名の関数のリスク値の合計を現在の修正ＩＤに関連付けられる優先度として修正履歴表２４０に追加する。
【００７２】
このようにして、図８（ｃ）に示されるような、関数の修正量による重み付けが考慮された優先度を含む修正履歴表が完成する。なお、第３重み付け部２２０による重み付けの結果を考慮して優先度を決定する場合の処理は、第１の関数リスク表の代わりに第２の関数リスク表が使用されるだけで、図１５に示す処理と基本的に同じであるため、詳細な説明は省略する。  
【００７３】
図１６は、リスト作成部２９０により作成されたリストの画面表示の一例を示す。図１６（ａ）は新規修正のリストの画面表示であり、１つのエントリは修正ＩＤ、修正要因の要約であるＴｉｔｌｅ、修正者を示すＯｗｎｅｒ、現在の作業状況を示すＳｔａｔｅを含む。ここで１つの新規修正を選択し（図１６（ａ）では修正ＩＤ「９００３」）、その状態で、「Ｄｅｆｅｃｔ（Ｄ）」メニューから「Ｒｅｌａｔｅｄ  Ｄｅｆｅｃｔｓ」を選択しマウス等の入力装置を用いてクリックすると、図１６（ｂ）に示す画面が情報処理装置１００の表示装置の画面に表示される。
【００７４】
図１６（ｂ）は、修正ＩＤ「９００３」に関連する過去の修正ＩＤのリストの一例である。過去の修正ＩＤのリストの１つのエントリは、図（ａ）のリストと同じく、修正ＩＤ、修正のＴｉｔｌｅ、修正のＯｗｎｅｒを含み、更に次の５つの項目を含む。その修正により修正した関数の数を示すＦｉｘｅｄ  Ｆｕｎｃｔｉｏｎｓ、一致する関数の数による優先度を示すＰｒｉｏｒｉｔｙ（Ｃｏｌｌｉｄｅｄ  Ｆｕｎｃｔｉｏｎｓ）、修正者による重み付けを考慮した優先度を示すＰｒｉｏｒｉｔｙ（Ｏｗｎｅｒ）、
修正回数による重み付けを考慮した優先度を示すＰｒｉｏｒｉｔｙ（Ｆｉｘｅｓ）、修正量による重み付けを考慮した優先度を示すＰｒｉｏｒｉｔｙ（Ｃｈａｎｇｅｄ  Ｓｉｚｅ）。
【００７５】
図１６（ｂ）の画面表示では、修正ＩＤは一致する関数の数による優先度に従ってソートされ、リストされている。他の優先度順に修正ＩＤをソートしたい場合は、それぞれの項目名（例えば、Ｐｒｉｏｒｉｔｙ（Ｏｗｎｅｒ））の「Ｖ」の表示をマウス等の入力装置を用いてクリックすれば、その優先度順に従って修正ＩＤがソートされる。リスト作成部２９０によるこのようなリストの作成は、図４（ｂ）、図５（ｂ）及び図８（ｃ）に示すような優先度を追加された修正履歴表２４０を第１格納部２３０から読み出し参照することにより行われる。
【００７６】
図１７は、本実施形態に係る情報処理装置１００のハードウェア構成の一例を示す。情報処理装置１００は、ホストコントローラ１１０により相互に接続されるＣＰＵ１０５及びＲＡＭ１１５を含むＣＰＵ周辺部と、入出力コントローラ１３０によりホストコントローラ１１０に接続される通信インターフェース１４５、ハードディスクドライブ１３５、及びＣＤ−ＲＯＭドライブ１４０を含む入出力部と、入出力コントローラ１３０に接続されるスーパーＩ／Ｏコントローラ１５０及びスーパーＩ／Ｏコントローラ１５０に接続されるフレキシブルディスクドライブ１５５、フラッシュＲＯＭ１６０、並びにキーボードマウスコントローラ１６５を有するレガシー入出力部とを備える。
【００７７】
ホストコントローラ１１０は、高い転送レートでＲＡＭ１１５にアクセスするＣＰＵ１０５をＲＡＭ１１５と接続する。ＣＰＵ１０５は、ハードディスクに格納されたプログラムに基づいて動作し、各部の制御を行う。本発明の実施形態に係る実施すべきテストケースの優先度を決定するためのプログラムは、ハードディスクに格納され、ＲＡＭ１１５を用いてＣＰＵ１０５により実行される。上記プログラムは、情報処理装置１００を、カウント部２０５、第１重み付け部２１０、第２重み付け部２１５、及び第３重み付け部２２５を含む優先度決定部２００、新規修正関連データ２３５、修正履歴表２４０、第１の関数リスク表２４５、及び第２の関数リスク表２５０を格納する第１格納部２３０、バージョン対応表２６０及び各バージョンのプログラムのソースコード２６５を格納する第２格納部２５５として機能させる。
【００７８】
上記プログラムは、情報処理装置１００を、更に、新規修正関連データ取得部２７０、修正履歴作成・更新部２７５、第１の関数リスク表作成部２８０、第２の関数リスク表作成部２８５、及びリスト作成・出力部２９０として機能させる。その具体的な機能及び動作は、図１乃至図１５を用いて説明したのと同一であるから説明を省略する。なお、上記プログラムは、情報処理装置１００により読み取り可能な媒体に格納できる。
【００７９】
情報処理装置で読み取り可能な媒体とは、命令実行システム、装置または機器に使用されあるいはこれらに関連するプログラムを含み、記憶し、通信し、伝搬し、あるいは搬送することができる任意の装置であることができる。媒体は、電子的、磁気的、光学的、電磁的、赤外線または半導体システム（または、装置または機器）あるいは伝搬媒体であることができる。情報処理装置可読の媒体の例には、半導体またはソリッド・ステート記憶装置、磁気テープ、取り外し可能な情報処理装置・ディスケット、ランダム・アクセス・メモリ（RAM）、リードオンリー・メモリ（ROM）、リジッド磁気ディスクおよび光ディスクが含まれる。現時点における光ディスクの例には、コンパクト・ディスク−リードオンリー・メモリ（CD-ROM）、コンパクト・ディスク−リード／ライト（CD-R/W）およびDVDが含まれる。
【００８０】
入出力コントローラ１３０は、比較的高速な入出力装置である通信インターフェース１４５、ハードディスクドライブ１３５、及びＣＤ−ＲＯＭドライブ１４０をホストコントローラ１１０と接続する。通信インターフェース１３５は、ネットワークを介して外部装置と通信する。
【００８１】
また、入出力コントローラ１３０には、スーパーＩ／Ｏコントローラ１５０やキーボードマウスコントローラ１６５等の比較的低速な入出力装置と、フラッシュＲＯＭ１６０とが接続される。フラッシュＲＯＭ１６０は、情報処理装置１００の起動時にＣＰＵ１０５が実行するブートプログラムや、情報処理装置１００のハードウェアに依存するプログラム等を格納する。フレキシブルディスクドライブ１５５は、フレキシブルディスクからプログラムまたはデータを読み取り、ＲＡＭ１１５を介してスーパーＩ／Ｏコントローラ１５０に提供する。スーパーＩ／Ｏコントローラ１５０は、フレキシブルディスクや、例えばパラレルポート、シリアルポート、キーボードポート、マウスポート等を介して各種の入出力装置を接続する。
【００８２】
以上、実施形態を用いて本発明の説明をしたが、本発明の技術範囲は上記実施形態に記載の範囲には限定されない。たとえば上記の実施例では、優先度を決定する際の重み付けは、修正者による重み付け、新規修正による関数の修正量による重み付け、及び関数の過去の修正の修正回数による重み付けのいずれか１つによるものであった。しかしながら、上記重み付けを複数組み合わせることも可能である。例として、新規修正による関数の修正量による重み付けと修正者による重み付けを組み合わせる場合を説明する。例えば、ある過去の修正ＩＤについて一致する関数が複数あり、かつその修正者が新規修正の修正者と異なるとする。この場合、当該修正ＩＤの優先度は、それら一致する関数の新規修正による修正量の合計に修正者が異なる場合の重み値を掛けることにより求めることができる。
【００８３】
また、上記説明では、修正者は修正ＩＤごとに決まったが、これには制限されず、修正者は関数ごとまたはファイルごとに決まってもよい。この場合、修正ＩＤの優先度は、一致する関数の修正者により決まる重み値の合計となる。このように上記の実施形態に、種々の変更または改良を加えることが可能であることが当業者に明らかである。従って、そのような変更または改良を加えた形態も当然に本発明の技術的範囲に含まれる。
【図面の簡単な説明】
【００８４】
【図１】本発明の一実施形態に係る実施すべきテストケースの優先度を決定するための情報処理装置１００の機能構成の一例を示す。
【図２】（ａ）は、新規修正関連データ２３５の一例を示す。（ｂ）は、バージョン対応表２６０の一例を示す。
【図３】（ａ）は、修正履歴表２４０の一例を示す。（ｂ）は、更新後の修正履歴表２４０の一例を示す。
【図４】（ａ）は、新規修正関連データ２３５の一例を示す。（ｂ）は、優先度を追加された修正履歴表２４０の一例を示す。
【図５】（ａ）は、新規修正関連データ２３５の一例を示す。（ｂ）は、修正者による重み付けの結果を考慮した優先度を含む修正履歴表２４０の一例を示す。
【図６】（ａ）は、新規修正関連データ２３５の一例を示す。（ｂ）は、第１の関数リスク表２４５の一例を示す。
【図７】（ａ）は、新規修正関連データ２３５の一例を示す。（ｂ）は、第２の関数リスク表２５０の一例を示す。
【図８】（ａ）は、新規修正関連データ２３５の一例を示す。（ｂ）は、第１の関数リスク表２４５の一例を示す。（ｃ）は、修正量による重み付けの結果を考慮した優先度を含む修正履歴表２４０の一例を示す。
【図９】新規修正関連データ２３５取得のための処理の流れの一例を示すフローチャートを示す。
【図１０】修正履歴表２４０作成・更新のための処理の流れの一例を示すフローチャートを示す。
【図１１】優先度決定のための処理の流れの一例を示すフローチャートを示す。
【図１２】、修正者による重み付けの結果を考慮した優先度決定のための処理の流れの一例を示すフローチャートを示す。
【図１３】第１の関数リスク表２４５作成のための処理の流れの一例を示すフローチャートを示す。
【図１４】第２の関数リスク表２５０作成のための処理の流れの一例を示すフローチャートを示す。
【図１５】修正量による重み付けの結果を考慮した優先度決定のための処理の流れの一例を示すフローチャートを示す。
【図１６】（ａ）は、新規修正のリストの画面表示の一例を示す。（ｂ）は、修正ＩＤ「９００３」に関連する過去の修正ＩＤのリストの画面表示の一例である。
【図１７】本発明の実施形態に係る情報処理装置１００のハードウェア構成の一例を示す。
【図１】
2008129661.tif 000003
【図２】
2008129661.tif 000004
【図３】
2008129661.tif 000005
【図４】
2008129661.tif 000006
【図５】
2008129661.tif 000007
【図６】
2008129661.tif 000008
【図７】
2008129661.tif 000009
【図８】
2008129661.tif 000010
【図９】
2008129661.tif 000011
【図１０】
2008129661.tif 000012
【図１１】
2008129661.tif 000013
【図１２】
2008129661.tif 000014
【図１３】
2008129661.tif 000015
【図１４】
2008129661.tif 000016
【図１５】
2008129661.tif 000017
【図１６】
2008129661.tif 000018
【図１７】
2008129661.tif 000019