バグが見つかりません

補足

孤立無援のような感覚になります

ベストアンサー

0

再現できない場合はテスト手順、環境、テスト回数(あるいは時間)を述べるしかない。 焦らず探すにあたり、砂場に落ちた針を探すような場合があることを周知徹底するしかない。 もしも現実的に絨毯爆撃したければ自動テストツールを導入して無人で延々と何時間もテストする体制を作るしかない。

その他の回答(4件)

0

エラーは想定されたもので、バグは想定外の動きをする事なので、エラーが出るはずがない場合にエラーとされるのであればバグになります。 エラーのメッセージが想定と違うのもバグですが。 なので、エラーが出ること自体はバグではないのですが、メモリーリークなどのバグを検知してエラーが出ている事もあり、その場合はエラーは想定されたものですが、メモリーリークの方がバグになります。安全装置が働いたという感じです。 頻発する場合は、ある時点で「次回出たら、その時の操作とエラー情報を記録しよう」となると思います。 エラー情報はメッセージとメモリーダンプやスタックトレースなどです。 メモリーダンプは、開発者でもないと解析するのは難しいですが、人間が読める文字列は読んでみると、結構親切に記載されている事がありますので、そこから推測して再現性を確認します。 報告するときは、記録したものをそのまま、こういったエラーが頻発するけど不具合ではないですか?と報告するでも良いです。 再現手順が分かった場合は、手順も添えれば良いです。 焦る理由って発生しないものを追いかけているかもしれないという感覚ですかね? でも事実として発生したわけで、エラーの内容が読めるようになっていて、読む癖が着くと、そんなに焦る必要も無くなると思います。 精度を上げるという意味で開発に貢献しているという事ですから、孤立無援ってことはないですよ。アプリケーションの開発者にも、利用者にも役立つ事をされているのですから。

0

> 1.再現できない場合、どのように報告すべきでしたでしょうか 「再現しませんでした」と報告する。 ただ、やり方が悪いと突っ込まれない様に、何をやったかの詳細は記録が必要。 > 2.焦らず探す方法はありますか? やる事を整理して一つ一つこなすしかない。 ブルーバック発生の瞬間を防犯カメラでとらえた事はある。

0

どんなソフトか判らないので、一般論だけ・・・ まずは、発生した時の再現を試みた時の条件の違いをちゃんと 調べましょう。 条件とは、データだったり、使い方だったり、時刻だったり・・・ 頻発時の条件をまとめて、それから推測する。 そして、推測した可能性の順に再現テストを実施する。 報告する際は、それらをちゃんとまとめ、状況からどう分析し、 どんな条件で再現テストを試みたかをちゃんと残す。 今後のためにも、それらをちゃんとのこすことが重要。

0

なにを聞きたいのかよくわかりませんが... > エラーが頻発するソフトのバグを再現しようとしました 「頻発する」という言葉は私とあなたで同じ意味で使っているのかしら... 頻発していたはずのエラーがテストに持ち込むと全然出なかった、とかいうことですか? この質問をそう読むのは難しいですが。 > 1.再現できない場合、どのように報告すべきでしたでしょうか やったこと、起こったことをそのまま。報告ってのはそういうものでしょう。他になにがありますか? 少なくとも、再現方法が見つかるまでは「このやり方では再現しない」ということも重要な情報です。 > 2.焦らず探す方法はありますか? 心を強くするしかないですね。日頃から禅でもやって。 最近の流行りは「メタ認知」でしょうか。「焦っている自分」を認識することでその状態を和らげる、みたいな話らしいです。