af Manoj Chaudhary, CTO og SVP for Engineering
For at kontrollere funktionaliteten, pålideligheden og sikkerheden af deres applikationsprogrammeringsgrænseflader (API'er) udfører it-teams en række forskellige tests, herunder funktions-, styrings-, kaos-, penetration-, ydeevne-, stress- og levetidsvurderinger. Nedenfor skitserer vi almindelige udfordringer, teams står over for i forbindelse med udførelse af disse tests og giver vores anbefalinger til at løse dem.
Udfordring: At komme igennem den indledende opsætning
At skabe, udvikle og få testinfrastruktur op at køre kan være en tidskrævende indsats, og det kan være svært at motivere dit team gennem hele processen.
vores anbefaling
At forklare, hvordan testprocessen betaler sig på lang sigt, kan være nøglen til at motivere et testhold. Det er også vigtigt at bemærke, hvor kritisk denne fase er i API-test generelt. Når du laver den indledende opsætning, skal du tænke grundigt over, hvordan du vil teste API'en, og hvad disse test kræver i dit infrastrukturdesign.
Udfordring: Generering og håndtering af store mængder testdata
API'er med mange parametre kræver en betydelig mængde data (og i nogle tilfælde data med høj kardinalitet) for effektiv test. At oprette, vedligeholde og sikre, at disse data kan genbruges, kan udgøre en udfordring for testere.
vores anbefaling
Nøglen til at generere og opsætte testdata er at forstå anmodnings- og svarstrukturerne og de tilhørende API-kald. Brug datastyringsværktøjer, der giver dig mulighed for at forstå disse forbindelser, og derefter maskere, generere og undersætte nye data, der passer til dine testbehov.
Udfordring: Klar forståelse af målene for styringstestning
Kritisk for API'er, der er bygget til multi-tenant cloud-applikationer, udføres styringstest for at hjælpe med at beskytte infrastrukturen mod overforbrug, støjende naboer og angreb. API'er har typisk styringsregler for deres brug (f.eks. lagerpolitikker, hastighedsgrænser og nyttelaststørrelse), men et fravær af viden og forståelse relateret til både API-arkitekturlogik og disse regler resulterer ofte i usikkerhed om testmål.
vores anbefaling
Opret veldefinerede og velskrevne styringsregler; byg hjælpeprogrammer til dit team for at tilpasse dem efter behov for at gøre test nemmere og mere effektivt.
Udfordring: Udførelse af kaostest effektivt
I 2010 skabte Netflix udviklings- og driftsteam denne form for test, da de begyndte at flytte traditionel infrastruktur til Amazon Web Services (AWS) cloud-infrastruktur. Kaostest, eller kaosteknik, er en meget disciplineret tilgang, der tester systemets integritet ved proaktivt at simulere og identificere fejl, før de fører til uplanlagt nedetid eller en dårlig brugeroplevelse. Processen involverer:
- Test af, at et system fungerer i en defineret steady state. Først skal testerne identificere et målbart systemoutput, der indikerer normal arbejdsadfærd. At skabe infrastrukturen og værktøjerne til at definere og måle en steady state kan være kompleks, afhængigt af arkitekturen og omfanget af de involverede applikationer.
- Test for at bestemme, om et systems steady state vil holde. Efter at have etableret en steady state, afgør testerne, om det vil fortsætte under kontrol, eksperimentelle og virkelige forhold.
- Test for minimal indvirkning på brugerne. Testere bryder eller forstyrrer tjenesten for at fastslå negativ indvirkning på brugerne.
- Indførelse af kaos. Efter at have fastslået, at et system fungerer i en defineret stabil tilstand, at den stabile tilstand holder op, og at "sprængningsradius" er indeholdt, kører testere deres kaostestapplikationer for at se, hvordan systemet opfører sig under særlige stressforhold eller omstændigheder (f.eks. servernedbrud, defekt hardware eller afbrudte netværksforbindelser).
vores anbefaling
Byg kroge i din applikation og infrastruktur, der giver dit testhold mulighed for at skabe kaos og nemt få relevante målinger for eksplosionsradius.
Udfordring: Engagere det rigtige hold til penetrationstest
Ved penetrationstest vil en tester med begrænset viden om den specifikke API angribe den for at vurdere trusselsvektoren fra et eksternt perspektiv. Angreb kan målrettes mod hele API'en eller visse funktioner og processer.
vores anbefaling
Et internt team kan udføre indledende penetrationstest, men en tredjeparts penetrationstester bør udføre opfølgende dyb penetrationstest.
