Antwoord.

Achtergrond van de vraag:

Smoke-tests zijn oorspronkelijk ontstaan als een snelle manier om te controleren of de meest basale functionaliteit van een systeem werkt na implementatie of codewijzigingen. De ideologie erachter is: "als er iets kritieks kapot is, heeft het geen zin om gedetailleerde controles uit te voeren". Bij automatisering werden de eerste smoke-tests uitgevoerd als kleine handmatige scripts om de applicatie op te starten, in te loggen en basale acties uit te voeren.

Probleem:

De belangrijkste complicaties bij het automatiseren van smoke-tests zijn de juiste isolatie van een minimale set scenario's, hoge uitvoegsnelheid, minimale afhankelijkheid van onbetrouwbare componenten (zoals externe diensten), evenals visuele en technische ondersteuning voor hun "lichtheid en transparantie". Als dit niet wordt gedaan, wordt smoke-automatisering of te zwaar of geeft het vaak valse positieven en vereist het veel onderhoud.

Oplossing:

Minimaliseer het aantal smoke-tests: het moet alleen de controles bevatten voor de meest kritische "toegangspunten" (zoals autorisatie, opstarten van de hoofdmodule, databasedoeleinden).
Verplaats onbetrouwbare stappen en externe afhankelijkheden buiten de smoke-scenario's of stabiliseer omgevingen met "stubs".
Gebruik tagging (@smoke, Suite('smoke'), enz.) en aparte secties in de CI/CD-pijplijn om smoke-tests altijd als eerste uit te voeren.

Belangrijke kenmerken:

Smoke-scenario's moeten snel worden uitgevoerd en alleen de meest stabiele infrastructuur gebruiken.
Smoke-tests mogen geen UX-details of complexe workflows dekken.
Smoke-automatisering vereist strikte controle over afhankelijkheden en minimale ondersteuningscode.

Misleidende vragen.

Mag je edge-case logica-controle scenario's toevoegen aan de smoke-set?

Nee, de smoke-set is bedoeld om alleen de levensvatbaarheid en beschikbaarheid van het hoofd systeem te controleren; edge-cases zijn hier overbodig, omdat ze de uitvoering vertragen en het onderhoud bemoeilijken.

Moeten smoke-tests meerlaagse foutverwerking en herstelmechanismen implementeren?

Het is vaak een verkeerd idee dat smoke-tests complexe herstelmechanismen nodig hebben. In werkelijkheid, als een smoke-test faalt, is dat een signaal van een kritieke fout die vijzel moet worden opgelost, niet "omzeilt" in de autotest.

Moeten smoke-tests afhangen van gegevens die door andere tests zijn achtergelaten?

Nee, smoke-tests mogen niet afhankelijk zijn van externe testgegevens en al helemaal niet van artefacten van andere tests. Dit is een van de belangrijkste principes van hun betrouwbaarheid.

Typische fouten en antipatterns

Overbelasting van smoke-tests: te veel scenario's, ze worden regressietests.
Code dupliceren tussen smoke- en reguliere autotests.
Impliciete afhankelijkheden: de test gebruikt "vuile" gegevens/artefacten van andere scenario's.

Voorbeeld uit de praktijk

Negatief geval

In de set van smoke-scenario's zijn 30 verschillende controles gedaan, waarvan sommige niet alleen de systeemstart testen, maar ook complexe algoritmes, edge-case voorwaarden. De uitvoering van de smoke-launch duurt nu 30 minuten, af en toe faalt een paar controles door backend-instabiliteit.

Voordelen:

Het is gemakkelijk om knelpunten van het systeem te zien.
Hoge testdekking onmiddellijk na de implementatie.

Nadelen:

De essentie van smoke is verloren gegaan: een "groene" build kan alleen worden verkregen na lange wachttijden en het oplossen van onbelangrijke problemen voor het live zetten van het systeem.
Moeilijk om tests te onderhouden en echte kritieke storingen te onderscheiden.

Positief geval

In de smoke-groep zijn de strikte minimum dingen: inloggen, openen van de hoofdpagina, databaseverzoek, basis API-handshake. Het smoke-framework werkt onafhankelijk van de hoofd testmatrix en altijd als eerste in de CI/CD-pijplijn. Resultaten — in een aparte chat en altijd beschikbaar voor snelle diagnose.