JP2024012759A - ソフトウェア分析システム、ソフトウェア分析方法 - Google Patents

Abstract

【課題】複数のソフトウェアの更新履歴が個別に管理されている場合であっても、不具合の原因となっているソフトウェアのバージョンを速やかに特定する。【解決手段】本発明に係るソフトウェア分析システムは、性能テストによって第２ソフトウェアの性能低下を検出した場合、前記第２ソフトウェアの過去バージョンのうち第１ソフトウェアをマージして更新されたものを特定するか、または、前記第１ソフトウェアの参照情報が従前のものから変更されたものを特定することにより、低下原因となっている前記第１ソフトウェアの候補を特定する。【選択図】図４Ｂ

Description

本発明は、ソフトウェアの性能劣化の原因を分析する技術に関する。

複数のソフトウェアによって構成されている情報システムにおいては、性能劣化や不具合があるソフトウェアにおいて生じたとき、その原因が別のソフトウェアにある可能性も考えられる。例えば車両の動作を制御する電子制御装置（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ：ＥＣＵ）は、アプリケーションサイドのソフトウェア（以下ではＡＳＷと呼ぶ）、基盤システムサイドのソフトウェア（以下ではＢＳＷと呼ぶ）、などのように、複数のソフトウェアが連携して動作する。例えばＡＳＷにおいて性能劣化が生じたとき、その原因がＢＳＷ側に起因する場合もある。

下記特許文献１は、プログラムの性能問題の原因を特定する技術を記載している。同文献が記載している技術は、『経路決定装置（１）は、第１差分抽出部（２１），経路抽出部（２２）及び決定部（２３）を備える。第１差分抽出部（２１）は、第１プログラムのソースコードと第２プログラムのソースコードとの複数の差分箇所と、第２プログラムの第１カバレッジ情報とを取得する。第１差分抽出部（２１）は第１カバレッジ情報を参照して、複数の差分箇所から第１カバレッジ情報に含まれる第１差分箇所を抽出する。経路抽出部（２２）は、第２プログラムのソースコードから第１差分箇所から影響を受ける複数の影響経路（３２）を、第１差分箇所（３１）ごとに抽出する。決定部（２３）は、第２プログラムの第２カバレッジ情報を取得し、経路抽出部（２２）によって抽出された複数の影響経路のうち、第２カバレッジ情報に含まれる影響経路を除外する。』というものである（要約参照）。

ＷＯ２０２１／１２４４６４

ソフトウェアの性能テストは、必ずしも頻繁に実施されるとは限らず、実施間隔がある程度の期間にわたる場合もある。特許文献１のような従来技術は、性能劣化の原因となるソフトウェア変更が比較的直近である場合を想定していると考えられる。そうすると、原因となったソフトウェア変更が分析時点からかなり前の時点である場合は、その変更箇所が変更差分箇所として抽出されず、原因箇所を発見することが困難となる可能性が考えられる。

またシステムを構成する複数のソフトウェアがそれぞれ更新履歴を有する場合、ソフトウェアごとに更新履歴が管理されているので、別の開発者が担当しているソフトウェアにおいて性能劣化などの原因がある場合はその原因部分を特定することが困難または長時間を要する場合がある。

本発明は、上記課題に鑑みてなされたものであり、複数のソフトウェアの更新履歴が個別に管理されている場合であっても、不具合の原因となっているソフトウェアのバージョンを速やかに特定することを目的とする。

本発明に係るソフトウェア分析システムは、性能テストによって第２ソフトウェアの性能低下を検出した場合、前記第２ソフトウェアの過去バージョンのうち第１ソフトウェアをマージして更新されたものを特定するか、または、前記第１ソフトウェアの参照情報が従前のものから変更されたものを特定することにより、低下原因となっている前記第１ソフトウェアの候補を特定する。

本発明に係るソフトウェア分析システムによれば、複数のソフトウェアの更新履歴が個別に管理されている場合であっても、不具合の原因となっているソフトウェアのバージョンを速やかに特定することができる。上記以外の課題、構成、効果などについては、以下の実施形態の説明により明らかにされる。

ＥＣＵが搭載しているソフトウェアの構成を模式的に示す図である。 ソフトウェアの継続的インテグレーション（ＣＩ）を説明する模式図である。 複数のソフトウェアがそれぞれ個別にバージョン管理されている場合の課題を説明する図である。 実施形態１において不具合の原因箇所を探索する手順を説明する概念図である。 実施形態１において不具合の原因箇所を探索する手順を説明する概念図である。 従来の２分探索によってＢＳＷ側の問題個所を探索する手順を説明する概念図である。 実施形態２に係るソフトウェア分析手法において不具合の原因箇所を探索する手順を説明する概念図である。 実施形態２に係るソフトウェア分析手法において不具合の原因箇所を探索する手順を説明する概念図である。 実施形態４に係るソフトウェア分析システム１の構成図である。 分析装置２００の動作を説明するフローチャートである。 分析装置１００の動作を説明するフローチャートである。 性能劣化の原因となっている問題個所を特定した結果を可視化して提示する画面インターフェースの例である。

＜実施の形態１＞
図１は、ＥＣＵが搭載しているソフトウェアの構成を模式的に示す図である。ＥＣＵは例えば、アプリケーションサイドのソフトウェア（ＡＳＷ）と、基盤システムサイドのソフトウェア（ＢＳＷ）とを搭載している。ＡＳＷとＢＳＷとの間は、適当なインターフェースを介して、相互に（あるいは一方から他方に向けて）機能を提供することができる。例えばＢＳＷがソフトウェア上の関数として提供する機能を、ＡＳＷが利用することができる。

図２は、ソフトウェアの継続的インテグレーション（ＣＩ）を説明する模式図である。ＣＩにおいて典型的には、ソースコードのバージョン管理ツール内に、ソースコードの変更履歴（例えば変更するごとのソースコード全文と差分箇所のマーク）を蓄積する。ソースコードをバージョン管理ツールへ登録する（その時点におけるバージョンを確定する）ことを、コミットと呼ぶ。コミットにともなって、自動テストツールを実行することにより、回帰テストや性能テストを実施する場合もある。このテストは、ソースコードの静的解析や、ビルド（ソースコードをコンパイルして実行可能形式とする）して実際にプログラムを実行することを含む。テスト結果は関係者（開発者など）に対して通知される。

ＣＩの上記仕組みは、自動テスト機能によって、不具合をチェックするための所要時間を抑制しつつも、不具合箇所はテスト結果として確実に報告され、かつテストの属人性を排除して均一なテスト品質を維持することができる。ただし、性能テストなど一部のテスト項目は、所要時間が長時間にわたる場合があるので、コミットごとにテストを実施することは困難であり、ある程度の間隔（例：２週間ごと、１か月ごと、など）を空けて実施されるのが一般的である。このようなテスト項目については、不具合を発見するまで、その時間間隔を要することになる。従来のソフトウェア分析手法は、この点について改善の余地があると考えられる。

図３は、複数のソフトウェアがそれぞれ個別にバージョン管理されている場合の課題を説明する図である。バージョン管理ツールは一般に、例えば２分探索によって、問題があるバージョン（コミットの通番）のソースコードを探索する機能を備えている。図３の例においては、最初にコミット（Ｃ１）したソースコードはテスト結果が問題なし（ｇｏｏｄ）であったが、９回目にコミットしたソースコードは問題あり（ｂａｄ）であった。バージョン管理ツールは、Ｃ９から遡って過去バージョン（典型的にはＣ１とＣ９との間の中間バージョン、図３においてはＣ５）を取得してテストする。テスト結果が問題なしであれば、Ｃ５よりも前方（より新しい）の中間バージョン（図３においてはＣ７）について、同様にテストする。この繰り返しにより、テスト結果が問題あるバージョンのうち最も古いもの（すなわちＣ９における問題の原因となっているバージョン）を特定することができる。このときのテストは、自動でも手動でもよい。

図３のような２分探索による問題バージョンの探索は、効率的に問題個所を特定することができる。一方で、複数のソフトウェアが連動して動作し、かつ各ソフトウェアが個別にバージョン管理されている場合を想定する。この場合、開発しているソフトウェアのテスト時に不具合が発見されたとき、その不具合の原因が別ソフトウェア上にある可能性が考えられる。したがって、別ソフトウェアのバージョン管理ツール内を探索して問題個所を特定する必要がある。しかしバージョン管理ツールをまたいで効率的に問題個所を探索する手法は、これまで十分検討されていない。

本発明の実施形態１に係るソフトウェア分析手法は、このような課題に鑑みて、連動動作する複数のソフトウェアがそれぞれ個別にバージョン管理されている場合において、性能テストなどの結果が問題ありの場合、その原因箇所を効率的に探索する手法を提供するものである。

図４Ａ～図４Ｂは、本実施形態において不具合の原因箇所を探索する手順を説明する概念図である。開発者は図１のＡＳＷを開発しており、ＡＳＷはＢＳＷが提供する機能を利用する。ＡＳＷとＢＳＷは、それぞれ個別のバージョン管理ツール（または同じバージョン管理ツール内の別インスタンスなど）によって、互いに独立してバージョン管理されている。ここでは、ＡＳＷの性能テストにおいて性能低下が発見され、その原因がＢＳＷ側にある場面を想定する。

ＡＳＷがＢＳＷ側の機能を利用する場合、ＡＳＷをビルドまたはテストする際に、ＢＳＷを取り込んだ上でこれらを実施する場合がある。例えばＢＳＷ側のあるバージョンのソースコード（あるいはコンパイル済のバイナリ、クラスライブラリ、などのように、ＡＳＷ側の実行時においてＢＳＷ機能を利用できるようにするためのもの）を、ＡＳＷ側の開発環境へ取り込む場合がある。取込元のＢＳＷバージョンと取込先のＡＳＷバージョンとの間の対応関係は、開発計画においてあらかじめ定めておけばよい。この例においては、ＡＳＷのコミットＣ２がＢＳＷのコミットＣ１（図４Ｂに示す）を取り込み、ＡＳＷのコミットＣ６がＢＳＷのコミットＣ５（図４Ｂに示す）を取り込むことを、あらかじめ規定済であるものとする。

図４Ａの開始時点において、過去に実施した初回コミットはテスト結果に問題なく（ｇｏｏｄ）、９回目のコミット時に実施した性能テストにおいて問題が発見された（ｂａｄ）ものとする。以下に説明する手順により、ＢＳＷ側においてその問題の原因となったソースコードバージョンを探索する。ＡＳＷ側において探索工程を実施するのは第２分析装置であり、ＢＳＷ側において探索工程を実施するのは第１分析装置であるものとする。これらの分析装置の構成は後述する。後述するＢＳＷ側においても、ＢＳＷのコミットＣ１は性能テスト結果が良好であったことを前提とする。

１回目の性能テストにおいて、第２分析装置は、ＡＳＷのソースコードの過去バージョンのうち、ＢＳＷを取り込んだものを特定する。ここではコミットＣ２とＣ６がこれに相当する。第２分析装置は、それらのうち最も古いもの（Ｃ２）について、性能テストを実施する。ここではテスト結果が良好であったものとする。

２回目の性能テストにおいて、第２分析装置は、ＢＳＷを取り込んだ過去バージョンのうち最も新しいもの（ここではＢＳＷを取り込んだバージョンがＣ２とＣ６の２つのみなので、Ｃ６が最も新しい）について、性能テストを実施する。ここではテスト結果が問題ありであったものとする。ＡＳＷ側において実施する性能テストは、ＢＳＷを取り込んだバージョンについてのみとする。したがってＡＳＷ側における性能テストは以上で完了する。

ＡＳＷ側におけるテスト対象は、ＢＳＷを取り込んだバージョンに限定するが、そのなかで探索対象（テスト対象）を選択する基準としては２分探索に準じる。すなわち第２分析装置は、２分探索によって、ＡＳＷソースコードのうちテスト対象とするものを選択する。例えば図４Ａにおいて、Ｃ２とＣ６以外にもＢＳＷを取り込んだ過去バージョンがあれば、それらに対して２分探索の要領で、性能テストの対象を決定する。

３回目の性能テスト（図４Ｂ）において、第１分析装置は、ＢＳＷソースコードの過去バージョンのうちＡＳＷ側へ取り込んだものの最新版（ここではＢＳＷのコミットＣ５）について、性能テストを実施する。ここではテスト結果が問題ありであったものとする。そうするとＢＳＷ側においては、コミットＣ２～Ｃ５のうちいずれかの時点で、問題原因が発生したと推定することができる。以下の探索手順は２分探索と同様である。

４回目の性能テストにおいて、第１分析装置は、ＢＳＷのコミットＣ２～Ｃ４のうち中間バージョン（ここではＣ３）について、性能テストを実施する。ここではテスト結果が良好であったとする。５回目の性能テストにおいて、第１分析装置は、Ｃ２～Ｃ５のうちテスト未実施のコミットＣ４について性能テストを実施する。ここではテスト結果が問題ありであったものとする。以上により、ＢＳＷ側において問題原因となっているバージョンＣ４を特定できたことになる。

図５は、従来の２分探索によってＢＳＷ側の問題個所を探索する手順を説明する概念図である。ＡＳＷ側において第２分析装置は、コミットＣ９から開始する２分探索によって問題個所を探索する。ここでは、Ｃ９＝＞Ｃ５＝＞Ｃ７＝＞Ｃ６の順に、性能テストを実施することになる。以下の手順は図４Ａ～図４Ｂと同様である。図４Ａとは異なり、ＡＳＷ側における探索対象を、ＢＳＷとマージしたバージョンに限定していないので、Ｃ６の性能テストは３回目となる。したがって、図４Ａ～図４Ｂよりも性能テストの実施回数が多いので、問題個所を発見するためにより長時間を必要とする。本実施形態はこの点において従来の２分探索よりも有利である。

＜実施の形態１：補足＞
上記とは異なり、図４Ａの１回目の性能テストにおいて、Ｃ２の性能テスト結果が不良であれば、ＡＳＷ側の不良個所のうち最も古いものはＣ２であることが、その時点で特定できる。したがって次は、ＢＳＷ側のコミットＣ１について性能テストを実施すればよい。その上で、ＢＳＷのコミットＣ１が問題ありであればそれが問題原因であり、ＢＳＷのコミットＣ１が問題なしであればＡＳＷのコミットＣ２が問題原因ということになる。ソフトウェア分析システム１（例えばいずれかの探索部）は、その旨の推定結果を出力する。

上記とは異なり、図４Ａの２回目の性能テストにおいて、Ｃ６の性能テスト結果が良好であれば、ＡＳＷ側において最初に問題が生じたのはＡＳＷ側のコミットＣ７～Ｃ９いずれかということになる。これらはＢＳＷを取り込んでいないので、問題原因はＡＳＷ側にあるということになる。ソフトウェア分析システム１（例えばいずれかの探索部）は、その旨の推定結果を出力する。この場合は、バージョン管理ツールをまたいで原因を探索する必要はないので、本発明が対象とする課題は生じない。

上記とは異なり、図４Ｂの３回目の性能テストにおいて、Ｃ５の性能テスト結果が良好であれば、ＢＳＷ側には問題がないことになる。問題ないＢＳＷソースコードＣ５をＡＳＷのＣ６へ取り込んだ結果、ＡＳＷのＣ６が問題ありとなったからである。ソフトウェア分析システム１（例えばいずれかの探索部）は、その旨の推定結果を出力する。

＜実施の形態１：まとめ＞
本実施形態に係るソフトウェア分析手法は、ＢＳＷ側において性能劣化の原因となっているバージョンを、２分探索に準じて自動的に探索する。これにより、問題個所を特定する技術の属人性を排除し、分析者の分析技能に依拠することなく問題個所を特定することができる。

本実施形態に係るソフトウェア分析手法は、ＡＳＷ側において探索対象とするコミットを特定する際に、２分探索に準じつつも、ＢＳＷを取り込んだバージョンのみについて探索対象とする。これにより、探索対象を絞り込むことができるので、問題個所を特定するために必要な時間を、従来よりも探索することができる。例えば図５に示す従来手法は性能テストを６回実施しているのに対して、図４Ａ～図４Ｂに示す本実施形態は５回で済んでいることが分かる。

本実施形態に係るソフトウェア分析手法は、ＡＳＷ側においてＢＳＷを取り込んだバージョンを起点として、ＢＳＷ側の過去バージョンを探索する。これにより、ＡＳＷとＢＳＷがそれぞれ個別にバージョン管理されている場合であっても、バージョン管理ツールをまたいで、かつ効率的に、問題個所を特定することができる。

本実施形態に係るソフトウェア分析手法は、ソースコードを変更するごと（コミットするごと）に性能テストを実施する必要はなく、ある時点において性能テスト結果が問題あることが分かれば、その時点から遡って問題個所を特定すれば足りる。例えば図４Ａ～図４Ｂにおいて、コミットＣ９の時点で性能問題があることが分かると、過去バージョンに遡りながら性能テストを実施すれば足りる。したがって、性能テストを実施するために用いる実機（例：車載システムにおけるＥＣＵ）を、性能テスト回数分だけ準備する必要はない。

＜実施の形態２＞
図６Ａ～図６Ｂは、本発明の実施形態２に係るソフトウェア分析手法において不具合の原因箇所を探索する手順を説明する概念図である。本実施形態においては、実施形態１で説明した手順に加えて、ＡＳＷ内で呼び出す関数のプロファイル情報を用いる。プロファイル情報は関数の呼び出し頻度の統計を記述した情報であり、例えばバージョン管理ツールがその統計を取得する機能を備えていればこれを用いればよい。あるいはテスト実行時に関数ごとの呼び出しを記録してもよい。その他は実施形態１と概ね同様であるので、前提条件などについては実施形態１に準じる。

図６Ａの開始時点において、第２分析装置は、ＡＳＷのコミットＣ９（性能テストによって問題が見つかった最新バージョン）のプロファイル情報を取得する。便宜上、ＡＳＷが提供する関数名は「ａｓｗ＿」から開始し、ＢＳＷが提供する関数名は「ｂｓｗ＿」から開始するものとしている。

１回目の性能テストにおいて、第２分析装置は、図４Ａと同様にコミットＣ２をテストする。ここではテスト結果が問題なしであったものとする。第２分析装置は、コミットＣ２についてプロファイル情報を取得する。Ｃ９のプロファイル情報とＣ２のプロファイル情報を比較すると、関数ｂｓｗ＿ｆｕｎｃ２の呼出頻度が、Ｃ２とＣ９との間で大きく変化し、Ｃ９における頻度が増加している。そうすると、この関数がＣ９における性能低下の原因になっているのではないかと推測することができる。

２回目の性能テスト（図６Ｂ）において、第１分析装置は、ＡＳＷ側へ取り込んだＢＳＷ過去バージョンのうち最も新しいもの（図６ＢにおいてはＣ５）について、性能テストを実施する。ここではテスト結果が問題ありであったものとする。そうすると、ＡＳＷ側の性能劣化の原因はＢＳＷ側にあると想定され、かつプロファイル情報によれば、関数ｂｓｗ＿ｆｕｎｃ２がその原因であると推定される。第１分析装置は、ＢＳＷのコミットＣ５よりも前について、関数ｂｓｗ＿ｆｕｎｃ２の変更履歴を取得する。ここではコミットＣ１～Ｃ３については変更がなく、コミットＣ４において同関数を変更したものとする。

３回目の性能テストにおいて、第１分析装置は、関数ｂｓｗ＿ｆｕｎｃ２を変更したコミットＣ４について、性能テストを実施する。ここではテスト結果が問題ありであったものとする。そうすると、このバージョンが性能劣化の原因となっている可能性が大きいので、このバージョン（特に関数ｂｓｗ＿ｆｕｎｃ２の変更箇所）について、詳細調査を実施すればよい。

図６Ａにおいては、関数ｂｓｗ＿ｆｕｎｃ２が性能劣化の原因であると推定した。ただし関数の構造によっては、その関数を呼び出した呼出元関数が、性能劣化の原因となっている可能性も考えられる。例えば、呼出元関数は以前は別の関数を呼び出していたが、あるバージョン以降はｂｓｗ＿ｆｕｎｃ２を呼び出すように変更され、これによりＡＳＷ側におけるｂｓｗ＿ｆｕｎｃ２の呼出頻度が増えたと仮定する。この場合、ｂｓｗ＿ｆｕｎｃ２には問題がないにも関わらず、プロファイル情報上では同関数が劣化原因であるかのように見えるので、分析結果として妥当ではない。そこで本実施形態においては、このような場合における探索精度を高めるために、トレース情報を追加的に用いてもよい。

トレース情報は、ＡＳＷ（またはＢＳＷ）が関数を呼び出す順序を記述している。図６Ｂに示す例において、第１分析装置は、２回目の性能テスト時に、コミットＣ５のトレース情報を取得する。トレース情報によれば、関数ｂｓｗ＿ｆｕｎｃ２は、関数ｂｓｗ＿ｉｎｉｔから呼び出されている。そこで第１分析装置は、ｂｓｗ＿ｉｎｉｔについてコミットＣ５以前の変更履歴を取得する。ここではコミットＣ１～Ｃ３については変更がなく、コミットＣ４において同関数を変更したものとする。

３回目の性能テストにおいて、第１分析装置は、関数ｂｓｗ＿ｉｎｉｔを変更したコミットＣ４について、性能テストを実施する。ここではテスト結果が問題ありであったものとする。そうすると、このバージョンが性能劣化の原因となっている可能性が大きいので、このバージョン（特に関数ｂｓｗ＿ｉｎｉｔの変更箇所）について、詳細調査を実施すればよい。

ｂｓｗ＿ｉｎｉｔの変更履歴について調査するのは、ｂｓｗ＿ｆｕｎｃ２を変更した履歴がない場合に限ってもよい。その場合は、ｂｓｗ＿ｆｕｎｃ２が劣化原因ではないと想定されるからである。あるいはｂｓｗ＿ｆｕｎｃ２を変更したバージョンにおいて性能テストが問題なしであった場合に限り、ｂｓｗ＿ｉｎｉｔの変更履歴を調査してもよい。

本実施形態２におけるソフトウェア分析手法は、性能テストの実施回数が３回であるので、実施形態１と比較してさらにテスト回数を削減することができる。図５で説明した従来手法と比較すると、半分の回数で足りる。

＜実施の形態３＞
実施形態２においては、ＡＳＷの性能劣化の原因を推定する根拠として、プロファイル情報またはトレース情報を用いることを説明した。関数の呼出順序に関する変更は、性能劣化の原因となり得るからである。その他に性能劣化の原因となり得るパラメータとしては、以下が挙げられる。

（原因パラメータの例その１）ソースコードをコンパイルするとき、コンパイルオプションを指定する。例えば最適化オプションとして、コンパイル時間の短縮／バイナリサイズの削減／実行パフォーマンスの向上などのうちいずれを重視するかを指定する場合がある。コンパイルオプションが変更されると、それが実行時の性能劣化の原因となり得る。

（原因パラメータの例その２）ソフトウェアを実行するＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）上のメモリマップ（バイナリをメモリ上のどこに配置するかについての情報）や排他制御レベルを変更すると、それが実行時の性能劣化の原因となり得る。

第１分析装置は、テスト対象とするＢＳＷの過去バージョンを特定する際に、実施形態２で説明したトレース情報に代えてまたはこれと併用して、上記２つのパラメータのうち少なくともいずれかを用いてもよい。例えば図６ＢにおいてＣ５のテスト結果が問題ありであった場合、コミットＣ２～Ｃ４のうちコンパイルオプションを変更した時点を、バージョン管理ツール上の変更履歴などを介して取得する。ＯＳパラメータについても同様に取得できる。第１分析装置は、パラメータが変更された時点のコミットについて、性能テストを実施する。以後は実施形態２と同様である。

＜実施の形態４＞
図７は、本発明の実施形態４に係るソフトウェア分析システム１の構成図である。ソフトウェア分析システム１は、実施形態１～３で説明したソフトウェア分析手法を実施するシステムであり、分析装置１００と分析装置２００によって構成されている。分析装置１００は、ＢＳＷ側のコミットを探索する装置であり、ＢＳＷの開発環境を兼ねている。分析装置２００は、ＡＳＷ側のコミットを探索する装置であり、ＡＳＷの開発環境を兼ねている。

分析装置２００（第２分析装置）は、ＡＳＷリポジトリ２１０（第２リポジトリ）、ソースコード取得部２２０、探索部２３０（第２探索部）、ＢＳＷマージ情報取得部２４０、テスト実行部２５０、疑義コミット情報送信部２６０、プロファイル取得部２７０を備える。ＡＳＷリポジトリ２１０は、ＡＳＷのバージョン管理ツールがＡＳＷのソースコードの過去バージョンを格納するデータベースである。ソースコード取得部２２０はＡＳＷリポジトリ２１０からＡＳＷのソースコードの各バージョンを取得する。探索部２３０は、実施形態１～３で説明した、２分探索によるテスト対象バージョンの探索（ＡＳＷ側）を実施する。ＢＳＷマージ情報取得部２４０は、ＡＳＷの過去バージョンのうちＢＳＷを取り込んだコミットを特定する。テスト実行部２５０はＡＳＷの性能テストを実施する。プロファイル取得部２７０は、実施形態２で説明したプロファイル情報を取得する。疑義コミット情報送信部２６０は、プロファイル情報において呼出頻度が基準値以上変化している（例：図６ＡのＣ２においては１０位だが、Ｃ９においては順位が５位以上上がっている）関数がある場合、その旨を分析装置１００に対して通知する。

分析装置１００（第１分析装置）は、ＢＳＷリポジトリ１１０（第１リポジトリ）、ソースコード取得部１２０、探索部１３０（第１探索部）、ＯＳ情報取得部１４０、テスト実行部１５０、トレース取得部１６０を備える。ＢＳＷリポジトリ１１０は、ＢＳＷのバージョン管理ツールがＢＳＷのソースコードの過去バージョンを格納するデータベースである。ソースコード取得部１２０はＢＳＷリポジトリ１１０からＢＳＷのソースコードの各バージョンを取得する。探索部１３０は、実施形態１～３で説明した、２分探索によるテスト対象バージョンの探索（ＢＳＷ側）を実施する。ＯＳ情報取得部１４０は、実施形態３で説明した、ＯＳパラメータおよびその変化点を取得する。コンパイルオプションおよびその変化点を併せて取得してもよい。テスト実行部１５０はＢＳＷの性能テストを実施する。トレース取得部１６０は、実施形態３で説明したトレース情報を取得する。

図８は、分析装置２００の動作を説明するフローチャートである。ここでは１例として実施形態２で説明した手順を説明する。本フローチャートは、図４Ａ（または図６Ａ）の開始時点を初期状態として実施される。以下図８の各ステップについて説明する。

（図８：ステップＳ８０１～Ｓ８０３）
ＢＳＷマージ情報取得部２４０は、ＡＳＷの過去バージョンのうちＢＳＷを取り込んだコミットを特定する（Ｓ８０１）。探索部２３０は、ＡＳＷ側における探索対象（テスト実施によって性能劣化の原因有無を調査する対象となるバージョン）を決定する（Ｓ８０２）。具体的には、ＡＳＷの過去バージョンのうちＢＳＷを取り込んだものを、探索対象として決定する。探索対象を決定できた場合はＳ８０４へ進み（Ｓ８０３：Ｙｅｓ）、決定できなければＳ８０９へスキップする（Ｓ８０３：Ｎｏ）。

（図８：ステップＳ８０４～Ｓ８０７）
ソースコード取得部２２０は、探索対象コミットのＡＳＷソースコードを取得する（Ｓ８０４）。テスト実行部２５０は、テストに先立って設定すべきプロファイル情報がある場合はこれをセットした上で（Ｓ８０５）、探索対象コミットのテストを実施する（Ｓ８０６）。プロファイル情報取得もＳ８０５において実施することができる。テスト実行部２５０は、テスト結果が変化するまで、探索対象コミットを変えながらＳ８０２～Ｓ８０６を実施する（Ｓ８０７）。具体的には、探索対象コミットのうちテスト結果が問題なしのものと問題ありのものをそれぞれ特定するまで、２分探索の要領で探索を実施する。

（図８：ステップＳ８０８～Ｓ８０９）
探索部２３０は、プロファイル情報上の呼出頻度がＣ９におけるものと比較して基準値以上変化しているコミットを特定できるまで、Ｓ８０２～Ｓ８０７を実施する（Ｓ８０８）。図６Ａの例においては、関数ｂｓｗ＿ｆｕｎｃ２の呼出頻度がＣ９におけるものと比較して大きく変化しているコミットＣ２を特定するまで、Ｓ８０２～Ｓ８０７を実施する。疑義コミット情報送信部２６０は、コミットを特定できた時点で、その旨および呼出頻度が大きく変化している関数名を、分析装置１００に対して通知する（Ｓ８０９）。

（図８：ステップＳ８０９：補足）
実施形態１：補足において説明したように、ＡＳＷ側における探索が終了し、ＢＳＷ側においてそれ以上の探索を実施する必要がない場合もある。この場合は、Ｓ８０３において探索対象コミット：なしと判断し、Ｓ８０９においてＢＳＷ側に対してその旨を通知することにより、ソフトウェア分析システム１としての動作を終了することができる。

図９は、分析装置１００の動作を説明するフローチャートである。ここでは１例として図８に対応するＢＳＷ側の動作（トレース情報を用いる動作例）を説明する。本フローチャートは、実施形態２において、探索するリポジトリをＡＳＷ側からＢＳＷ側へ切り替えた時点（図６Ｂにおいては２回目の性能テスト）で開始される。

（図９：ステップＳ９０１～Ｓ９０２）
探索部１３０は、ＢＳＷ側における探索対象（テスト実施によって性能劣化の原因有無を調査する対象となるバージョン）を決定する（Ｓ９０１）。具体的には、Ｓ９０１を最初に実施するときは、ＡＳＷ側においてテスト結果が問題ありであったバージョンに対して取り込まれているＢＳＷ側バージョンを探索開始点とする。２回目以後は、２分探索の要領で、テスト結果が問題ありとなっているバージョンを探索する。探索対象コミットがあればＳ９０３へ進み、なければＳ９０８へスキップする（Ｓ９０２）。

（図９：ステップＳ９０３～Ｓ９０７）
ソースコード取得部１２０は、探索対象コミットのＢＳＷソースコードを取得する（Ｓ９０３）。テスト実行部１５０は、テストに先立って設定すべきトレース情報がある場合はこれをセットした上で（Ｓ９０４）、探索対象コミットのテストを実施する（Ｓ９０５）。トレース情報取得もＳ９０４において実施することができる。テスト実行部１５０は、テスト結果が問題あるコミットを特定した上で（図６ＢにおいてはコミットＣ５）、それ以前のコミットにおいてトレース情報における呼出元関数（図６Ｂにおいてはｂｓｗ＿ｉｎｉｔ）が変更された時点を特定するまで、Ｓ９０１～Ｓ９０５を実施する（Ｓ９０６）。探索部１３０は、次に探索する対象コミットを、呼出元関数が変化した時点のコミットとする（Ｓ９０７）。図６Ｂにおいては、コミットＣ４を次の探索対象とする。

（図９：ステップＳ９０８）
探索部１３０は、以上の手順により、ＢＳＷ側において性能劣化の原因となっている問題個所（問題があるバージョン）を特定する。探索部１３０は、特定した問題個所を記述したデータ、画面インターフェースなどを出力する。

図１０は、性能劣化の原因となっている問題個所を特定した結果を可視化して提示する画面インターフェースの例である。探索部１３０または２３０は、以上の手順によって特定した問題個所（ＢＳＷ側において問題原因となっているバージョン）およびその探索過程を可視化し、例えば画面インターフェースとして提示することができる。可視化の具体的な内容としては、図４Ａ～図４Ｂ、図６Ａ～図６Ｂなどをそのまま提示してもよいし、これらの過程を時系列に沿って提示してもよい。あるいは可視化結果を記述したデータを出力し、別の装置上でこれを再現できるようにしてもよい。

＜本発明の変形例について＞
本発明は、前述した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることが可能であり、また、ある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

以上の実施形態において、ソースコードのバージョンを２分探索によって探索する例を説明したが、その他の探索手法を用いる場合においても本発明を適用することができる。すなわち、以上の実施形態において説明した手法を用いて、探索対象とするバージョンを絞り込むことにより、２分探索以外の探索手法においても、以上の実施形態と同様の効果を発揮できる。

以上の実施形態において、分析装置１００と２００が備える各機能部は、その機能を実装した回路デバイスなどのハードウェアによって構成することもできるし、その機能を実装したソフトウェアをＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などの演算装置が実行することによって構成することもできる。

以上の実施形態において、複数のソフトウェアによって構成されているシステムの例としてＥＣＵを例示したが、本発明はその他のソフトウェアシステムにおいても適用することができる。

１：ソフトウェア分析システム
１００：分析装置
１１０：ＢＳＷリポジトリ
１３０：探索部
２００：分析装置
２１０：ＡＳＷリポジトリ
２３０：探索部

Claims (12)

1. 第１ソフトウェアの性能テストを実行する第１分析装置と、第２ソフトウェアの性能テストを実行する第２分析装置と、を有するソフトウェア分析システムであって、
   前記第１分析装置は、
   前記第１ソフトウェアの更新情報を含めたソフトウェアの情報を蓄積する第１リポジトリと、
   前記第１ソフトウェアの更新情報に基づき前記第１リポジトリ内に蓄積された複数の第１ソフトウェアを探索する第１探索部とを備え、
   前記第２分析装置は、
   前記第２ソフトウェアの更新情報を含めたソフトウェアの情報を蓄積する第２リポジトリと、
   前記第２ソフトウェアの更新情報に基づき前記第２リポジトリ内に蓄積された複数の第２ソフトウェアを探索する第２探索部とを備え、
   前記第２探索部は、
   前記第２ソフトウェアの性能テストを実行することにより、前記第２ソフトウェアの性能低下を検知した場合、
   前記第２リポジトリ内にある前記更新情報を検索し、前記第１ソフトウェアの更新情報をマージして更新された１つ以上の古いバージョンの前記第２ソフトウェアを特定し、特定された前記古いバージョンの前記第２ソフトウェアのテストを実行し、前記第２ソフトウェアの性能劣化に寄与した前記第１ソフトウェアを特定し、
   もしくは、前記第２リポジトリ内にある前記更新情報を検索し、前記第１ソフトウェアの参照情報が更新された１つ以上の古いバージョンの前記第２ソフトウェアと前記第１ソフトウェアとを特定し、
   前記特定された前記第１ソフトウェアの情報を前記第１分析装置に送信し、
   前記第１探索部は、
   前記第２探索部より送信された前記特定された前記第１ソフトウェアの情報に基づき、前記第１リポジトリに格納された１つ以上の古いバージョンの前記第１ソフトウェアを特定し、
   前記古いバージョンの前記第１ソフトウェアの性能テストを実行することにより、性能劣化をした前記第１ソフトウェアを特定する
   ことを特徴とするソフトウェア分析システム。
2. 前記第２探索部は、前記古いバージョンの前記第２ソフトウェアのうち、前記第１ソフトウェアの更新情報をマージして更新されたものについてのみ、テストを実行することにより、前記古いバージョンの前記第２ソフトウェアのうち性能劣化しているバージョンと性能劣化していないバージョンをそれぞれ特定し、
   前記第１探索部は、前記第２探索部が特定した、前記第２ソフトウェアのうち性能劣化しているバージョンと性能劣化していないバージョンそれぞれに対してマージされた前記第１ソフトウェアのバージョンを、前記第１リポジトリから探索する前記第１ソフトウェアのバージョンの両端として特定し、
   前記第１探索部は、前記特定した両端の間にある前記第１ソフトウェアのバージョンに対して性能テストを実行することにより、性能劣化した前記第１ソフトウェアのバージョンを特定する
   ことを特徴とする請求項１記載のソフトウェア分析システム。
3. 前記ソフトウェア分析システムは、前記古いバージョンの前記第２ソフトウェアのうち、前記第１ソフトウェアの更新情報をマージして更新されたものが、性能劣化していない場合は、前記第２ソフトウェアにおける性能劣化の原因は前記第２ソフトウェア側にあると推定する
   ことを特徴とする請求項２記載のソフトウェア分析システム。
4. 前記ソフトウェア分析システムは、前記第１探索部が特定した前記両端の前記第１ソフトウェアのバージョンがいずれも性能劣化していない場合は、前記第２ソフトウェアにおける性能劣化の原因は前記第２ソフトウェア側にあると推定する
   ことを特徴とする請求項２記載のソフトウェア分析システム。
5. 前記第２探索部は、前記第２ソフトウェアが呼び出す関数の呼び出し頻度についての統計を取得し、
   前記第２探索部は、前記統計に含まれる関数のうち、前記第１ソフトウェアが提供しており、かつ、前記第２ソフトウェアのバージョンのうち性能劣化しているものと性能劣化していないものとの間で呼び出し頻度が所定値以上異なっているものを、劣化原因候補関数として特定し、
   前記第１探索部は、前記劣化原因候補関数の更新履歴に基づき、前記両端間にある前記第１ソフトウェアのバージョンのうち前記劣化原因候補関数を従前バージョンから変更したものを、前記第２ソフトウェアにおける性能劣化の原因候補として特定する
   ことを特徴とする請求項２記載のソフトウェア分析システム。
6. 前記第１探索部は、前記第１ソフトウェアが呼び出す関数の順序を記述したトレース情報を取得し、
   前記第１探索部は、前記トレース情報に基づき、前記劣化原因候補関数を呼び出す呼出元関数を特定し、
   前記第１探索部は、前記呼出元関数の更新履歴から、前記両端の間にある前記第１ソフトウェアのバージョンのうち前記呼出元関数を従前バージョンから変更したものを、前記第２ソフトウェアにおける性能劣化の原因候補として特定する
   ことを特徴とする請求項５記載のソフトウェア分析システム。
7. 前記第１探索部は、前記両端間の前記第１ソフトウェアのバージョンにおいて、前記劣化原因候補関数が従前バージョンから変更されている場合は、前記呼出元関数を従前バージョンから変更した前記第１ソフトウェアのバージョンを探索することなく、前記劣化原因候補関数を従前バージョンから変更した前記第１ソフトウェアのバージョンを探索し、
   前記第１探索部は、前記両端間の前記第１ソフトウェアのバージョンにおいて、前記劣化原因候補関数が従前バージョンから変更されていない場合は、前記呼出元関数を従前バージョンから変更した前記第１ソフトウェアのバージョンを探索する
   ことを特徴とする請求項６記載のソフトウェア分析システム。
8. 前記参照情報は、前記第１ソフトウェアのシステムコール関数の変更情報、前記第１ソフトウェアが参照するＯＳの変更情報、前記第１ソフトウェアのコンパイラの変更情報、のうち少なくとも１つである
   ことを特徴とする請求項１記載のソフトウェア分析システム。
9. 前記第１探索部は、前記参照情報として、前記第１ソフトウェアが参照するＯＳの設定変更を記述した変更情報、または、前記第１ソフトウェアのコンパイラのコンパイルオプションの変更を記述した変更情報、のうち少なくとも１つを取得し、
   前記第１探索部は、前記両端間にある前記第１ソフトウェアのバージョンのうち、前記ＯＳの設定または前記コンパイルオプションが従前バージョンから変更されたことを前記変更情報が記述しているものを、前記第２ソフトウェアにおける性能劣化の原因候補として特定する
   ことを特徴とする請求項２記載のソフトウェア分析システム。
10. 前記第１探索部または前記第２探索部のうち少なくともいずれかは、前記探索の過程または前記テストの結果のうち少なくともいずれかを可視化した結果を出力する
    ことを特徴とする請求項１記載のソフトウェア分析システム。
11. 前記第１探索部および前記第２探索部は、２分探索によって前記第１ソフトウェアおよび前記第２ソフトウェアを特定する
    ことを特徴とする請求項１記載のソフトウェア分析システム。
12. 第１ソフトウェアの性能テストを実行する第１分析装置と、第２ソフトウェアの性能テストを実行する第２分析装置と、によってソフトウェアを分析するソフトウェア分析方法であって、
    前記第１分析装置は、
    前記第１ソフトウェアの更新情報に基づき、前記第１ソフトウェアの更新情報を含めたソフトウェアの情報を蓄積する第１リポジトリ内に蓄積された複数の第１ソフトウェアを探索するステップを実施し、
    前記第２分析装置は、
    前記第２ソフトウェアの更新情報に基づき、前記第２ソフトウェアの更新情報を含めたソフトウェアの情報を蓄積する第２リポジトリ内に蓄積された複数の第２ソフトウェアを探索するステップを実施し、
    前記第２ソフトウェアを探索するステップにおいては、
    前記第２ソフトウェアの性能テストを実行することにより、前記第２ソフトウェアの性能低下を検知した場合、
    前記第２リポジトリ内にある前記更新情報を検索し、前記第１ソフトウェアの更新情報をマージして更新された１つ以上の古いバージョンの前記第２ソフトウェアを特定し、特定された前記古いバージョンの前記第２ソフトウェアのテストを実行し、前記第２ソフトウェアの性能劣化に寄与した前記第１ソフトウェアを特定し、
    もしくは、前記第２リポジトリ内にある前記更新情報を検索し、前記第１ソフトウェアの参照情報が更新された１つ以上の古いバージョンの前記第２ソフトウェアと前記第１ソフトウェアとを特定し、
    前記特定された前記第１ソフトウェアの情報を前記第１分析装置に送信し、
    前記第１ソフトウェアを探索するステップにおいては、
    前記第２分析装置より送信された前記特定された前記第１ソフトウェアの情報に基づき、前記第１リポジトリに格納された１つ以上の古いバージョンの前記第１ソフトウェアを特定し、
    前記古いバージョンの前記第１ソフトウェアの性能テストを実行することにより、性能劣化をした前記第１ソフトウェアを特定する
    ことを特徴とするソフトウェア分析方法。

Images