Menü

Code Refactoring: Was Sie darüber wissen müssen

code refactoring what you need know about it

Versuchen Sie Unser Instrument, Um Probleme Zu Beseitigen

Grundlegendes zum Code-Refactoring: Die Perspektive eines Testers

Der Begriff 'Refactoring' wird hauptsächlich verwendet, um die erforderliche Codebereinigung / -neugestaltung anzuzeigen.

In diesem Tutorial werden wir die Definition von Refactoring verstehen, die Notwendigkeit von Code-Refactoring erörtern und die Auswirkungen von Refactoring-Code auf verschiedene Mitglieder des Projektteams untersuchen. Wir werden auch die Antwort auf die wichtigste Frage diskutieren - Warum müssen Sie als Tester etwas über Refactoring wissen?

Darüber hinaus werden wir einige Fallstudien diskutieren, um das Konzept zu verdeutlichen.

Code Refactoring

Was du lernen wirst:

Einführung in das Refactoring

Lassen Sie uns zunächst verstehen, was Refactoring eigentlich ist.

Refactoring ist im Wesentlichen eine Praxis oder ein Prozess zur Verbesserung des Codes und / oder der Datenbank unter Beibehaltung der vorhandenen Funktionalität. Die Idee ist, ineffizienten und überkomplizierten Code in effizienteren, vorzugsweise einfacheren und einfacheren Code umzuwandeln.

Das Refactoring von Code hat jetzt auch bei mehr Teams an Dynamik gewonnen, indem es dem Ansatz der agilen Softwareentwicklung gefolgt ist. Projektteams haben häufig nur begrenzte Zeit, um neue Funktionen zu implementieren oder die Funktionalität der vorhandenen Funktionen und des sauberen Codes zu erweitern. Der Code, der leicht zu verstehen und zu pflegen ist, trägt zweifellos wesentlich zur Einhaltung der Iterationsfrist bei.

Notwendigkeit für Code Refactoring

Wenn wir die ursprüngliche Funktionalität der Anwendung oder des Moduls beibehalten, stellt sich die Frage: Warum kümmern wir uns überhaupt um das Refactoring? Nun, es gibt zahlreiche Gründe, aus denen ein bestimmtes Modul oder ein bestimmter Code möglicherweise überarbeitet werden muss, z.

  1. Code riecht
  2. Technische Schulden
  3. Agiler Softwareentwicklungsansatz usw.

Wir werden diese Punkte in den folgenden Abschnitten ausführlich erörtern.

# 1) Code riecht:

Wir alle können verstehen, dass wenn das Essen anfängt zu riechen, dies darauf hinweist, dass es höchstwahrscheinlich schlecht wird - dies gilt auch für Code! Code-Gerüche sind Anzeichen dafür, dass im Code ein sehr ernstes Problem vorliegen kann.

Im Folgenden sind einige häufig vorkommende Codegerüche aufgeführt:

  • Vorhandensein von redundantem oder identischem Code.
  • Eine deklarierte Variable, die im Rest des Codes nirgendwo verwendet wird.
  • Überkompliziertes Code-Design.
  • Codeklasse, die zu wenig tut und die Existenz der definierten Klasse nicht rechtfertigt. Solche Klassen werden als Lazy Class oder Freeloader bezeichnet.
  • Das Vorhandensein zu vieler Bedingungen und Schleifen, die möglicherweise aufgeschlüsselt und vereinfacht werden können.
  • Code wird so erstellt, dass für eine Änderung in einem Teil des Codes die Änderung auch an den anderen Stellen implementiert werden muss.

Code-Gerüche werden mit der Zeit deutlicher. Wenn die Anwendung oder das System wächst, wirken sich diese Codegerüche schließlich auf die Codeentwicklung, -wartung und sogar auf die Systemleistung in extremen Szenarien aus.

# 2) Technische Schulden:

Während der Entwicklung einer Software können wir während der begrenzten Zeit und der begrenzten verfügbaren Ressourcen häufig Verknüpfungen verwenden, um die gewünschten Ergebnisse zu erzielen.

Stellen Sie sich eine Funktion vor, die einem vorhandenen Modul hinzugefügt werden muss. Nach der Diskussion schränkt das Team zwei Ansätze ein, um diese Funktion hinzuzufügen. Ansatz A, für dessen Durchführung 2 Sprints erforderlich sind, ist der genehmigte langfristige Ansatz. Die Bereitstellung von Ansatz B dauert nur 5 Tage. Es handelt sich um einen chaotischen, hartcodierten Hack, der nur dazu dient, das Modul kurzfristig zu warten.

Wenn das Team unter dem Druck steht, die Funktion innerhalb einer begrenzten Zeit bereitzustellen, kann es sich bereit erklären, Ansatz B vorerst zu befolgen und Ansatz A für die Zukunft in den Rückstand aufzunehmen. Auf diese Weise hat dieses Team gerade die technischen Schulden für sich selbst geschaffen.

In einfachen Worten bezieht sich die technische Verschuldung bei der Softwareentwicklung auf die zusätzliche Nacharbeit oder den zusätzlichen Aufwand, der erforderlich ist, um die entsprechenden Korrekturen vorzunehmen oder die Dinge auf die „richtige Art und Weise“ zu erledigen.

Legacy-Systeme neigen dazu, im Laufe der Zeit enorme technische Schulden zu machen, was wiederum dazu führen kann, dass die Anwendung fehleranfällig und schwer zu unterstützen und zu warten ist.

Weiterlesen=> Was ist die technische Abteilung?

# 3) Nach dem Ansatz der agilen Softwareentwicklung:

Der agile Softwareentwicklungsansatz befürwortet eine schrittweise Entwicklung. Ohne sauberen, gut strukturierten und einfach zu pflegenden Code wäre es Teams nicht möglich, den vorhandenen Code bei jeder Iteration zu erweitern. Wenn der Code ohne ordnungsgemäßes Refactoring geändert wird, kann dies zu Code-Gerüchen oder technischen Schulden führen.

Diese Beziehung ist in der folgenden Abbildung dargestellt

Agiler Softwareentwicklungsansatz

Empfohlene Lektüre => Top-Code-Analyse-Tools

Warum muss eine Qualitätssicherung etwas über Refactoring wissen?

Was auch immer wir bisher in diesem Tutorial besprochen haben, scheint mit dem Codieren zu tun zu haben und sieht aus wie die Dinge, über die sich ein Entwickler Sorgen machen sollte.

Warum diskutieren wir dann dieses nicht verwandte Konzept in der Software Testing Help Community? Lesen Sie den Rest dieses Tutorials weiter, um die Antwort auf diese Frage zu erhalten.

# 1) Für Unit Tester / Entwickler

Während der Umgestaltung des Codes werden beim Einfügen von neuem Code alte Klassen aktualisiert, neue Klassen hinzugefügt und vorhandene Komponententests können jetzt fehlschlagen. Darüber hinaus sind für Legacy-Systeme möglicherweise überhaupt keine Komponententests implementiert. Diese neuen Komponententests müssen in den meisten Fällen von Grund auf neu erstellt und eingerichtet werden.

# 2) Für Tester

Wenn eine Funktion überarbeitet wird (da keine neuen Funktionen hinzugefügt werden), sollte nach den erforderlichen Änderungen ein Großteil der Funktionen für den Endbenutzer unverändert bleiben.

  • Als Tester bedeutet Refactoring von Code ungefähr = eingehende Tests + Regressionstests. Bei eingehenden Tests müssen alle vorhandenen Benutzerabläufe berücksichtigt werden, um sicherzustellen, dass alle Funktionen wie zuvor funktionieren. Regressionstests der gesamten Anwendung (oder der betroffenen Bereiche) ist erforderlich, um sicherzustellen, dass durch das Aktualisieren eines Moduls die Funktionalität der anderen Module nicht unbeabsichtigt beeinträchtigt wird.
  • Benutzerakzeptanztests sind wichtig, und diese Tests müssen bestanden werden, bevor der Build für die Freigabe bereit erklärt werden kann.
  • Darüber hinaus sind alle anderen erforderlichen Tests wie Belastungstests erforderlich. Sicherheitstest usw. müssten auch nach Bedarf implementiert werden.

# 3) Automatisierungstestingenieure

Das Refactoring von Code kann dazu führen, dass funktionale und nicht funktionale Automatisierungsskripte fehlschlagen.

Dies kann folgende Gründe haben:

  • Wenn sich die Seitenobjekte im Rahmen der Umgestaltung ändern und Ihre Selenium-Automatisierungsskripts auf den Seitenobjekten basieren, schlagen die Skripte fehl und müssen aktualisiert werden.
  • Wenn geringfügige Änderungen vorgenommen wurden, werden diejenigen umgeleitet, die während des Refactorings hinzugefügt oder entfernt wurden, und vorhandene Automatisierungsskripts würden fehlschlagen und müssten aktualisiert werden

Es wird empfohlen, die Funktionsautomatisierungstests erst dann einzurichten, wenn eine Funktion stabil ist. Andernfalls wird die Entwicklung der Funktion erheblich überarbeitet.

Als Entwickler von Automatisierungstests müssen Automatisierungstestingenieure auch wie ein Entwickler denken und darauf abzielen, einen sauberen und einfach zu wartenden Code zu erstellen. Die meisten IDEs wie IntelliJ IDEA, Eclipse usw. enthalten ein integriertes Refactoring-Menü mit häufig verwendeten Refactoring-Methoden zum einfachen Nachschlagen.

Unten sehen Sie einen Screenshot des Refactoring-Menüs in IntelliJ IDEA (Community Edition).

beste youtube konvertieren in mp3 app

Refactoring-Menü

# 4) Für Testleitungen / QS-Leitungen

  • Test Leads / QA Leads müssen möglicherweise mit dem Rest des Teams zusammenarbeiten, einschließlich Entwicklern, Produktanalysten und möglicherweise sogar Stakeholdern, um sicherzustellen, dass die Testplanung für solche Projekte sorgfältig durchgeführt wird.
  • Es ist wichtig, die vorhandenen Funktionen zu verstehen. Basierend auf den vorhandenen Funktionen müssen Geschäftsfälle, Benutzerabläufe und Benutzerakzeptanztests dokumentiert werden. Wenn ein überarbeiteter Code getestet wird, müssen alle diese Szenarien validiert werden, zusammen mit Regressionstests der betroffenen Bereiche.
  • Seien Sie proaktiv bei der Planung des Testansatzes und Testpläne . Wenn Sie die Anforderung mehrerer Testumgebungen oder neuer Testtools erwarten, senden Sie die Anforderung bitte frühzeitig, um Verzögerungen zu vermeiden, sobald die Testphase beginnt.
  • Zögern Sie nicht, Nicht-Projektteammitglieder oder Endbenutzer einzubeziehen, um zum Testen beizutragen.

Fallstudien

Wir werden nun einige reale Fallstudien diskutieren, in denen ich die Möglichkeit hatte, entweder direkt zu arbeiten oder indirekt dazu beizutragen.

Fallstudie Nr. 1

Aufgabe: Überarbeiten Sie ein Modul, um die fest codierten Werte durch Variablen zu ersetzen und Kommentare für das neue Tool zur automatisierten Generierung technischer Dokumentationen hinzuzufügen.

Herausforderungen ::Keine großen Herausforderungen. Das Modul war neu, hatte Funktions- und Benutzerakzeptanzanforderungen, Benutzerabläufe und Testfälle dokumentiert. Unit-Tests wurden bereits beim ersten Start selbst durchgeführt.

Testansatz ::Die Testfälle für das umgestaltete Modul und die relativ bekannten betroffenen Bereiche wurden ausgeführt. Alle Mängel wurden vor der Freigabe gemeldet und behoben.

Fallstudie Nr. 2

Aufgabe ::Refactor vorhandene gespeicherte Prozedur, um die Skalierung der Anwendung zu erleichtern.

Die in diesem Szenario gespeicherte Prozedur war eine ältere gespeicherte Prozedur, die vor einigen Jahren entwickelt wurde, wobei zu berücksichtigen ist, dass die Anwendung ihre gespeicherte Prozedur als interne Anwendung mit weniger als 10 gleichzeitigen Sitzungen verwendet.

Jetzt wollte das Unternehmen diese Anwendung als Software as a Service (SaaS) mit dem erwarteten Volumen von zunächst 300 gleichzeitigen Sitzungen vermarkten.

Das Team führte einige erste Auslastungstests durch und kam zu dem Schluss, dass das System mit einer Auslastung von 25 gleichzeitigen Sitzungen ausfällt. Das Team überprüfte den Code und empfahl, eine vorhandene gespeicherte Kernprozedur umzugestalten, damit die Anwendung bis zu 500 gleichzeitige Sitzungen skalieren und unterstützen kann, ohne zu unterbrechen.

Einige Probleme, die bei dieser gespeicherten Prozedur festgestellt wurden, waren mehrere Unterabfragen innerhalb einer einzelnen Abfrage, umfangreiche Verknüpfungen mit Ansichten anstelle von Tabellen, die Verwendung von select * anstelle der Auswahl einer bestimmten Spalte usw. Aufgrund dieser Codierungsprobleme holte die Anwendung mehr Daten ab war wirklich notwendig, wodurch die Anwendung langsamer wurde und schließlich abstürzte.

Herausforderungen:

# 1) Projektmanager / Produktanalyst

  • Anforderungserfassung - Da es sich bei dieser gespeicherten Prozedur um einen Legacy-Code handelte, gab es beim ersten Entwurf des Moduls keine dokumentierten Anforderungen dafür. Auch für die in den letzten Jahren durchgeführten Iterationen gab es kein Änderungsprotokoll, das die Geschäftsregeln und die Logik angibt, die dem Modul hinzugefügt oder daraus entfernt wurden.
  • Projektplan - Da die Anforderungen nicht klar definiert waren und die Codeabhängigkeiten noch nicht vollständig identifiziert wurden, war es schwierig, den vorläufigen Zeitplan zu kommunizieren.

# 2) Für Entwickler

  • Fehlen klarer Anforderungen und Geschäftsregeln.
  • Bereinigen des Codes ohne Verlust seiner Funktionalität.
  • Unbekannte betroffene Bereiche und / oder Code-Abhängigkeiten.
  • Konkrete Schätzungen der Entwicklungszeit können nicht bereitgestellt werden.
  • Neue Unit-Tests müssen erstellt werden.

# 3) Für Tester

  • Das Fehlen klarer Anforderungen und Geschäftsregeln wirkt sich auf die Testplanung aus.
  • Unbekannte betroffene Bereiche wirken sich auf die Testplanung aus, insbesondere für Regressionstests.
  • Konkrete Testschätzungen können nicht bereitgestellt werden.

# 4) Stakeholder

  • Fehlen klar dokumentierter Anforderungen und / oder Benutzerströme + enge Fristen = Höheres Ausfallrisiko.

Der Ansatz des Teams, Risiken zu minimieren und die Herausforderungen zu bewältigen ::

(i) Das Team verfolgte einen kollaborativen Ansatz, um Anforderungen zu erfassen : Projektmanager / Produktanalyst und Tester arbeiteten eng mit den internen Endbenutzern zusammen, um die wichtigsten Funktionen und den Benutzerfluss zu verstehen und zu dokumentieren.

Die Entwickler überprüften auch den Code und fügten dem Anforderungsdokument relevante Informationen hinzu. Dies geschah vor dem Start des Sprints.

(ii) Die alternative Testumgebung wurde erstellt, um die implementierte Änderung zu testen : Nennen wir diese Umgebungen Gamma und Phi. Gamma würde den alten Code haben und Phi würde die neueste überarbeitete gespeicherte Prozedur jederzeit bereitstellen.

Durch die parallele Verwendung von zwei Testumgebungen vor und nach dem Ansatz konnte das Team eingehendere und explorativere Tests durchführen, indem es das Verhalten in diesen beiden Testumgebungen verglich. Dadurch konnten die wahrscheinlichen Fehler identifiziert werden.

Das Team stellte die Anforderungen für eine alternative Testumgebung bereit, die vor dem Startdatum des Sprints bereitgestellt wurde.

(iii) Endbenutzer und Stakeholder, die frühzeitig an Tests beteiligt sind : Alle offensichtlichen Probleme wurden frühzeitig erkannt und gemeldet, sodass das Team mehr Zeit für die Bereitstellung und den Test des erforderlichen Fixes hat.

(iv) Ausstiegskriterien definieren und einhalten: In der ersten Planungsphase wurden Exit-Kriterien definiert - 80% der getesteten Benutzerströme, kein ungelöster kritischer Fehler, Demo und Abmeldung von den Stakeholdern vor der Veröffentlichung.

(v) Festlegen eines vorläufigen Veröffentlichungsdatums: Festlegen eines abgestimmten Veröffentlichungsdatums und Motivieren des Teams, auf einen gemeinsamen Endpunkt hinzuarbeiten. Aufgrund des Projektumfangs wurde vom Team empfohlen, anstelle eines regulären 2-Wochen-Sprints einen 3-wöchigen Sprint durchzuführen, damit das Team genügend Zeit für die Ausführung des Projekts hat.

Fazit

Zusammenfassend ist das Refactoring von Code ein Prozess, um das Design eines Moduls zu bereinigen / zu vereinfachen, ohne dessen Funktionalität zu ändern. Der Refactoring-Prozess kann einfach sein, z. B. das Hinzufügen von Kommentaren, das Hinzufügen korrekter Einrückungen, das Entfernen einer statischen Variablen usw. oder für komplexe Legacy-Systeme kompliziert sein.

Ein bestimmtes Modul oder Code muss möglicherweise aufgrund von Codegerüchen, technischer Verschuldung oder aufgrund eines agilen Softwareentwicklungsansatzes überarbeitet werden.

Für Tester bedeutet das Refactoring von Code ungefähr = eingehende Tests + Regressionstests.

Um alle vorhandenen Benutzerabläufe zu testen, sind eingehende Tests erforderlich, um sicherzustellen, dass alle Funktionen wie zuvor funktionieren. Regressionstests der gesamten Anwendung (oder der betroffenen Bereiche) sind erforderlich, um sicherzustellen, dass durch das Aktualisieren eines Moduls die Funktionalität der anderen Module nicht unbeabsichtigt beeinträchtigt wird.

Test- / QS-Leads können erforderlich sein, um mit dem Rest des Teams zusammenzuarbeiten, einschließlich Entwicklern und Produktanalysten, insbesondere für ältere Projekte. Seien Sie proaktiv bei der Planung des Testansatzes und der Testpläne. Wenn Sie die Anforderung mehrerer Testumgebungen oder neuer Testtools erwarten, senden Sie die Anforderung bitte frühzeitig, um Verzögerungen zu vermeiden, sobald die Testphase beginnt.

Über den Autor: Dieses informative Tutorial wurde von Neha B verfasst. Sie arbeitet derzeit als Qualitätssicherungsmanagerin und ist auf die Leitung und Verwaltung von internen und Offshore-QS-Teams spezialisiert.

Haben Sie an einem herausfordernden Projekt gearbeitet, bei dem Code oder ein Modul / eine Anwendung überarbeitet wurden? Wenn ja, teilen Sie Ihre Erfahrungen im Kommentarbereich mit, von dem unsere Testkollegen lernen können.

Literatur-Empfehlungen

^