(57)【要約】  本明細書において説明するのは、コンピューティング・システムにおいて検出された問題が、開発者によって混入されたバグなのか、または間欠的な問題なのか判定するためのシステムおよび方法である。問題が検出されると、この問題についての情報を受け取る。次いで、この問題が新たな問題か否か、または以前に検出されたことがあるか否かについて判定を行う。問題が新たな問題であると判定されたとき、この問題についての情報を記憶デバイスに格納する。この問題に対して特徴ベクトルを生成し、この問題がバグである確率を判定するために分析する。この問題がバグであると判定されたとき、この問題の発生をシステムのユーザーに報告し、バグを訂正することができる。一旦バグが訂正されたなら、この訂正をシステムに供給し、システムを訓練するために使用される。【選択図】図１
2020518064.tif 000002
【特許請求の範囲】
【請求項１】
コンピューティング・システムにおいて検出された問題がバグであるか否か自動的に判定する方法であって、
検出された問題についての情報を受け取るステップと、
前記検出された問題についての情報を記憶デバイスに格納するステップと、
前記検出された問題に対して特徴ベクトルを生成するステップと、
前記特徴ベクトルを分析して、前記検出された問題がバグである確率を判定するステップであって、前記分析が少なくとも部分的に前記特徴ベクトルに基づく、ステップと、
前記確率が閾値よりも高いとき、前記検出された問題をクライアント・デバイスに報告するステップと、
を含む、方法。
【請求項２】
請求項１記載の方法であって、更に、前記検出された問題に対する修正を受け取るステップを含む、方法。
【請求項３】
請求項２記載の方法であって、更に、少なくとも部分的に、前記検出された問題に対して受け取った修正に基づいて、前記分析(analyzation)を更新するステップを含む、方法。
【請求項４】
請求項２記載の方法であって、更に、
前記修正を前記検出された問題と関連付けるステップと、
前記修正を前記記憶デバイスに格納するステップと、
を含む、方法。
【請求項５】
請求項１記載の方法であって、更に、１つ以上の追加の検出された問題に関して、前記検出された問題に優先順位を付けるステップを含む、方法。
【請求項６】
請求項１記載の方法において、特徴ベクトルを生成するステップが、前記検出された問題についての情報に対して１つ以上の変換を実行するステップを含む、方法。
【請求項７】
請求項６記載の方法において、前記１つ以上の変換が、正規化、スタック・トレースからのキー・ワードの発生回数の計数、およびビニングから成る１群から選択される、方法。
【請求項８】
システムであって、
少なくとも１つの処理ユニットと、
コンピューター実行可能命令を格納するメモリーと、
を備え、
前記コンピューター実行可能命令が、前記少なくとも１つの処理ユニットによって実行されると、ソフトウェア・システムにおいて問題の発生を検出する方法を前記システムに実行させ、前記方法が、
検出された問題についての情報を受け取るステップと、
前記検出された問題の指紋を、以前に検出された問題の１つ以上の指紋と比較して、前記検出された問題が新たなものであるか否か判定するステップと、
前記検出された問題が新たなものであると判定されたときに、
前記検出された問題についての情報を記憶デバイスに格納するステップと、
前記検出された問題についての情報を、前記検出された問題に対して特徴ベクトルを生成する特徴生成コンポーネントに提供するステップと、
前記特徴ベクトルを、前記特徴ベクトルを分析する評価コンポーネントに供給し、前記検出された問題がバグである確率を判定するステップと、
検出された問題を順番に並べたリストを供給するステップと、
を含む、システム。
【請求項９】
請求項８記載のシステムにおいて、前記評価コンポーネントが１つ以上のモデルと関連付けられ、前記１つ以上のモデルの内各々が、少なくとも部分的に、前記特徴ベクトルに収容されている情報に基づいて、受け取った特徴ベクトルを評価するように構成される、システム。
【請求項１０】
請求項８記載のシステムであって、更に、前記検出された問題に対する修正を受け取るための命令を含む、システム。
【請求項１１】
請求項１０記載のシステムであって、更に、前記修正を前記検出された問題と関連付けるための命令を含む、システム。
【請求項１２】
請求項１０記載のシステムであって、更に、少なくとも部分的に、前記修正に基づいて前記評価コンポーネントの１つ以上のモデルを更新するための命令を含む、システム。
【請求項１３】
請求項８記載のシステムにおいて、前記順番に並べたリストの順序が、前記判定された確率に基づく、システム。
【請求項１４】
請求項８記載のシステムであって、更に、以前に検出された問題を考慮して、前記検出された問題に優先順位を指定するための命令を含む、システム。
【請求項１５】
コンピューター実行可能命令を格納するコンピューター読み取り可能記憶媒体であって、前記コンピューター実行可能命令が処理ユニットによって実行されると、前記処理ユニットに方法を実行させ、前記方法が、
検出された問題に関連する情報を使用して、前記検出された問題に対する特徴ベクトルを生成するステップと、
前記特徴ベクトルを評価コンポーネントの１つ以上のモデルに供給するステップと、
前記評価コンポーネントの１つ以上のモデルに前記特徴ベクトルを分析させ、前記検出された問題がバグである確率を判定するステップと、
前記検出された問題の発生を報告するステップと、
前記検出された問題に対する修正を受け取るステップと、
前記検出された問題に対する前記修正を使用して、前記１つ以上のモデルの内少なくとも１つを更新するステップと、
を含む、コンピューター読み取り可能記憶媒体。
【発明の詳細な説明】
【背景技術】
【０００１】
[0001]  自動統合検査および監視は、種々のソフトウェア・システムにおいてバグの数を減らすための重要なツールである。しかしながら、これらのソフトウェアの複雑さが増大し、多数の異なるプラットフォームを跨いで分散されるに連れて、コンポーネント間の相互運用性が断続的な障害になりつつある。場合によっては、障害がソフトウェア関連の問題である可能性もある。例えば、新たなソフトウェアがシステムに実装されるとき、開発者が１つ以上のバグをシステムに不用意に混入させるおそれがある。このような場合、開発者はバグを特定し、１つ以上の更新をソフトウェアに供給すればよい。他の場合では、障害がネットワークおよび／またはハードウェア問題に関係することもある。これらのエラーが発生するとき、これらはバグのように思われるが、実際には誤検出であることもある。これらの障害は、新たに実装されたコードによって発生するのではないので、開発者はこれらの障害を調査するのに不必要な時間を費やすこともある。
【０００２】
[0002]  これらおよびその他の一般的な検討事項に関して、実施例を説明する。また、比較的具体的な問題について論ずるが、実施例は、背景において特定した具体的な問題を解決することに限定されるのではないことは理解されてしかるべきである。
【発明の概要】
【０００３】
[0003]  本開示は、一般的には、ソフトウェア・システムにおいて検出された問題または障害が、プログラミングによって誘発されたバグの結果なのか、または何らかの他の原因によるものなのか判定するためのシステムおよび方法に関する。ソフトウェア・システムに伴う障害または他の問題が検出されると、本明細書において説明するシステムは、誤検出を追跡して修正(fix)しようとするのではなく、開発者の判断プロセスを誘導し(guide)、彼らがソフトウェア問題（例えば、ソフトウェア・システムへのソース・コードの追加によって生じたバグ）を認識しこれらに取り組むのを助ける。したがって、本明細書において説明するシステムは、開発者が彼らの時間を一層効率的に使う(spend)ことを可能にする。問題が解決されると、種々の検出された問題に対応するデーター（例えば、問題の原因、問題をどのようにして修正したか等）がシステムにフィードバックされ、指針の改良およびモデルの高精度化をもたらす(provide)。
【０００４】
[0004]  したがって、本明細書において説明するのは、コンピューティング・システムにおいて検出された問題がバグであるか否か自動的に判定するための方法である。この方法は、検出された問題についての情報を受け取るステップと、検出された問題についての情報を記憶デバイスに格納するステップとを含む。検出された問題に対して特徴ベクトルを生成し、検出された問題がバグである確率を判定するために分析する。ある実施例では、分析は、少なくとも部分的に、特徴ベクトルに基づく。確率が閾値よりも高いとき、検出された問題がクライアント・デバイスに報告される。
【０００５】
[0005]  また、少なくとも１つの処理ユニットと、コンピューター実行可能命令を格納するメモリーとを備えるシステムについても説明する。コンピューター実行可能命令が少なくとも１つの処理ユニットによって実行されると、ソフトウェア・システムにおいて検出された問題がバグであるか、または誤検出であるか判定するための方法を、このシステムに実行させる。この方法は、検出された問題についての情報を受け取るステップと、検出された問題の指紋を、以前に検出した問題の1つ以上の指紋と比較して、検出された問題が新たなものか否か判定するステップとを含む。検出された問題が新たなものであると判定されたとき、検出された問題についての情報を記憶デバイスに格納する。検出された問題についての情報は、特徴生成コンポーネントにも供給され、特徴生成コンポーネントは、検出された問題に対して特徴ベクトルを生成する。次いで、特徴ベクトルを評価コンポーネントに供給することができ、評価コンポーネントは、この特徴ベクトルを分析して、検出された問題がバグである確率を判定する。次いで、検出された問題を順番に並べたリストをクライアント・デバイスに供給することができる。
【０００６】
[0006]  また、本開示は、コンピューター実行可能命令を格納するコンピューター読み取り可能記憶媒体についても説明する。コンピューター実行可能命令が処理ユニットによって実行されると、検出された問題に関連する情報を使用して、検出された問題に対して特徴ベクトルを生成するステップと、この特徴ベクトルを評価コンポーネントの１つ以上のモデルに供給するステップを含む方法を、処理ユニットに実行させる。評価コンポーネントの１つ以上のモデルは、特徴ベクトルを分析して、検出された問題がバグである確率を判定することができる。次いで、検出された問題の発生を報告する。一旦検出された問題が報告されたなら、検出された問題に対する修正(fix)を受け取ることができる。受け取ったときに、検出された問題に対する修正を使用して１つ以上のモデルの内少なくとも１つが更新される。
【０００７】
[0007]  この摘要は、詳細な説明において以下で更に説明する概念から選択したものを、簡略化した形態で紹介するために設けられている。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を限定するために使用されることを意図するのでもない。
【図面の簡単な説明】
【０００８】
[0008]  以下の図を参照しながら、非限定的および非網羅的な実施例について説明する。
【図１】実施例にしたがって、ソフトウェア・システムにおいて発生した警告を評価し格付けする(ranking)システムを示す。
【図２】実施例にしたがって、ソフトウェア・システムにおいて発生した問題を評価し格付けする方法を示す。
【図３】実施例にしたがって、ソフトウェア・システムにおいて発生した問題を自動的に解決する方法を示す。
【図４】実施例にしたがって、検出された問題についてのフィードバックを受け取る方法を示す。
【図５】本開示の態様を実施することができるコンピューティング・デバイスの物理コンポーネント例を示すブロック図である。
【図６Ａ】本開示の態様を実施することができる移動体コンピューティング・デバイスの簡略ブロック図である。
【図６Ｂ】本開示の態様を実施することができる移動体コンピューティング・デバイスの簡略ブロック図である。
【図７】本開示の態様を実施することができる分散型コンピューティング・システムの簡略ブロック図である。
【図８】本開示の1つ以上の態様を実行するタブレット・コンピューティング・デバイスを示す。
【発明を実施するための形態】
【０００９】
[0017]  以下の詳細な説明では、その一部を形成する添付図面を参照する。添付図面では、一例として、具体的な実施形態または実施例を示す。これらの態様を組み合わせでもよく、他の態様を利用してもよく、本開示から逸脱することなく、構造的変更を行ってもよい。実施例は、方法、システム、またはデバイスとして実施することができる。したがって、実施例は、ハードウェアの実施態様、全体的にソフトウェアの実施態様、またはソフトウェアおよびハードウェアの態様を組み合わせた実施態様という形態を取ることができる。したがって、以下の詳細な説明は、限定的な意味で捕らえてはならず、本開示の範囲は、添付する請求項およびそれらの均等物によって定められるものとする。
【００１０】
[0018]  ソフトウェア・システムの自動検査および監視は、ソフトウェア開発プロセスの統合部分である。本開示は、ソフトウェア・システムにおいて検出された問題または障害がバグであるか否か、またはそれが誤検出であるか否か判定するシステムおよび方法について説明する。
【００１１】
[0019]  例えば、任意の時点において、多くの異なるソフトウェア・コンポーネントが、種々の検査プロセスを受けて、１つのソフトウェア・コンポーネントにおける変更が他のコンポーネントに悪影響を及ぼすか否か、および／または変更がシステムに全体として悪影響を及ぼすか否か確認するのでもよい。場合によっては、種々のソフトウェア・コンポーネントの統合を、新たなソフトウェアを構築する際に、および／または既存のソフトウェア・コンポーネントを修正する際に、検査してもよい。
【００１２】
[0020]  しかしながら、コンポーネントの統合を自動的に検査する自動化ラボ(automation lab)の複雑さのために、怪しい問題または断続的な問題が発生するおそれがある。場合によっては、これらの問題が、いくつかのコンポーネント間の統合を破壊し、誤検出の報告を出す結果となる。誤検出がバグまたは警告として開発者に伝えられることもある。これらの問題が報告されると、開発者は、貴重な時間を費やして、彼ら自身の誤りによるのではなく発生したエラーを修正しようとする場合もある。
【００１３】
[0021]  本明細書において説明するシステムは、自動化ラボから発生して(originate)報告されたバグまたは警報の各々を走査し、どのバグおよび／または警告を開発者が優先すべきかについての判断支援を開発者に提供するように構成される。また、このシステムは、誤検出であると想定された問題、またそうでなければ(otherwise)誤検出であると判定された問題、を自動的に解決することもできる。
【００１４】
[0022]  例えば、問題、障害、または他の警告（ここでは纏めて「問題」と呼ぶ）が検出されたとき、この問題についての情報を自動化ラボから記憶レイヤーに送信する。特徴生成コンポーネントが、この記憶コンポーネントにアクセスして、格納されている情報を使用して、問題に対して特徴ベクトルを生成する。次いで、特徴ベクトルを評価コンポーネントに送信する。評価コンポーネントは、特定の問題が誤検出であるか、または実際にバグであるか否か予測する、またそうでなければ判定する、ために使用される種々のモデルをホストする。
【００１５】
[0023]  本明細書において使用する場合、「バグ」という用語はソフトウェア・バグを意味する。例えば、ソフトウェア・バグは、ソース・コードの変更または追加によって生ずる、コンピューター・プログラムまたはシステムにおけるエラーとしてもよい。このエラーが、コンピューター・プログラムまたはシステムに、正しくない結果を生成させ、予期しない結果を生成させ、および／または一貫性がない態様、予期しない態様、もしくは意図しない態様で挙動を生成させる。本明細書において使用する場合、「誤検出」という語句は、検出された問題が、本明細書において定められるようなバグであると、誤って(incorrectly)示す結果のことである。
【００１６】
[0024]  以下で説明するように、評価コンポーネントにおける各モデルは、記憶コンポーネントおよび特徴生成コンポーネントと相互作用し、新たなデーターが入手可能になるに連れて、更新および訓練することができる。例えば、一旦ある問題がバグであるか否かに関する確率をモデルが決定したなら、この情報は開発者に送られる。本明細書では「確率」という用語を使用するが、評価コンポーネントにおけるモデルは、検出された問題を格付けする、または問題がバグであるか否かの判定が行われたことの何らかの他の指示を示すように構成することもできる。例えば、問題の各々に採点（例えば、信頼度の採点、または何らかの他の採点）を与えることができる。採点が閾値よりも高い（または低い）場合、問題は開発者によって混入されたバグなのか、または何らかの他の断続的問題なのか示すことができる。
【００１７】
[0025]  開発者は、問題を見直し、この問題がバグであるか否判定し、バグに対して修正を示し（例えば、ソース・コードを更新する）、この情報をシステムに提供する。この情報は、訓練モジュールおよび／または特徴生成コンポーネントを更新するために使用することができるので、時間が進むに連れてこれらは一層高精度になる。
【００１８】
[0026]  これらおよび他の実施例について、図１〜図４に関して以下に更に詳しく説明する。
[0027]  図１は、実施例にしたがって、ソフトウェア・システムにおいて発生した問題を評価し格付けするシステム１００を示す。実施例では、ソフトウェア・システムは、一緒に動作して機能を実行する種々のモジュールおよびコンポーネントを含むことができる。これらの例には、オペレーティング・システム、アプリケーション（例えば、ワード・プロセッシング・アプリケーション、スプレッドシート・アプリケーション、インターネット・ブラウザ等）、クラウド・コンピューティング環境等が含まれる。
【００１９】
[0028]  ときの経過と共に、ソフトウェア・システムまたはソフトウェア・システムの種々のコンポーネントが、開発者によって更新されるのはもっともである。更新が実行されていくにしたがって、ソフトウェア・システムの種々のコンポーネントを検査して（別個に、あるいは他のソフトウェアおよび／またはハードウェア・コンポーネントと一緒に）、１つのコンポーネントに対する更新が、ソフトウェア・システムの他のコンポーネントおよび／またはソフトウェア・システム全体に悪影響を及ぼすか否か判定する。
【００２０】
[0029]  システム１００において、検査対象のソフトウェア・システムは、そのコンポーネントおよび関連するハードウェア（例えば、ネットワーキング機器、データーベース、サーバー等）の全てを含み、自動化ラボ１０５内において実行および検査することができる。先に端的に説明したように、自動化ラボは、新たなソフトウェアが構築されるに連れて、および／または既存のソフトウェア・コンポーネントが修正されるに連れて、ソフトウェア・システムの種々のソフトウェア・コンポーネントを連続的に検査することができる。
【００２１】
[0030]  実施例では、自動化ラボは１つ以上のモニタ１１０を含む。モニタ１１０は、検査プロセス中に問題が発生したか否か検出する。場合によっては、異なるモニタ１１０がソフトウェア・システムの異なる部分を監視する。例えば、第１モニタがソフトウェア・システムの１つ以上のソフトウェア・コンポーネントを担当し(cover)、一方で第２モニタが、ソフトウェア・システムに関連する、またそうでなければ相互作用する、１つ以上のハードウェア・コンポーネントを担当するのでもよい。自動化ラボ１０５は、種々の検査事例(test case)を連続的に実行するように構成することができる。他の実施態様では、自動化ラボ１０５は、要求に応じて検査事例を実行するように構成することもできる。
【００２２】
[0031]  自動化ラボにおける１つ以上のモニタ１１０が問題を検出した場合、問題１１５についての生情報がデーター供給コンポーネント１２０に送信される。実施例では、データー供給コンポーネント１２０は、自動化ラボ１０５から生成された、またそうでなければ検出された、全ての問題１１５を処理する(handle)ように構成される。
【００２３】
[0032]  一旦問題１１５が受け取られたなら、データー供給コンポーネント１２０は問題１１５についての情報を、格納を容易にする構造化方式に変換する。場合によっては、データー供給コンポーネント１２０によって処理される(handle)問題１１５についての情報は、スタック・トレース、クラッシュ・ダンプ(crash dump)等を含む。この情報に加えて、データー供給コンポーネント１２０は、自動化ラボ１０５の現在の状態についての情報も受け取ることができる。
【００２４】
[0033]  この情報から、データー供給コンポーネント１２０は、問題１１５が発生したコンテキストを判定することができる。例えば、データー供給コンポーネント１２０は、検査対象のソース・コードの構築番号(build number)、現在の日時、ホストが実行していたオペレーティング・システムのバージョン、およびその他のこのような情報を判定することができる。
【００２５】
[0034]  また、データー供給コンポーネント１２０は、ビニング機能(binning functionality)によって、種々の問題１１５の指紋を生成するように構成することもできる。一旦問題１１５の指紋が確定されたなら、データー供給コンポーネント１２０に既に報告されている他の問題１１５の指紋と突き合わせて、この指紋を比較する。現在の問題１１５が新たな問題であると判定された場合、問題１１５についての情報は、その指紋と共に格納される。場合によっては、ビニングは、ソフトウェア・システム内に存在するかもしれない種々の問題１１５の種々の時間的統計（例えば、週間、月間、および使用期間(lifetime)中のヒット数）の生成も可能にする。
【００２６】
[0035]  問題１１５が新たな問題であると判定された場合、データー供給コンポーネント１２０は、問題１１５についての情報を問題分析コンポーネント１２５にプッシュする。問題分析コンポーネント１２５は、この情報を分析し、問題１１５がバグかまたは誤検出かの確率を判定し、この情報を使用してその評価モデルを訓練する。
【００２７】
[0036]  場合によっては、問題分析コンポーネント１２５は記憶レイヤー１３０を含む、またそうでなければ関連付けられる。記憶レイヤー１３０は、問題１１５についての情報を、データー供給コンポーネント１２０から受け取る。ある実施例では、記憶レイヤー１３０が拡張可能および編集可能でもよい。また、記憶レイヤー１３０は、検出された種々の問題についての開発者フィードバックや、開発者によって供給され、受け取られ、関連付けられたあらゆるフィードバックも格納するように構成することができる。また、記憶レイヤー１３０は、システム１００の種々の開発者および／またはコンポーネントに、格納されているデーターに対して範囲限定クエリ(scoped queries)（例えば、部分集合に対するクエリ）を実行させることもできる。
【００２８】
[0037]  また、問題分析コンポーネント１２５は特徴生成コンポーネント１４０も含む。特徴生成コンポーネント１４０は、１つ以上の特徴生成器１４５を含む。各特徴生成器１４５は、特定の問題１１５と関連付けられる特徴ベクトル１５０を生成するように構成されている。
【００２９】
[0038]  場合によっては、ソフトウェア・システム内に存在する問題には多くの異なるクラスがあることもある。例えば、１つ以上のバグが異なるソフトウェア・コンポーネントおよび／または１つ以上の異なる開発チームに関係することもあり得る。加えて、種々の問題１１５が異なる挙動を呈することもある。したがって、特徴生成コンポーネント１４０における各特徴生成器１４５は、問題の種類毎に特定的に構成することができる。このため、特徴生成コンポーネントは多くの異なる特徴生成器１４５を含んでもよい。
【００３０】
[0039]  例えば、各特徴生成器１４５は、特定の問題１１５に関係する情報を捜すように構成することができる。特定の問題に関する情報が問題情報１３５において発見された場合、この特定の問題と関連付けられた特徴ベクトルが生成される。例えば、特定の特徴生成器は、スタック・トレースにおいて作業「エラー」および「メモリー」が発生した回数を計数するように構成することができる。つまり、特徴生成器が「メモリー位置１におけるメモリー・エラー」のスタック・トレースを受け取った場合、「エラー」という単語が１回発生し、「メモリー」という単語が２回発生したので、特徴生成器によって生成される特徴ベクトルは、[１，２］となる。しかしながら、スタック・トレースが空であるまたは存在しない場合、結果的に生成される特徴ベクトルは［０，０］となってもよい。一旦特徴ベクトルが生成されたなら、この情報は評価コンポーネントに渡される。
【００３１】
[0040]  場合によっては、各特徴生成器１４５が記憶レイヤー１３０から種々のデーター点を引き出してもよい。また、各特徴生成器１４５が、少なくとも部分的に、特徴生成器１４５の構成に基づいて、データーに対して１つ以上の変換を実行してもよい。
【００３２】
[0041]  例えば、特徴生成器１４５が特定の種類の問題を捜すように構成される場合、あるいは特定のソフトウェア・コンポーネントまたはハードウェア・コンポーネントと関連付けられる場合、特徴生成器１４５は、指定された種類の変換をデーターに対して実行することができる。このような変換の例には、正規化、スタック・トレースからの特定のキー・ワードの発生回数の計数、ビニングが可能であり、あるいは、これら以外では、記憶レイヤー１３０において入手可能な生データーからの特徴の抽出または生成が可能である。特徴生成器１４５は、変換した情報を使用して特徴ベクトル１５０を生成する。
【００３３】
[0042]  一旦特徴ベクトル１５０が生成されたなら、この特徴ベクトル１５０は評価コンポーネント１５５に渡される。評価コンポーネント１５５は１つ以上のモデル１６０を含む。ある実施例では、各モデル１６０が特定の特徴生成器１４５と１対１の対応を有する。
【００３４】
[0043]  例えば、各特徴生成器１４５には、１つのモデル１６０に対して特徴ベクトルを生成する役割がある。このように、システム１００は、非常に精度が高いドメイン特定モデル１６０で構成することができる。更に、これによって、システム１００の柔軟性も高くなる。何故なら、記憶レイヤー１３０から読み出すのであれば、異なる特徴生成器１４５を異なる技術者チームによって独立して開発し体験することができるからである。
【００３５】
[0044]  １対１の対応について述べたが、特徴生成器１４５は特徴ベクトル１５０を多くの異なるモデル１６０に供給してもよい。同様に、１つのモデル１６０が種々の異なる特徴生成器１４５から特徴ベクトル１５０を受け取ってもよい。
【００３６】
[0045]  本明細書において説明する実施例では、評価コンポーネント１５５は、受け取ったベクトル１５０がバグに関連付けられるか、または誤検出に関連付けられるかの確率を判定するため、またそうでなければ予測するために使用される。例えば、モデル１６０が、各問題がバグまたは断続的ノイズである確率を判定し、この問題が所与のチームに属するか否か予測する等というように構成されてもよい。実施例では、どのクラスのバグが彼らの自動化ラボ１０５から発生したのか把握することは、システム１００を使用する開発者に任せてもよい。したがって、開発者が、個々の必要性に基づいて、彼ら自身のモデル１６０および特徴生成器１４５を作成および／または更新することもできる。
【００３７】
[0046]  場合によっては、問題が発生しても、特徴ベクトル１５０に収容されている情報に基づいて予測を処理する(handle)ためのモデル１６０が、評価コンポーネント１５５内に装備されていないこともある。このような場合、システム１００が開発者に通知し、他のモデル１６０および／または特徴生成器１４５の作成を許可してもよい。
【００３８】
[0047]  また、評価コンポーネント１５５内にデプロイされる各モデル１６０は、記憶レイヤー１３０および特徴生成コンポーネント１４０と相互作用することも可能である。したがって、種々の更新および／またはフィードバックが供給されるに連れ、そして新たな訓練データーが入手可能になるに連れて、各モデル１６０を更新および再訓練することができる。
【００３９】
[0048]  ある実例では、評価コンポーネント１５５における各特徴生成器１４５および各モデル１６０が互いに独立して動作する。したがって、各特徴生成器１４５および／または各モデル１６０を任意の時点で訓練することができる。更に、各モデル１６０は異なる型式のモデルであってもよい。例えば、１つのモデルが、バッチで訓練されるサポート・ベクトル・マシン（ＳＶＭ）ランカー(ranker)であってもよく、オンラインで訓練される一方他のモデルがｋ近傍（ＫＮＮ）ランカーであってもよい。
【００４０】
[0049]  一旦評価コンポーネント１５５の１つ以上のモデル１６０が特徴ベクトル１５０を分析し終えると、予測１６５を生成し、クライアント・コンポーネント１７０に供給する。クライアント・コンポーネント１７０は、１つ以上のクライアント１７５を含んでもよい。１つ以上のクライアント１７５の各々は、先に説明した種々の他のコンポーネントと相互作用することができる。
【００４１】
[0050]  例えば、第１クライアントが特定のモデルおよび特徴生成器と相互作用するように構成され、一方第２クライアントが異なるモデルおよび特徴生成器と相互作用するように構成されてもよい。第１クライアントは、新たな問題（例えば、開発者によって未だ調査されていない問題）を検査するように構成されてもよく、モデル１６０を使用して、問題が誤検出またはバグである確率を予測する。次いで、このクライアント１７５は、発生している問題(active issue)の内バグである可能性が最も高いものを優先順に並べたリストを、開発者に供給する(serve)ことができる。
【００４２】
[0051]  同様に、第２クライアントは、記憶レイヤー１３０と相互作用し、バグまたは未解決である他の問題１１５を検索するように構成されてもよい。第２クライアントは、それに関連する特徴生成器１４５に、特徴ベクトル１５０を作成し、この特徴ベクトル１５０を関連するモデル１６０に供給するように要求することができる。先に説明したように、モデル１６０は、検出された問題１１５がバグであるか否か、またはこれが誤検出であるか否かに関する確率を判定する。また、この情報は、先に説明したように、開発者に送ることもできる。
【００４３】
[0052]  開発者がシステム１００にアクセスするとき、開発者は調査する１つ以上のバグを選択することができる。調査の間、開発者は、検出された問題１１５がバグであると判定し、このバグに対する修正を示すことができる。この情報は、図１においてフィードバック１８０として示されており、次いで記憶レイヤー１３０に送信および格納される。また、フィードバック１８０は、特徴生成コンポーネント１４０内にある種々の特徴生成器１４５および／または評価コンポーネント内にあるモデル１６０にも供給することができる。
【００４４】
[0053]  ある実例では、開発者が、報告された問題１１５が誤検出であると判定する場合もある。これらの場合では、問題１１５についてのフィードバック１８０（例えば、問題１１５が開発者によって生じたバグではなかったことを示すフィードバック）も記憶レイヤー１３０に供給される。
【００４５】
[0054]  ある実例では、クライアント１７５が、問題が関連付けられた特徴生成器１４５および／またはモデル１６０に、フィードバックを直接供給してもよい。例えば、そして先に説明したように、各特徴生成器１４５および／または各モデル１６０は、特定の問題１１５と関連付けるように、またそうでなければ、特定の問題１１５を処理する(handle)ように、構成することができる。つまり、同じ問題または同様の問題が後の時点において検出されたとき、特徴生成器１４５および／またはモデル１６０は、問題１１５をどのように処理する(handle)かに対して、そして検出された問題１１５がバグかまたは誤検出かに関する判定を行うことに対して、訓練を改善することができる。他の場合では、特定の問題についての情報を記憶レイヤー１３０に格納することもできる。同じまたは同様の問題が発生した場合、この問題についての情報を、記憶レイヤー１３０内にある問題情報と比較し、次いでステートレスの特徴生成および評価フローに渡す。ある実例では、ステートレスの特徴生成および評価フローは、本明細書において説明する動作の流れと同様となる場合もある。
【００４６】
[0055]  以上で説明したシステム１００をどのように使用すればよいかという実施例を、以下に示す。具体的事項が記載されるが、これらは例に過ぎないことを意図しており、システム１００は多数の異なるシナリオにおいて使用することができる。
【００４７】
[0056]  この実施例では、開発者のチームが、文書を分析するソフトウェアを開発するとしてもよい。ソフトウェアの分析コンポーネント、およびこのコンポーネントの検査は、複数の異なる機械およびソフトウェアを伴う。例えば、文書の検査コーパスを記憶サーバー上にホストしてもよい。クローワー(crawler)を記憶サーバーに向けて実行し、文書からテキストを抽出するように構成してもよい。一旦テキストが抽出されたなら、このテキストを分析コンポーネントに渡すことができる。また、このシステムは、分析コンポーネントからの結果を格納するデーターベース・システムを実行する他のサーバーを含んでもよい。
【００４８】
[0057]  この実施例では、ソフトウェア開発チームが、先に説明したシステム１００を利用する。例えば、自動化ラボにおいて問題が検出されたとき、この問題についての情報が記憶レイヤー（例えば、記憶レイヤー１３０）に送信される。特徴生成器（例えば、特徴生成コンポーネント１４０の特徴生成器１４５）は、誤検出を検出するのに有効であると見なされた情報からデーターを抽出する。例えば、特徴生成器は、問題が発生した総回数（例えば、使用期間中のヒット数）、各問題が先月発生した総回数（例えば、先月のヒット数）、各問題が先週発生した総回数（例えば、先週のヒット数）、問題が最後に発生したビルド(build)番号、およびこの問題の最終的な解決策（例えば、問題が修正されたか否か、または問題が再現可能でないという判定）に関する情報を抽出することができる。
【００４９】
[0058]  具体的な情報について述べたが、これは例示を目的とするに過ぎない。したがって、特徴生成器は、以上で述べた程多くの情報を抽出しなくてもよく、また追加の情報を抽出してもよい。
【００５０】
[0059]  一旦この情報が収集されたなら、この情報の一部を更に正規化してもよい。例えば、先週のヒット数および先月のヒット数を、使用期間中のヒット総数で除算してもよい。これらの数値は、特定の問題が、先週では、その前の週よりも頻繁に発生したか否かというような時間的傾向を判定するために使用することができる。
【００５１】
[0060]  特徴生成コンポーネントは、この情報を使用して特徴ベクトルを生成し、評価コンポーネント（例えば、評価コンポーネント１５５）内にあるモデル（例えば、モデル１６０）にこれを供給する。先に論じたように、このモデルは、次いで問題がバグであるかまたは誤検出であるかの確率を判定する。この実施例では、このモデルの出力は、新たな問題の各々（例えば、以前には開発者によって確認、調査、および／または修正されていない問題）に誤検出である確率を指定することである。次いで、このモデルはこの予測をクライアント（例えば、クライアント１７５）に提示する。次いで、クライアントは新たな問題をソフトウェア開発チームに提示することができる。場合によっては、モデルによって判定された確率を使用して、問題を順番に並べてもよい。
【００５２】
[0061]  開発者は、１つの問題を選択し、それを調査し、この問題をバグであると特定し、これを修正する、またはこの問題を誤検出であると特定することができる。開発者がこの問題はバグであると判定した場合、開発者はこのバグを修正し、記憶レイヤーにおいて、検出された問題に関連する問題エントリーが更新される。開発者がこの問題はバグでない（例えば、問題は誤検出である）と判定した場合も、システムが今後それから学習できるようにこの情報を記憶レイヤーにフィードバックする。
【００５３】
[0062]  本明細書において説明したシステムがどのように動作するかに関する他の実施例を以下に示す。この実施例では、ソフトウェア開発チームの開発者がクライアントを開いて、またそうでなければ、クライアントにアクセスして（または直接記憶レイヤーにアクセスしてもよい）、未だ修正されていない問題について記憶レイヤーに問い合わせることができる（例えば、未だ修正されていない(fixed)バグ、誤検出と見なされるバグ、または再生可能と見なされないバグ）。これらの問題は特徴生成コンポーネントに供給され、特徴生成コンポーネントはこれらの問題に対して１組の特徴ベクトルを出力する。
【００５４】
[0063]  特徴ベクトルはモデル評価コンポーネントに供給され、モデル評価コンポーネントは、問題が誤検出またはバグである確率を算出する(yield)。実際に問題である可能性にしたがって、問題を順番に並べてもよい（または、例えば、問題が存在している時間量が長い順、問題が発生した回数等のように、何らかの他の方法で順番に並べてもよい）。
【００５５】
[0064]  開発者は１つの問題（例えば、バグである確率が最も高い問題）を選択し、それを調査する。開発者がこの問題がバグであると判定した場合、開発者はこのバグを修正する。この問題がバグであったという情報、および実行された修正によって、記憶レイヤーにおける問題エントリーを更新する。問題が誤検出であると開発者によって判定された場合も、この情報は記憶レイヤーにフィードバックされ、システムが今後この情報から学習できるようにする。次いで、開発者は新たな問題を選択することができ、このサイクルが繰り返す。
【００５６】
[0065]  以上で説明したプロセスは、人の介入および知識の双方をコンピューターに基づく分析と共に使用することによって、システム１００の精度を向上させるために使用することができる。したがって、開発者は、処理される問題毎に、訓練データーの品質を高めることができる。場合によっては、システム内部の複数のモデルを異なる時点でそして異なる頻度で訓練してもよい。例えば、モデルの訓練が、モデルにフィードバックが組み込まれる頻度に応じて行われてもよく、更にモデルの型式および問題が修正された素早さに応じて行われてもよい。例えば、オンライン・アルゴリズムでは、フィードバックの新たな各項目を直ちに組み込むことができる。逆に、バッチ計算様式で構築されたモデルは、１時間に１回、１日に１回、１週間に１回等で再生される場合もある。
【００５７】
[0066]  ある実例では、以上で説明したシステム１００は、性質上間欠的であるまたは偽りである(spurious)と見なされる問題を自動的に閉じるために使用することもできる。場合によっては、この判定が、少なくとも部分的に、確率判定に基づくのでもよい。例えば、システムのクライアントが、各問題が誤検出である確率を、確定閾値(determined threshold)と比較するのでもよい。閾値を上回る場合、クライアントは、これが再生可能でなかったことを意味するために、記憶レイヤーにおける問題エントリーを更新する。場合によっては、この判定が、開発者によって行われた以前の判定に基づくのでもよい。
【００５８】
[0067]  場合によっては、そしてシステムが人の介入なく問題を評価し続けるのを防止するために、新たなモデルを訓練するために使用されるデーター集合に問題が含まれないように、問題にタグ付けしてもよい。しかしながら、問題の記憶レイヤー表現を後の時点で編集することができるので、開発者がシステムによって行われた判断と同意すること、および／または自動判定によって作られたあらゆる誤りを訂正することを可能にするためのツールを構築することができる。いずれの場合でも、データーを受け入れるまたは訂正する判断は、モデルおよび／または特徴生成器を訓練するために使用することができる。
【００５９】
[0068]  以上、本システムについて自動化ラボに関して説明したが、以上で説明したシステム１００を任意の他のシステム内に統合することも可能である。同様に、システム１００が他のシステムを外側から観察することもできる。更に他の実施例では、１つのソフトウェア・システム上で複数のシステム（例えば、統合システムおよび外部システム）を使用することもできる。
【００６０】
[0069]  同様に、システム１００は、１つのホスト上で実行するリッチ・クライアント(rich client)として、サーバー側システムとして（例えば、ウェブ・インターフェースとして提供する）、またはその任意の組み合わせで（例えば、サーバ・バックエンドおよびもっと薄いクライアント・フロント・エンドと共に）実行するように実装されてもよい。
【００６１】
[0070]  図２は、実施例にしたがってソフトウェア・システムにおいて発生した問題を評価および格付けする方法２００を示す。ある実施例では、方法２００は、図１に関して先に説明したようなシステム１００によって使用されてもよい。
【００６２】
[0071]  方法２００は、動作２１０において開始し、検出された問題に関連するデーターを検出し、システムに供給する。この実施例では、動作２１０は、問題が新たな問題であるか否か、またはこの問題が既に検出されたことがあるか否か判定するために使用することもできる。問題についての情報は、以上で説明したようなデーター供給コンポーネントによってシステムに供給することができる。加えて、問題についての情報をデーター記憶コンポーネントに格納することもできる。
【００６３】
[0072]  一旦問題についてのデーターが受け取られたなら、フローは動作２２０に進み、特徴生成コンポーネントにデーターを供給する。特徴生成コンポーネントはこの情報を分析し、情報を送信しようとしているモデルに基づいて、問題を記述する、問題を特定する、またそうでなければ問題と関連付けられる、特徴ベクトルを生成する。例えば、特徴生成コンポーネントは、１つ以上の特徴生成器を含むことができ、特定の単語がその情報内に存在するか否か、特定のエラーが情報内に現れる回数等を判定するために、特徴生成器が使用される。次いで、特徴生成器は、以上で説明したような特徴ベクトルを生成する。
【００６４】
[0073]  動作２３０において、特徴ベクトルを評価コンポーネントに供給する。ある実施例では、評価コンポーネントが１つ以上のモデルを有し、これらが特徴ベクトルを評価し、特徴ベクトルがバグを特定する、またそうでなければ特徴ベクトルがバグと関連付けられる、確率を判定する。モデルは、特定の種類のバグを探すように構成することもできる。したがって、モデルは、その型式のモデルに合わせて特定的に生成された特徴ベクトルを受け取ることができる。
【００６５】
[0074]  このように、複数の異なるモデルが、各々、そのモデルに合わせて特定的に作られたが同じ問題を起源とする(originate)特徴ベクトルを分析することができる。即ち、問題情報を複数の特徴生成器に送ることができ、各特徴生成器が、それに関連するモデルに合わせて特定の特徴ベクトルを生成する。他の実施例では、受け取った問題情報に基づいて、特徴ベクトルを作成するためにどの特徴生成器を使用すべきか決定するために、特徴生成コンポーネントを使用することもできる。
【００６６】
[0075]  動作２４０において、確率判定をクライアント・デバイスに提示する。実施例の中には、１つよりも多い問題がクライアントに存在する場合もある。このような場合、報告された問題の順序を、特定の判断基準に基づいて、列挙または格付けすることができる。例えば、検出された問題がバグである確率の順、検出された問題が誤検出である確率の順、問題が存在している時間長の順等で、問題を列挙してもよい。
【００６７】
[0076]  動作２５０において、特定の問題に対するフィードバックが受け取られたか否かについて判定を行う。例えば、開発者が特定の問題を選択し、その問題を分析してその問題がバグかまたは誤検出か確認したかについて判定を行うのでもよく、その問題がバグである場合、問題に対する修正を提示する。フィードバックが受け取られていない場合、フローは動作２１０に戻り、動作を繰り返すことができる。
【００６８】
[0077]  しかしながら、問題が選択されており、修正されている場合、またはその問題が誤検出であったと判定し（例えば、開発者によって）、フィードバックが供給された場合、フローは動作２６０に進む。動作２６０において、システムの種々のコンポーネントを訓練するために、フィードバックを使用することができる。例えば、評価コンポーネントにおけるモデルおよび／または特徴生成コンポーネントにおける種々の特徴生成器を訓練するために、フィードバックを使用するのでもよい。また、フィードバックは、問題についての情報と共に、システムの記憶レイヤーに格納されてもよい。
【００６９】
[0078]  図３は、実施例にしたがってソフトウェア・システムにおいて発生した問題を自動的に解決する方法３００を示す。場合によっては、方法３００は、図１に関して先に説明したようなシステム１００によって使用されてもよい。
【００７０】
[0079]  方法３００は動作３１０において開始し、検出された問題がバグであるか否かについての確率（あるいは他の格付けおよび／または採点指標）を受け取る。他の実施態様では、動作３１０において受け取る確率が、問題が誤検出である確率であってもよい。いずれの場合でも、評価コンポーネントと関連付けられたモデルが、確率を受け取ればよい。
【００７１】
[0080]  次いで、フローは動作３２０に進み、動作３１０において受け取った確率を、確率閾値と比較する。ある実施例では、確率閾値は開発者によって設定されてもよい。他の場合では、確率閾値は、少なくとも部分的に、開発者によって供給されたフィードバックに基づいて、システムによって自動的に調整されてもよい。例えば、問題がバグであることをシステムが判定し、開発者が後にこの判定を確認した場合、それに応じて確率閾値を変更しても（例えば、上げるまたは下げる）よい。開発者が判定を訂正しなければならない場合、確率閾値も変更されるのはもっともである。
【００７２】
[0081]  場合によっては、問題の各種類が異なる確率閾値と関連付けられてもよい。このような場合、特定の問題と関連付けられた確率閾値が、開発者から受け取られたフィードバックに基づいて調節されてもよい。他の場合では、報告された全ての問題が同じ確率閾値と関連付けられてもよく、報告された問題の種類には関係なく調節され、自動的にシステムによって取り組まれてもよい。
【００７３】
[0082]  次いで、フローは動作３３０に進み、確率が確率閾値を超えるか否かについて判定を行う。確率が閾値を超える場合、フローは動作３４０に進み、図２に関して先に説明したように、問題を開発者に報告する。次いで、フローは動作３７０に進み、あらゆる開発者フィードバックがシステムに供給され、以上で説明したようなモデルおよび／または特徴生成器を訓練するために使用される。
【００７４】
[0083]  しかしながら、確率が閾値を超えていないと判定された場合（例えば、検出された問題がバグでないと判定された）、動作３５０において問題はシステムによって自動的に解決される。次いで、フローは動作３６０に進み、問題にタグ付けするか、または他の方法で、開発者が問題の解決について再検討することを望む可能性があることを示す印を付ける。次いで、フローは動作３７０に進み、開発者から受け取ったあらゆるフィードバック（例えば、正のフィードバックおよび／または負のフィードバック）をシステムに供給し、以上で説明したようにシステムの種々のコンポーネントを訓練するために使用することができる。
【００７５】
[0084]  図４は、検出された問題に対するフィードバックを受け取る方法４００を示す。場合によっては、方法４００は以上で説明したシステム１００によって使用されてもよい。更に、方法４００は、問題情報を開発者に提供するクライアント・デバイスによって使用されてもよい。
【００７６】
[0085]  方法４００は動作４１０において開始し、問題情報を順番に並べたリストがクライアント・デバイスによって受け取られる。場合によっては、問題情報を順番に並べたリストは、例えば、評価コンポーネント１５５のような、評価コンポーネントによって受け取られる。他の場合には、問題情報のリストは、システムに付随する記憶デバイスに格納されている問題情報から受け取られてもよい。
【００７７】
[0086]  リストは、任意の数の要因にしたがって順番に並べられてもよい。例えば、問題がバグである確率、問題が誤検出である確率、問題が検出された日付け、検出の頻度等に基づいて、リストを順番に並べてもよい。他の場合では、問題のリストは、不規則な順序で、先入れ先出し順で、後入れ先出し順(last in, first out order)等で提示されてもよい。
【００７８】
[0087]  一旦問題情報が受け取られると、フローは動作４２０に進み、問題のリストが開発者に供給される。一旦受け取られると、クライアント・デバイスは特定の問題の選択を受け取り（動作４３０）、この選択に応答して、問題についての追加情報を提供することができる（動作４４０）。例えば、クライアント・デバイスは、問題の日時、問題が検出されたモジュールまたはコンポーネント、問題が発生したソース・コードのエリア等を提供することができる。
【００７９】
[0088]  次いで、フローは動作４５０に進み、問題についてのフィードバックが受け取られる。場合によっては、一旦開発者がこの問題を調査した(research)なら、開発者によってフィードバックを供給してもよい。例えば、フィードバックは、問題がバグであることを確認する、システムによって指示されるように、問題がバグでなかったことを示す、問題が誤検出であったことを確認する、またはシステムによって指示されるように、問題が誤検出でなかったことを示すのでもよい。場合によっては、フィードバックはソース・コードの訂正、ソース・コードの更新、または問題がどのように解決されたかについての他のフィードバックを含むこともできる。
【００８０】
[0089]  一旦フィードバックが受け取られたなら、フローは動作４６０に進み、フィードバックがシステムに供給される。場合によっては、フィードバックは、システムの種々のコンポーネントを訓練するために使用される。例えば、フィードバックは、評価コンポーネントの１つ以上のモデルを訓練または更新するため、評価コンポーネントの１つ以上のモデルを作成するため、特徴生成コンポーネントの１つ以上の特徴生成器を訓練または更新するため、および／または特徴生成コンポーネントの１つ以上の特徴生成器を作成するために使用されるのでもよい。また、場合によっては、フィードバックをシステムの記憶デバイスに格納してもよい。
【００８１】
[0090]  一旦フィードバックが受け取られたなら、この方法、またはこの方法の一部を繰り返すことができる。例えば、図４に示すように、一旦フィードバックが受け取られたなら、フローは動作４３０に戻ることができ、開発者はリストにおいて他の問題を選択し、このプロセスは繰り返す。
【００８２】
[0091]  ある実例では、開発者が選択した問題を調査しながら、追加の問題を検出しクライアント・デバイスに供給することもできる。このような場合、問題情報を順番に並べたリストを継続的に更新することができる。他の場合では、問題情報のリストは、周期的に、要求に応じて、またはこれらの任意の組み合わせで、クライアント・デバイスに供給してもよい。
【００８３】
[0092]  図５〜図８および関連する説明は、本開示の態様を実施することができる種々の動作環境についての論述を示す。しかしながら、図５〜図８に関して図示および論述するデバイスならびにシステムは、例示および図示を目的とするに過ぎず、本明細書において説明したような、本開示の態様を実施するために利用することができる大多数の電子デバイス構成の限定ではない。
【００８４】
[0093]  図５は、本開示の態様を実施することができる電子デバイス５００の物理コンポーネント（例えば、ハードウェア）を示すブロック図である。以下に説明する電子デバイス５００のコンポーネントは、以上で説明したような一式のソフトウェアで問題を自動的に特定するためのコンピューター実行可能命令を有するのでもよい。
【００８５】
[0094]  基本的な構成では、電子デバイス５００は、少なくとも１つの処理ユニット５１０とシステム・メモリー５１５とを含めばよい。電子デバイスの構成および種類に応じて、システム・メモリー５１５は、揮発性ストレージ（例えば、ランダム・アクセス・メモリー）、不揮発性ストレージ（例えば、リード・オンリー・メモリー）、フラッシュ・メモリー、またはこのようなメモリーの任意の組み合わせを含むことができるが、これらに限定されるのではない。システム・メモリー５１５は、オペレーティング・システム５２５と、本明細書において説明したような種々の問題を特定するのに適した１つ以上のプログラム・モジュール５２０とを含むことができる。
【００８６】
[0095]  オペレーティング・システム５２５は、例えば、電子デバイス５００の動作を制御に適しているとしてもよい。更に、本開示の実施例は、グラフィックス・ライブラリー、他のオペレーティング・システム、または任意の他のアプリケーション・プログラムと併せて実施することもでき、いずれの特定のアプリケーションにもシステムにも限定されない。この基本構成は、図５において、破線５３０内にあるコンポーネントによって例示されている。
【００８７】
[0096]  電子デバイス５００は、追加の特徴(feature)または機能を有することもできる。例えば、電子デバイス５００は、例えば、磁気ディスク、光ディスク、またはテープのような追加のデーター記憶デバイス（リムーバブルおよび／または非リムーバブル）も含んでもよい。このような追加のストレージは、図５ではリムーバブル記憶デバイス５３５および非リムーバブル記憶デバイス５４０によって例示されている。
【００８８】
[0097]  先に述べたように、多数のプログラム・モジュールおよびデーター・ファイルをシステム・メモリー５１５に格納することができる。処理ユニット５１０上で実行している間、プログラム・モジュール５２０（例えば、特徴生成モジュール５０５またはコンポーネント、評価モジュール５０７またはコンポーネント等。これらはシステム１００を構成することができる）は、本明細書において説明した態様を含むがこれらに限定されないプロセスを実行することができる。
【００８９】
[0098]  更に、本開示の実施例は、ディスクリート電子エレメント、論理ゲートを内蔵するパッケージ化または集積電子チップ、マイクロプロセッサを利用する回路を含む電気回路内、あるいは電子エレメントまたはマイクロプロセッサを内蔵する単一チップ上で実施することもできる。例えば、本開示の実施例は、システム・オン・チップ（ＳＯＣ）によって実施することもでき、この場合、図５に示すコンポーネントの各々または多くを１つの集積回路上に集積することができる。このようなＳＯＣデバイスは、１つ以上の処理ユニット、グラフィックス・ユニット、通信ユニット、システム仮想化ユニット、および種々のアプリケーション機能を含むことができ、これらの全てがチップ基板上に１つの集積回路として集積される（または「焼かれる」）。
【００９０】
[0099]  ＳＯＣによって動作するとき、プロトコルを切り替えるクライアントの能力に関して本明細書において説明した機能は、電子デバイス５００の他のコンポーネントと共に１つの集積回路（チップ）上に集積された特定用途ロジックによって動作させることもできる。また、本開示の実施例は、例えば、ＡＮＤ、ＯＲ、およびＮＯＴのような論理演算を実行することができる他の技術を使用して実施することもでき、他の技術には、機械、光、流体、および量子技術が含まれるが、これらに限定されるのではない。加えて、本開示の実施例は、汎用コンピューター内において、あるいは任意の他の回路またはシステムにおいて実施することもできる。
【００９１】
[00100]  また、電子デバイス５００は、キーボード、トラックパッド、マウス、ペン、音響または音声入力デバイス、タッチ、力、および／またはスワイプ入力デバイス等のような１つ以上の入力デバイス（１つまたは複数）５４５も有することができる。ディスプレイ、スピーカー、プリンター等のような出力デバイス（１つまたは複数）５５０も含むことができる。以上で述べたデバイスは例であって、他のものが使用されてもよい。電子デバイス５００は、他の電子デバイス５６０との通信を可能にする１つ以上の通信接続５５５を含むことができる。適した通信接続５５５の例には、無線周波数（ＲＦ）送信機、受信機、および／または送受信機回路、ユニバーサル・シリアル・バス（ＵＳＢ）、パラレル・ポート、および／またはシリアル・ポートが含まれるが、これらに限定されるのではない。
【００９２】
[00101]  本明細書において使用する場合、コンピューター読み取り可能媒体という用語は、コンピューター記憶媒体を含むことができる。コンピューター記憶媒体は、揮発性および不揮発性、リムーバブルおよび非リムーバブル媒体を含むことができ、コンピューター読み取り可能命令、データー構造、またはプログラム・モジュールのような、情報格納のための任意の方法または技術で実施される。
【００９３】
[00102]  システム・メモリー５１５、リムーバブル記憶デバイス５３５、および非リムーバブル記憶デバイス５４０は、全てコンピューター記憶媒体の例（例えば、メモリー・ストレージ）である。コンピューター記憶デバイスは、ＲＡＭ、ＲＯＭ、電気的消去可能リード・オンリー・メモリー（ＥＥＰＲＯＭ）、フラッシュ・メモリーまたは他のメモリー技術、ＣＤ−ＲＯＭ、ディジタル・バーサタイル・ディスク（ＤＶＤ）または他の光ストレージ、磁気カセット、磁気テープ、磁気ディスク記憶デバイスまたは他の磁気記憶デバイス、あるいは情報を格納するために使用することができ電子デバイス５００によってアクセスすることができる任意の他の製品を含むことができる。任意のこのようなコンピューター記憶媒体は、電子デバイス５００の一部とすることができる。コンピューター記憶媒体は、搬送波や他の伝搬または変調データー信号を含まない。
【００９４】
[00103]  通信媒体は、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、あるいは搬送波のような変調データー信号または他の移送メカニズムにおけるその他のデーターによって具体化されてもよく、任意の情報配信媒体を含む。「変調データー信号」という用語は、信号内に情報をエンコードするような方法で１つ以上の特性が設定または変更された信号を記述することができる。一例として、そして限定ではなく、通信媒体は、有線ネットワークまたは直接有線接続のような有線媒体、ならびに音響、無線周波数（ＲＦ）、赤外線、および他のワイヤレス媒体のようなワイヤレス媒体を含むことができる。
【００９５】
[00104]  図６Ａおよび図６Ｂは、本開示の実施例を実施することができる移動体電子デバイス６００、例えば、移動体電話機、スマート・フォン、ウェアラブル・コンピューター（スマート・ウオッチのような）、タブレット・コンピューター、ラップトップ・コンピューター等を示す。図６Ａを参照すると、前述の態様を実施するための移動体電子デバイス６００の１つの態様を示す。
【００９６】
[00105]  基本構成では、移動体電子デバイス６００は、入力エレメントおよび出力エレメントの双方を有するハンドヘルド・コンピューターである。移動体電子デバイス６００は、通例、ユーザーが情報を移動体電子デバイス６００に入力することを可能にするディスプレイ６０５および１つ以上の入力ボタン６１０を含む。移動体電子デバイス６００のディスプレイ６０５は、入力デバイス（例えば、タッチおよび／または力入力を受け入れるディスプレイ）として機能することもできる。
【００９７】
[00106]  随意の側面入力エレメント６１５が含まれる場合、更に他のユーザー入力が可能になる。側面入力エレメント６１５は、回転スイッチ、ボタン、または任意の他の型式の手動入力エレメントであってもよい。代替態様では、移動体電子デバイス６００はもっと多いまたはもっと少ない入力エレメントを内蔵することもできる。例えば、ディスプレイ６０５は、ある例では、タッチ・スクリーンでなくてもよい。更に他の代替実施形態では、移動体電子デバイス６００はセルラ・フォンのような、可搬型電話システムである。また、移動体電子デバイス６００は、随意のキーパッド６３５も含むことができる。随意のキーパッド６３５は、物理キーパッド、またはタッチ・スクリーン・ディスプレイ上に生成される「ソフト」キーパッドであってもよい。
【００９８】
[00107]  種々の実施例において、出力エレメントは、グラフィカル・ユーザー・インターフェース（ＧＵＩ）、視覚インディケーター６２０（例えば、発光ダイオード）、および／またはオーディオ変換器６２５（例えば、スピーカー）を示すためのディスプレイ６０５を含む。ある態様では、移動体電子デバイス６００は、ユーザーに触覚フィードバックを付与するための振動変換器を内蔵する。更に他の態様では、移動体電子デバイス６００は、オーディオ入力（たとえば、マイクロフォン・ジャック）、オーディオ出力（例えば、ヘッドホン・ジャック）、ビデオ出力（例えば、ＨＤＭＩ（登録商標）ポート）のような、信号を外部デバイスに送るためまたは信号を外部デバイスから受信するための入力および／または出力ポートを内蔵する。
【００９９】
[00108]  図６Ｂは、移動体電子デバイス６００の１つの態様のアーキテクチャを示すブロック図である。即ち、移動体電子デバイス６００は、いくつかの態様を実装するためにシステム（例えば、アーキテクチャ）６４０を内蔵することができる。一実施形態では、システム６４０は、１つ以上のアプリケーション（例えば、ブラウザー、電子メール、カレンダー作成、接触先管理表(contact manager)、メッセージング・クライアント、ゲーム、メディア・クライアント／プレーヤー、コンテンツ選択および共有アプリケーション等）を実行することができる「スマート・フォン」として実装される。ある態様では、システム６４０は、統合パーソナル・ディジタル・アシスタント（ＰＤＡ）およびワイヤレス・フォンのような、電子デバイスとして統合される。
【０１００】
[00109]  １つ以上のアプリケーション・プログラム６５０は、メモリー６４５にロードされ、オペレーティング・システム６５５上でまたはオペレーティング・システム６５５と関連付けて実行することができる。アプリケーション・プログラムの例には、発呼(phone dialer)プログラム、電子メール・プログラム、個人情報管理（ＰＩＭ：personal information management）プログラム、ワード・プロセッシング・プログラム、スプレッドシート・プログラム、インターネット・ブラウザー・プログラム、メッセージング・プログラム等が含まれる。
【０１０１】
[00110]  また、システム６４０はメモリー６４５内に不揮発性記憶エリア６６０も含む。不揮発性記憶エリア６６０は、システム６４０の電力が停止しても失われてはいけない永続的情報を格納するために使用することができる。
【０１０２】
[00111]  アプリケーション・プログラム６５０は、電子メール・アプリケーション等によって使用される電子メールまたは他のメッセージのような情報を使用し、不揮発性記憶エリア６６０に格納することができる。また、同期アプリケーション（図示せず）もシステム６４０上に常駐し、不揮発性記憶エリア６００に格納されている情報を、ホスト・コンピューターに格納されている対応する情報と同期させ続けるためにホスト・コンピューター上に常駐する対応する同期アプリケーションと相互作用するようにプログラミングされている。
【０１０３】
[00112]  システム６４０は電源６６５を有し、電源６６５は１つ以上のバッテリーとして実装されてもよい。更に、電源６６５は、ＡＣアダプターのような外部電源、またはバッテリーを補充するまたは再充電する給電ドッキング・クレードルも含むことができる。
【０１０４】
[00113]  また、システム６４０は、無線周波数通信を送信および受信する機能を実行する無線インターフェース・レイヤー６７０も含むことができる。無線インターフェース・レイヤー６７０は、通信事業者またはサービス・プロバイダを通じて、システム６４０と「外部世界」との間におけるワイヤレス接続(wireless connectivity)を容易にする。無線インターフェース・レイヤー６７０への送信および無線インターフェース・レイヤー６７０からの送信は、オペレーティング・システム６５５の制御下で行われる。言い換えると、無線インターフェース・レイヤー６７０によって受信された通信は、オペレーティング・システム６５５を通じてアプリケーション・プログラム６５０に拡散する(disseminate)ことができ、その逆も可能である。
【０１０５】
[00114]  視覚インディケーター６２０は、視覚通知を出すために使用することができ、および／またはオーディオ・インターフェース６７５は、オーディオ変換器（例えば、図６Ａに示すオーディオ変換器６２５）を介して可聴通知を生成するために使用することができる。図示する実施形態では、視覚インディケーター６２０は発光ダイオード（ＬＥＤ）であり、オーディオ変換器６２５はスピーカーであってもよい。これらのデバイスは、有効化されたときには、バッテリー電力を保存するためにプロセッサー６８５および他のコンポーネントが一時停止するとよい場合でも、通知メカニズムによって指令される期間だけ動作状態に留まるように、電源６６５に直接結合することができる。ユーザーがデバイスの通電状態(powered-on status)を指示する行為を行うまで無期限に動作状態に留まるように、ＬＥＤをプログラミングすることができる。
【０１０６】
[00115]  オーディオ・インターフェース６７５は、可聴信号をユーザーに供給するため、そして可聴信号（例えば、先に説明したような音声入力）をユーザーから受け取るために使用される。例えば、オーディオ変換器６２５に結合されることに加えて、オーディオ・インターフェース６７５は、電話の会話を容易にするため等で、可聴入力を受信するためにマイクロフォンに結合することもできる。本開示の実施例によれば、マイクロフォンは、以下で説明するように、通知の制御を容易にするために、オーディオ・センサとしての役割を果たすこともできる。
【０１０７】
[00116]  更に、システム６４０は、静止画像、ビデオ・ストリーム等を記録することを周辺デバイス６３０（例えば、内蔵カメラ）の動作によって可能にするビデオ・インターフェース６８０も含むことができる。
【０１０８】
[00117]  システム６４０を実装する移動体電子デバイス６００は、追加の特徴(feature)または機能を有することもできる。例えば、移動体電子デバイス６００は、磁気ディスク、光ディスク、またはテープのような追加のデーター記憶デバイス（リムーバブルおよび／または非リムーバブル）も含んでもよい。このような追加のストレージは、図６Ｂでは不揮発性記憶デバイス６６０によって例示されている。
【０１０９】
[00118]  移動体電子デバイス６００によって生成またはキャプチャされシステム６４０を介して格納されたデーター／情報は、先に説明したように、移動体電子デバイス６００上にローカルに格納することができ、あるいは、無線インターフェース・レイヤー６７０を介して、または移動体電子デバイス６００とこの移動体電子デバイス６００と関連付けられた別個の電子デバイス、例えば、インターネットのような分散型コンピューティング・ネットワークにおけるサーバ・コンピューターとの間の有線接続を介して、デバイスによってアクセスすることができる任意の数の記憶媒体上にデーターを格納することができる。認められるはずであるが、このようなデーター／情報には、移動体電子デバイス６００を介して、無線インターフェース・レイヤー６７０を介して、または分散型コンピューティング・ネットワークを介してアクセスすることができる。同様に、このようなデーター／情報は、電子メールおよび協調データー／情報共有システムを含む、周知のデーター／情報転送および記憶手段にしたがって、格納および使用のために電子デバイス間で容易に転送することができる。
【０１１０】
[00119]  認められるはずであるが、図６Ａおよび図６Ｂは、本発明の方法およびシステムを例示する目的に限って説明したのであり、本開示を特定のシーケンスのステップやハードウェアまたはソフトウェア・コンポーネントの特定の組み合わせに限定することを意図するのではない。
【０１１１】
[00120]  図７は、本明細書において説明したようなソフトウェア・システムに伴って検出された問題を自動的に報告するためのシステム７００のアーキテクチャの１つの態様を示す。システム７００は、先に説明したように、汎用電子デバイス７１０（例えば、パーソナル・コンピューター）、タブレット電子デバイス７１５、または移動体電子デバイス７２０を含むことができる。これらのデバイスの各々は、先に説明したように、報告された問題を受け取るため、および／またはフィードバック７２５を供給するために使用することができる。
【０１１２】
[00121]  ある態様では、汎用電子デバイス７１０（例えば、パーソナル・コンピューター）、タブレット電子デバイス７１５、または移動体電子デバイス７２０の各々が、ディレクトリー・サービス７４５、ウェブ・ポータル７５０、メールボックス・サービス７５５、インスタント・メッセージング・ストア７６０、またはソーシャル・ネットワーキング・サービス７６５によって格納されている、またはこれらから送信された種々の他の種類の情報またはコンテンツを受信することもできる。
【０１１３】
[00122]  複数の態様では、問題および／またはフィードバック７２５は、ネットワーク７３０を通じて、サーバー７０５上の問題特定システム７３５（または問題特定システムのコンポーネント）に供給されてもよい（とは言え、問題特定システム７３５はローカル・システムであってよい）。
【０１１４】
[00123]  一例として、以上で説明した態様は、汎用電子デバイス７１０（例えば、パーソナル・コンピューター）、タブレット電子デバイス７１５、および／または移動体電子デバイス７２０（例えば、スマート・フォン）において具体化することもできる。電子デバイスのこれらの例はいずれも、ストア７４０からコンテンツを得ること、またはストア７４０にデーターを供給することができる。
【０１１５】
[00124]  認められるはずであるが、図７は、本発明の方法およびシステムを例示する目的に限って説明したのであり、本開示を特定のシーケンスのステップやハードウェアまたはソフトウェア・コンポーネントの特定の組み合わせに限定することを意図するのではない。
【０１１６】
[00125]  図８は、本明細書において開示した１つ以上の態様を実行することができるタブレット電子デバイス例８００を示す。加えて、本明細書において説明した態様および機能は、分散型システム（例えば、クラウド・ベースのコンピューティング・システム）上で動作することもでき、この場合、アプリケーション機能、メモリー、データー格納および検索、ならびに種々の処理機能は、互いに離れて、インターネットまたはイントラネットのような分散型コンピューティング・ネットワークを通じて処理する(operate)ことができる。種々の種類のユーザー・インターフェースおよび情報は、電子デバイスの内蔵ディスプレイによって、または１つ以上の電子デバイスに付帯するリモート・ディスプレイ・ユニットによって表示することができる。例えば、種々の種類のユーザー・インターフェースおよび情報が、壁の表面上に表示され、ここに種々の種類のユーザー・インターフェースおよび情報が投影され、対話処理されてもよい。本発明の実施例を実施することができる多数のコンピューティング・システムとの対話処理には、打鍵入力(keystroke entry)、タッチ・スクリーン入力、音声または他の音響入力、ジェスチャ入力等が含まれる。ジェスチャ入力の場合、関連する電子デバイスには、ユーザーのジェスチャをキャプチャおよび解釈して電子デバイスの機能を制御するために検出（例えば、カメラ）機能が装備される。
【０１１７】
[00126]  認められるはずであるが、図８における図は、本発明の方法およびシステムを例示する目的に限って説明したのであり、本開示を特定のシーケンスのステップやハードウェアまたはソフトウェア・コンポーネントの特定の組み合わせに限定することを意図するのではない。
【０１１８】
[00127]  以上で説明したように、本明細書において開示したのは、コンピューティング・システムにおいて検出された問題がバグであるか否か自動的に判定する方法である。この方法は、検出された問題についての情報を受け取るステップと、検出された問題についての情報を記憶デバイスに格納するステップと、検出された問題に対する特徴ベクトルを生成するステップと、特徴ベクトルを分析して、検出された問題がバグである確率を判定するステップであって、分析が、少なくとも部分的に、特徴ベクトルに基づく、ステップと、確率が閾値よりも高いとき、検出された問題をクライアント・デバイスに報告するステップとを含む。他の実施例では、この方法は、検出された問題に対する修正を受け取ることを含む。更に他の実施例では、この方法は、少なくとも部分的に、検出された問題に対して受け取った修正に基づいて、分析を更新するステップを含む。更に他の実施例では、この方法は、修正を検出された問題と関連付けるステップと、修正を記憶デバイスに格納するステップとを含む。更に他の実施例では、この方法は、１つ以上の追加の検出された問題に関して、検出された問題に優先順位を付けるステップを含む。更に他の実施例では、この方法は、特徴ベクトルを生成するステップを含み、この生成するステップは、検出された問題についての情報に対して１つ以上の変換を実行するステップを含む。更に他の実施例では、１つ以上の変換が、正規化、スタック・トレースからのキー・ワードの発生回数の計数、およびビニングから成る１群から選択される。
【０１１９】
[00128]  また、説明したのはシステムであり、このシステムは、少なくとも１つの処理ユニットと、コンピューター実行可能命令を格納するメモリーとを備える。コンピューター実行可能命令は、少なくとも１つの処理ユニットによって実行されると、ソフトウェア・システムにおいて問題の発生を検出する方法を、システムに実行させる。この方法は、検出された問題についての情報を受け取るステップと、検出された問題の指紋を、以前に検出された問題の１つ以上の指紋と比較して、検出された問題が新たなものであるか否か判定するステップと、検出された問題が新たなものであると判定されたとき、検出された問題についての情報を記憶デバイスに格納するステップと、検出された問題についての情報を、検出された問題に対して特徴ベクトルを生成する特徴生成コンポーネントに提供するステップと、特徴ベクトルを、特徴ベクトルを分析する評価コンポーネントに供給し、検出された問題がバグである確率を判定するステップと、検出された問題を順番に並べたリストを供給するステップとを含む。他の実施例では、評価コンポーネントが１つ以上のモデルと関連付けられ、１つ以上のモデルの各々が、少なくとも部分的に、特徴ベクトル内に収容されている情報に基づいて、受け取った特徴ベクトルを評価するように構成される。更に他の実施例では、メモリーが、検出された問題に対する修正を受け取るための命令を格納する。更に他の実施例では、メモリーが、修正を検出された問題と関連付けるための命令を格納する。更に他の実施例では、メモリーが、少なくとも部分的に、修正に基づいて、評価コンポーネントの１つ以上のモデルを更新するための命令を格納する。更に他の実施例では、順番に並べたリストの順番は、判定された確率に基づく。更に他の実施例では、メモリーが、以前に検出された問題を考慮して、検出された問題に対して優先順位を指定するための命令を格納する。更に他の実施例では、メモリーが、検出された問題がバグでないと判定されたときに、検出された問題についての情報を記憶デバイスに格納するための命令を格納する。
【０１２０】
[00129]  また、説明したのは、コンピューター実行可能命令を格納するコンピューター読み取り可能記憶媒体であり、このコンピューター実行可能命令が処理ユニットによって実行されると、この処理ユニットに方法を実行させる。この方法は、検出された問題に関連する情報を使用して、検出された問題に対して特徴ベクトルを生成するステップと、特徴ベクトルを評価コンポーネントの１つ以上のモデルに供給するステップと、評価コンポーネントの１つ以上のモデルに特徴ベクトルを分析させて、検出された問題がバグである確率を判定するステップと、検出された問題の発生を報告するステップと、検出された問題に対する修正を受け取るステップと、検出された問題に対する修正を使用して、１つ以上のモデルの内少なくとも１つを更新するステップとを含む。他の実施例では、メモリーが、修正を記憶デバイスに格納するための命令を格納する。更に他の実施例では、メモリーが、修正を検出された問題と関連付けるための命令を格納する。更に他の実施例では、メモリーが、検出された問題についての情報を格納するための命令を格納する。更に他の実施例では、メモリーが、１つ以上のモデルの内どのモデルが、特徴ベクトルを分析するように構成されるか決定するための命令を格納する。
【０１２１】
[00130]  本願において示した１つ以上の態様の説明および例示は、特許請求する本開示の範囲を如何様にも限定も制限もすることを意図していない。本願において示した態様、実施例、および詳細は、所有を伝え(convey possession)、他の者が特許請求する開示の最良の態様を実施し使用することを可能にするのに十分であることが考慮されている。特許請求する開示は、本願において示したいずれの態様、実施例、または詳細にも限定されるように解釈してはならない。組み合わせでまたは別々に示され説明されているか否かには関係なく、種々の特徴（構造的および方法論的の双方）は、特定の１組の特徴を有する実施形態を生成するために、選択的に含まれるまたは省かれることを意図している。以上、本本願の説明および例示を行ったが、当業者は、本願において具体化された総合的な発明概念の広義な態様(broader aspects)の主旨に該当し、特許請求する開示の広義な範囲(broader scope)から逸脱しない、変形、変更、および代替態様を構想することができよう。
【図１】
2020518064.tif 000003
【図２】
2020518064.tif 000004
【図３】
2020518064.tif 000005
【図４】
2020518064.tif 000006
【図５】
2020518064.tif 000007
【図６Ａ】
2020518064.tif 000008
【図６Ｂ】
2020518064.tif 000009
【図７】
2020518064.tif 000010
【図８】
2020518064.tif 000011
【国際調査報告】
2020518064.tif 000012
2020518064.tif 000013
2020518064.tif 000014