JP6365543B2 - ソフトウェアエージングテストシステム、ソフトウェアエージングテスト方法及びソフトウェアエージングテスト用プログラム - Google Patents
ソフトウェアエージングテストシステム、ソフトウェアエージングテスト方法及びソフトウェアエージングテスト用プログラム Download PDFInfo
- Publication number
- JP6365543B2 JP6365543B2 JP2015531784A JP2015531784A JP6365543B2 JP 6365543 B2 JP6365543 B2 JP 6365543B2 JP 2015531784 A JP2015531784 A JP 2015531784A JP 2015531784 A JP2015531784 A JP 2015531784A JP 6365543 B2 JP6365543 B2 JP 6365543B2
- Authority
- JP
- Japan
- Prior art keywords
- software
- test
- result
- version
- load test
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
- G06F11/3433—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment for load management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/368—Test management for test version control, e.g. updating test cases to a new software version
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3692—Test management for test results analysis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
- G06F11/3428—Benchmarking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/81—Threshold
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/865—Monitoring of software
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
- Stored Programmes (AREA)
Description
本発明はソフトウェアエージングテストシステム、ソフトウェアエージングテスト方法及びソフトウェアエージングテスト用プログラムに関し、特にソフトウェアの開発効率をより高められるソフトウェアエージングテストシステム、ソフトウェアエージングテスト方法及びソフトウェアエージングテスト用プログラムに関する。
ソフトウェアエージングとは、ソフトウェアの長時間連続稼働によってソフトウェアの実行環境に劣化が生じる現象のことである。ソフトウェアエージングは時間と共に進行し、プログラム処理性能の低下やシステム故障率の増加を招く。ソフトウェアエージングの多くはソフトウェアの欠陥（プログラム中のバグ）に起因している。メモリリークはメモリの解放し忘れによって生じる典型的なソフトウェアエージングの一例である。ソフトウェアのリリース後にこのような欠陥が発覚すると、システムの運用に支障をきたし、信頼性の低下につながる。したがって、ソフトウェアエージングの原因となる欠陥はできるだけソフトウェアをリリースする前に取り除くことが望ましい。
ソフトウェアをリリースする前にソフトウェアエージングの問題を検出するためには、ソフトウェアをコンピュータ上で実際に稼働させ、ワークロードを与えてその動作を観察する負荷テストが必要となる。ところが、そのような負荷テストには実験環境を用意してテストを実行する必要があるため、コストと時間がかかる。特に、ソフトウェアエージングの問題を検出するためには長時間の連続稼働と継続的な監視が必要である。そこで、ソフトウェアエージングを検出するための負荷テストを効率化するため、非特許文献１に示すテスト手法が提案されている。
非特許文献１では、同じソフトウェアの過去のバージョンに対して実行した負荷テストの結果と現在のテスト対象のバージョンに対するテスト結果を比較することにより、ソフトウェアエージングの傾向を検出する手法が示されている。例えば、過去のバージョンにおいてメモリの消費量に増加傾向はなく、現在のバージョンにおいて増加傾向が見られた場合、高い確率で現在のバージョンにソフトウェアエージングの原因となる欠陥が含まれていると判定できる。過去の傾向との比較によって判定するため、ソフトウェアを長時間稼働させる前に早期に問題の兆候をとらえることが可能となる。
なお、明細書及び特許請求の範囲において「ソフトウェアエージングの問題」とは、ソフトウェアに潜在的に存在するソフトウェアエージングのリスクを意味する。
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）ともいう）１０が入力として与えられ、テスト対象のソフトウェアに潜在的に存在するエージングリスクの分析結果である潜在エージングリスク分析結果２０が出力される。コンピュータ１００は、ソフトウェアのバージョンを管理するソフトウェアバージョン管理記憶装置１０１と、テスト対象のソフトウェアバージョンの変化量を調べる変化量チェック手段１０２と、負荷テストを実施する基準とする変化量のしきい値を格納する変化量しきい値格納装置１０３と、ソフトウェアに対して負荷テストを実施する負荷テスト手段１０４と、負荷テストの結果を格納する負荷テスト結果格納装置１０５と、負荷テストの結果を過去の結果と比較するテスト結果比較手段１０６と、比較結果に基づいて変化量しきい値を更新するしきい値更新手段１０７とから構成されている。
なお、特許請求の範囲において、上記のコンピュータ１００はソフトウェアエージングテストシステムに対応し、変化量チェック手段１０２は判定手段に対応し、負荷テスト手段１０４は実施手段に対応し、テスト結果比較手段１０６は検出手段に対応し、しきい値更新手段１０７は更新手段に対応する。また、本明細書において「ソフトウェアバージョン」又は単に「バージョン」というときは、該当バージョンのソフトウェアを意味する。
上記の各手段はそれぞれ概略つぎのように動作する。
変化量チェック手段１０２は、テスト対象のソフトウェアバージョンに対して、ソフトウェアエージングの問題が検出されなかった以前の正常なソフトウェアバージョン（複数ある場合には例えば直近のもの）からの変化量をチェックし、変化量がしきい値に達しているか否かを判定する。変化量がしきい値に達している場合にのみ負荷テストを実施するように制御する。
変化量チェック手段１０２は、テスト対象のソフトウェアバージョンに対して、ソフトウェアエージングの問題が検出されなかった以前の正常なソフトウェアバージョン（複数ある場合には例えば直近のもの）からの変化量をチェックし、変化量がしきい値に達しているか否かを判定する。変化量がしきい値に達している場合にのみ負荷テストを実施するように制御する。
負荷テスト手段１０４は、変化量がしきい値に達した場合にテスト対象のソフトウェアバージョンを実行させ、ワークロードを与えたときの実行環境の状態変化を観測し、測定した結果を負荷テスト結果格納装置１０５に格納する。
テスト結果比較手段１０６は、テスト対象のソフトウェアに対する負荷テストの結果と、比較対象の以前のバージョンに対する負荷テストの結果とを比較し、ソフトウェアエージングの有無を検出し、その結果を出力する。
しきい値更新手段１０７は、ソフトウェアエージング検出結果に基づいて、以降の負荷テスト実施間隔を適切に変更するように変化量しきい値を更新する。
これらの手段は、ソフトウェアエージング検出のための負荷テストとバージョン比較とを実施する間隔を負荷テスト実施の都度調整する様に相互に作用することで、開発効率を改善しつつより正確なソフトウェアエージング検出を実現する。
[動作の説明]
次に、図１及び図２のフローチャートを参照して本実施の形態の全体の動作について詳細に説明する。
次に、図１及び図２のフローチャートを参照して本実施の形態の全体の動作について詳細に説明する。
まず、テスト対象のソフトウェアバージョン（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以下であれば、ソフトウェアエージングは存在しないと判定する。この結果から、しきい値更新手段１０７は現在の負荷テストを実施する間隔はより長く設定する余地があると判断し、コミット数に関するしきい値を例えば５から７に変更する。この設定変更により、次回の負荷テスト実施は先延ばしされ、その間により多くの更新を行うことができるため、開発効率の改善につながる。
負荷テストを実施した際にソフトウェアが消費したメモリ量（Resident Set Size）の変化を観測した結果、図６の結果が得られた場合を考える。テスト対象のソフトウェアバージョン（SVUT）と直近の正常なソフトウェアバージョン（LGV）で観測されたそれぞれの値、および観測結果から線形回帰分析によって得られた近似曲線を示す。近似曲線の傾きを比較してわかるように、テスト対象のソフトウェアバージョン（SVUT）と直近の正常なソフトウェアバージョン（LGV）に大きな傾きの差は見られない。したがって、この場合はテスト対象のソフトウェアバージョンにソフトウェアエージングは存在しないと判定する。判定の際に、具体的な差のしきい値を用いても良い。例えば、Resident Set Sizeの変化量の差が2.0以下であれば、ソフトウェアエージングは存在しないと判定する。この結果から、しきい値更新手段１０７は現在の負荷テストを実施する間隔はより長く設定する余地があると判断し、コミット数に関するしきい値を例えば５から７に変更する。この設定変更により、次回の負荷テスト実施は先延ばしされ、その間により多くの更新を行うことができるため、開発効率の改善につながる。
ケース２
観測したメモリ量の変化が図７のようであったとする。テスト対象のソフトウェアバージョン（SVUT）と直近の正常なソフトウェアバージョン（LGV）で観測された値から線形回帰分析を行った直線の傾きを比較すると、明らかにテスト対象のソフトウェアバージョンに大きな傾向の変化が認められる。このような場合、テスト対象のソフトウェアバージョンにソフトウェアエージングの問題が存在していると判定する。判定の際に、具体的な差のしきい値を用いても良い。例えば、Resident Set Sizeの変化量の差が5.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)が請求項で定義された発明の精神と範囲から逸脱することなくなされることが理解されるべきである。また、仮にクレームが出願手続きにおいて補正されたとしても、クレームされた発明の均等の範囲は維持されるものと発明者は意図する。
本発明は、例えばソフトウェアの信頼性を向上させるためのソフトウェアテストシステムといった用途に適用できる。また、ソフトウェアの開発を効率化させるためのソフトウェア開発プロジェクト管理システムといった用途にも適用可能である。
１００ ソフトウェアエージングテストシステム
１０１ ソフトウェアバージョン管理記憶装置
１０２ 変化量チェック手段
１０３ 変化量しきい値格納装置
１０４ 負荷テスト手段
１０５ 負荷テスト結果格納装置
１０６ テスト結果比較手段
１０７ しきい値更新手段
１０１ ソフトウェアバージョン管理記憶装置
１０２ 変化量チェック手段
１０３ 変化量しきい値格納装置
１０４ 負荷テスト手段
１０５ 負荷テスト結果格納装置
１０６ テスト結果比較手段
１０７ しきい値更新手段
Claims (9)
- 実施基準に従ってテスト対象のバージョンのソフトウェアに負荷テストを実施し、そのテスト結果と比較対象の以前のバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出し、検出結果に基づいて前記実施基準を変更して次回以降の負荷テストの実施頻度を調整することを特徴とするソフトウェアエージングテストシステムであって、
テスト対象のバージョンのソフトウェアとソフトウェアエージングの問題のない直近の正常なバージョンのソフトウェアとの差分を定量的に示す変化量を求め、前記変化量から前記実施基準に基づいて負荷テストの要否を判定する判定手段と、
前記判定手段により負荷テストの実施が必要と判定された場合にテスト対象のバージョンのソフトウェアに負荷テストを実施する実施手段と、
前記実施手段により得られたテスト対象のバージョンのソフトウェアの負荷テストのテスト結果と、事前に得られた前記直近の正常なバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出する検出手段と、
前記検出手段により得られたソフトウェアエージングの問題の有無の検出結果に基づいて前記実施基準を更新する更新手段と
を備えたソフトウェアエージングテストシステム。 - 前記変化量はソフトウェアのコミット数の変化量を含み、その変化量のしきい値に達していることを前記実施基準とすることを特徴とする請求項１に記載のソフトウェアエージングテストシステム。
- 前記更新手段は、前記検出手段がソフトウェアエージングの問題を検出しなかった場合には、負荷テストの実施間隔がより長くなるように前記実施基準を更新することを特徴とする請求項１又は２に記載のソフトウェアエージングテストシステム。
- 前記更新手段は、前記検出手段がソフトウェアエージングの問題を検出した場合には、負荷テストの実施間隔がより短くなるように前記実施基準を更新することを特徴とする請求項１から３のいずれか１項に記載のソフトウェアエージングテストシステム。
- ソフトウェアエージングの問題が検出された場合に実施したデバッグの結果を入力するデバッグ結果入力手段を更に備え、
前記更新手段は、前記デバッグ結果入力手段が入力したデバッグ結果と前記検出手段によるソフトウェアエージングの問題の有無の検出結果とに基づいて前記実施基準を更新することを特徴とする請求項１から４のいずれか１項に記載のソフトウェアエージングテストシステム。 - 前記更新手段は、前記デバッグ結果と前記ソフトウェアエージングの問題の有無の検出結果が一致するか否かを判定し、一致しない場合には負荷テストの実施間隔がより短くなるように前記実施基準を更新することを特徴とする請求項５に記載のソフトウェアエージングテストシステム。
- 前記更新手段は、前記デバッグ結果と前記ソフトウェアエージングの問題の有無の検出結果が一致するか否かを判定し、一致する場合には前記実施基準を維持するか又は負荷テストの実施間隔がより長くなるように前記実施基準を更新することを特徴とする請求項５又は６に記載のソフトウェアエージングテストシステム。
- 実施基準に従ってテスト対象のバージョンのソフトウェアに負荷テストを実施し、そのテスト結果と比較対象の以前のバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出し、検出結果に基づいて前記実施基準を変更して次回以降の負荷テストの実施頻度を調整し、
テスト対象のバージョンのソフトウェアとソフトウェアエージングの問題のない直近の正常なバージョンのソフトウェアとの差分を定量的に示す変化量を求め、前記変化量から前記実施基準に基づいて負荷テストの要否を判定し、
負荷テストの実施が必要と判定された場合にテスト対象のバージョンのソフトウェアに負荷テストを実施し、
得られたテスト対象のバージョンのソフトウェアの負荷テストのテスト結果と、事前に得られた前記直近の正常なバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出し、
得られたソフトウェアエージングの問題の有無の検出結果に基づいて前記実施基準を更新することを特徴とするソフトウェアエージングテスト方法。 - コンピュータに、実施基準に従ってテスト対象のバージョンのソフトウェアに負荷テストを実施し、そのテスト結果と比較対象の以前のバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出し、検出結果に基づいて前記実施基準を変更して次回以降の負荷テストの実施頻度を調整する処理と、
テスト対象のバージョンのソフトウェアとソフトウェアエージングの問題のない直近の正常なバージョンのソフトウェアとの差分を定量的に示す変化量を求め、前記変化量から前記実施基準に基づいて負荷テストの要否を判定する処理と、
負荷テストの実施が必要と判定された場合にテスト対象のバージョンのソフトウェアに負荷テストを実施する処理と、
得られたテスト対象のバージョンのソフトウェアの負荷テストのテスト結果と、事前に得られた前記直近の正常なバージョンのソフトウェアの負荷テストのテスト結果とを比較してソフトウェアエージングの問題の有無を検出する処理と、
得られたソフトウェアエージングの問題の有無の検出結果に基づいて前記実施基準を更新する処理とを実行させることを特徴とするソフトウェアエージングテスト用プログラム。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2013167466 | 2013-08-12 | ||
| JP2013167466 | 2013-08-12 | ||
| PCT/JP2014/070688 WO2015022890A1 (ja) | 2013-08-12 | 2014-08-06 | ソフトウェアエージングテストシステム、ソフトウェアエージングテスト方法及びソフトウェアエージングテスト用プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPWO2015022890A1 JPWO2015022890A1 (ja) | 2017-03-02 |
| JP6365543B2 true JP6365543B2 (ja) | 2018-08-01 |
Family
ID=52468277
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2015531784A Expired - Fee Related JP6365543B2 (ja) | 2013-08-12 | 2014-08-06 | ソフトウェアエージングテストシステム、ソフトウェアエージングテスト方法及びソフトウェアエージングテスト用プログラム |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US9858176B2 (ja) |
| JP (1) | JP6365543B2 (ja) |
| WO (1) | WO2015022890A1 (ja) |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10152369B2 (en) * | 2014-09-24 | 2018-12-11 | Activision Publishing, Inc. | Compute resource monitoring system and method associated with benchmark tasks and conditions |
| CN104750612B (zh) * | 2015-03-31 | 2018-03-27 | 腾讯科技（深圳）有限公司 | 对文件操作进行测试方法及装置 |
| US9971677B2 (en) | 2015-05-28 | 2018-05-15 | International Business Machines Corporation | Generation of test scenarios based on risk analysis |
| CN107453960B (zh) * | 2017-09-26 | 2020-08-25 | 青岛聚看云科技有限公司 | 一种在服务测试中处理测试数据的方法、装置和*** |
| JP6940768B2 (ja) * | 2017-11-01 | 2021-09-29 | 富士通株式会社 | テスト制御プログラム、テスト制御装置及びテスト制御方法 |
| CN108595323B (zh) * | 2018-03-30 | 2021-08-03 | 华为技术有限公司 | 一种***测试方法及相关装置 |
| CN109062790B (zh) * | 2018-07-19 | 2022-04-05 | 北京首汽智行科技有限公司 | 车载终端蓝牙固件的升级测试方法 |
| CN110083518B (zh) * | 2019-04-29 | 2021-11-16 | 东北大学 | 一种基于AdaBoost-Elman的虚拟机软件老化预测方法 |
| CN110275825A (zh) * | 2019-05-15 | 2019-09-24 | 南京航空航天大学 | 一种基于构件影响力的软件可靠性评估方法 |
| US11144435B1 (en) | 2020-03-30 | 2021-10-12 | Bank Of America Corporation | Test case generation for software development using machine learning |
| US11036613B1 (en) | 2020-03-30 | 2021-06-15 | Bank Of America Corporation | Regression analysis for software development and management using machine learning |
| CN111881023B (zh) * | 2020-07-10 | 2022-05-06 | 武汉理工大学 | 一种基于多模型对比的软件老化预测方法及装置 |
| CN112000580B (zh) * | 2020-08-27 | 2022-09-23 | 武汉理工大学 | 负载相关的软件老化检测方法 |
| JP7217767B2 (ja) * | 2021-03-19 | 2023-02-03 | 本田技研工業株式会社 | 更新管理サーバ、更新管理方法、及びプログラム |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2001020455A1 (en) * | 1999-09-10 | 2001-03-22 | Koninklijke Philips Electronics N.V. | Microcomputer with test instruction memory |
| US7428726B1 (en) * | 2000-04-12 | 2008-09-23 | Compuware Corporation | Techniques for software configuration tracking |
| US6769114B2 (en) * | 2000-05-19 | 2004-07-27 | Wu-Hon Francis Leung | Methods and apparatus for preventing software modifications from invalidating previously passed integration tests |
| US6609216B1 (en) * | 2000-06-16 | 2003-08-19 | International Business Machines Corporation | Method for measuring performance of code sequences in a production system |
| KR100420266B1 (ko) * | 2001-10-23 | 2004-03-02 | 한국전자통신연구원 | 클러스터 컴퓨터 시스템의 소프트웨어 가용도 개선 방법및 그 장치 |
| US7028290B2 (en) * | 2002-04-29 | 2006-04-11 | Microsoft Corporation | Method and apparatus for prioritizing software tests |
| US20070180490A1 (en) * | 2004-05-20 | 2007-08-02 | Renzi Silvio J | System and method for policy management |
| WO2007038953A1 (en) * | 2005-09-30 | 2007-04-12 | Telecom Italia S.P.A. | A method and system for automatically testing performance of applications run in a distributed processing structure and corresponding computer program product |
| US20080201705A1 (en) * | 2007-02-15 | 2008-08-21 | Sun Microsystems, Inc. | Apparatus and method for generating a software dependency map |
| JP2011090457A (ja) * | 2009-10-21 | 2011-05-06 | Toyota Motor Corp | 車両診断装置 |
| JP2012234448A (ja) * | 2011-05-07 | 2012-11-29 | Hitachi Ltd | ソフトウェア性能逐次予測方法及び予測システム |
| US8850272B2 (en) * | 2011-05-30 | 2014-09-30 | Infosys Limited | Method and system to measure preventability of failures of an application |
| US9785542B2 (en) * | 2013-04-16 | 2017-10-10 | Advantest Corporation | Implementing edit and update functionality within a development environment used to compile test plans for automated semiconductor device testing |
-
2014
- 2014-08-06 US US14/909,519 patent/US9858176B2/en not_active Expired - Fee Related
- 2014-08-06 WO PCT/JP2014/070688 patent/WO2015022890A1/ja active Application Filing
- 2014-08-06 JP JP2015531784A patent/JP6365543B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| WO2015022890A1 (ja) | 2015-02-19 |
| US9858176B2 (en) | 2018-01-02 |
| US20160188449A1 (en) | 2016-06-30 |
| JPWO2015022890A1 (ja) | 2017-03-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6365543B2 (ja) | ソフトウェアエージングテストシステム、ソフトウェアエージングテスト方法及びソフトウェアエージングテスト用プログラム | |
| US11321081B2 (en) | Affinity recommendation in software lifecycle management | |
| US10762110B2 (en) | Method and system for real-time, false positive resistant, load independent and self-learning anomaly detection of measured transaction execution parameters like response times | |
| US9594553B2 (en) | Identifying semantic differences between source code versions | |
| US9400732B2 (en) | Performance regression testing in presence of noise | |
| US8140911B2 (en) | Dynamic software tracing | |
| US8386851B2 (en) | Functional coverage using combinatorial test design | |
| US9921948B2 (en) | Software commit risk level | |
| US8949676B2 (en) | Real-time event storm detection in a cloud environment | |
| US9430359B1 (en) | Identifying and resolving software issues | |
| US20140019403A1 (en) | Transaction server performance monitoring using component performance data | |
| JP2015507303A (ja) | コード網羅率決定方法およびシステム | |
| US9135146B1 (en) | Identifying and resolving software issues | |
| US20200310779A1 (en) | Validating a firmware compliance policy prior to use in a production system | |
| US20170097812A1 (en) | Automated and heuristically managed solution to quantify cpu and path length cost of instructions added, changed or removed by a service team | |
| US20140365833A1 (en) | Capturing trace information using annotated trace output | |
| US9842044B2 (en) | Commit sensitive tests | |
| Amvrosiadis et al. | Getting back up: Understanding how enterprise data backups fail | |
| JP2014021577A (ja) | 故障予測装置、故障予測システム、故障予測方法、及び、故障予測プログラム | |
| US20140324409A1 (en) | Stochastic based determination | |
| US10089213B1 (en) | Identifying and resolving software issues | |
| US20150261661A1 (en) | Artifact selection using textual reports | |
| JP2016018470A (ja) | 情報処理装置，情報処理方法及び情報処理プログラム | |
| US8566074B2 (en) | Mapping between stress-test systems and real world systems | |
| CN113820649B (zh) | 一种电能表固件的寿命可靠性测试方法和装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20170718 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20180403 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20180507 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20180605 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20180618 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6365543 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |