0

私は最近、デバッグについて読むことに多くの時間を費やしました。継続的に参照された側面の 1 つは、単なるバグ追跡システムではなく、バグ解決プロセスでした。私は、人々が問題のテイクを書き留めていること（それが機能したか機能しなかったか）、修正の特定のテイクが機能するかどうかを判断するテストなどについて読みました。

だから私は「ねえ、これはいいアイデアだ」と思っています。

私は現在Mantisを使用していますが、その機能を持っていないようです（フィールドを悪用することなく）。Mantis はバグ ロガーとして最適です。でも、もっと洗練されたインターフェイスを探していると思います。

例

私のバグが「ズボンが落ちる」だったとします。次に、この情報を次のようにログに記録したい...

「ズボンが脱げる 2009年2月32日 25時61分 部屋に入ったらズボンが脱げた！」

開発者 1...

仮説1：パンツが大きすぎる。

テスト1：ベルトを装着。

考えられる解決策 1: ベルトを購入する。

結果=?? 結果 ？？？

テスト 2: 子供の妹のズボンをはきます。

考えられる解決策 2: 彼女の部屋に忍び込み、学校にいる間に彼女のズボンをすべて持っていきます!

結果 = ??、日付/時刻 = ???

開発者 2...

仮説 2: あなたのズボンには穴が開いています。

テスト 1: それらに光を当てます。

考えられる解決策: 新しいパンツを購入する。

結果 = ???、日付/時刻 = ???

さて、これはばかげた例です。しかし、ソフトウェアツールとしては素晴らしいと思います。そのようなものは存在しますか?存在する場合、それは何と呼ばれますか?

4

3 に答える 3

2

私を信じてください: あなたは本当にバグを維持したくないので、「バグ メンテナンス システム」が見つからないのです :-)

申し訳ありません...抵抗できませんでした。あなたの質問の実際の内容について: 私は個人的に、チケットのコメント履歴ですべての情報を追跡しています。ほとんどの場合、 tracはその単純さのために使用しますが、必要に応じてソースにリンクする機能もあります (少なくともファイル レベルでは、コードを grok して AST を参照できるようにしてほしい)。

于 2009-03-22T23:24:13.253 に答える
0

Bugzillaの拡張であるTestopiaを使用できます。もちろん、これは Bugzilla を使用する必要があることも意味します。

Testopia の Web サイトからの抜粋:

Testopia は、Bugzilla のテスト ケース管理拡張機能です。これは、テスト ケースを追跡するための汎用ツールとして設計されており、テスト組織がバグ レポートをテスト ケースの実行結果と統合できるようにします。ソフトウェア テストを念頭に置いて設計されていますが、エンジニアリング プロセスのほぼすべてのテストを追跡するために使用できます。

于 2009-03-23T00:09:36.670 に答える
0

また、Mantis も使用しており、Peter Becker が説明しているように、コメントを使用してバグの作業を説明しています。ほとんどのバグにはそれほど長い歴史がないため、これは通常うまくいきます。

バグの作業が非常に複雑になり、独自の会議や会議メモが必要になった場合は、通常、メインの作業計画システムでタスクを作成し、そこで議論を行います (Mantis からのリンク)。それは少なくとも私たちにとってはうまくいきます。

いずれにしても、特定のワークフローを明示的にサポートしようとするシステムには注意が必要です。これらのシステムも、システムが期待するワークフローに閉じ込められる傾向があるためです。バグハンティングでは、ワークフローはバグごとに大きく異なる可能性があります...

最後に、Mantis ではコメントを編集することもできます。そのため、古いコメントを変更して、バグ レポートが煩雑にならないようにすることができます。

于 2009-03-23T00:11:56.180 に答える