1

サブモジュールのリリースを親プロジェクトに統合するとき、統合されたときにのみ表示およびトリガーされるバグに定期的に遭遇します。これは正常です。バグは正常です。それらをデバッグして修正し、サブモジュールに送信します。

現在、そのような修正が後でサブモジュール開発者によって上書きされ、このサブモジュールを統合したプロジェクトで再発することが何度かありました。

時間の経過とともに、彼らの行動と症状のインテリジェントな追跡が事実上ないため、それが忘れられ、再び修正されることがあります. これは、特にトリッキーな場合は非常に時間がかかります。

したがって、私の質問:バグの「動作」を技​​術的に保存して、その症状が再び表示されたときに「思い出させる」にはどうすればよいですか?

私の問題に対処するツールはありますか。修正されたバグを症状別に分類するために使用できるものはありますか?

私が持っていた 1 つのアイデアは、静的アナライザー (コベリティや clang-analyzer など) をカスタム パターンで拡張することでした。これは動作/症状アプローチに対処しませんが、最初の修正中に作成されたパターンを使用してコンパイル中にコードを分析できました:「このコードが特定の方法で書かれている場合、それは良くありません」. 私の経験では、この方法でかなりの数のバグに対処できましたが、すべてではありませんでした。

これらは私が使用している言語であるため、C および C++ タグを追加しました。

更新: コメントに質問があったため: git を使用しています。再発するバグは、最初の修正から数か月または数年後にコミットされます。

更新: バグ追跡に Mantis を使用しています。

4

1 に答える 1

0

これはツールではなく、プロセスです。これを行うためにBFV(バグ修正検証)テストを使用しました。バグを修正するたびに、そのバグの自動BFVテストを追加します。テストの名前はBFV#bugnoになります-これはバグデータベースのバグ番号です。テストに提供されるすべてのビルドの一部として、回帰テストの一部としてすべてのBFVテストを実行します。BFV2042に障害が発生した場合は、バグデータベースでBug#2042を検索して、そのことを通知することができます。サブモジュールブランチからのマージを受け入れる前に回帰テストを実行している場合は、さらに優れています。

于 2012-10-24T14:42:27.890 に答える