[JAVA] Ich habe die Testautomatisierung untersucht

Ich habe die Testautomatisierung untersucht

Einführung

――Ich habe noch nie zuvor Testcode oder Testautomatisierung durchgeführt, und es ist etwas mehr als ein halbes Jahr her, seit ich in die aktuelle Firma eingetreten bin und angefangen habe, Testcode zu schreiben.

• Sprache ist hauptsächlich PHP, Javascript (Knoten) ――Vor dem Schreiben des Testcodes Um den Grund und die Motivation für das Schreiben des Testcodes zu erörtern, werde ich den Testcode und den Test zusammenfassen, einschließlich des Gefühls, das ich gerade schreibe.

Geschichte bis zur Testautomatisierung

• 1960er Jahre

• Die Methode der Testautomatisierung wurde bereits 1962 in Betracht gezogen.

• Software-Krise ――Die auf der 1. NATO-Konferenz für Softwaretechnik Ende der 1960er Jahre behauptete Geschichte besagt, dass sich die Komplexität der Softwareentwicklung aufgrund der höheren Leistung von Computern beschleunigen wird. ――Um dieser Zeit haben Diskussionen über Methoden in der Softwareentwicklung wie strukturierte Programmierung und automatisierte Tests als Reaktion auf die immer komplexer werdende Softwareentwicklung begonnen, aktiver zu werden.

• 1970er Jahre

• Software-Testtechnik 1976

• Mit zunehmender Komplexität von Software wurden Testmethoden zur Verbesserung der Softwarequalität untersucht und etabliert. --Objekt orientierte Programmierung

• Um mit der Komplexität von Software fertig zu werden, hat die objektorientierte Denkweise, dass Programmierung mit einem tatsächlichen Objekt (Ding) verglichen wird, begonnen, populär zu werden.

• 1980er Jahre

• Human Moon Mythos (keine Silberkugel) 1988

• Ein berühmtes Papier über Softwareentwicklung. In der Softwareentwicklung hinterließ er den berühmten Satz "Es gibt keine Silberkugel", was bedeutet, dass es für kein Ereignis eine Einheitsmethode gibt. Ein anderes berühmtes Wort aus Brooks 'Gesetz ist, dass das Hinzufügen von Personal zu einem Softwareprojekt, das sich verzögert, das Projekt nur noch weiter verzögert.

• 1990er Jahre

• Extreme Programmierung (allgemein bekannt als XP) 1999 Die Methode selbst wurde um 1996 entwickelt

• Ein Buch über Entwicklungsmethoden von Kent Beck, der auch als Entwickler von Small Talk bekannt ist. Es enthält die Hauptideen moderner automatisierter Testideen. (Details werden später beschrieben)

  • Scrum

• Eine der Methoden der agilen Entwicklung. Ich habe das Bild, das ich zuletzt gehört habe. ――Eine Methode zum Erstellen eines Produkts, indem in kurzer Zeit ein Sprint erstellt und mit dem Scrum Master, dem Product Owner und dem Team zusammengearbeitet wird. ――Der Scrum Master hilft Ihnen bei der Einführung von Scram, der Product Owner arbeitet an dem Produkt mit den geschäftlichen Anforderungen und Verantwortlichkeiten und das Team arbeitet zusammen, um die geschäftlichen Anforderungen des Product Owners zu erfüllen.

• Obwohl es in der gleichzeitig mit XP vorgeschlagenen Entwicklungsmethode keine detaillierte Beschreibung der Testautomatisierung gibt, wird die Testautomatisierung grundsätzlich als Methode zur Entwicklung in kurzer Zeit eingeführt.

• 2000er Jahre --Lean Startup ――Streng genommen handelt es sich nicht um eine Softwareentwicklungsmethode, sondern um eine Methode zur Unternehmensgründung, sondern um eine Entwicklungsmethode, die häufig von Start-up-Unternehmen verwendet wird. Eine der agilen Entwicklungsmethoden. Eine Methode zum Erstellen eines minimalen praktischen Produkt-MVP (Minimum Viable Product), Wiederholen von Hypothesen und Überprüfungen und Verbessern des Produkts. Wiederholte Aufgaben und Methoden haben viel mit XP und agilen Methoden gemeinsam.

  • DevOps

• Eine Entwicklungsmethode, bei der das Entwicklungspersonal und das Betriebspersonal in einer Beutelsprache zusammenarbeiten, die Entwicklung und Betrieb kombiniert. Eine Entwicklungsmethode, die Betrieb, Infrastruktur und Entwicklung nahtlos miteinander verbindet. Die Einführung der Testautomatisierung zusammen mit der Infrastrukturautomatisierung wurde befürwortet.

Arten von Softwaretests

• Testtyp. Die folgenden Wörter können als Testphase verwendet werden, hier werden sie jedoch als Testtyp klassifiziert. Je nach Unternehmen gibt es verschiedene Namen.

Gerätetest

• Prüfen Sie, ob die Funktion jedes Moduls erfüllt ist
• Allgemein bekannt als UT (Unit Test)
• Grundsätzlich in einem White-Box-Test durchgeführt

Kombinierter Test

• Verketten und testen Sie jedes Modul
• Allgemein bekannt als IT (Integrationstest)
• Funktionstest Funktionstest ist ähnlich wie hier
• In einigen Fällen werden schrittweise Tests auf externe Verbindungen wie externe APIs durchgeführt.
• Grundsätzlich ein Black-Box-Test, manchmal ein White-Box-Testbild

Umfassender Test

• Ein Test, der alle Bedingungen wie externe API und Browser kombiniert
• Bereiten Sie eine Umgebung vor, die der Produktion entspricht, und führen Sie den Test durch. Hier prüfen wir, ob das Programm wie erforderlich funktioniert --UAT (Benutzerakzeptanztest)
• Grundsätzlich in einem Black-Box-Test durchgeführt

Testperspektive

• Die Gesichtspunkte, die bei der Durchführung von Softwaretests geprüft werden müssen, lassen sich grob in "funktionale Anforderungen" und "nicht funktionale Anforderungen" unterteilen.

Funktionale Anforderungen

• Teile, die den Kundenanforderungen entsprechen --Überprüfen Sie, ob der von Ihnen erstellte Code den vom Client geforderten Funktionen entspricht und ob er ordnungsgemäß funktioniert. ――Der Teil, der durch den Testcode garantiert werden kann, ist im Grunde dieser Teil

Nicht-funktionale Anforderungen

• Andere Teile als Spezifikationen und Funktionen --Informationssicherheit
• Leistung
• Serverleistung --Netzwerk-Design
• Wie man sich von einem Fehler usw. erholt

Testprozess

• Testanalyse
• Testdesign

Code-Story testen

Testcodetyp

Gerätetest

• Einheitentest, allgemein bekannt als UT (Unit Test)
• Ein Test, um zu bestätigen, dass der Code wie vom Entwickler beabsichtigt funktioniert. ≠ Ein Test, der die Geschäftsanforderungen garantiert
• Für jede Methode erstellen. Feinkörnig --Stub und verspotten Sie die Teile, die von anderen Modulen abhängen, und testen Sie sie
• Verdienst
• Durch das Schreiben von Testcode können Entwickler den Funktionsumfang jedes Moduls besser verstehen. ――Die Korngröße ist in Ordnung, und Sie können den Teil, an dem der Fehler aufgetreten ist, detailliert analysieren.
• Der Testcode, der die Funktion der Methode ausdrückt, wird erstellt, und der Entwickler kann den Testcode lesen und die Absicht der Methode später verstehen.
• Fehler
• Da Vollständigkeit erforderlich ist, steigen die Kosten für das Schreiben von Testcode je nach logischem Inhalt.
• Mit eng gekoppeltem Code ist es schwierig, Testcode zu schreiben, und es ist einfach, Code anzufordern, der einfach ist, lose gekoppelte Tests zu schreiben.

Funktionsprüfung

--Funktionstest

• Der Teil, an dem jedes Modul (externe API und DB-Teil) angeschlossen ist, wird ebenfalls getestet. Große Korngröße
• Testen Sie mehrere Module zusammen, einschließlich der Frage, ob das Programm die Anforderungen erfüllt
• Verdienst
• Sie können Fehler finden, die durch die Kombinationsbedingungen jedes Moduls verursacht werden und für sich selbst nicht verständlich sind. --API usw. können bis zur Anforderungsebene bestätigt werden, nicht bis zur Logik des Programms
• Fehler
• Da die Testgranularität groß ist, ist es schwierig zu identifizieren, wo der Fehler aufgetreten ist. ――Da der Testinhalt Geschäftslogik, Anforderungen und IF für die Kommunikation mit der Außenwelt erfordert, ist es erforderlich, den einfachen Codeinhalt zu überprüfen und die Anforderungen zu verstehen, damit der zu verstehende Bereich groß wird.

UI-Test

• Der Test mit Software, auf der aktuelle Browser und Apps wie Selen und Appinum ausgeführt werden, weist die größte Granularität auf.
• Verdienst ――Da alle angeschlossen und getestet werden können, ist der zu bestätigende Bereich groß und die Anforderungen können bestätigt werden. ――Da Sie die Umgebung überprüfen können, die tatsächlich funktioniert, können Sie auch externe Faktoren wie die Abhängigkeit von der Browserumgebung überprüfen.
• Fehler ――Weil der Bestätigungsbereich groß ist, ist komplizierter Code in der Regel groß und die Wartung in der Regel schwierig. ――Da es durch einen Black-Box-Test durchgeführt wird, ist es schwierig zu wissen, wo der Fehler aufgetreten ist.

Projekte, in denen Sie Testcode einführen sollten

• Ein langfristiges Projekt, das die Wartung berücksichtigt
• Projekte mit vielen Änderungen der Spezifikationen und häufigen Änderungen der Personen

Gründe, Testcode zu schreiben

--Um die Testkosten zu senken ――Da der Komponententest den Code umfassend ausführt, denke ich, dass die Kosten des Regressionstests nach dem Schreiben reduziert werden können.

• Da der Code leicht zu testen ist, werden Sie auf lose gekoppelte Programme aufmerksam.
• Weil der Testcode selbst eine Spezifikation für Programmierer wird ――Das Nachdenken über den Testcode vertieft Ihr Verständnis der Anforderungen.

Granularität testen

• Die Bedeutung des Testcodes wird allgemein als wichtig in der Reihenfolge Unit-Test> Funktionstest> UI-Test bezeichnet. ――Es ist wichtig für feinkörnige Tests wie Integrationstests, da Sie die Spezifikationen überprüfen können, die Bedingungen jedoch kompliziert sind, was die Testwartung kompliziert macht. Wenn ein Fehler auftritt, welcher Teil ist die Ursache des Fehlers? Da es schwer zu verstehen ist, die Grundlagen der Erweiterung von Unit-Tests, bei denen die Granularität gering ist und es einfach ist, Tests zu beheben und Fehler zu finden

Die Wirkung des Testcodes

• Reduzieren Sie den Stress des Programmierers
• Das Programm ist eine stressige Aufgabe
• Sie müssen die Spezifikationen verstehen ――Schreiben Sie unter Berücksichtigung verschiedener Aspekte wie abnormales System und normales System ――In erster Linie müssen Sie darüber nachdenken, wie Sie es im Programm ausdrücken können ――Wenn sich die Spezifikationen ändern, müssen Sie sie neu erstellen ...
• Sie müssen über Leistung und Lesbarkeit nachdenken ...
• Einfach zu ändern etc ... ――Der Programmierer muss das Programm mit verschiedenen Überlegungen schreiben. ――Es ist sehr schwierig, richtigen Code auf einmal zu schreiben. Es kann Änderungen in den Spezifikationen geben.
• Ich weiß nicht, wo ein Programm ohne Testcode kaputt geht.
• Testcode schreiben
• → Machen Sie es einfach zu sehen, was beim Refactoring kaputt gegangen ist
• → Reduzieren Sie den Stress des Programmierers

Über die Kosten für Testcode

――Die Kosten für das Schreiben von Testcode betragen die Hälfte der Kosten für die Implementierung, was für diejenigen, die daran gewöhnt sind, schnell ist, und das 1,5- bis 2-fache der Kosten für die Implementierung für diejenigen, die nicht damit vertraut sind. (Persönliches Hautgefühl)

• Wenn Sie Code in Code einführen, der keinen Testcode enthält, sind die Kosten für die Einführung von Testcode häufig hoch, da der Code selbst nicht weiß, dass der Testcode geschrieben ist.
• Für den Testcode fallen auch Wartungskosten an, die sich bei Änderung entsprechend dem Code des Hauptgeräts ändern.
• Einführung der Testcode-Umgebung, Kosten für das Erlernen des Schreibens von Testcode selbst

Extreme Programming XP (eXtreme Programming)

• Entwicklungsmethode als Ersatz für den in den 90er Jahren vorgeschlagenen Wasserfalltyp
• Das Buch wurde 1999 zusammengestellt ――Eine der Ursprünge der aktuellen Entwicklungsmethode namens Agile —— Besteht aus 4 Werten, 5 Grundprinzipien und 19 Best Practices ――Der konventionelle Wasserfall zeichnet sich durch eine Methode aus, bei der die Entwicklung in einem kurzen Zyklus wiederholt und nach und nach verbessert wird, verglichen mit der Methode, mit dem nächsten Prozess fortzufahren, nachdem der vorherige Prozess vollständig abgeschlossen wurde.

TDD(Test Driven Development)

• Testgetriebene Entwicklung
• Vorgeschlagen von Kent Beck als eine der Best Practices von XP
• XP und Testcode ――XP basiert auf der Entwicklung in einem kurzen Zyklus, Anforderungen und Code ändern sich ständig, und Programmierer werden umgestalten, während es schwierig ist, alle zu verstehen. Testcode hilft Ihnen, diesen sich ändernden Code mutig zu optimieren
• Eine Methode namens test-first, bei der Sie zuerst einen "fehlgeschlagenen Test" schreiben, bevor Sie ihn implementieren, und dann mit der Implementierung beginnen.
• BDD und FDD sind die Entwicklungsmethoden für die Entwicklung (ich bin nicht damit vertraut, weil ich es noch nicht getan habe)

Zuerst testen

• Eine der grundlegenden Methoden von TDD, eine Methode zum Schreiben eines Tests vor der Implementierung, zum Festlegen der Schnittstelle des Implementierungsinhalts und zum anschließenden Implementieren, um die Bewegung der Implementierung sicherzustellen und den Testcode gleichzeitig mit der Implementierung zu haben .. Verbessern Sie den Code, indem Sie den Zyklus von "Rot" → "Grün" → "Refactor" für den Code durchlaufen. --Verfahren --Schreibe einen "fehlgeschlagenen Test", der den Methodeninhalt IF und Ausgabe beschreibt (rot) -- Fehlgeschlagener Test Fahren Sie mit der Implementierung fort und machen Sie den Test erfolgreich (grün)
• Ändern Sie den Inhalt des Codes so, dass der abgeschlossene Test nicht fehlschlägt, und fügen Sie nach Bedarf Tests hinzu (Refactor).
• Wenn es eine Codeänderung gibt, schreiben Sie erneut einen "fehlgeschlagenen Test", implementieren Sie den Code gemäß dem Test und durchlaufen Sie den Zyklus.

Testcode-Framework

―― Grundsätzlich gibt es viele xUnit-Serien, einschließlich Materialien. Wenn es keinen bestimmten Grund gibt, ist es besser, die xUnit-Serien jeder Sprache zu verwenden.

• Testrahmen für jede Sprache (Beispiel)
• php
  • PHPUnit
  • behat
• java
  • jUnit
• javascrpt
  • mocha
  • ava
  • jasmine
• Ruby
  • minitest
  • RSpec
• Python --unittest (in Standardfunktionen enthalten)
  • Pytest

CI (Continuous Integration)

• In dem Projekt zur Einführung des Testcodes wird empfohlen, eine Umgebung einzuführen, in der der eingeführte Testcode automatisch ausgeführt wird. Es wurde mit Jenkins usw. erstellt. In jüngster Zeit wurden Dienste entwickelt, die auf CI-Funktionen wie Circle CI und Travis CI spezialisiert sind.

Was Sie brauchen, um Testcode zu schreiben

• Team Zusammenarbeit
• Machen Sie sich die Mühe, den Testcode zu schreiben
• Übliche Umgebung zum Schreiben von Testcode
• Automatisieren Sie die Testausführungsumgebung
• Schreiben Sie einen Beispielcode, damit andere ihn schreiben können, da er zuerst kopiert werden kann
• Detaillierte Anforderungen frühzeitig, um Testcode frühzeitig zu schreiben

Beiseite

Was ich in letzter Zeit mache und darüber nachdenke

• Fügen Sie beim Erstellen von MR / PR der Implementierung den Testcode (mindestens das normale System) der Implementierung zusammen.
• Die Überprüfungsseite kann auch den Implementierungsinhalt mit dem Inhalt des Testcodes überprüfen, und Sie können auch die Bestätigung des Codes testen. --Betrachten Sie die Priorität des Testcodes ――Es ist wichtig, den Test ordnungsgemäß zu erweitern, aber der Fortschritt des Projekts und der Grad der Bestimmung der Anforderungen bestimmen den Test, der zu diesem Zeitpunkt vorteilhaft zu schreiben ist. --Beispiel
• Wenn die Anforderungen flauschig sind
• Schreiben Sie zunächst einen Funktionstest, der die Anforderungen mit losen Überprüfungsinhalten garantiert, und schreiben Sie dann nach Festlegung der Anforderungen einen feinkörnigen Test.
• Wenn die Anforderungen angeklickt werden
• Schreiben aus dem Unit Test (ich möchte schreiben)
• Über Umfang, Name und Bedeutung des Tests ――Ich möchte den Definitionsbereich, der sich auf Komponententests und Funktionstests bezieht, trennen. ――Wenn es sich im reinen Sinne um einen Komponententest handelt, sollten alle Teile, die von anderen Methoden abhängen, verspottet oder abgestumpft werden? Ich denke auch, dass je nach dem Bereich, den Sie überprüfen möchten, wenn Sie ein wenig kombinieren möchten, dies als Integrationstest bezeichnet wird. Wenn ja, denke ich, dass der Bereich, auf den sich das Wort Integrationstest bezieht, zu groß ist. Oder ich möchte Wörter, die den Umfang und die Bedeutung des Mouchi-Tests organisieren können. .. ..

Schließlich

Der Testcode ist keine Silberkugel.

――Der Testcode hat verschiedene Vorteile, ist jedoch keine Wunderwaffe, die in jeder Situation wirksam ist. ――Aber ich denke, dass die mutige Option, Testcode zu schreiben, gute Ergebnisse bringen kann. ――Ich denke, es gibt immer noch einige Missverständnisse und Engpässe aufgrund mangelnder Studien, daher wäre ich dankbar, wenn Sie verschiedene Bearbeitungsanfragen stellen könnten.