CI / CD-Muster und Anti-Muster. Teil 2

Guten Tag. Heute teilen wir Ihnen die Übersetzung des zweiten Teils des Artikels „CI / CD-Muster und Anti-Muster“ mit , der dem Start eines neuen Streams im Kurs „DevOps Practices and Tools“ gewidmet ist . Der erste Teil dieses Artikels kann hier gelesen werden .

1.3 Muster und Antimuster beim Testen

1.3.1 Testautomatisierung

• Muster: Automatisieren Sie die Softwarevalidierung und -validierung, indem Sie Testeinheiten, Komponenten, Kapazität, Funktionalität und Bereitstellung einbeziehen.
• Anti-Patterns: Manuelles Testen von Einheiten, Komponenten, Bereitstellung usw.
• Unit-Automatisierung von Tests ohne Abhängigkeiten.
• Komponentenautomatisierung von Tests mit Abhängigkeiten von anderen Komponenten, Datenbanken und Dateisystemen.
• Bereitstellung - Automatisieren Sie Tests, um die erfolgreiche Bereitstellung und Konfiguration zu überprüfen. Dies wird manchmal als "Rauch" -Test bezeichnet.
• Funktionale Automatisierung von Tests zur Überprüfung des Verhaltens von Software aus Sicht des Benutzers.
• Kapazität - Automatisierung von Last- und Leistungstests unter betriebsnahen Bedingungen.

1.3.2 Isolierung von Testdaten

• Muster: Verwenden Sie Transaktionen für datenbankabhängige Tests (z. B. Komponententests) und setzen Sie die Transaktionen nach Abschluss zurück. Verwenden Sie eine kleine Teilmenge von Daten, um das Verhalten effektiv zu testen.
• Anti-Patterns: Verwenden einer Kopie der Produktionsdaten für Commit Stage-Tests. Ausführen von Tests in einer gemeinsamen Datenbank.

1.3.3 Parallele Tests

• Muster: Führen Sie parallel mehrere Tests auf Hardwareinstanzen durch, um den Zeitaufwand zu verringern.
• Anti-Patterns: Ausführen von Tests auf einem einzelnen Computer oder einer einzelnen Instanz. Ausführen abhängiger Tests, die nicht parallel ausgeführt werden können.

1.3.4 Systemstabilität

• Muster: Verwenden Sie Stubs, um externe Systeme zu simulieren und die Komplexität der Bereitstellung zu verringern.
• Anti-Patterns: Manuelle Installation und Konfiguration von voneinander abhängigen Systemen für die Erstellung und Bereitstellung von Commit Stage.

1.3.5 End-to-End-Tests gelten als schädlich

Continuous Delivery ist eine Reihe ganzheitlicher Prinzipien und Praktiken, die darauf abzielen, die Markteinführungszeit zu verkürzen. Es basiert auf schnellem und zuverlässigem Feedback dank Tests. Für die kontinuierliche Bereitstellung sind Änderungen an Code, Konfiguration, Daten oder Infrastruktur erforderlich, um eine Reihe automatisierter und explorativer Tests in der Bereitstellungspipeline durchzuführen und die Betriebsbereitschaft zu bewerten. Wenn die Organisation kürzere Fristen erreichen möchte, sollte die Testausführungszeit daher kurz und die Testergebnisse eindeutig sein.

Betrachten Sie beispielsweise den Dienst "Unternehmenszahlungen", bei dem Zahlungen zum Jahresende an den nachfolgenden Zahlungsdienst gesendet werden.

Das Verhalten des Unternehmenszahlungsdienstes kann während der Montagezeit überprüft werden, indem die folgenden Arten von automatischen Tests durchgeführt werden:

• Unit-Tests: Vergleich von Ziel und Implementierung bei der Überprüfung einzelner Codemodule.
• Abnahmetests: Vergleich von Implementierung und Anforderungen bei der Überprüfung des Funktionsteils des Systems.
• End-to-End-Tests: Vergleich von Implementierung und Anforderungen bei der Überprüfung des Funktionsteils des Systems, einschließlich inhaberloser abhängiger Dienste.

Während sich Einheits- und Abnahmetests in Zweck und Umfang unterscheiden, unterscheiden sich Akzeptanz- und End-to-End-Tests nur im Volumen. Abnahmetests umfassen keine inhaberlosen abhängigen Dienste. Daher wird für den Abnahmetest der Reise des Benutzers der Unternehmenszahlungen das Testsystem verwendet , das aus dem Code der neuesten Version der Unternehmenszahlungen und dem Zahlungsstab besteht .

End-to-End-Tests umfassen inhaberlose abhängige Dienste. Daher verwendet der End-to-End-Reisetest des Benutzers der Unternehmenszahlungen das Testsystem, das aus dem neuesten Code der Unternehmenszahlungen und der Arbeitsversion der Zahlungen besteht.

Wenn die Teststrategie mit Continuous Delivery kompatibel ist, sollte sie ein angemessenes Verhältnis von Einheiten-, Akzeptanz- und End-to-End-Tests aufweisen, das den Informationsbedarf und das schnelle, eindeutige Feedback in Einklang bringt. Wenn das Testen keine neuen Informationen liefert, bleiben Fehler unbemerkt. Wenn das Testen jedoch zu lange dauert, ist die Lieferung langsam und der Umsatzverlust steigt.

Das Ende des zweiten Teils.

Nach gängiger Tradition warten wir auf Ihre Kommentare und laden Sie zu einem Tag der offenen Tür ein . Der dritte Teil des Artikels ist hier bereits verfügbar.