2009-03-22 5 views
0

Ich habe in letzter Zeit viel über Debugging gelesen. Einer der Aspekte, auf die ständig Bezug genommen wurde, war nicht nur ein Fehlerverfolgungssystem, sondern auch ein Fehlerlösungsverfahren. Ich las über Leute, die das Problem aufnahmen (das hat oder nicht funktioniert), Tests, die bestimmen würden, ob ein gegebenes Update funktionieren würde oder nicht, etc.Bug Maintenance System

Also denke ich, "hey, das ist eine gute Idee "

Ich benutze Mantis gerade jetzt, und es scheint nicht diese Fähigkeit zu haben (ohne seine Felder zu missbrauchen). Mantis funktioniert hervorragend als Bug Logger. Aber ich suche nach etwas anspruchsvolleren Interface, denke ich.

Beispiel

mein Fehler Angenommen war "Hosen herunterfallen". Dann möchte ich diese Informationen als ...

"Hosen fallen ab; Februar 32, 2009, 25:61; als ich in ein Zimmer ging, fiel meine Hose aus!"

Entwickler 1 ...

Hypothese 1: Hosen zu groß.

Test 1: Einen Gürtel anlegen.

Mögliche Lösung 1: Kaufen Sie einen Gürtel.

Ergebnis = ?? Ergebnis ???

Test 2: Zieh deine Kinderschwester an.

Mögliche Lösung 2: Stehlen Sie in ihr Zimmer und nehmen Sie alle ihre Hosen, während sie in der Schule ist!

Ergebnis = ??, Datum/Uhrzeit = ??? 2

Entwickler ...

Hypothese 2: Ihre Hosen haben Löcher.

Test 1: Leuchten Sie sie an.

Mögliche Lösung: Kaufen Sie neue Hosen.

Ergebnis = ???, Datum/Uhrzeit = ???


Nun, das ist ein dummes Beispiel. Aber ich denke, es wäre großartig, als Software-Tool zu haben. Gibt es solche, und wenn ja, wie heißt es?

Antwort

2

Vertrauen Sie mir: Sie wirklich wollen nicht Ihre Fehler zu halten, das ist, warum Sie nicht „Bug Maintenance Systems“ finden :-)

Sorry ... konnte nicht widerstehen. Was den eigentlichen Inhalt Ihrer Frage betrifft: Ich persönlich behalte nur all diese Informationen in der Kommentarhistorie des Tickets im Auge. Meistens verwende ich trac für seine Einfachheit, aber auch die Fähigkeit, bei Bedarf in Quellen zu verlinken (zumindest auf der Dateiebene, ich wünschte, es wäre grok Code, so dass Sie in die AST zeigen können).

+0

Ich hätte es getan, wenn Sie es nicht getan hätten. –

+0

haha ​​:) –

+0

Das machen wir, wo ich arbeite: Fügen Sie jedes Mal einen weiteren Kommentar hinzu, wenn wir etwas Neues lernen. Wenn derselbe Fehler erneut auftritt, wissen wir, was wir sofort versuchen sollten, um zu bestätigen, ob es sich um einen Duplikat oder um einen neuen Fehler handelt. –

0

Sie könnten Testopia verwenden, was eine Erweiterung von Bugzilla ist. Dies würde natürlich auch bedeuten, dass Sie Bugzilla verwenden müssten.

von der Testopia Website genommen:

Testopia ist ein Testfall-Management-Erweiterung für Bugzilla. Es wurde entwickelt, um ein generisches Tool für die Nachverfolgung von Testfällen zu sein, das es Testunternehmen ermöglicht, Fehlerberichte in ihre Testfall-Ergebnisse zu integrieren. Obwohl es im Hinblick auf das Testen von Software entwickelt wurde, kann es verwendet werden, um Tests an praktisch allem im Entwicklungsprozess zu verfolgen.

0

Wir verwenden auch Mantis, und wie Peter Becker beschreibt, verwenden wir die Kommentare, die Arbeit auf einen Fehler zu beschreiben. Dies funktioniert normalerweise, weil die meisten Bugs keine so lange Geschichte haben.

Wenn die Arbeit an einem Fehler so komplex wird es seine eigenen Sitzungen und Besprechungen machen muß, wir in der Regel eine Aufgabe in unserem Arbeit Planungssystem erstellen und zu tun, die Diskussion dort (Verknüpfung von Mantis). Das funktioniert zumindest für uns.

Auf jeden Fall würde ich vorsichtig bei einem System, das einen bestimmten Workflow explizit zu unterstützen versucht, da diese dazu neigen, auch Sie in den Workflow sperren sie erwarten. Ein in Fehlerjäger kann der Workflow viel von Fehler zu Fehler variieren ...

Schließlich ist zu beachten, dass Mantis können Sie auch Ihre Kommentare bearbeiten. Sie können also alte Kommentare ändern, um den Fehlerbericht nicht zu überladen.