Testimine DevOps Worldis

DevOps on tarkvara arendamise ja edastamise arendus- ja toimimistavade ühendamine.

DevOpsi kohaletoimetamise mudelis osalevad testijad hakkavad küsima järgmisi küsimusi:

  • Kuhu testimine DevOpsi mudelisse sobib?
  • Mille poolest erinevad DevOpsis testimine ja kvaliteedikontroll kui Agile ja juga mudelites?
  • Milliseid täiendavaid oskusi peaksin QAna teadma?

Selles postituses käsitletakse tööriistu, strateegiaid ja tavasid, mida peame rakendama DevOpsi maailmas tõhusaks testimiseks, hõlmates automatiseerimist ja pidevat testimist DevOpsis.




QA ja testimine DevOpsis

Kuidas on testimine arenenud kosest kiireks kuni DevOpsini?

Juga mudel

Testimise ja kvaliteedi tagamise tavades on juga, Agile ja nüüd DevOps, aegadest märkimisväärselt nihkunud. Koske mudelis nähti testimist tarkvaraarenduse elutsükli etapina. Testijad ja testimisvajadused olid väga vaigistatud seal, kus testijad kuulusid varem testimisrühma ja sageli eraldati arendustiimist.


Testijatele kuulus testimisstrateegia ja neid peeti kvaliteedi väravavahtidena. Testimine oli suures osas käsitsi ja seda tehti pärast tarkvara täielikku väljatöötamist ja vahetult enne tootmisse laskmist.

Samamoodi võttis tarkvara tarnimine kaua aega. Eraldi operatiivmeeskond vastutas tarkvara tootmisse viimise eest, mis parimal juhul toimus iga paari kuu tagant. Ops-meeskonna ja Dev-meeskonna suhtlus / koostöö puudus või oli madal.

Vilgas mudel

Agile mudel tekitas nihke nii arendus- ja testimisruumis kui ka vabastamissageduses. Tarkvara töötati välja iteratiivselt ja järk-järgult. Scrum, mis on Agile'i kohaletoimetamise mudeli metoodika, sai kiiresti väga populaarseks.

Arendustegevus jaotati lühikeste korduste reaks, mis tavaliselt kestis 2–4 nädalat. Iga iteratsioon looks potentsiaalselt vahetatava tarkvara, lisades uusi või täiustades olemasolevaid funktsioone.


Testijatest sai osa arendusmeeskonnast ja testimisest sai paralleelne tegevus tarkvaraarendusega, mitte faas SDLC lõpus. Testimistegevusest sai ühine vastutus ja kvaliteet kuulus arendusmeeskonnale.

Agile mudel sulatas arendus- ja testimispraktikad ning sillutas teed tarkvara kiiremaks edastamiseks, kuid tegeliku juurutamise tootmisse tegi siiski eraldi TechOpsi meeskond.

Kuigi TechOpsi meeskonnal oleks teadmisi serveritest, võrkudest ja juurutamisest, ei teadnud nad tavaliselt iga versiooni üksikasju. Tagasiside arendustiimile oli aeglane. Kui versioonis oli viga, kulub arendusmeeskonnal sellest probleemist teadasaamiseks tavaliselt mõni tund.

DevOpsi mudel

DevOps viib Agile mudeli sammu võrra kaugemale, viies väljalaske- ja juurutamistegevused lähemale arendus- ja testimistegevustele. See tähendab, et vilgas meeskond vastutab ise loodud tarkvara väljatöötamise, testimise ja väljaandmise eest.




DevOpsi testimisstrateegia

DevOpsis testimine hõlmab kogu tarkvaraarenduse ja tarnimise elutsüklit. Testijad ei keskendu enam ainult funktsionaalsele testimisele ja funktsioonide kontrollimisele.

Testijatena peaksime olema kaasatud ka operatsioonide testimisse, jõudluskontrolli, elementaarsesse turvatestimisse ning suutma jälgida ja analüüsida tootmisandmeid ja logisid.

Dan Ashbyl on suurepärane postitus DevOpsis testimise kohta, mida ta kirjeldab

Näete, miks inimesed näevad vaeva, et mõista, kuhu sobib testimine mudelis, milles seda üldse ei mainita. Minu jaoks sobib testimine selle mudeli igas punktis.


Tõepoolest, testimine võib ja peaks toimuma DevOpsi mudeli igas etapis. Aastal Agile Test Strategy postitus kirjeldasime, kuidas testimine sobib Agile mudelisse.

DevOpsi testimisstrateegia saab seda laiendada, lisades järgmised jaotised:

Testimisautomaatika ja pidev testimine DevOpsis

Tööriistade ja tehnoloogiate valik muutub DevOpsi mudelis üha olulisemaks. Tööriistade valik võimaldab organisatsioonil pakkuda rakendusi ja teenuseid suure kiirusega.


DevOpsis on rohkem rõhku pandud automatiseeritud testimisele, kuna soovime luua kultuuri, kus saaksime koodi kiiresti ja enesekindlalt süsteemist alla suruda.

Lisaks automatiseeritud funktsionaalsetele testidele peaks meil tarnetorustikus olema ka toimivuskatsete komplekt ning turvalisuse / vastupidavuse testid.

Ütlematagi selge, et enne ülaltoodud automatiseeritud testide rakendamist ehitab ennekõike pideva integreerimise tööriista, näiteks Jenkins, automatiseeritud ehitamise ja tarnimise torujuhtme.

Testimine tootmises

Tootmises testimine ei tähenda tingimata teie funktsionaalsuse / jõudluse testimise skriptide käivitamist reaalajas töötava süsteemi vastu, kus kasutajad rakendust kasutavad.

Alustuseks võime analüüsida A / B või mitmemõõtmeliste testide suundumusi. Samuti võime jälgida servereid igasuguse kummalise käitumise suhtes, näiteks mälulekked, protsessori kõrge kasutus jne.



DevOpsi mõju testimisele

Kuidas see kõik muutis testijate ja testimise rolli DevOpsis?

Testijatel on nüüd eeldatavasti vähemalt järgmised teadmised ja oskused, et nad saaksid testimistegevusi tõhusalt läbi viia

  • Põhilised teadmised võrgustike loomisest
  • Unixi / Shelli põhiskriptimine, nt. bash, python
  • Pidev integreerimine / pidev kohaletoimetamine nt. Jenkins,
  • Jõudluskontrolli tööriistad nagu JMeter või Gatling
  • Operatsioonide ja vastupidavuse testimiseks valmis
  • Teadmised konteineritest, Docker, Kubernetes
  • Järelevalvetööriistade, näiteks Splunk, pärimine
  • Pilveteenused, nt. AWS, Azure