👩‍⚖️ 💸 🎾 Zusammenfassung des Berichts „Monolith für Hunderte von Client-Versionen“ (HL2018, Badoo, Vladimir Yants) ㊗️ 🗣️ 👨🏾‍🏫

Fortsetzung einer Reihe von Abstracts mit HL2018. Die Jungs von Badoo (Vladimir Yants vyants und Nikolai Krapivny) haben mir geholfen, dieses Kompendium zu überprüfen, wofür ich ihnen vielmals danke. Ich hoffe, dies wirkt sich positiv auf die Qualität der Botschaft des Berichts aus.

Bild

Merkmale des Entwicklungsprozesses:

Die Verantwortung des Entwicklers endet nicht mit der Veröffentlichung des Backends. Er ist vor der Implementierung auf Plattformen verantwortlich.

Bild

Es gibt manuelle Tests, aber der Client ist zum Zeitpunkt der Veröffentlichung noch nicht bereit und wird mit einer (unvorhersehbaren) Verzögerung freigegeben. Wir wissen oft nicht, wann Kunden mit der Implementierung beginnen werden. Manchmal (nicht oft) werden Funktionen nach langer Zeit ausgeführt. Daher ist das Testen mit den Händen schwierig und nicht alles möglich. Daher sind Autotests erforderlich.

Tests

Unit-Tests

Geschrieben in phpunit.

Testen Sie eine kleine Einheit. Sie gehen nicht zur Datenbank oder zu den Diensten (sie sollten mit nichts interagieren).

Legacy hat und erschwert den Testprozess immer noch.

Sie haben die softMocks-Bibliothek entwickelt - sie enthält alle Hooks, die enthalten / erforderlich sind, und ersetzt sie durch die geänderte.

Sie können alle Methoden beenden: statisch, privat, endgültig.
Die Bibliothek ist in Open Source verfügbar.

Problem: Softmocks entspannen sich und ermöglichen es Ihnen, nicht getesteten Code zu schreiben (und ihn mit Tests abzudecken).

Akzeptierte die Regeln:

Neuer Code sollte einfach zu testen sein
SoftMocks - Extremfall (alter Code / lang / teuer / kompliziert)

Wir sehen uns die Codeüberprüfung für diese Regeln an.

Testqualität

Mutationstests

Nimm den Code
Nehmen Sie die Codeabdeckung
Wir analysieren den Code und wenden Mutationen an (change + => -; true => false usw.)
Für jede Mutation führen wir eine Reihe (Tests) von Tests durch.
Wenn die Tests fehlschlagen, werden ca. Wenn nicht, sind sie nicht effektiv genug. Wir verstehen, ändern / fügen Tests hinzu.

Es gibt vorgefertigte Lösungen (Humbug, Infection), die jedoch nicht passen (nicht kompatibel mit Softmocks, es gibt Probleme mit der Codeabdeckung). Deshalb haben sie ihre eigenen geschrieben.

Mutationstests sind für manuelle Tests noch nicht verfügbar. Verfügbar für die manuelle Ausführung über die Konsole. Jetzt implementieren wir es in der CI-Pipeline, wir bauen den Prozess auf. Das Ergebnis wird auf Habr sein.

Integrationstests

Testen des Betriebs mehrerer Komponenten in Verbindung; Wir überprüfen die Arbeit mit der Basis und / oder den Diensten.

Standardansatz für Datenbanktests (DBUnit):

Erhöhen Sie die Testdatenbank
Fülle es aus
Führen Sie den Test aus
Wir bereinigen die Datenbank

Die Probleme:

Es ist erforderlich, Datentabellen und Dataset zu unterstützen (Relevanz des Inhalts der Datenbank).
Die Vorbereitung der Datenbank dauert einige Zeit
Parallele Starts machen Tests instabil und verursachen Deadlocks

Lösung: DBMocks-Bibliothek (eigene Lösung)

Arbeitsprinzip:

DB-Treibermethoden, die beim setUp-Test mit SoftMocks abgefangen wurden
Aus der Anfrage parsim db + Tabelle
Tmpfs erstellt temporäre Tabellen mit demselben Schema
Alle Abfragen werden nur an temporäre Tabellen gesendet
Bei TearDown werden sie gelöscht.

Die Bibliothek ist klein, aber noch nicht in Open Source geöffnet.

Ergebnisse:

Tests können keine Daten in Originaltabellen beschädigen
Tests sind voneinander isoliert (können parallel ausgeführt werden)
Testen der Abfragekompatibilität mit der MySQL-Version

API-Tests

Imitieren Sie eine Client-Sitzung
Kann Backend-Anfragen senden
Das Backend reagiert fast wie ein echter Kunde

Typischerweise erfordern solche Tests einen autorisierten Benutzer. Es muss vor dem Test erstellt und danach gelöscht werden. Dies bringt zusätzliche Risiken mit sich (Replikation, Hintergrundaufgaben).

Lösung: Wir haben einen Pool von Testbenutzern erstellt. Ich habe gelernt, wie man sie reinigt.

Bild

Testbenutzer befinden sich in derselben Umgebung wie echte Benutzer, da devel! = Prod. Es ist notwendig, Test- und Live-Benutzer zu isolieren.

Zur Isolierung wurde das Flag is_test_user für den Benutzer hinzugefügt. Diese Benutzer sind auch von den Analyse- und A / B-Testergebnissen ausgeschlossen.

Es kann billiger gemacht werden, indem Testbenutzer „in die Antarktis“ geschickt werden, wo niemand sie sehen wird (außer Pinguine).

QA-API

Ein Tool zum Vorbereiten der Umgebung in API-Tests, eine Hintertür im Backend zum schnellen Ändern von Benutzer- / Umgebungseinstellungen.

Gut dokumentierte API-Methoden
Verwalten Sie Daten schnell und einfach.
Entwickler schreiben Backend
Kann nur auf Testbenutzer angewendet werden.

Ermöglicht dem Benutzer das Ändern unveränderlicher Daten (z. B. Registrierungsdatum).

Schutz erforderlich:

Auf Netzwerkebene (nur über das Büronetzwerk verfügbar)
Mit jeder Anfrage wird ein Geheimnis weitergegeben, dessen Gültigkeit überprüft wird
Methoden funktionieren nur mit Testbenutzern.

Es gibt ein BugsBounty-Programm auf HackerOne. Sie zahlen für die gefundenen Schwachstellen. Eine Überhöhung mit der QA-API wurde gefunden, wenn sie verwendet wurde.

Remote Mocks

Moki für das Remote-Backend.

Arbeiten Sie an der Basis von weichen Mocks. Der Test fordert das Backend auf, die Mock-Sitzung zu initialisieren. Nach Erhalt der Anfrage überprüft das Backend die Liste der Mox für die Sitzung und wendet sie mit SoftMocks an.

Testbeispiel:

Bild

API-Tests sind zu bequem. Es ist verlockend, sie anstelle von Unit zu schreiben. API-Tests sind jedoch viel langsamer.

Verabschiedete eine Reihe von Regeln:

Der Zweck der API-Tests besteht darin, das Protokoll und die Integration zu testen
Gültiger komplexer Ablauf prüfen
Kleine Variabilität kann nicht getestet werden.
Bei der Codeüberprüfung testen wir auch die Tests.

UI-Tests

Der Backend-Befehl schreibt nicht.

Die Funktion wird durch Ui-Tests abgedeckt, wenn sie sich stabilisiert.
Wird von Selen für das Web verwendet. Für mobile Kalebasse.

Testlauf

100.000 Unit-Tests. 6.000 Integration, 14.000 API-Tests.
In einem Stream beträgt die Zeit 40 min / 90 min / 10 Stunden.

Made TestCloud - eine Cloud zum Ausführen von Tests.

Bild

Die Verteilung des Tests zwischen Threads:

Sie können gleichermaßen (schlecht, alle Tests sind unterschiedlich, es stellt sich in Zeitteilen als ungleich heraus)
Führen Sie mehrere Threads aus und führen Sie Phpunit-Tests nacheinander durch (Initialisierungsaufwand. Lang!)

Lösung:

Sammlung von Statistiken zur Laufzeit.
Layout der Tests, sodass der Block nicht länger als 30 Sekunden läuft

Das Problem mit API-Tests ist eine lange Zeit, viele Ressourcen und erlauben nicht, dass andere ausgeführt werden.

Zur Lösung haben wir die Wolke in zwei Teile geteilt:

Führt nur schnelle Tests aus.
Führt beide Arten von Tests aus.

Das Ergebnis ist eine Beschleunigung der Zeit auf:

Einheit - 1 min
Integration - 5 min
API - 15 Minuten.

Codeabdeckungslauf

Welche Tests sind durchzuführen? Zeigt die Codeabdeckung an.

Wir bekommen Zweigdifferenz
Erstellen Sie eine Liste der geänderten Dateien
Holen Sie sich eine Liste der Tests für diese Dateien.
Wir führen die Suite nur mit diesen Tests aus.

Die Abdeckung für die Hauptniederlassung wird einmal täglich in der Nacht gebildet. Die Ergebnisse (diff) werden der Datenbank hinzugefügt.

Vorteile:

Wir führen weniger Tests durch: weniger Hardwarelast und schnelleres Testfeedback
Sie können Tests für Patches ausführen. Auf diese Weise können Sie den Hotfix schnell einführen. Bei Patches ist die Geschwindigkeit am wichtigsten.

Nachteile:

Backend-Veröffentlichung 2 mal am Tag. Nach dem Mittagessen ist die Berichterstattung weniger relevant (aber wenn wir einen Beat ausrollen, fahren wir immer eine komplette Suite).
API-Tests erzeugen eine umfassende Abdeckung. Für sie bringt dieser Ansatz nicht viel Einsparungen.

Wenn der Entwickler die Codeabdeckung sofort sehen muss, dh ein Tool, das in der Konsole gestartet werden kann und sofort eine neue Metrik für die Abdeckung einer bestimmten Datei / Komponente erhält.
Es wird als schwierig angesehen: Die Daten auf dem Coverege-Master werden erfasst, alle geänderten Tests werden hinzugefügt, es stellt sich heraus, dass es sich um eine kleine Suite handelt, für die die Abdeckung bereits berücksichtigt wird.