Automatisert Robusthetstesting. Erik Arisholm Testify AS

Automatisert Robusthetstesting Erik Arisholm Testify AS

21. september Robusthetstesting Robusthetstesting er testing som avslører sårbarheter i et system overfor uventede (kombinasjoner av) input stressende miljøpåvirkninger Dagens tema: stressende miljøpåvirkninger Test som avslører sårbarheter som oppstår ved høy last, nettverk/serverproblemer, nedetid/oppgradering, opp-/nedskalering på avhengige komponenter, o.l.

21. september Motivasjon Skatteetatens moderniserte systemlandskap Java mikrotjenestebasert arkitektur Skybasert infrastruktur (Openshift PaaS) Stor grad av automatisering (24/7, grønt løp, uberørt av menneskehånd) Alle komponenter skal kunne skaleres opp og ned uten forvarsel, redeployes uten at andre komponenter feiler permanent men i stedet høflig står og venter, rapportere egen helsetilstand til alle som bør vite om det, forstå hva som har feilet tidligere og fikse seg selv

21. september Testutfordringer Forretningstransaksjoner er distribuert på tvers av mange komponenter Atomiske transaksjoner finnes ikke lenger Fingranulert sikkerhet/tilgangskontroll Nye komponenter og tjenester hele tiden! Parallell og asynkron behandling Kompleks feilhåndtering som forårsaker følgefeil for eksempel en retry-kø som er for treg (hoper seg opp, disk full, manglende indeks ) eller for rask (overbelaster andre komponenter) Krav til robusthet er ofte skissert på et generelt nivå

Med andre ord En testers drøm!!

Automatisert test Testnivåer vs robusthetstesting Akseptansetest Verdikjedetest Kontrollpunkt Demo Manuell test Systemintegrasjonstest Systemtest Ende-til-ende-test Grensesnitttester Utforskende tester Black-box tester White-box tester BDD-tester Regresjonstester Enhetintegrasjonstest White-box tester TDD-tester Enhetstest White-box tester TDD-tester

Eks: komponent svarer ikke 21. september finnpart(orgnr) finnpart(orgnr) Tolldek-mottak Feed GET tolldekl.xml tolldekmottak finnpart(orgnr) partsregister finnpart(orgnr) Hvordan kan vi teste (deler av) dette scenariet ved hjelp av enhetstesting?

JUnit + Mockito (TDD) 21. september tolldekl-mottak OPPSETT (when-then) identpart(orgnr) TollBehandling :: finndeklarant identpart(orgnr) identpart(orgnr) identpart(orgnr) Partsregister PartsregisterREST RESTKlient Klient MOCK finnpart partsreg VERIFISER (antall kall + sluttresultat)

21. september Hva har vi (ikke) testet så langt?? Vi har testet at feilhåndteringen er implementert i Tollbehandling, dvs: At metoden TollBehandling::finnDeklarant vil kalle PartsregisterRESTKlient::identPart flere ganger dersom identpart returnerer en feilkode, og helt til den returnerer et gyldig partsnummer Vi har IKKE testet PartsregisterRestKlient eller dens integrasjon mot Partsregisteret Likevel en billig og enkel test av sentral feilhåndtering, som også i beste TDD-ånd spesifiserer at det er metoden finndeklarant som har ansvaret for å prøve igjen!

21. september Black-box isolert systemtest Verifikasjon av hver enkelt komponent gjennom eksterne grensesnitt (GUI, REST) både for funksjonell og ikke-funksjonell testing Isolert testing, slik at vi har kontroll over omgivelsene og ikke trenger å inkludere hele verden i en test Nyttig for å verifisere at en komponent ikke er sårbar overfor mer komplekse feilsituasjoner, og mer helhetlig enn det vi kan teste på enhetstestnivå

21. september Eks. verktøy for isolert robusthetstest Cucumber BDD Største verdien er kanskje at man «limer sammen» krav og tester Robusthetskravene = testscenariene blir lette å forstå. Wiremock et mock-verktøy på «utsiden» (Mockito = på innsiden ) Er en stand-alone HTTP-server som testkomponenten kan kobles til Emulerer (deler av et) API til felleskomponenter slik at komponenten under test er helt uvitende om at den kjører i et isolert testmiljø. Kan også simulere nettverksfeil (delays, responsfeil, komponent svarer ikke, osv) Kalles også tjenestesimulering

Eksempel - systemnivå (Wiremock) Tolldekl Atomhopper Tolldekl mottak 21. september Scenario: Partsregisteret svarer ikke Gitt at 1 tolldeklarasjon er tilgjengelig Når tolldekl_mottak startes Så skal tolldekl_mottak hente tolldeklarasjon Og skal partsregister ikke svare 3 ganger Og skal partsregister returnere OK 3x feil + OK (Wiremock) Partsregister

Eksempel - systemnivå 21. september Saksmappe Oppslag Tolldekl Atomhopper Filarkiv Scenario: Filarkiv er utilgjengelig Når Filarkiv stoppes Og tolldekl_mottak startes Så skal Oppslag motta helsetilstand "PAUSE_RETRY" * at Filarkiv startes Og skal Filarkiv kalles Tolldekl mottak Og skal Kvitteringshopper motta kvittering Og skal tolldeklarasjonen lagres i Skatteinfo Og skal det søkes etter og opprettes ny mappe i Saksmappe Og skal Oppslag motta helsetilstand "FRISK" Kvittering Atomhopper Skatteinfo Partsregister

Oppsummering systemtester Kan teste mer komplekse og realistiske systemnivå scenarier Komponenten kjører som den vil kjøre i PROD (uvitende om at det finnes mocks) testen kontrollerer (mesteparten av) omgivelsene Krever mye oppsett hvis man skal teste lange kallsekvenser og tilstandsavhengige responser. Klarer uansett ikke å spesifisere ALLE mulige (kombinasjoner av) scenarier! Antar at komponenter faktisk oppfører seg slik vi har definert dem i WireMock! Kun en test av seg selv i en emulator, ikke av alle andre Kan altså ikke erstatte systemintegrasjonstest mot reelle komponenter

Ende-til-ende robusthetstesting - inkl. funksjonell verifikasjon Testklient Saksmappe Meldings produsent TollDek Feed Tolldekl mottak Skatteinfo partreg Filarkiv Statens innkrevingssentral

Automatisert Sabotasjetesting Ta opp og ned komponenter og komponentinstanser (skalering) Kontrollerte kall til OS (kill -9, ssh start-app, OpenShift REST API) Chaos Monkey: Monkey-Ops, m.m. Framprovosere nettverkstrøbbel skape mer sammensatte eller uforutsette robusthetstester. sette opp delays, pakketap, TCP timeouts, mm (kontrollert og tilfeldig) Eksempel på verktøy: Saboteur/Crash Lab/ToxiProxy

21. september Oppsummering Modernisert arkitektur krever mye ift test av robusthet Automatisert robusthetstesting på flere testnivåer er helt sentralt TDD enhetstesting inkl. objectmocking: JUnit + Mockito BDD + Isolert systemtesting: Cucumber + Wiremock E2e-testing: kombinere ytelse og robusthetsscenarier med funksjonell verifikasjon på tvers av verdikjeden Saboteur el.l. for å teste oppførsel under nettverksfeil automatisert chaos monkey tankegang i test.

Takk for meg! 21. september