A shift-left tesztelés megismerése

Befejezett

Az alkalmazás-életciklus-felügyelet tesztelése elengedhetetlen a kódminőség maximalizálásához, valamint a szoftverek üzembe helyezésével és frissítésével kapcsolatos működési kockázatok minimalizálásához. Ebben a kontextusban a shift-left kifejezés azt az elképzelést közvetíti, hogy a fejlesztési fázisban a lehető leghamarabb át kell költöztetni a tesztelési tevékenységeket. A mintaforgatókönyvben a szervezetnek érdemes megfontolnia, hogy ezt a megközelítést beépítse a DevOps-stratégiájába a jelenlegi biztonsági és stabilitási problémák minimalizálása érdekében. Ebben a leckében tekintse át az ilyen módon implementálható különböző típusú teszteket, majd vizsgálja meg azok implementálási módszereit.

A DevOps-teszt alapelveit bemutató ábra.

Milyen teszteknek kell részesítenie a bal oldali műszakos tesztelést?

A szoftverfejlesztés számos teszttípust tartalmaz, de a számunkra különösen fontosak közé tartoznak a következők:

  • Egységtesztek: Ezek a tesztek az alkalmazáskód legkisebb tesztelhető részeire összpontosítanak, például az egyes függvényekre vagy metódusokra. A cél annak megállapítása, hogy az egyes kódegységek sikeresen végrehajthatják-e a kívánt műveletet a kódbázis többi részétől és külső függőségektől elkülönítve. Az ilyen teszteknek teljesen automatizáltnak, gyorsnak (30 másodpercen belül befejezettnek) és teljes kódlefedettségnek kell lenniük (ami lényegében azt jelenti, hogy az összes egységtesztnek együttesen kell tesztelnie a teljes kódbázist). Az egységtesztelés alkalmas a shift-left megközelítésre. Javasoljuk, hogy a fejlesztési ciklus korai szakaszában, lehetőleg a programozási fázis elején alkalmazza az összes kódra.

    A tesztelés és az egységtesztek látását bemutató ábra.

  • Füsttesztek: Ezek a tesztek egy alkalmazás alapvető funkcióinak felmérésére szolgálnak egy tesztkörnyezetben. Bár a tényleges alkalmazást tesztelik (nem az egyedi, izolált összetevőket, mint az egységteszteket), a céljuk annak megállapítása, hogy az alkalmazás összeállítása vagy üzembe helyezése kellően stabil-e ahhoz, hogy alaposabb tesztelést lehessen végezni. Azonban nem ellenőrzik az alkalmazások közötti együttműködést. Az egységtesztekhez hasonlóan ezeket is teljesen automatizáltnak és viszonylag gyorsnak kell lenniük (a felhasználói interakciót a böngészőautomatizálási eszközökkel és a felhasználói felület automatizálási keretrendszereivel lehet szimulálni). A füstteszt kifejezés azt az elképzelést hivatott közvetíteni, hogy a füst egy fontos problémát (tüzet) jelez, amelyet a lehető leghamarabb meg kell oldani. A füsttesztelést a fejlesztési ciklus korai szakaszában is végre kell hajtani, lehetőleg azonnal, amint elérhető a szoftvernek az alapvető funkcióit biztosító verziója. Ez az alkalmazás buildelési és üzembe helyezési fázisára is vonatkozik.

  • Integrációs tesztek: Ezek a tesztek ellenőrzik a különböző alkalmazásösszetevők közötti interakciót. Az egységtesztekkel ellentétben ezek végrehajtása jelentős időt vehet igénybe. Ezeknek a teszteknek a hosszabb időtartamát gyakran használják argumentumként a szoftverfejlesztési életciklus korai szakaszában. Általában olyan helyzetekben érdemes megfontolni az integrációs teszteket, amelyeknél az egység- vagy füsttesztek nem megfelelőek. A javaslat azonban az, hogy rendszeres időközönként ütemezze a végrehajtást. Ez a megközelítés ésszerű kompromisszumot kínál az integrációs problémák észlelésének lehetséges késleltetése és a befejezésükhöz szükséges további várakozási idő között.

  • Elfogadási tesztek: Ezek a tesztek határozzák meg, hogy egy szoftvertermék megfelel-e az üzleti követelményeknek, és készen áll-e a fogyasztóknak történő kézbesítésre. Az elfogadási tesztelés nem alkalmas a bal oldali váltásos stratégiára, de előfordulhat, hogy egyes elemeit már a szoftverfejlesztési életciklus korai szakaszában beépítheti. Például az elfogadási kritériumokat és a felhasználói történeteket, amelyek az elfogadási tesztelés alapvető összetevői, a fejlesztési folyamat korai szakaszában kell bevezetni. Ez elősegíti a fejlesztési csapatok, a terméktulajdonosok és a projekt érdekelt felei közötti együttműködést. Emellett a szoftverfelhasználóknak és a projekt érdekelt feleinek részt kell venniük a korábbi tesztelési fázisokban, hogy megoszthassák visszajelzéseiket. Ez magában foglalhatja az olyan módszerek használatát, mint az alfa- vagy bétatesztelés, a használhatósági tesztelés vagy a korai kiadások a hivatalos elfogadási tesztelés előtt.