av Manoj Chaudhary, CTO og SVP of Engineering
For å sjekke funksjonaliteten, påliteligheten og sikkerheten til deres applikasjonsprogrammeringsgrensesnitt (API), gjennomfører IT-team en rekke forskjellige tester, inkludert funksjons-, styrings-, kaos-, penetrasjons-, ytelses-, stress- og levetidsvurderinger. Nedenfor skisserer vi vanlige utfordringer team møter når de utfører disse testene og gir våre anbefalinger for å håndtere dem.
Utfordring: Komme gjennom det første oppsettet
Å lage, utvikle og få testinfrastruktur i gang kan være en tidkrevende oppgave, og det kan være vanskelig å motivere teamet ditt gjennom hele prosessen.
vår anbefaling
Å forklare hvordan testprosessen lønner seg på lang sikt kan være nøkkelen til å motivere et testteam. Det er også viktig å merke seg hvor kritisk denne fasen er i API-testing generelt. Når du gjør det første oppsettet, tenk nøye gjennom hvordan du vil teste API-en og hva disse testene krever i infrastrukturdesignen din.
Utfordring: Generere og administrere store mengder testdata
APIer med mange parametere krever en betydelig mengde data (og i noen tilfeller data med høy kardinalitet) for effektiv testing. Å opprette, vedlikeholde og sikre at disse dataene er gjenbrukbare kan utgjøre en utfordring for testere.
vår anbefaling
Nøkkelen til å generere og sette opp testdata er å forstå forespørsels- og svarstrukturene og de tilhørende API-kallene. Bruk databehandlingsverktøy som lar deg forstå disse forbindelsene, og deretter maskere, generere og undersette nye data som passer dine testbehov.
Utfordring: Klar forståelse av mål for styringstesting
Kritisk for APIer som er bygget for skyapplikasjoner med flere leietakere, utføres styringstesting for å beskytte infrastrukturen mot overbruk, støyende naboer og angrep. APIer har vanligvis styringsregler for bruken deres (f.eks. lagringspolicyer, hastighetsgrenser og nyttelaststørrelse), men mangel på kunnskap og forståelse knyttet til både API-arkitekturlogikk og disse reglene resulterer ofte i usikkerhet om testmål.
vår anbefaling
Lag veldefinerte og velskrevne styringsregler; bygg verktøy for teamet ditt for å tilpasse dem etter behov for å gjøre testingen enklere og mer effektiv.
Utfordring: Utføre kaostesting effektivt
I 2010 opprettet Netflix utviklings- og driftsteam denne formen for testing da de begynte å flytte tradisjonell infrastruktur til Amazon Web Services (AWS) skyinfrastruktur. Kaostesting, eller kaosteknikk, er en svært disiplinert tilnærming som tester systemets integritet ved proaktivt å simulere og identifisere feil før de fører til uplanlagt nedetid eller en dårlig brukeropplevelse. Prosessen innebærer:
- Tester at et system fungerer i en definert stabil tilstand. Først må testerne identifisere en målbar systemutgang som indikerer normal arbeidsatferd. Å lage infrastrukturen og verktøyene for å definere og måle en stabil tilstand kan være komplisert, avhengig av arkitekturen og omfanget av applikasjonene som er involvert.
- Testing for å fastslå at et systems steady state vil holde. Etter å ha etablert en stabil tilstand, bestemmer testerne om den vil fortsette under kontroll, eksperimentelle og virkelige forhold.
- Testing for minimal innvirkning på brukerne. Testere bryter eller forstyrrer tjenesten for å fastslå negativ innvirkning på brukere.
- Introduserer kaos. Etter å ha konstatert at et system fungerer i en definert steady state, at steady state holder seg oppe og at "eksplosjonsradiusen" er begrenset, kjører testerne sine kaostesteapplikasjoner for å se hvordan systemet oppfører seg under spesielle stressforhold eller omstendigheter (f.eks. serverkrasj, maskinvare som ikke fungerer, eller avbrutt nettverkstilkobling).
vår anbefaling
Bygg kroker i applikasjonen og infrastrukturen din som lar testteamet ditt skape kaos og enkelt få relevante beregninger for eksplosjonsradiusen.
Utfordring: Engasjere det rette teamet for penetrasjonstesting
I penetrasjonstesting vil en tester med begrenset arbeidskunnskap om det spesifikke API angripe det for å vurdere trusselvektoren fra et eksternt perspektiv. Angrep kan målrettes mot hele API-en eller visse funksjoner og prosesser.
vår anbefaling
Et internt team kan utføre innledende penetrasjonstesting, men en tredjeparts penetrasjonstester bør utføre oppfølgingstestingen av dyp penetrasjon.
