(57)【要約】  ソフトウェア開発効率の低下とソフトウェアエージングの検出精度の低下を招かないような適切な頻度で負荷テストを実行する。実施基準に従ってテスト対象のバージョンのソフトウェアに負荷テストを実施し、そのテスト結果と比較対象の以前のバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出し、検出結果に基づいて前記実施基準を変更して次回以降の負荷テストの実施頻度を調整する。
2015022890.tif 000002
【特許請求の範囲】
【請求項１】
実施基準に従ってテスト対象のバージョンのソフトウェアに負荷テストを実施し、そのテスト結果と比較対象の以前のバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出し、検出結果に基づいて前記実施基準を変更して次回以降の負荷テストの実施頻度を調整することを特徴とするソフトウェアエージングテストシステム。
【請求項２】
テスト対象のバージョンのソフトウェアとソフトウェアエージングの問題のない直近の正常なバージョンのソフトウェアとの差分を定量的に示す変化量を求め、前記変化量から前記実施基準に基づいて負荷テストの要否を判定する判定手段と、
前記判定手段により負荷テストの実施が必要と判定された場合にテスト対象のバージョンのソフトウェアに負荷テストを実施する実施手段と、
前記実施手段により得られたテスト対象のバージョンのソフトウェアの負荷テストのテスト結果と、事前に得られた前記直近の正常なバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出する検出手段と、
前記検出手段により得られたソフトウェアエージングの問題の有無の検出結果に基づいて前記実施基準を更新する更新手段と
を備えたことを特徴とする請求項１に記載のソフトウェアエージングテストシステム。
【請求項３】
前記変化量はソフトウェアのコミット数の変化量を含み、その変化量のしきい値を前記実施基準とすることを特徴とする請求項２に記載のソフトウェアエージングテストシステム。
【請求項４】
前記変化量はソフトウェアに含まれるコード行数、機能の数、オブジェクトの数、関数の数、及び外部ライブラリの数を含む群のうちの１つ以上を含むソフトウェアメトリクスの変化量を含み、その変化量のしきい値を前記実施基準とすることを特徴とする請求項２に記載のソフトウェアエージングテストシステム。
【請求項５】
前記変化量はソフトウェア開発における経過時間の変化量を含み、その変化量のしきい値を前記実施基準とすることを特徴とする請求項２に記載のソフトウェアエージングテストシステム。
【請求項６】
前記検出手段は、負荷テストにおいてソフトウェアが消費したメモリ量の時間変化を両テスト結果間で比較することによりソフトウェアエージングの問題の有無を検出することを特徴とする請求項２〜５のいずれか１項に記載のソフトウェアエージングテストシステム。
【請求項７】
前記検出手段は、負荷テストにおける空きメモリ容量、仮想メモリサイズ、スワップ利用サイズ、ディスク空き容量及びプロセス数を含む群のうちの１つ以上についての時間変化を両テスト結果間で比較することによりソフトウェアエージングの問題の有無を検出することを特徴とする請求項２〜５のいずれか１項に記載のソフトウェアエージングテストシステム。
【請求項８】
前記時間変化を両テスト結果間で比較する際に線形回帰分析により前記時間変化を直線近似し、近似直線の傾きを両テスト結果間で比較することを特徴とする請求項６又は７に記載のソフトウェアエージングテストシステム。
【請求項９】
前記更新手段は、前記検出手段がソフトウェアエージングの問題を検出しなかった場合には、負荷テストの実施間隔がより長くなるように前記実施基準を更新することを特徴とする請求項２〜８のいずれか１項に記載のソフトウェアエージングテストシステム。
【請求項１０】
前記更新手段は、前記検出手段がソフトウェアエージングの問題を検出した場合には、負荷テストの実施間隔がより短くなるように前記実施基準を更新することを特徴とする請求項２〜９のいずれか１項に記載のソフトウェアエージングテストシステム。
【請求項１１】
ソフトウェアエージングの問題が検出された場合に実施したデバッグの結果を入力するデバッグ結果入力手段を更に備え、
前記更新手段は、前記デバッグ結果入力手段が入力したデバッグ結果と前記検出手段によるソフトウェアエージングの問題の有無の検出結果とに基づいて前記実施基準を更新することを特徴とする請求項２〜８のいずれか１項に記載のソフトウェアエージングテストシステム。
【請求項１２】
前記更新手段は、前記デバッグ結果と前記ソフトウェアエージングの問題の有無の検出結果が一致するか否かを判定し、一致しない場合には負荷テストの実施間隔がより短くなるように前記実施基準を更新することを特徴とする請求項１１に記載のソフトウェアエージングテストシステム。
【請求項１３】
前記更新手段は、前記デバッグ結果と前記ソフトウェアエージングの問題の有無の検出結果が一致するか否かを判定し、一致する場合には前記実施基準を維持するか又は負荷テストの実施間隔がより長くなるように前記実施基準を更新することを特徴とする請求項１１又は１２に記載のソフトウェアエージングテストシステム。
【請求項１４】
実施基準に従ってテスト対象のバージョンのソフトウェアに負荷テストを実施し、そのテスト結果と比較対象の以前のバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出し、検出結果に基づいて前記実施基準を変更して次回以降の負荷テストの実施頻度を調整することを特徴とするソフトウェアエージングテスト方法。
【請求項１５】
テスト対象のバージョンのソフトウェアとソフトウェアエージングの問題のない直近の正常なバージョンのソフトウェアとの差分を定量的に示す変化量を求め、前記変化量から前記実施基準に基づいて負荷テストの要否を判定する判定ステップと、
前記判定ステップにて負荷テストの実施が必要と判定された場合にテスト対象のバージョンのソフトウェアに負荷テストを実施する実施ステップと、
前記実施ステップで得られたテスト対象のバージョンのソフトウェアの負荷テストのテスト結果と、事前に得られた前記直近の正常なバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出する検出ステップと、
前記検出ステップで得られたソフトウェアエージングの問題の有無の検出結果に基づいて前記実施基準を更新する更新ステップと
を含むことを特徴とする請求項１４に記載のソフトウェアエージングテスト方法。
【請求項１６】
前記変化量はソフトウェアのコミット数の変化量を含み、その変化量のしきい値を前記実施基準とすることを特徴とする請求項１５に記載のソフトウェアエージングテスト方法。
【請求項１７】
前記変化量はソフトウェアに含まれるコード行数、機能の数、オブジェクトの数、関数の数、及び外部ライブラリの数を含む群のうちの１つ以上を含むソフトウェアメトリクスの変化量を含み、その変化量のしきい値を前記実施基準とすることを特徴とする請求項１５に記載のソフトウェアエージングテスト方法。
【請求項１８】
前記変化量はソフトウェア開発における経過時間の変化量を含み、その変化量のしきい値を前記実施基準とすることを特徴とする請求項１５に記載のソフトウェアエージングテスト方法。
【請求項１９】
前記検出ステップでは、負荷テストにおいてソフトウェアが消費したメモリ量の時間変化を両テスト結果間で比較することによりソフトウェアエージングの問題の有無を検出することを特徴とする請求項１５〜１８のいずれか１項に記載のソフトウェアエージングテスト方法。
【請求項２０】
前記検出ステップでは、負荷テストにおける空きメモリ容量、仮想メモリサイズ、スワップ利用サイズ、ディスク空き容量及びプロセス数を含む群のうちの１つ以上についての時間変化を両テスト結果間で比較することによりソフトウェアエージングの問題の有無を検出することを特徴とする請求項１５〜１８のいずれか１項に記載のソフトウェアエージングテスト方法。
【請求項２１】
前記時間変化を両テスト結果間で比較する際に線形回帰分析により前記時間変化を直線近似し、近似直線の傾きを両テスト結果間で比較することを特徴とする請求項１９又は２０に記載のソフトウェアエージングテスト方法。
【請求項２２】
前記更新ステップでは、前記検出ステップにてソフトウェアエージングの問題が検出されなかった場合、負荷テストの実施間隔がより長くなるように前記実施基準を更新することを特徴とする請求項１５〜２１のいずれか１項に記載のソフトウェアエージングテスト方法。
【請求項２３】
前記更新ステップでは、前記検出ステップにてソフトウェアエージングの問題が検出された場合、負荷テストの実施間隔がより短くなるように前記実施基準を更新することを特徴とする請求項１５〜２２のいずれか１項に記載のソフトウェアエージングテスト方法。
【請求項２４】
ソフトウェアエージングの問題が検出された場合に実施したデバッグの結果を入力するデバッグ結果入力ステップを更に含み、
前記更新ステップでは、前記デバッグ結果入力ステップにて入力したデバッグ結果と前記検出ステップでのソフトウェアエージングの問題の有無の検出結果とに基づいて前記実施基準を更新することを特徴とする請求項１５〜２１のいずれか１項に記載のソフトウェアエージングテスト方法。
【請求項２５】
前記更新ステップでは、前記デバッグ結果と前記ソフトウェアエージングの問題の有無の検出結果が一致するか否かを判定し、一致しない場合には負荷テストの実施間隔がより短くなるように前記実施基準を更新することを特徴とする請求項２４に記載のソフトウェアエージングテスト方法。
【請求項２６】
前記更新ステップでは、前記デバッグ結果と前記ソフトウェアエージングの問題の有無の検出結果が一致するか否かを判定し、一致する場合には前記実施基準を維持するか又は負荷テストの実施間隔がより長くなるように前記実施基準を更新することを特徴とする請求項２４又は２５に記載のソフトウェアエージングテスト方法。
【請求項２７】
コンピュータに、実施基準に従ってテスト対象のバージョンのソフトウェアに負荷テストを実施し、そのテスト結果と比較対象の以前のバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出し、検出結果に基づいて前記実施基準を変更して次回以降の負荷テストの実施頻度を調整する処理を実行させることを特徴とするソフトウェアエージングテスト用プログラム。
【請求項２８】
前記コンピュータに、
テスト対象のバージョンのソフトウェアとソフトウェアエージングの問題のない直近の正常なバージョンのソフトウェアとの差分を定量的に示す変化量を求め、前記変化量から前記実施基準に基づいて負荷テストの要否を判定する判定処理と、
前記判定処理にて負荷テストの実施が必要と判定された場合にテスト対象のバージョンのソフトウェアに負荷テストを実施する実施処理と、
前記実施処理で得られたテスト対象のバージョンのソフトウェアの負荷テストのテスト結果と、事前に得られた前記直近の正常なバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出する検出処理と、
前記検出処理で得られたソフトウェアエージングの問題の有無の検出結果に基づいて前記実施基準を更新する更新処理と
を実行させることを特徴とする請求項２７に記載のソフトウェアエージングテスト用プログラム。
【請求項２９】
前記変化量はソフトウェアのコミット数の変化量を含み、その変化量のしきい値を前記実施基準とすることを特徴とする請求項２８に記載のソフトウェアエージングテスト用プログラム。
【請求項３０】
前記変化量はソフトウェアに含まれるコード行数、機能の数、オブジェクトの数、関数の数、及び外部ライブラリの数を含む群のうちの１つ以上を含むソフトウェアメトリクスの変化量を含み、その変化量のしきい値を前記実施基準とすることを特徴とする請求項２８に記載のソフトウェアエージングテスト用プログラム。
【請求項３１】
前記変化量はソフトウェア開発における経過時間の変化量を含み、その変化量のしきい値を前記実施基準とすることを特徴とする請求項２８に記載のソフトウェアエージングテスト用プログラム。
【請求項３２】
前記検出処理では、負荷テストにおいてソフトウェアが消費したメモリ量の時間変化を両テスト結果間で比較することによりソフトウェアエージングの問題の有無を検出することを特徴とする請求項２８〜３１のいずれか１項に記載のソフトウェアエージングテスト用プログラム。
【請求項３３】
前記検出処理では、負荷テストにおける空きメモリ容量、仮想メモリサイズ、スワップ利用サイズ、ディスク空き容量及びプロセス数を含む群のうちの１つ以上についての時間変化を両テスト結果間で比較することによりソフトウェアエージングの問題の有無を検出することを特徴とする請求項２８〜３１のいずれか１項に記載のソフトウェアエージングテスト用プログラム。
【請求項３４】
前記時間変化を両テスト結果間で比較する際に線形回帰分析により前記時間変化を直線近似し、近似直線の傾きを両テスト結果間で比較することを特徴とする請求項３２又は３３に記載のソフトウェアエージングテスト用プログラム。
【請求項３５】
前記更新処理では、前記検出処理にてソフトウェアエージングの問題が検出されなかった場合、負荷テストの実施間隔がより長くなるように前記実施基準を更新することを特徴とする請求項２８〜３４のいずれか１項に記載のソフトウェアエージングテスト用プログラム。
【請求項３６】
前記更新処理では、前記検出処理にてソフトウェアエージングの問題が検出された場合、負荷テストの実施間隔がより短くなるように前記実施基準を更新することを特徴とする請求項２８〜３５のいずれか１項に記載のソフトウェアエージングテスト用プログラム。
【請求項３７】
前記コンピュータに、
ソフトウェアエージングの問題が検出された場合に実施したデバッグの結果を入力するデバッグ結果入力処理を更に実行させ、
前記更新処理では、前記デバッグ結果入力処理にて入力したデバッグ結果と前記検出処理で得られたソフトウェアエージングの問題の有無の検出結果とに基づいて前記実施基準を更新することを特徴とする請求項２８〜３４のいずれか１項に記載のソフトウェアエージングテスト用プログラム。
【請求項３８】
前記更新処理では、前記デバッグ結果と前記ソフトウェアエージングの問題の有無の検出結果が一致するか否かを判定し、一致しない場合には負荷テストの実施間隔がより短くなるように前記実施基準を更新することを特徴とする請求項３７に記載のソフトウェアエージングテスト用プログラム。
【請求項３９】
前記更新処理では、前記デバッグ結果と前記ソフトウェアエージングの問題の有無の検出結果が一致するか否かを判定し、一致する場合には前記実施基準を維持するか又は負荷テストの実施間隔がより長くなるように前記実施基準を更新することを特徴とする請求項３７又は３８に記載のソフトウェアエージングテスト用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はソフトウェアエージングテストシステム、ソフトウェアエージングテスト方法及びソフトウェアエージングテスト用プログラムに関し、特にソフトウェアの開発効率をより高められるソフトウェアエージングテストシステム、ソフトウェアエージングテスト方法及びソフトウェアエージングテスト用プログラムに関する。
【背景技術】
【０００２】
ソフトウェアエージングとは、ソフトウェアの長時間連続稼働によってソフトウェアの実行環境に劣化が生じる現象のことである。ソフトウェアエージングは時間と共に進行し、プログラム処理性能の低下やシステム故障率の増加を招く。ソフトウェアエージングの多くはソフトウェアの欠陥（プログラム中のバグ）に起因している。メモリリークはメモリの解放し忘れによって生じる典型的なソフトウェアエージングの一例である。ソフトウェアのリリース後にこのような欠陥が発覚すると、システムの運用に支障をきたし、信頼性の低下につながる。したがって、ソフトウェアエージングの原因となる欠陥はできるだけソフトウェアをリリースする前に取り除くことが望ましい。【０００３】
ソフトウェアをリリースする前にソフトウェアエージングの問題を検出するためには、ソフトウェアをコンピュータ上で実際に稼働させ、ワークロードを与えてその動作を観察する負荷テストが必要となる。ところが、そのような負荷テストには実験環境を用意してテストを実行する必要があるため、コストと時間がかかる。特に、ソフトウェアエージングの問題を検出するためには長時間の連続稼働と継続的な監視が必要である。そこで、ソフトウェアエージングを検出するための負荷テストを効率化するため、非特許文献１に示すテスト手法が提案されている。【０００４】
非特許文献１では、同じソフトウェアの過去のバージョンに対して実行した負荷テストの結果と現在のテスト対象のバージョンに対するテスト結果を比較することにより、ソフトウェアエージングの傾向を検出する手法が示されている。例えば、過去のバージョンにおいてメモリの消費量に増加傾向はなく、現在のバージョンにおいて増加傾向が見られた場合、高い確率で現在のバージョンにソフトウェアエージングの原因となる欠陥が含まれていると判定できる。過去の傾向との比較によって判定するため、ソフトウェアを長時間稼働させる前に早期に問題の兆候をとらえることが可能となる。【０００５】
なお、明細書及び特許請求の範囲において「ソフトウェアエージングの問題」とは、ソフトウェアに潜在的に存在するソフトウェアエージングのリスクを意味する。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】Felix  Langner and Artur Andrzejak, Detecting Software Aging in a Cloud Computing Framework by Comparing Development Versions, In Proceeding of International Symposium on Integrated network Management (IM), 2013.
【発明の概要】
【発明が解決しようとする課題】
【０００７】
一方、非特許文献１の手法によるソフトウェアエージングの検出には以下の問題があった。第１の問題点は、ソフトウェアエージング検出のための負荷テストをプログラムのコミットの都度実行すると開発効率が著しく低下してしまうことである。以前のバージョンとの比較評価のためには定期的に負荷テストとリソース使用量に関する監視が必要となる。負荷テストには一定の時間とコストがかかるため、コミットの都度負荷テストを実行すると開発効率が低下しコストが嵩んでしまう。【０００８】
第２の問題点は、負荷テストをまとまったバージョン毎に実行すると、比較評価によるソフトウェアエージング検出の精度が低下してしまうことである。負荷テストをまとまったバージョン毎に実行する場合、以前のバージョンとの間に多くのプログラムコードの追加や更新が含まれるため、以前のバージョンの結果と異なる傾向となる確率が高くなる。比較評価によってソフトウェアエージングの問題があると判定された場合でも、機能追加に起因している場合があり、誤検出となってしまう。以前のバージョンとの間に多くの機能追加や更新がある場合、誤検出かどうかの判定は難しくなる。【０００９】
以上のように従来のバージョン比較に基づくソフトウェアエージングの検出方法は、比較を実施する頻度に関して注意が払われてこなかった。【００１０】
［発明の目的］
そこで、本発明の目的は、高頻度な負荷テストによるソフトウェア開発効率の低下を招かず且つ低頻度な負荷テストによるソフトウェアエージングの検出精度の低下も招かないような適切な頻度で負荷テストを実行するソフトウェアエージングテストシステム、方法及びプログラムを提供することである。
【課題を解決するための手段】
【００１１】
本発明のソフトウェアエージングテストシステムは、実施基準に従ってテスト対象のバージョンのソフトウェアに負荷テストを実施し、そのテスト結果と比較対象の以前のバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出し、検出結果に基づいて前記実施基準を変更して次回以降の負荷テストの実施頻度を調整することを特徴とする。【００１２】
本発明のソフトウェアエージングテスト方法は、実施基準に従ってテスト対象のバージョンのソフトウェアに負荷テストを実施し、そのテスト結果と比較対象の以前のバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出し、検出結果に基づいて前記実施基準を変更して次回以降の負荷テストの実施頻度を調整することを特徴とする。【００１３】
本発明のソフトウェアエージングテスト用プログラムは、コンピュータに、実施基準に従ってテスト対象のバージョンのソフトウェアに負荷テストを実施し、そのテスト結果と比較対象の以前のバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出し、検出結果に基づいて前記実施基準を変更して次回以降の負荷テストの実施頻度を調整する処理を実行させることを特徴とする。
【発明の効果】
【００１４】
本発明により、高頻度な負荷テストによる開発効率の低下と低頻度な負荷テストによるソフトウェアエージングの検出精度の低下とを招かないような適切な頻度にて負荷テストを実施することができる。
【図面の簡単な説明】
【００１５】
【図１】本発明の第１の実施の形態の構成を示すブロック図である。
【図２】第１の実施の形態の動作を示すフローチャートである。
【図３】本発明の第２の実施の形態の構成を示すブロック図である。
【図４】第２の実施の形態の動作を示すフローチャートである。
【図５】本発明の実施例のソフトウェアバージョン管理記憶装置に格納されるコミットログの一例を示す表である。
【図６】本発明の実施例の負荷テストの比較結果によりソフトウェアエージングの問題が検出されなかった場合の結果を示すグラフである。
【図７】本発明の実施例の負荷テストの比較結果によりソフトウェアエージングの問題が検出された場合の結果を示すグラフである。
【発明を実施するための形態】
【００１６】
[第1の実施の形態]
[構成の説明]
次に、本発明の第１の実施の形態について図面を参照して詳細に説明する。
図１を参照すると、本発明の第１の実施の形態では、プログラム制御により動作するコンピュータ（中央処理装置、プロセッサ又はデータ処理装置ともいう）１００に、テスト対象のバージョンのソフトウェア（テスト対象のソフトウェアバージョン（SVUT）ともいう）１０が入力として与えられ、テスト対象のソフトウェアに潜在的に存在するエージングリスクの分析結果である潜在エージングリスク分析結果２０が出力される。コンピュータ１００は、ソフトウェアのバージョンを管理するソフトウェアバージョン管理記憶装置１０１と、テスト対象のソフトウェアバージョンの変化量を調べる変化量チェック手段１０２と、負荷テストを実施する基準とする変化量のしきい値を格納する変化量しきい値格納装置１０３と、ソフトウェアに対して負荷テストを実施する負荷テスト手段１０４と、負荷テストの結果を格納する負荷テスト結果格納装置１０５と、負荷テストの結果を過去の結果と比較するテスト結果比較手段１０６と、比較結果に基づいて変化量しきい値を更新するしきい値更新手段１０７とから構成されている。
【００１７】
なお、特許請求の範囲において、上記のコンピュータ１００はソフトウェアエージングテストシステムに対応し、変化量チェック手段１０２は判定手段に対応し、負荷テスト手段１０４は実施手段に対応し、テスト結果比較手段１０６は検出手段に対応し、しきい値更新手段１０７は更新手段に対応する。また、本明細書において「ソフトウェアバージョン」又は単に「バージョン」というときは、該当バージョンのソフトウェアを意味する。
【００１８】
上記の各手段はそれぞれ概略つぎのように動作する。
変化量チェック手段１０２は、テスト対象のソフトウェアバージョンに対して、ソフトウェアエージングの問題が検出されなかった以前の正常なソフトウェアバージョン（複数ある場合には例えば直近のもの）からの変化量をチェックし、変化量がしきい値に達しているか否かを判定する。変化量がしきい値に達している場合にのみ負荷テストを実施するように制御する。
【００１９】
負荷テスト手段１０４は、変化量がしきい値に達した場合にテスト対象のソフトウェアバージョンを実行させ、ワークロードを与えたときの実行環境の状態変化を観測し、測定した結果を負荷テスト結果格納装置１０５に格納する。
【００２０】
テスト結果比較手段１０６は、テスト対象のソフトウェアに対する負荷テストの結果と、比較対象の以前のバージョンに対する負荷テストの結果とを比較し、ソフトウェアエージングの有無を検出し、その結果を出力する。
【００２１】
しきい値更新手段１０７は、ソフトウェアエージング検出結果に基づいて、以降の負荷テスト実施間隔を適切に変更するように変化量しきい値を更新する。
【００２２】
これらの手段は、ソフトウェアエージング検出のための負荷テストとバージョン比較とを実施する間隔を負荷テスト実施の都度調整する様に相互に作用することで、開発効率を改善しつつより正確なソフトウェアエージング検出を実現する。
【００２３】
[動作の説明]
次に、図１及び図２のフローチャートを参照して本実施の形態の全体の動作について詳細に説明する。
【００２４】
まず、テスト対象のソフトウェアバージョン（SVUT）を決める（図２のステップＡ１）。次に、ソフトウェアバージョン管理記憶装置１０１を参照し、ソフトウェアエージングの検出されなかった直近の正常なソフトウェアバージョン（LGV）を取得する（ステップＡ２）。変化量チェック手段１０２はテスト対象のソフトウェアバージョンと直近の正常なソフトウェアバージョンとの差分量（変化量ともいう）ｄを求める（ステップＡ３）。
【００２５】
差分量としては、例えば正常なソフトウェアバージョンから追加されたソースコードの行数、ソフトウェアバージョン管理記憶装置１０１に記録されたコミットの数、追加された機能の数、メモリ管理に関連する関数の数、アクセスするオブジェクトの数、新たに追加された外部ライブラリの数、経過期間などがある。変化量チェック手段は変化量しきい値格納装置１０３に格納されたしきい値Ｄを参照し、求めた差分量ｄと比較する（ステップＡ４、ステップＡ５）。
【００２６】
差分量ｄがしきい値Ｄに達していない場合（ステップＡ５のＮＯ）、ソフトウェアエージング検出のための負荷テストは実施せずに終了する。差分量ｄがしきい値Ｄに達した場合（ステップＡ５のＹＥＳ）、負荷テスト手段１０４によってテスト対象のソフトウェアバージョンに対して負荷テストを実施し、その際のシステムメトリクスの値の変化を記録する（ステップＡ６）。
【００２７】
測定対象とするシステムメトリクスはソフトウェアエージングの傾向を示す可能性のあるメトリクスで、例えば、空きメモリ容量、アプリケーションが利用中の物理メモリのサイズ、スワップ利用サイズ、ディスク空き容量、プロセス数などあり、これらのうちの１つ以上のメトリクスを測定対象としてもよい。測定したシステムメトリクスの値は負荷テスト結果格納装置１０５に記録する。
【００２８】
次にテスト結果比較手段１０６は、直近の正常なソフトウェアバージョンに対して負荷テストを実施した際のシステムメトリクスの値の変化と、テスト対象のソフトウェアバージョンに対して測定した結果を比較する（ステップＡ７）。比較方法は非特許文献１に示される方法や、統計的に傾向の差を分析する方法や、単純に目視で行う方法がある。
【００２９】
比較の結果は、テスト対象のソフトウェアバージョンにおけるソフトウェアエージングのリスク分析結果として出力する（ステップＡ８）。分析結果にはソフトウェアエージングの問題が見られるシステムメトリクス、およびソフトウェアエージング傾向の有無やその確率などを含んでもよく、テスト者がソフトウェアエージングの原因となるソフトウェアの欠陥を詳細に調査するかどうかの判断基準を与えるものとするのが好ましい。
【００３０】
最後にしきい値更新手段１０７はソフトウェアエージングの可能性を分析した結果に基づき、負荷テスト効率を改善するように変化量しきい値を更新する（ステップＡ９）。例えば、テストした結果ソフトウェアエージング傾向がほとんど見られなかった場合、テストの間隔をより長くとるようにしきい値Ｄを更新する（コードライン数、コミット数、経過期間などのしきい値をより大きくする）。逆に、ソフトウェアエージングの可能性が複数見つかった場合などには、負荷テストの間隔をより短くするようにしきい値Ｄを更新する（コードライン数、コミット数、経過期間などのしきい値をより小さくする）。
【００３１】
[効果の説明] 
次に、本実施の形態の効果について説明する。
本実施の形態では、負荷テスト結果の比較によってソフトウェアエージングの可能性を分析し、その分析結果に基づいて負荷テストの実施間隔を決定するためのしきい値を変化させるように構成されているため、高頻度な負荷テストによる開発効率の低下および低頻度の負荷テストに起因する問題の検出精度の低下を回避できる。
【００３２】
具体的には、負荷テストの結果、ソフトウェアエージングの問題が発見されなかった場合、負荷テストの間隔をより長くとるように変化量のしきい値を更新することにより、高頻度な負荷テストを回避してソフトウェアの開発効率を向上できる。また、負荷テストの結果、ソフトウェアエージングの問題が発見された場合、負荷テストの間隔をより短くとるように変化量のしきい値を更新することにより、バージョン毎の比較よりも短い間隔でソフトウェアエージングの検出評価を行えるため、バージョン毎の低頻度な負荷テストによるソフトウェアエージングの検出精度の低下を回避できる。これにより、ソフトウェアの開発効率を損なわず、適切なタイミングでソフトウェアの負荷テストを実施してソフトウェアエージングの問題を早期に精度よく発見できる。また、ソフトウェアエージングの問題のない直近の正常なバージョンのソフトウェアを比較対象とすることにより、ソフトウェアエージングの傾向を的確に把握できるので、ソフトウェアエージングの問題の検出精度を向上させることができる。
【００３３】
[第２の実施の形態] 
[構成の説明]
次に、本発明の第２の実施の形態について図面を参照して詳細に説明する。
図３を参照すると、本発明の第２の実施の形態は、図１の第１の実施の形態の構成におけるしきい値更新手段１０７にデバッグ結果３０がデバッグ結果入力手段（図示せず）を介して入力される点で第１の実施の形態と相違する。
【００３４】
[動作の説明] 
コンピュータ１００のデバッグ結果入力手段はソフトウェアエージングの問題が検出された場合にデバッグを実施した結果を入力として受け付け、受け付けたデバッグ結果をしきい値更新手段１０７に送る。しきい値更新手段１０７は、このデバッグ結果と、テスト結果比較手段１０６から取得したソフトウェアエージング検出結果とに基づいてしきい値の更新を決定する。
【００３５】
次に、図３及び図４のフローチャートを参照して本実施の形態の全体の動作について詳細に説明する。
【００３６】
図４のフローチャートのステップＢ８までの動作は図２のフローチャートに示す第１の実施の形態の動作と同じである。ただし、テスト結果比較手段１０６はソフトウェアエージングのリスクを分析した結果に基づいてソフトウェアのデバッグ必要性の有無を決定し、その結果を潜在エージングリスク分析結果２０に含めてもよい。例えば、一つでもソフトウェアエージングの問題が検出されたらデバッグが必要と判定する。あるいは、ソフトウェアエージングが存在する可能性が一定の確率を上回った場合にのみデバッグの必要性を指摘しても良い（ステップＢ９）。ここで、デバッグは不要と判定された場合は（ステップＢ９のＹＥＳ）、第１の実施の形態の動作に従って、しきい値更新手段１０７はソフトウェアエージングの可能性を分析した結果に基づき、テスト効率を改善するように変化量しきい値を更新する（ステップＢ１０）。
【００３７】
一方、デバッグが必要と判定された場合は（ステップＢ９のＮＯ）、開発者によるソフトウェアのデバッグ処理を行い、その結果（例えばソフトウェアエージングの問題の有無）をデバッグ結果入力手段によって受け付ける（ステップＢ１１）。デバッグの結果、実際にソフトウェアエージングの問題となるソフトウェア欠陥が含まれていたかどうかが判明する。しきい値更新手段１０７は分析結果とデバッグ結果の一致・不一致を判定し、テスト効率を改善するように変化量しきい値を更新する（ステップＢ１２）。例えば、デバッグの結果、示唆されたソフトウェアエージングのほとんどが誤検知であったと判明した場合、テスト間隔が長すぎる可能性があるため、テストの間隔をより短くするようにしきい値Ｄを更新する。逆に、デバッグ結果が分析結果と適確に一致していた場合は、現在のテスト間隔で適切に問題が検出できているため、現在のしきい値Ｄを維持する。あるいは、テスト間隔を少し長くとれる可能性があるため、テスト間隔が短い場合は間隔をより長くするようにしきい値Ｄを更新しても良い。
【００３８】
[効果の説明] 
次に、本発明を実施するための形態の効果について説明する。
本発明を実施するための形態では、テスト結果比較手段１０６によってソフトウェアのデバッグの必要性を判定し、しきい値更新手段１０７がデバッグの結果と分析結果の相違に基づいてソフトウェアエージングの誤検知を減らすようにしきい値を設定するように構成されているため、ソフトウェアエージングの検出精度を高めることができる。
【実施例】
【００３９】
次に、具体的な実施例を用いて本発明を実施するための形態の動作を説明する。【００４０】
複数のメンバで構成される開発チームによってソフトウェア開発が行われている状況を想定する。ソフトウェアのソースコードはソフトウェアバージョン管理記憶装置１０１に格納し、開発メンバで共有する。各メンバはそれぞれ担当の機能を開発し、ソフトウェアバージョン管理記憶装置１０１に更新をコミットする。ここで開発されるソフトウェアのソフトウェアエージングテストを効率的に実施することを目的とする。【００４１】
図５にソフトウェアバージョン管理記憶装置１０１に記録されたコミットログの一例を示す。コミットログの各行は、いつ（Date）、誰が（User）、どのような更新を行ったかを記録する。コミットする各メンバがどのような変更を行ったかをコメント（Comment）に記述する。リビジョン（Revision）はソフトウェアバージョン管理記憶装置１０１で記録したコミットの通し番号で、コミットの都度値が自動的に更新される。タグ（Tag）はソフトウェアのある一時点でのスナップショットを記録するために用いられるラベルで、図５の例では5/21にBobによってバージョン0.7のタグがつけられていることを示している。このようなコミットログはSubversionなどのバージョン管理システムにおいて一般的なものであり、特定のソフトウェアバージョン管理システムに特化したものではない。【００４２】
ここで、0.7のタグが打たれたソフトウェアのバージョンに対して負荷テストを実施し、ソフトウェアエージングの問題が確認されなかったものとする。バージョン0.7はソフトウェアエージングの検出されなかった直近のソフトウェアバージョン（LGV）となる。以降ソフトウェア開発の進行に合わせて負荷テスト実施必要性の有無を変化量チェック手段１０２が判断する。例えば、変化量しきい値格納装置１０３に格納された変化量のしきい値Ｄがコミット数＝５であるとする。このとき、図２のフローチャートのステップＡ５までの処理に従い、コミット数が５になるまでは負荷テストが実施されない。図５のコミットログを参照すると、5/24のDaveによるコミットにより、リビジョン番号が59となり、直近の正常なソフトウェアバージョン（LGV）からのコミット数が5に達する。したがって、このバージョンが負荷テストの対象となり、負荷テスト手段１０４によってテストが実行される。負荷テスト中は定期的にシステムメトリクスの値を監視し、観測した結果を負荷テスト結果格納装置１０５に格納する。次に、テスト結果比較手段１０６はテスト対象のソフトウェアバージョン（SVUT）と直近の正常なソフトウェアバージョン（LGV）の負荷テストの結果を比較する。【００４３】
ケース１
負荷テストを実施した際にソフトウェアが消費したメモリ量（Resident Set Size）の変化を観測した結果、図６の結果が得られた場合を考える。テスト対象のソフトウェアバージョン（SVUT）と直近の正常なソフトウェアバージョン（LGV）で観測されたそれぞれの値、および観測結果から線形回帰分析によって得られた近似曲線を示す。近似曲線の傾きを比較してわかるように、テスト対象のソフトウェアバージョン（SVUT）と直近の正常なソフトウェアバージョン（LGV）に大きな傾きの差は見られない。したがって、この場合はテスト対象のソフトウェアバージョンにソフトウェアエージングは存在しないと判定する。判定の際に、具体的な差のしきい値を用いても良い。例えば、Resident Set Sizeの変化量の差が2.0以下であれば、ソフトウェアエージングは存在しないと判定する。この結果から、しきい値更新手段１０７は現在の負荷テストを実施する間隔はより長く設定する余地があると判断し、コミット数に関するしきい値を例えば５から７に変更する。この設定変更により、次回の負荷テスト実施は先延ばしされ、その間により多くの更新を行うことができるため、開発効率の改善につながる。【００４４】
ケース２
観測したメモリ量の変化が図７のようであったとする。テスト対象のソフトウェアバージョン（SVUT）と直近の正常なソフトウェアバージョン（LGV）で観測された値から線形回帰分析を行った直線の傾きを比較すると、明らかにテスト対象のソフトウェアバージョンに大きな傾向の変化が認められる。このような場合、テスト対象のソフトウェアバージョンにソフトウェアエージングの問題が存在していると判定する。判定の際に、具体的な差のしきい値を用いても良い。例えば、Resident Set Sizeの変化量の差が5.0以上であれば、ソフトウェアエージングの問題が存在すると判定する。エージングの問題が存在するという分析結果が得られた際にはデバッグを必要とするものとする。デバッグが必要と判定されると、ソフトウェアエージングの原因を究明するため、開発者がソースコードを解析する。解析した結果はしきい値更新手段１０７に入力される。【００４５】
ここで、デバッグの結果、ソフトウェアエージングの原因となる欠陥が見つかった場合を考える。このとき、バージョンの比較によるソフトウェアエージングの問題検出の結果は正しかったこととなる。したがって、現在の負荷テスト実施間隔はソフトウェアエージングを検出するためには適度な間隔であり、しきい値更新手段は現在のしきい値をそのまま維持する選択をする。検出精度には問題がないため、負荷テストの間隔を延ばすようにしきい値を更新しても良い。しきい値を維持あるいは更新することで、検出の精度を維持しつつ、適度なテスト実施間隔を維持あるいはテスト間隔をより長くするようにして開発効率を高めることができる。【００４６】
ケース３
図７に示す観測結果が得られ、ソフトウェアエージングが存在すると判定したが、デバッグによってその判定が誤りであったことが分わかった場合を考える。すなわち、バージョンの比較によるソフトウェアエージングの問題検出の結果が間違っていたことになる。傾向変化の原因は必要な機能追加等に起因している。誤検知によるソースコード解析の労力を減らす上では、このような基本的な傾向の変化をできるだけ早期に把握しておくことが重要である。したがって、しきい値更新手段は誤検知ができるだけ早期に発見されるようにコミット数に関するしきい値を例えば５から４に変更する。この設定変更により、より高頻度で負荷テストのバージョンの比較が実施されるため、誤検知の問題をできるだけ早期に解決して開発を効率化することができる。【００４７】
以上の例ではコミット数に関してしきい値を用いたが、コミット数の代わりにソースコードの変更行数、追加された機能の数、メモリ管理に関連する関数の数、アクセスするオブジェクトの数、新たに追加された外部ライブラリの数などの１つ以上のソフトウェアメトリクスや、経過期間などを用いても良い。【００４８】
また、ソフトウェアエージングの傾向を見る指標としてResident Set Sizeの例を示したが、負荷テストを実施する際には、空きメモリ容量、仮想メモリサイズ、スワップ利用サイズ、ディスク空き容量、プロセス数などの１つ以上の指標も観測して比較評価に利用することもできる。【００４９】
さらに、測定した結果を線形回帰分析によって直線近似する例を示したが、傾きを予測するノンパラメトリックな手法（Sen’s slope estimate）や時系列の周期性も考慮した傾向分析を行う手法（Hodrick-Prescott Filer）などを用いても良い。【００５０】
なお、上記のソフトウェアエージングテストシステムは、ハードウェア、ソフトウェア又はこれらの組合せにより実現することができる。また、上記のソフトウェアエージングテストシステムにより行なわれるソフトウェアエージングテスト方法も、ハードウェア、ソフトウェア又はこれらの組合せにより実現することができる。ここで、ソフトウェアによって実現されるとは、コンピュータがプログラムを読み込んで実行することにより実現されることを意味する。【００５１】
プログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えば、フレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば、光磁気ディスク）、ＣＤ−ＲＯＭ(Read Only Memory)、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ(Programmable ROM)、ＥＰＲＯＭ(Erasable PROM)、フラッシュＲＯＭ、ＲＡＭ(random access memory)）を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。【００５２】
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。【００５３】
（付記１）
実施基準に従ってテスト対象のバージョンのソフトウェアに負荷テストを実施し、そのテスト結果と比較対象の以前のバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出し、検出結果に基づいて前記実施基準を変更して次回以降の負荷テストの実施頻度を調整することを特徴とするソフトウェアエージングテストシステム。【００５４】
（付記２）
テスト対象のバージョンのソフトウェアとソフトウェアエージングの問題のない直近の正常なバージョンのソフトウェアとの差分を定量的に示す変化量を求め、前記変化量から前記実施基準に基づいて負荷テストの要否を判定する判定手段と、
前記判定手段により負荷テストの実施が必要と判定された場合にテスト対象のバージョンのソフトウェアに負荷テストを実施する実施手段と、
前記実施手段により得られたテスト対象のバージョンのソフトウェアの負荷テストのテスト結果と、事前に得られた前記直近の正常なバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出する検出手段と、
前記検出手段により得られたソフトウェアエージングの問題の有無の検出結果に基づいて前記実施基準を更新する更新手段と
を備えたことを特徴とする付記１に記載のソフトウェアエージングテストシステム。【００５５】
（付記３）
前記変化量はソフトウェアのコミット数の変化量を含み、その変化量のしきい値を前記実施基準とすることを特徴とする付記２に記載のソフトウェアエージングテストシステム。【００５６】
（付記４）
前記変化量はソフトウェアに含まれるコード行数、機能の数、オブジェクトの数、関数の数、及び外部ライブラリの数を含む群のうちの１つ以上を含むソフトウェアメトリクスの変化量を含み、その変化量のしきい値を前記実施基準とすることを特徴とする付記２に記載のソフトウェアエージングテストシステム。【００５７】
（付記５）
前記変化量はソフトウェア開発における経過時間の変化量を含み、その変化量のしきい値を前記実施基準とすることを特徴とする付記２に記載のソフトウェアエージングテストシステム。【００５８】
（付記６）
前記検出手段は、負荷テストにおいてソフトウェアが消費したメモリ量の時間変化を両テスト結果間で比較することによりソフトウェアエージングの問題の有無を検出することを特徴とする付記２〜５のいずれか１に記載のソフトウェアエージングテストシステム。【００５９】
（付記７）
前記検出手段は、負荷テストにおける空きメモリ容量、仮想メモリサイズ、スワップ利用サイズ、ディスク空き容量及びプロセス数を含む群のうちの１つ以上についての時間変化を両テスト結果間で比較することによりソフトウェアエージングの問題の有無を検出することを特徴とする付記２〜５のいずれか１に記載のソフトウェアエージングテストシステム。【００６０】
（付記８）
前記時間変化を両テスト結果間で比較する際に線形回帰分析により前記時間変化を直線近似し、近似直線の傾きを両テスト結果間で比較することを特徴とする付記６又は７に記載のソフトウェアエージングテストシステム。【００６１】
（付記９）
前記更新手段は、前記検出手段がソフトウェアエージングの問題を検出しなかった場合には、負荷テストの実施間隔がより長くなるように前記実施基準を更新することを特徴とする付記２〜８のいずれか１に記載のソフトウェアエージングテストシステム。【００６２】
（付記１０）
前記更新手段は、前記検出手段がソフトウェアエージングの問題を検出した場合には、負荷テストの実施間隔がより短くなるように前記実施基準を更新することを特徴とする付記２〜９のいずれか１に記載のソフトウェアエージングテストシステム。【００６３】
（付記１１）
ソフトウェアエージングの問題が検出された場合に実施したデバッグの結果を入力するデバッグ結果入力手段を更に備え、
前記更新手段は、前記デバッグ結果入力手段が入力したデバッグ結果と前記検出手段によるソフトウェアエージングの問題の有無の検出結果とに基づいて前記実施基準を更新することを特徴とする付記２〜８のいずれか１に記載のソフトウェアエージングテストシステム。【００６４】
（付記１２）
前記更新手段は、前記デバッグ結果と前記ソフトウェアエージングの問題の有無の検出結果が一致するか否かを判定し、一致しない場合には負荷テストの実施間隔がより短くなるように前記実施基準を更新することを特徴とする付記１１に記載のソフトウェアエージングテストシステム。【００６５】
（付記１３）
前記更新手段は、前記デバッグ結果と前記ソフトウェアエージングの問題の有無の検出結果が一致するか否かを判定し、一致する場合には前記実施基準を維持するか又は負荷テストの実施間隔がより長くなるように前記実施基準を更新することを特徴とする付記１１又は１２に記載のソフトウェアエージングテストシステム。【００６６】
（付記１４）
実施基準に従ってテスト対象のバージョンのソフトウェアに負荷テストを実施し、そのテスト結果と比較対象の以前のバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出し、検出結果に基づいて前記実施基準を変更して次回以降の負荷テストの実施頻度を調整することを特徴とするソフトウェアエージングテスト方法。【００６７】
（付記１５）
テスト対象のバージョンのソフトウェアとソフトウェアエージングの問題のない直近の正常なバージョンのソフトウェアとの差分を定量的に示す変化量を求め、前記変化量から前記実施基準に基づいて負荷テストの要否を判定する判定ステップと、
前記判定ステップにて負荷テストの実施が必要と判定された場合にテスト対象のバージョンのソフトウェアに負荷テストを実施する実施ステップと、
前記実施ステップで得られたテスト対象のバージョンのソフトウェアの負荷テストのテスト結果と、事前に得られた前記直近の正常なバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出する検出ステップと、
前記検出ステップで得られたソフトウェアエージングの問題の有無の検出結果に基づいて前記実施基準を更新する更新ステップと
を含むことを特徴とする付記１４に記載のソフトウェアエージングテスト方法。【００６８】
（付記１６）
前記変化量はソフトウェアのコミット数の変化量を含み、その変化量のしきい値を前記実施基準とすることを特徴とする付記１５に記載のソフトウェアエージングテスト方法。【００６９】
（付記１７）
前記変化量はソフトウェアに含まれるコード行数、機能の数、オブジェクトの数、関数の数、及び外部ライブラリの数を含む群のうちの１つ以上を含むソフトウェアメトリクスの変化量を含み、その変化量のしきい値を前記実施基準とすることを特徴とする付記１５に記載のソフトウェアエージングテスト方法。【００７０】
（付記１８）
前記変化量はソフトウェア開発における経過時間の変化量を含み、その変化量のしきい値を前記実施基準とすることを特徴とする付記１５に記載のソフトウェアエージングテスト方法。【００７１】
（付記１９）
前記検出ステップでは、負荷テストにおいてソフトウェアが消費したメモリ量の時間変化を両テスト結果間で比較することによりソフトウェアエージングの問題の有無を検出することを特徴とする付記１５〜１８のいずれか１に記載のソフトウェアエージングテスト方法。【００７２】
（付記２０）
前記検出ステップでは、負荷テストにおける空きメモリ容量、仮想メモリサイズ、スワップ利用サイズ、ディスク空き容量及びプロセス数を含む群のうちの１つ以上についての時間変化を両テスト結果間で比較することによりソフトウェアエージングの問題の有無を検出することを特徴とする付記１５〜１８のいずれか１に記載のソフトウェアエージングテスト方法。【００７３】
（付記２１）
前記時間変化を両テスト結果間で比較する際に線形回帰分析により前記時間変化を直線近似し、近似直線の傾きを両テスト結果間で比較することを特徴とする付記１９又は２０に記載のソフトウェアエージングテスト方法。【００７４】
（付記２２）
前記更新ステップでは、前記検出ステップにてソフトウェアエージングの問題が検出されなかった場合、負荷テストの実施間隔がより長くなるように前記実施基準を更新することを特徴とする付記１５〜２１のいずれか１に記載のソフトウェアエージングテスト方法。【００７５】
（付記２３）
前記更新ステップでは、前記検出ステップにてソフトウェアエージングの問題が検出された場合、負荷テストの実施間隔がより短くなるように前記実施基準を更新することを特徴とする付記１５〜２２のいずれか１に記載のソフトウェアエージングテスト方法。【００７６】
（付記２４）
ソフトウェアエージングの問題が検出された場合に実施したデバッグの結果を入力するデバッグ結果入力ステップを更に含み、
前記更新ステップでは、前記デバッグ結果入力ステップにて入力したデバッグ結果と前記検出ステップでのソフトウェアエージングの問題の有無の検出結果とに基づいて前記実施基準を更新することを特徴とする付記１５〜２１のいずれか１に記載のソフトウェアエージングテスト方法。【００７７】
（付記２５）
前記更新ステップでは、前記デバッグ結果と前記ソフトウェアエージングの問題の有無の検出結果が一致するか否かを判定し、一致しない場合には負荷テストの実施間隔がより短くなるように前記実施基準を更新することを特徴とする付記２４に記載のソフトウェアエージングテスト方法。【００７８】
（付記２６）
前記更新ステップでは、前記デバッグ結果と前記ソフトウェアエージングの問題の有無の検出結果が一致するか否かを判定し、一致する場合には前記実施基準を維持するか又は負荷テストの実施間隔がより長くなるように前記実施基準を更新することを特徴とする付記２４又は２５に記載のソフトウェアエージングテスト方法。【００７９】
（付記２７）
コンピュータに、実施基準に従ってテスト対象のバージョンのソフトウェアに負荷テストを実施し、そのテスト結果と比較対象の以前のバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出し、検出結果に基づいて前記実施基準を変更して次回以降の負荷テストの実施頻度を調整する処理を実行させることを特徴とするソフトウェアエージングテスト用プログラム。【００８０】
（付記２８）
前記コンピュータに、
テスト対象のバージョンのソフトウェアとソフトウェアエージングの問題のない直近の正常なバージョンのソフトウェアとの差分を定量的に示す変化量を求め、前記変化量から前記実施基準に基づいて負荷テストの要否を判定する判定処理と、
前記判定処理にて負荷テストの実施が必要と判定された場合にテスト対象のバージョンのソフトウェアに負荷テストを実施する実施処理と、
前記実施処理で得られたテスト対象のバージョンのソフトウェアの負荷テストのテスト結果と、事前に得られた前記直近の正常なバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出する検出処理と、
前記検出処理で得られたソフトウェアエージングの問題の有無の検出結果に基づいて前記実施基準を更新する更新処理と
を実行させることを特徴とする付記２７に記載のソフトウェアエージングテスト用プログラム。【００８１】
（付記２９）
前記変化量はソフトウェアのコミット数の変化量を含み、その変化量のしきい値を前記実施基準とすることを特徴とする付記２８に記載のソフトウェアエージングテスト用プログラム。【００８２】
（付記３０）
前記変化量はソフトウェアに含まれるコード行数、機能の数、オブジェクトの数、関数の数、及び外部ライブラリの数を含む群のうちの１つ以上を含むソフトウェアメトリクスの変化量を含み、その変化量のしきい値を前記実施基準とすることを特徴とする付記２８に記載のソフトウェアエージングテスト用プログラム。【００８３】
（付記３１）
前記変化量はソフトウェア開発における経過時間の変化量を含み、その変化量のしきい値を前記実施基準とすることを特徴とする付記２８に記載のソフトウェアエージングテスト用プログラム。【００８４】
（付記３２）
前記検出処理では、負荷テストにおいてソフトウェアが消費したメモリ量の時間変化を両テスト結果間で比較することによりソフトウェアエージングの問題の有無を検出することを特徴とする付記２８〜３１のいずれか１に記載のソフトウェアエージングテスト用プログラム。【００８５】
（付記３３）
前記検出処理では、負荷テストにおける空きメモリ容量、仮想メモリサイズ、スワップ利用サイズ、ディスク空き容量及びプロセス数を含む群のうちの１つ以上についての時間変化を両テスト結果間で比較することによりソフトウェアエージングの問題の有無を検出することを特徴とする付記２８〜３１のいずれか１に記載のソフトウェアエージングテスト用プログラム。【００８６】
（付記３４）
前記時間変化を両テスト結果間で比較する際に線形回帰分析により前記時間変化を直線近似し、近似直線の傾きを両テスト結果間で比較することを特徴とする付記３２又は３３に記載のソフトウェアエージングテスト用プログラム。【００８７】
（付記３５）
前記更新処理では、前記検出処理にてソフトウェアエージングの問題が検出されなかった場合、負荷テストの実施間隔がより長くなるように前記実施基準を更新することを特徴とする付記２８〜３４のいずれか１に記載のソフトウェアエージングテスト用プログラム。【００８８】
（付記３６）
前記更新処理では、前記検出処理にてソフトウェアエージングの問題が検出された場合、負荷テストの実施間隔がより短くなるように前記実施基準を更新することを特徴とする付記２８〜３５のいずれか１に記載のソフトウェアエージングテスト用プログラム。【００８９】
（付記３７）
前記コンピュータに、
ソフトウェアエージングの問題が検出された場合に実施したデバッグの結果を入力するデバッグ結果入力処理を更に実行させ、
前記更新処理では、前記デバッグ結果入力処理にて入力したデバッグ結果と前記検出処理で得られたソフトウェアエージングの問題の有無の検出結果とに基づいて前記実施基準を更新することを特徴とする付記２８〜３４のいずれか１に記載のソフトウェアエージングテスト用プログラム。【００９０】
（付記３８）
前記更新処理では、前記デバッグ結果と前記ソフトウェアエージングの問題の有無の検出結果が一致するか否かを判定し、一致しない場合には負荷テストの実施間隔がより短くなるように前記実施基準を更新することを特徴とする付記３７に記載のソフトウェアエージングテスト用プログラム。【００９１】
（付記３９）
前記更新処理では、前記デバッグ結果と前記ソフトウェアエージングの問題の有無の検出結果が一致するか否かを判定し、一致する場合には前記実施基準を維持するか又は負荷テストの実施間隔がより長くなるように前記実施基準を更新することを特徴とする付記３７又は３８に記載のソフトウェアエージングテスト用プログラム。【００９２】
本願は、日本の特願２０１３−１６７４６６（２０１３年０８月１２日に出願）に基づいたものであり、又、特願２０１３−１６７４６６に基づくパリ条約の優先権を主張するものである。特願２０１３−１６７４６６の開示内容は、特願２０１３−１６７４６６を参照することにより本明細書に援用される。【００９３】
本発明の代表的な実施の形態が詳細に述べられたが、様々な変更(changes)、置き換え(substitutions)及び選択(alternatives)が請求項で定義された発明の精神と範囲から逸脱することなくなされることが理解されるべきである。また、仮にクレームが出願手続きにおいて補正されたとしても、クレームされた発明の均等の範囲は維持されるものと発明者は意図する。
【産業上の利用可能性】
【００９４】
本発明は、例えばソフトウェアの信頼性を向上させるためのソフトウェアテストシステムといった用途に適用できる。また、ソフトウェアの開発を効率化させるためのソフトウェア開発プロジェクト管理システムといった用途にも適用可能である。
【符号の説明】
【００９５】
１００  ソフトウェアエージングテストシステム
１０１  ソフトウェアバージョン管理記憶装置
１０２  変化量チェック手段
１０３  変化量しきい値格納装置
１０４  負荷テスト手段
１０５  負荷テスト結果格納装置
１０６  テスト結果比較手段
１０７  しきい値更新手段
【図１】
2015022890.tif 000003
【図２】
2015022890.tif 000004
【図３】
2015022890.tif 000005
【図４】
2015022890.tif 000006
【図５】
2015022890.tif 000007
【図６】
2015022890.tif 000008
【図７】
2015022890.tif 000009
【手続補正書】
【提出日】平成28年1月21日(2016.1.21)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
実施基準に従ってテスト対象のバージョンのソフトウェアに負荷テストを実施し、そのテスト結果と比較対象の以前のバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出し、検出結果に基づいて前記実施基準を変更して次回以降の負荷テストの実施頻度を調整することを特徴とするソフトウェアエージングテストシステム。
【請求項２】
テスト対象のバージョンのソフトウェアとソフトウェアエージングの問題のない直近の正常なバージョンのソフトウェアとの差分を定量的に示す変化量を求め、前記変化量から前記実施基準に基づいて負荷テストの要否を判定する判定手段と、
前記判定手段により負荷テストの実施が必要と判定された場合にテスト対象のバージョンのソフトウェアに負荷テストを実施する実施手段と、
前記実施手段により得られたテスト対象のバージョンのソフトウェアの負荷テストのテスト結果と、事前に得られた前記直近の正常なバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出する検出手段と、
前記検出手段により得られたソフトウェアエージングの問題の有無の検出結果に基づいて前記実施基準を更新する更新手段と
を備えたことを特徴とする請求項１に記載のソフトウェアエージングテストシステム。
【請求項３】
前記変化量はソフトウェアのコミット数の変化量を含み、その変化量のしきい値を前記実施基準とすることを特徴とする請求項２に記載のソフトウェアエージングテストシステム。
【請求項４】
前記更新手段は、前記検出手段がソフトウェアエージングの問題を検出しなかった場合には、負荷テストの実施間隔がより長くなるように前記実施基準を更新することを特徴とする請求項２又は３に記載のソフトウェアエージングテストシステム。
【請求項５】
前記更新手段は、前記検出手段がソフトウェアエージングの問題を検出した場合には、負荷テストの実施間隔がより短くなるように前記実施基準を更新することを特徴とする請求項２から４のいずれか１項に記載のソフトウェアエージングテストシステム。
【請求項６】
ソフトウェアエージングの問題が検出された場合に実施したデバッグの結果を入力するデバッグ結果入力手段を更に備え、
前記更新手段は、前記デバッグ結果入力手段が入力したデバッグ結果と前記検出手段によるソフトウェアエージングの問題の有無の検出結果とに基づいて前記実施基準を更新することを特徴とする請求項２から５のいずれか１項に記載のソフトウェアエージングテストシステム。
【請求項７】
前記更新手段は、前記デバッグ結果と前記ソフトウェアエージングの問題の有無の検出結果が一致するか否かを判定し、一致しない場合には負荷テストの実施間隔がより短くなるように前記実施基準を更新することを特徴とする請求項６に記載のソフトウェアエージングテストシステム。
【請求項８】
前記更新手段は、前記デバッグ結果と前記ソフトウェアエージングの問題の有無の検出結果が一致するか否かを判定し、一致する場合には前記実施基準を維持するか又は負荷テストの実施間隔がより長くなるように前記実施基準を更新することを特徴とする請求項６又は７に記載のソフトウェアエージングテストシステム。
【請求項９】
実施基準に従ってテスト対象のバージョンのソフトウェアに負荷テストを実施し、そのテスト結果と比較対象の以前のバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出し、検出結果に基づいて前記実施基準を変更して次回以降の負荷テストの実施頻度を調整することを特徴とするソフトウェアエージングテスト方法。
【請求項１０】
コンピュータに、実施基準に従ってテスト対象のバージョンのソフトウェアに負荷テストを実施し、そのテスト結果と比較対象の以前のバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出し、検出結果に基づいて前記実施基準を変更して次回以降の負荷テストの実施頻度を調整する処理を実行させることを特徴とするソフトウェアエージングテスト用プログラム。
【国際調査報告】
2015022890.tif 000010
2015022890.tif 000011
2015022890.tif 000012
2015022890.tif 000013