[NCTS サミット レビュー] Ele.me Qiu Huafeng: バグの検出における人工知能の応用

2019年10月26日、Testinが主催する第2回NCTS中国クラウドテスト業界サミットが北京で開催されました。「AI+未来」をテーマにしたこのサミットには、国内外のテスト分野の著名な専門家や学者、大手企業の意思決定者、上級技術管理者、メディア関係者などが集まり、ハイエンドのクラウドテスト技術について議論し、テスト担当者が最先端の業界動向と最新の業界慣行を理解できるようにしました。

[[283752]]

会議では、Ele.me のテストおよび開発の専門家である Qiu Huafeng 氏が「バグの検出における人工知能の応用」について基調講演を行いました。邱華鋒氏は「企業が人工知能がもたらす利便性の恩恵を受けたいのであれば、まずそれに応じた標準を策定しなければならない。そのような標準がなければ、固定されたアルゴリズムでそれを実現するのは難しいだろう」と指摘した。

以下は邱華鋒氏のスピーチの記録です。

今日は、バグ対策における人工知能の位置づけについてお話します。この話題についてお話しする前に、統計をとりたいと思います。バグ管理に Java を使用している人はどれくらいいるでしょうか?バグを修正した後、コード内のバグが何であるかを知りたい場合は手を挙げてください。人工知能によるポジショニングには、まずデータ基盤が必要です。このデータのソースは何ですか?テストの際には、Java を通じてバグを送信します。バグの説明、バグの関連情報、バグを再現する手順が開発者に直接送信されます。開発者はこれらの手順に従って実行し、バグが再現可能かどうかを確認します。再現可能な場合、開発者は関連する問題を関連付けるように求められます。関連付け後、それはバグ分析の前提条件として機能します。サンプルに手動でラベルを付ける必要はありません。バグの説明の関連情報を入れた後、自然言語または手動処理を使用して、例外が何であるか、エラーが何であるか、問題が何であるかなど、バグに関連するフィールドを抽出できるためです。この基盤があれば、人間によるラベル付けなしでサンプルを入手できます。学術コミュニティが行う必要があることがもう 1 つあります。まず、すべての Java バグのメンテナンスを専門とする人がいます。これらのバグが修正されると、どのメソッドがどのレイヤーにあり、どのメソッドのどの行にどのようなエラーがあるかを示すデータが生成されます。人工知能がもたらす利便性を利用したい場合、まずそれに対応する標準を確立する必要があります。この標準がなければ、固定されたアルゴリズムに従って欲しいものを得ることは困難になります。これらの前提についてお話しした後、主に 3 つの部分についてお話しします。1 つ目はツールの紹介、2 つ目はバグの検出の原則と方法、3 つ目はこれらのツールを使用した後のアプリケーションの具体的な実装の側面です。

ツールは 8 種類あります。この PPT は以前に作成されたものです。先月、新しいバグ検出技術が登場しました。それは、動作ベースのバグ検出技術です。上記の 8 つのポジショニング技術はすべて、対応する処理のための関連サンプルを取得することに基づいており、これらはテストケースを抽出し、テストをコンパイルすることによって行われます。これらはほとんどが単体テストに基づいて行われますが、動作ベースのテストでは単体テストのレベルを超えて、バグのサンプルを取得し、リンクに基づいて状況を分析します。 1 つ目はプログラム スペクトルです。これは、実行したテスト ケースの数、成功したテスト ケースでカバーされた行、失敗したテスト ケースでカバーされた行を示します。失敗したテストケースが占める行数を計算し、このコード行にバグが発生する確率をランキング化します。次に、バリアントに基づいて、プログラム スペクトルの改善を行いました。現在、バリアントの最も実用的な用途は、テスト ケースの有効性を測定するための重要な手段であることです。私は非常に多くのテスト ケースを作成しました。これらのテスト ケースが本当に効果的かどうかは、バリアントを使用して測定できます。バリアントに基づいて 2 つが生成され、変異スコアが付けられます。スコアが高いほど、ユニット テスト ケースの品質が高くなります。プログラムスライシングとは、プログラムスライシングやシナリオを通じてプログラムのユースケースを生成する方法です。プログラムスライシングは、バグの箇所やスタックトレースにも使用できます。モニタリングシステムに接続している方など、APP側でモニタリングをご利用の方は挙手ください。 Android システムのアプリケーションのうち、iOS アプリケーションではなく Android アプリケーションのみをリリースしている学生はどれくらいいますか?そのほとんどはAndroidとiOSの両方でリリースされています。スタック トレースに基づいて、ログやこれらのオンライン データを取得する方法など、議論すべきスタック トピックが多数あります。スタック トレースは、サーバー側だけでなく、クライアント側のバグを見つけるためにも使用されます。たとえば、インターフェイスが突然フリーズしたりクラッシュしたりした場合、対応するスタック情報を取得して、バグを直接特定し、予測を行うことができます。 5 番目はコンテキストの切り替えですが、ここでは説明しません。 6 番目は、単語の出現頻度や出現確率の計算による情報検索です。ホット スポット カバレッジの概念をご存知の方は手を挙げてください。説明していただけますか。

オーディエンス: ユーザーがどちらの側をより多くクリックし、どちらの側をより少なくクリックしているかを示すヒート マップがあります。

Qiu Huafeng: 私たちの方法は、ホットスポットを間接的にカバーすることであり、最も一般的な方法は、ホットスポットを変更にマッピングすることです。最後に、機械学習があります。人工知能を通じてバグを見つける方法を知る必要がある場合、まずさまざまな指標を定義する必要があります。これらの指標によって、バグを見つける精度が決まります。 Java ベースで 7 つ挙げてみました。まずは有効コード行数、サイクロマティック複雑度、Javadoc 仕様に準拠しているかどうかを見てみましょう。なぜこれを参考指標にすべきなのでしょうか。 Alibaba は Java の記述標準を発表しましたが、これは何もないところから生まれたものではありません。空白行を何行空けるべきかといった履歴記録を含む Alibaba のすべてのコード リポジトリをスキャンしてまとめたものです。当社には人工知能によるポジショニングツールがあります。バグの種類を数えて統計を作成しました。バグを引き起こす最も一般的な要因は、変数の恣意的な命名です。これはバグを見つけるための最も重要な参照指標です。ほとんどのバグは、関数を含む変数名を人間の理解や認識の一定範囲内で誤って使用することで発生します。コード記述標準の第 1 世代は関数型であり、第 2 世代はオブジェクト指向です。オブジェクト指向は万能でしょうか? オブジェクト指向のコードを書くと、保守や理解が容易になりますか?最も重要なのはファンインとファンアウトです。バグを見つけるときに、このメソッドが複数回参照されている場合、バグが発生する可能性が高くなります。次に、パッケージの設計品質があります。以前はモノリシック アプリケーションでしたが、現在はマイクロサービスとミドル プラットフォームについて話しているところです。これらは、パッケージに基づいていくつかの変更を加えることと同じです。以前はモノリシック アプリケーションでしたが、マイクロサービスに分割した後はどうすればよいのでしょうか。マイクロサービスを個別に抽出してミドル プラットフォームを作成すると、最も重要な変更は、Jar パッケージの構造など、これらも常に変化することです。 4 番目は、Jar パッケージのアップグレード品質、変数の数、およびパラメーターの数を分析するために使用されます。これは、バグ内のバグの位置に影響を与える主な指標でもあります。見たことがありますか? テスト中に最も多くの変数を見つけたのは誰か教えてもらえますか? 使用されたパラメーターの数、または関数がサポートできる関数の数を見つけたことがありますか? 誰か知っていますか?パラメータの数は言語によって異なります。関数にパラメータを渡す場合、関数のパラメータ名と変数には最大 256 個しか許可されません。256 個を超えると、プログラムは実行されません。変数とパラメータの数もバグの場所の指標として使用されます。最後に、オペレーターの数について見てみましょう。ご存知のとおり、機能テストとミドルウェア テストは基本的に異なります。違いは何でしょうか?ビジネスベースのものは、ビジネスシナリオに基づいている場合があり、ロジックやビジネスシナリオは比較的固定されています。統一されたロジックを持っている方が良いですが、ミドルウェアとしては多くの不確定要素を考慮することになります。これらの不確実な要素を考慮すると、実際にはオペレータ操作が隠された形で追加されていることになります。

パート II: 原則と方法。ここまでは基礎を皆さんに紹介しました。トレーニング セットのこの部分は実際のコードや例から得たものです。これはバグ防止の第一世代のプロトタイプです。比較的シンプルで、循環的複雑度のみを使用します。循環的複雑度を知っている方は手を挙げてください。なぜそれがバグ発生の確率を予測する重要な指標として使用できるのでしょうか?サイクロマティック複雑度は、記述するコード、その中の分岐数、プロセス数に基づいて決定され、サイクロマティック複雑度と比較されます。関数において、サイクロマティック複雑度が軍事ソフトウェアなどの産業レベルにある場合、一般的には 7 以下と検出され、より厳密には、コード複雑度は 5 を超えることはできません。サイクロマティック複雑度が高いほど、関数本体がどんどん長くなっている証拠です。ただし、5 から 7 の間であれば、約 40 行です。7 を超えて 20 に達すると、コード行数は数千行になる可能性があります。数千行の関数は、元の開発者であっても、引き継いだ新しい開発者であっても、メンテナンスが非常に困難になります。循環的複雑度にはこのような機能があることがわかっているので、循環的複雑度を使用してテストコードを予測し、循環的複雑度をスキャンして、それが妥当な範囲内にあるかどうかを確認できます。妥当な範囲内にない場合は、一定の確率でバグが発生する可能性があります。

この図は、学術分野への応用を紹介し、追加されたコードのバグを解決し、バグが修正される前のコードがどのように書かれていたか、バグが修正された後のコードがどのように書かれていたかを示すサンプルを作成します。

これは、バグの欠陥を予測するために使用される、バグの位置に基づいた 2 番目のプロトタイプです。最初のプロトタイプから 2 番目のプロトタイプまでの間には、さらに多くのステップがあります。まず、データセットが必要です。 2つ目は、先ほど述べた学術界におけるデータセットの入手方法です。 3 つ目は、Java 管理なしで、または JavaBug に関連せずに、人工自然言語を使用して処理することですが、多くの開発者は英語または中国語の注釈を付けて直接記述し、特定の問題について話し合います。これは、ほとんどの開発者が行うことです。 3つ目はサンプルの入手方法です。今後バグを引き起こす可能性のある要因は何でしょうか。これらの要因は分類され、処理されています。バグを特定したり予測したりする場合、まずどの指標がどの程度の割合を占めるべきかを知る必要があります。先ほど述べた方法を使用すると、さまざまな指標の割合を継続的に調整し、その割合に基づいて実際に得られたものと実際に発生したバグとの実際の一致を判断できます。人工知能には、再現率という専門用語があります。最終結果を見てみましょう。これが第2世代のプロトタイプです。このプロトタイプにはテスト サンプルがあり、そのほとんどは突然変異テストを使用して実行されます。

これはJavaベースであり、さまざまな要素や指標を参照することで、いくつかのサンプル結果を表示することができます。各測位技術によって得られる測位結果には多くの違いがあります。具体的な実装を見たい場合は、以下のリンクから、さまざまな技術の統計結果を生成し、方法、ソースコード、結果など、具体的な実行状況を確認できます。

これがスタックです。これでスタックは破棄されます。一般的に、フロントエンドでもバックエンドでもカプセル化が必要です。例外、スタックには複数の方法があり、例外はどのような例外であるかを尋ねます。システムレベルに基づくもの、ミドルウェアによって定義されるもの、ユーザーの行動によって定義されるものがあります。現時点では、欠陥防止に単純に使用することはできません。まず、3つのレイヤーをレイヤーに分割する必要があります。単純に直接使用することはできません。スタックに基づいて状況を予測する必要があり、より正確になります。これにより、特定のクラス、特定のメソッド、および下のどの行に移動するかがわかります。ホットスポットに基づいてカバーする場合、多くの場合、概念に言及し、変更された行を取得し、変更された行を介して一致させます。この行のコードは、この行に投げたことを明確に示します。開発者が問題を解決しようとするとき、経験豊富な開発者は1つのことを行います。常に0または1を確認し、それ以降のものは見ません。後で投げられたものは、現在のものとはまったく異なります。これを通じて開発が行えるため、これを欠陥防止または判定の技術的手段に変換できます。このとき、スローされた例外のランキングを作成できます。すべてのオンライン ログを収集し、すべてのログをまとめる必要があります。このタイプまたはこのメソッドに関係なく、そこに 1 回出現する限り、ランキングに「1」を追加します。まず、グローバル タイプとメソッドを確認します。行数が異なっていても、このメソッドの下にあるサーバーのランキングをカウントします。

今言ったことは、私の欠陥防止指標を確立するための参考資料です。リンクがいくつ呼び出されたか、関数が合計でいくつあるか、スタック例外関連の情報が投げられたかなど、これらの指標を見ることができます。先頭のSTは基本データです。基本データを使用してスタックトレースのバグの確率を予測することはあまり正確ではないことがわかりました。バグの確率はどれくらいですか？私たちは加重平均のようなもの、または統計学では平均と呼ぶべきものを行い、パラメータを組み合わせました。簡単な例として、このプロジェクトにファイルが2つしかない場合、スタック例外がスローされた場合、2つのクラスにいくつあるか、そして私は10個のファイルを持っていますが、各クラスのコード行数は異なります。バグの発生確率を完全に理解したい場合は、指標の1つを単純に参照として使用することはできません。組み合わせを行った後は、バグ発生の確率や状況のより詳細な指標定義を行うことに相当します。この指標を定義すると、バグの発生確率を予測しやすくなります。

これはスタック情報の AI 予測モデルです。スタック トレースをエラーのあるコードと関連付け、モデルを抽出して構築し、自動的にラベル付けします。第 2 段階では、オンラインですでに非常に多くの例外が発生しています。新しい例外を追加して、特定のタイプと行のメソッドで直接見つけることができるかどうかを確認してみましょう。なぜこれをするのですか?現在、テストは左または右にシフトされています。開発者と協力する場合、理想的なテストは、多くのステップやメソッドを与えることではなく、問題がどこにあるかを直接教えてくれる単体テストを書くことだと考えています。テストを通じてこれを実現する方法はたくさんあります。テストができないわけではありません。テストは可能ですが、履歴データの蓄積など、多くのツールが必要です。多くの場合、テストではシナリオとビジネスをより深く理解する必要があります。ここではモジュールのごく一部のみが記述されています。テスト結果を開発者にフィードバックすれば、これを実現できます。

これは、静的解析と動的解析を統合し、コード カバレッジ、メソッド カバレッジ、ブランチ カバレッジを統一されたマトリックスにまとめた第 3 世代のテクノロジです。このマトリックスに対応するネイティブの第 1 世代は 1 次元であり、判断に役立つものは 1 つしかありません。これは 2 次元です。第 3 世代は実際にはより多くの次元を持っていますが、この次元には静的解析と動的解析の両方が含まれます。同時に、カバレッジ行も統一された PageRank マトリックスにまとめられ、このバグの発生確率を複数の角度から予測できるかどうかを確認します。

最後に、ランクリストを取得します。さまざまなランキングを均一に作成し、バグの発生確率をこれまでよりも正確に予測します。

動作に基づいた別の方法もあります。これは最近登場したばかりで、バグを見つけるために使用されます。詳細については説明しません。

それでは、それをどのように適用するかについて話しましょう。プログラム スペクトルは、バグの検出に効果的な方法です。行き詰まったときは、指標だけで測定することはできません。テスト全体の品質を見るための包括的な指標として使用する必要があります。正の相関関係または線形データ指標があることがわかります。コードが悪いほど、バグの可能性が高くなります。これは疑う余地がありません。 2 つ目は、スタック トレースはクラッシュの特定に非常に効果的です。最近の携帯電話は動作が停止したり、応答が遅くなったりすることがよくあります。スタックからエラー例外を取得してレポートすることができます。これは、これらの例外の特定に非常に効果的です。どのようなエラーが発生したかなど、Android 側の応答を改善するために使用できます。これは非常に効果的な手段です。 3つ目に、エラーサンプルセットがまだ十分ではありません。先ほど述べた3つの方法では、仕様や固定オペレーティングシステムに従わないものが多く見逃されています。途中の開発者の多くは、これに従って作業しませんでした。フルサンプルと呼ばれるものがあり、これも密接に関連する要因です。もう1つは、アルゴリズムの多様性です。静的呼び出しと動的呼び出しを使用しており、内部のアルゴリズムも多様です。現在、20以上のアルゴリズムがあります。アルゴリズムは、バグの発生確率を予測するための重要な参照要素でもあります。明らかに、第 1 世代は第 2 世代ほど優れておらず、第 2 世代は第 3 世代ほど優れていません。ただし、反復バージョンと方法が増えると、元の単純なアルゴリズムはもはや適さなくなります。要素が追加されるたびに、または参照要素が追加されるたびに、モデルもそれに応じて処理され、バグの発生を予測する必要があります。

ライブビデオ（下記）

これらのバグ検出技術と方法を通じて、最も直接的かつ効果的な方法が得られます。これを実際の実装としてとらえれば、会社に直接的な利益をもたらすことができます。一般的に言えば、これまで多くの分析を行ってきましたが、これらのことは実装できず、コラボレーションの効率を向上させることもできず、推進と適用が非常に困難でした。これを通じて、これら 4 つのシナリオを実現でき、全員の効率を向上させ、バグを見つけるための開発を支援することができます。 Alibaba には視覚的な品質スコア システムがあり、4 つの次元に分かれています。1 つ目は循環的複雑度、2 つ目はオブジェクト指向指標、3 つ目は忘れました。各指標には要素があり、各側面に重みが与えられています。コードをテストした後、コードの品質スコアと直接相関関係があるかどうかを確認する開発が行われます。 指標が適切に定義されていれば、問題を発見できます。指標が適切に定義されていなければ、それは冗談になってしまいます。

たとえば、クロス検出や大規模なバグ検出を行う場合、アウトソーシングやインターネットから無料で公開されているテストツールを使用すると、バグが指摘された後に、バグの重複を排除して、将来の重要な指標を決定することもできます。バグの自動割り当て。開発者の提出ごとに、シナリオに関係するケースや提出されたブランチ バージョンに基づいて、バグと作成者を直接関連付けることができます。バグが発生したときに、どの開発者が行うべきかを決定する必要がなく、開発者にこのことに問題があることを伝えることができます。次に、ケースのレベル分類です。4 番目をやれば誰でもできると思います。ケースのレベル分類をやらないと、テストは始まったことすらありません。なぜそれを持ち出すのですか?ユニット テスト コードの生成に役立つツールは多数ありますが、これらのユニット テスト コードとこれの間には強い相関関係がないことがわかったからです。私たちは皆、「8020」ルールを知っています。バグの 80% はコードの 20% から発生します。すべてのケースが同じレベルにあるべきではありません。この理論に基づいて、コードのこれらの 20% をケース レベルに分類できます。反復バージョンが増えるほど、開発者とテスターは、単体テスト スクリプトを含む独自の自動化スクリプトを常にメンテナンスするようになります。これらのことは徐々に蓄積されます。この時点で、最初のバージョンは 10 分で実行できますが、半年または 1 年以上実行した後、プロジェクトが死んでいないことがわかります。テスト ケースが山積みになっていることがわかります。以前は 10 分または 30 分で完了できましたが、現在はスペースを使用して時間を交換して、ケースがどのように実行されるかを確認しています。スペースを時間と交換することに加えて、階層的な分類を使用してこれらのケースをマークすることもできます。これにより、使用するスペースや時間を節約できます。

これらは 4 つの論文です。オンラインで検索して、どれを直接実装できるかを調べることができます。

本日のシェアは以上です。