[Softwaretests] Der Feind des Testens und der Entwicklung – BUG

1. Einleitung

Im Vergleich zu BUG weiß jeder, dass ein Programm, das falsch läuft oder nicht den Erwartungen entspricht, ein BUG ist. Schauen wir uns nun BUG aus der Perspektive eines Testers an.

2. Wie man einen Fehler beschreibt/erstellt

Tester müssen den Code des Entwicklers testen, um die Probleme herauszufinden, die der Entwickler möglicherweise übersehen hat, und das Problem dann dem Entwickler melden.
Wie man den Fehler klar und prägnant beschreibt, erfordert viele Dinge. Dies ist nicht nur eine einfache Aussage. Wenn a Es ist ein Fehler aufgetreten.
Die Beschreibung eines qualifizierten Fehlers ist in die folgenden Teile unterteilt:

• Die Version, in der das Problem gefunden wurde: Es sollte viele Versionen der meisten Software geben. Tester müssen die Version kennen, die dem Problem entspricht, um den Code der entsprechenden Version zu erhalten und den Fehler zu reproduzieren
• Die Umgebung, in der das Problem auftritt: Die Umgebung ist in Hardwareumgebung und Softwareumgebung unterteilt. Wenn es sich um ein WEB-Projekt handelt, ist es auch erforderlich, die Version des Browsers, das Betriebssystem des Clients usw. zu beschreiben Bei einem APP-Projekt müssen das Modell, die Auflösung, das Betriebssystem usw. beschrieben werden. Eine detaillierte Umgebungsbeschreibung ist hilfreich für die Fehlerlokalisierung.
• Schritte zum Reproduzieren des Fehlers: Beschreiben Sie die Mindestschritte zum Reproduzieren des Problems.
• Beschreibung des erwarteten Verhaltens: Es ist richtig, Entwickler aus der Sicht der Benutzer anzuleiten.
• Beschreibung des Fehlerproblems: Die Szene, in der ein Fehler auftritt

Die Beschreibung eines Fehlers bedeutet nicht, dass er nur aus den oben genannten Teilen bestehen kann, sondern kann auch andere Aspekte beschreiben, z. B. ob der Fehler ein Front-End-Problem oder ein Back-End-Problem ist, die Ebene des Fehlers usw .

Die Fähigkeit, einen BUG zu beschreiben, macht es einfacher, einen BUG zu erstellen.

3. BUG-Ebene

Es gibt verschiedene Schweregrade für BUG. Die Definition von BUG ist für jedes Unternehmen unterschiedlich. Sie müssen die Unternehmensspezifikation überprüfen, bevor Sie den Grad festlegen .
Zum Beispiel:

• Blocker (Absturz) : Probleme, die die Entwicklung oder das Testen behindern; Systemabstürze, Abstürze und Endlosschleifen verursachen, was zum Verlust von Datenbankdaten, Fehlern in Verbindung mit der Datenbank, zum Verlust von Hauptfunktionen und zum Fehlen von Basismodulen führt. Zum Beispiel: Codefehler, Endlosschleife, Datenbank-Deadlock, wichtige Menüfunktionen der ersten Ebene können nicht verwendet werden usw. (Dieses Problem tritt im Test selten auf. Sobald es auftritt, sollte der aktuelle Versionstest sofort beendet werden).
• Kritisch (schwerwiegend) : Die Hauptfunktionen des Systems gehen teilweise verloren, die Datenbank wird falsch gespeichert und aufgerufen, Benutzerdaten gehen verloren und das Funktionsmenü der ersten Ebene kann nicht verwendet werden, hat jedoch keinen Einfluss auf den Test anderer Funktionen. Das funktionale Design entspricht nicht ernsthaft den Anforderungen, das Modul kann nicht gestartet oder aufgerufen werden, das Programm startet neu, wird automatisch beendet, Aufrufkonflikte zwischen verwandten Programmen, Sicherheitsprobleme, Stabilität usw. Zum Beispiel: Fehler, die in der Datenbank nach dem Speichern von Daten in der Software angezeigt werden, fehlende von Benutzern benötigte Funktionen, Fehler in der Programmschnittstelle, Fehler in der numerischen Berechnungsstatistik usw.
• Schwerwiegend (Allgemein) : Die Funktion ist nicht vollständig implementiert, beeinträchtigt jedoch nicht die Verwendung, und das Funktionsmenü weist Mängel auf, beeinträchtigt jedoch nicht die Systemstabilität. Zum Beispiel: lange Betriebszeit, lange Abfragezeit, falsches Format, falsche Randbedingungen, kein Bestätigungsfeld zum Löschen, zu viele Felder in der Datenbanktabelle usw. (dieses Problem tritt am häufigsten im tatsächlichen Test auf)
• Geringfügig (geringfügig) : Schnittstelle, Leistungsmängel, Vorschläge, Probleme, die die Ausführung von Betriebsfunktionen nicht beeinträchtigen, Lösungen, die die Leistung optimieren können usw. Zum Beispiel: Tippfehler, unregelmäßiges Schnittstellenformat, überlappende Seitenanzeige, Ausblenden dessen, was nicht angezeigt werden soll, unklare Beschreibung, fehlende Eingabeaufforderungen, ungleichmäßige Textanordnung, falsche Cursorposition, schlechte Benutzererfahrung, Lösungen, die die Leistung optimieren können usw. (Es gibt viele solche Probleme treten in der frühen Phase des Tests auf und haben eine geringe Priorität; in der späteren Phase des Tests gibt es nur wenige Probleme, und sie sollten rechtzeitig behoben werden)

4. BUG-Lebenszyklus

Wenn während der Testausführung ein entsprechender Fehler vorliegt, muss der Tester einen Fehler auf der entsprechenden Fehlerverwaltungsplattform erstellen.
Jedes Unternehmen und jedes Tool hat eine inkonsistente Definition des Fehlerlebenszyklus.
Zum Beispiel:

• Neu: Tester erstellen Fehler
• Offen: Der Entwickler bestätigt, ob es sich um einen Fehler handelt. Wenn es sich um einen Fehler handelt, wird der Status in „Offen“ geändert
• Abgelehnt: Wenn es sich nicht um einen Fehler handelt, wird die Änderung abgelehnt.
• Behoben: Nachdem der Entwickler den Fehler behoben hat, wird der Status in „Behoben“ geändert
• Verzögerung: Nach Bestätigung des Fehlers wird der Status in „Verzögerung“ geändert, wenn der Fehlerpegel nicht hoch ist oder der Entwickler den Fehler nicht sofort beheben kann.
• Geschlossen: BUG bestätigt, dass die Reparatur abgeschlossen ist, und der Tester ändert den BUG in „Geschlossen“.
• Erneut öffnen: Der Entwickler behebt den Fehler, der Fehler wurde jedoch nicht behoben und der Fehlerstatus wird in „Erneut öffnen“ geändert

5. Was ist zu tun, wenn es zu Streitigkeiten mit der Entwicklung kommt?

Schließlich müssen Tester ihr Bestes geben, um den Code des Entwicklers zu testen und Fehler zu melden. Wenn er nicht richtig gehandhabt wird, kann es leicht zu Streitigkeiten mit der Entwicklung kommen. Was sollen wir tun, wenn es Streit gibt? Für dieses Problem
:我们要坚持"对事不对人".

1. Denken Sie „kritisch“ nach, überlegen Sie, ob der von Ihnen beschriebene Fehler nicht klar genug ist usw.
2. Wenn der Entwickler den Grad des Fehlers nicht erkennt, müssen wir sicherstellen, dass der Grad des Fehlers gerechtfertigt ist.
3. Das Vorschlagen eines Fehlers erhöht die Arbeitsbelastung des Entwicklers und das kleine Problem kann möglicherweise nicht gelöst werden. Zu diesem Zeitpunkt kann der Entwickler dazu angeleitet werden, sich einzufühlen: „Wenn Sie ein Benutzer sind, würden Sie eine solche Situation akzeptieren?“
4. Nicht nur um Fehler vorzuschlagen, sondern auch um Lösungen vorzuschlagen
5. Wenn es sich tatsächlich um einen BUG handelt und eine freundliche Kommunikation das Problem zu diesem Zeitpunkt nicht lösen kann, wird eine BUG-Überprüfung durchgeführt.

Die obigen Antworten dienen nur als Referenz. Wenn Sie bessere Ideen haben, können Sie diese auch hinzufügen.

Ergänzung: Zu den Personen, die an der BUG-Überprüfung teilnehmen müssen, gehören Produktmanager, Entwicklungsvertreter, Testvertreter usw. Der Diskussionsinhalt gliedert sich im Allgemeinen in zwei Teile: 1. Wie der Fehler behoben wird, 2. Wie man das Auftreten ähnlicher Probleme vermeidet.

Vielen Dank fürs Zuschauen! Ich hoffe, dieser Artikel kann Ihnen helfen!
Kolumne: „Softwaretests“ wird ständig aktualisiert, willkommen zum Abonnieren!
„Ich möchte Sie ermutigen und zusammenarbeiten!“