Testavimas „DevOps World“
„DevOps“ yra programinės įrangos kūrimo ir pristatymo praktikos kūrimo ir operacijų sujungimas.
Testuotojai, dalyvaujantys „DevOps“ pristatymo modelyje, pradeda užduoti tokius klausimus:
- Kur testavimas tinka „DevOps“ modelyje?
- Kuo testavimas ir kokybės užtikrinimas „DevOps“ skiriasi nuo testavimo „Agile“ ir krioklio modeliuose?
- Kokius papildomus įgūdžius, kaip QA, manau žinoti?
Šiame įraše aptariami įrankiai, strategijos ir praktikos, kurias turime įdiegti, kad galėtume efektyviai išbandyti „DevOps“ pasaulyje, apimančią automatizavimą ir nuolatinį testavimą „DevOps“.
Kokybė ir testavimas „DevOps“
Kaip testavimas iš krioklio virto judriu į „DevOps“?
Krioklio modelis
Testavimo ir kokybės užtikrinimo praktikoje pastebimas didelis pokytis nuo krioklio, „Agile“ ir dabar „DevOps“ dienų. Krioklio modelyje bandymai buvo vertinami kaip programinės įrangos kūrimo gyvavimo ciklo etapas. Testuotojai ir bandymai buvo labai nutildyti ten, kur testuotojai anksčiau buvo testavimo grupės dalis ir dažnai atskirti nuo kūrėjų komandos.
Testuotojai priklausė testavimo strategija ir buvo vertinami kaip kokybės vartai. Testavimas dažniausiai vyko rankiniu būdu ir buvo naudojamas visiškai sukūrus programinę įrangą ir prieš pat pradedant gaminti.
Panašiai programinės įrangos pristatymas užtruko ilgai. Atskira operacijų komanda buvo atsakinga už programinės įrangos išleidimą į gamybą, o tai geriausiu atveju įvyko kas kelis mėnesius. Nebuvo arba buvo mažai bendraujant / bendradarbiaujant „Ops“ komandai ir „Dev“ komandai.
Vikrus modelis
Vikrus modelis sukūrė pokyčių kūrimo ir bandymo erdvėje, taip pat išleidimo dažnyje. Programinė įranga buvo kuriama kartotinai ir palaipsniui. „Scrum“, kuri yra „Agile“ pristatymo modelio metodika, greitai tapo labai populiari.
Plėtros pastangos buvo suskirstytos į trumpų pakartojimų seriją, paprastai trunkančią 2–4 savaites. Kiekviena iteracija sukurtų potencialiai perduodamą programinę įrangą, pridedant naujų ar patobulinant esamas funkcijas.
Testuotojai tapo kūrėjų komandos dalimi, o testavimas tapo lygiagrečia programinės įrangos kūrimo veikla, o ne etapu SDLC pabaigoje. Testavimo veikla tapo bendra atsakomybe, o kokybė priklausė kūrėjų komandai.
„Agile“ modelis sujungė kūrimo ir testavimo praktiką ir atvėrė kelią greitesniam programinės įrangos pristatymui, tačiau faktinį diegimą gamybai vis tiek atliko atskira „TechOps“ komanda.
Nors „TechOps“ komanda turėtų žinių apie serverius, tinklus ir diegimą, jie paprastai nežinojo kiekvieno leidimo detalių. Atsiliepimai kūrėjų komandai buvo lėti. Jei leidime buvo klaida, tai užtruko kelias valandas, kol kūrėjų komanda sužinojo apie šią problemą.
„DevOps“ modelis
„DevOps“ žengia „Agile“ modelį dar labiau, priartindama leidimo ir diegimo veiklą prie kūrimo ir bandymo. Tai reiškia, kad judri komanda pati yra atsakinga už savo sukurtos programinės įrangos kūrimą, testavimą ir išleidimą.
„DevOps“ testavimo strategija
„DevOps“ bandymai apima visą programinės įrangos kūrimo ir pristatymo gyvavimo ciklą. Testuotojai daugiau dėmesio nesiekia tik funkciniams bandymams ir funkcijų patikrinimui.
Kaip bandytojai, mes taip pat turėtume dalyvauti atliekant operacijų testavimą, našumo testavimą, pagrindinius saugumo testus, taip pat galėdami stebėti ir analizuoti gamybos duomenis ir žurnalus.
Danas Ashby turi puikus postas apie testavimą „DevOps“, kuriame jis aprašo
Galite suprasti, kodėl žmonės stengiasi suprasti, kur bandymai tinka modeliui, kuriame jo visai neminima. Man bandymai tinka kiekviename šio modelio taške.
Iš tiesų testavimas gali ir turėtų vykti kiekviename „DevOps“ modelio etape. Viduje konors „Agile Test Strategy“ pranešimas , aprašėme, kaip testavimas tinka „Agile“ modeliui.
„DevOps“ testavimo strategija gali išplėsti tai pridėdama šiuos skyrius:
Testavimo automatika ir nuolatinis testavimas „DevOps“
Priemonių ir technologijų pasirinkimas „DevOps“ modelyje tampa toks svarbus. Pasirinkus įrankius organizacija gali teikti programas ir paslaugas dideliu greičiu.
„DevOps“ yra labiau akcentuojamas automatizuotas testavimas, nes mes norime sukurti kultūrą, kurioje mes galime greitai ir užtikrintai nuspausti kodą sistemose.
Be automatinių funkcinių bandymų, pristatymo procese taip pat turėtume turėti našumo testų rinkinį, taip pat saugumo / atsparumo testus.
Nereikia nė sakyti, kad prieš įgyvendindamas bet kurį iš aukščiau nurodytų automatizuotų bandymų, pirmiausia stato automatinį statybos ir pristatymo vamzdyną nuolatinės integracijos įrankyje, pavyzdžiui, „Jenkins“.
Testavimas gamyboje
Testavimas gamyboje nebūtinai reiškia, kad jūsų funkciniai / našumo testavimo scenarijai vykdomi naudojant veikiančią sistemą, kurioje vartotojai naudojasi programa.
Pradėti galime analizuodami A / B arba daugianarių testų tendencijas. Mes taip pat galime stebėti serverius dėl bet kokio keisto elgesio, pvz., Atminties nutekėjimo, didelio procesoriaus naudojimo ir kt.
„DevOps“ poveikis testavimui
Kaip visa tai pakeitė testuotojų ir testavimo vaidmenį „DevOps“?
Tikimasi, kad testuotojai dabar turės bent šias žinias ir įgūdžius, kad galėtų efektyviai vykdyti testavimo veiklą
- Pagrindinės tinklų žinios
- Pagrindiniai „Unix“ / „Shell“ scenarijai, pvz. bash, pitonas
- Nuolatinė integracija / nuolatinis pristatymas, pvz. Jenkins,
- Našumo tikrinimo įrankiai, tokie kaip „JMeter“ ar „Gatling“
- Paruošta operacijoms ir atsparumo testavimui
- Žinios apie konteinerius, „Docker“, „Kubernetes“
- Užklausos stebėjimo įrankiai, pvz., „Splunk“
- Debesų paslaugos, pvz. AWS, „Azure“
