Utforsk skift-høyre-testing
Som forklart tidligere i kurset, er testing i programmets livssyklusbehandling avgjørende for å maksimere kodekvaliteten og minimere driftsrisiko forbundet med distribusjon og oppdatering av programvare. Dette er grunnen til å bruke skift-venstre tilnærming, som introduserer testaktiviteter så tidlig som mulig i utviklingsfasen. Det er imidlertid visse aspekter ved testing, som ikke er effektive når de utføres på denne måten. I stedet, for å fullt ut tjene sin hensikt, må de utføres i produksjonsmiljøet. Dette kalles shift-right tilnærming. Organisasjonen i vårt eksempelscenario må bruke dette for å kunne vurdere påliteligheten til systemene i kombinasjon med feilinjeksjon. I denne enheten kan du undersøke dette og andre kriterier der skift-høyre-testing er berettiget.
Hva er årsakene til skift-høyre-testing?
Selv om skift-venstre-testingen er ideell for enhets- og røyktesting, utføres den under forhold som vanligvis avviker betydelig fra de som gjelder for tiltenkte leveringsmål. Selv kvalitetssikring og oppsamlingsmiljøer gjenspeiler sjelden kompleksiteten til sine produksjonskolleger fullt ut. Effektivt er den beste måten å undersøke virkemåten til en arbeidsbelastning etter distribusjonen på, å teste den på det tidspunktet.
Testing i produksjon gir følgende fordeler:
- Gjenspeiler de faktiske arbeidsbetingelsene, inkludert ekstra belastning knyttet til håndtering av sluttbrukerforespørsler.
- Tar hensyn til faktorer, som ville være vanskelig å simulere, for eksempel tilkobling til eksterne systemer.
- Gjenspeiler endringer i arbeidsbelastningsbehov over tid.
Hva er vanlige testscenarioer for skift-høyre?
Selv om testtilnærmingen for skift-høyre kan rettferdiggjøres i mange scenarier, er det få der det er egnet. Disse scenariene omfatter:
Microservices-distribusjoner: mikrotjenestearkitekturen består vanligvis av et stort antall uavhengig utviklede komponenter. Et stort antall kombinasjoner av disse tjenestene kan rettferdiggjøre skift-høyre-testingen for å fokusere på scenarioene som er mest relevante i det faktiske produksjonsmiljøet (i henhold til deres virkelige bruk).
Evaluering av virkningen av nettverksbåndbredde og ventetidsforhold: Nettverksforhold har en tendens til å være utfordrende å simulere, så hvis ytelsen til en arbeidsbelastning er svært ventetid eller båndbreddeavhengig, kan det hende at skift-høyre-testingen er det mest passende alternativet.
testing av brukergodkjenning: Tilbakemeldinger fra faktiske brukere kan være avgjørende for å validere arbeidsbelastningens ytelse og brukervennlighet.
Valideringsprosedyrer i redundante konfigurasjoner: feilinjeksjon og nødgjenopprettingstesting er ment å vurdere robustheten til produksjonsarbeidsbelastninger. Feilinjeksjon innebærer med vilje å innføre feil i individuelle komponenter i en arbeidsbelastning under utførelsen for å identifisere eventuelle svakheter og redusere dem, noe som øker den generelle påliteligheten.
Notat
Chaos engineering er et annet konsept innen DevOps pålitelighetstesting. Som med feilinjeksjon innebærer det å simulere feil ( i dette tilfellet å skape et kontrollert kaos i systemet som testes). Omfanget er imidlertid vanligvis bredere, rettet mot hele systemet, i stedet for bare individuelle komponenter, og testscenarioene har en tendens til å være mer omfattende. Effektivt er kaosteknikk vanligvis begrenset til kanarifugler miljøer som har svært begrenset eller ingen produksjonspåvirkning.
Notat
Du kan bruke Azure Chaos Studio til å implementere kaosteknikkeksperimenter som retter seg mot løsninger som driftes i Microsoft Azure. Du vil gå gjennom et eksempel på slike eksperimenter i laboratoriet i denne modulen.