SZOFTVER TESZT AUTOMATIZÁLÁS Eszter Vezdén Budapest, 08 November 2018
Bemutatkozás Vezdén Eszter Okl. villamosmérnök ( 2018 ) Szoftverfejlesztő gyakornok ( 2015 2017 ), B.Braun Medical Kft. Szoftverfejlesztő mérnök ( 2017 - ) Kérdés esetén elérhetőség: balazs.varga@bbraun.com eszter.vezden@bbraun.com dorottya.fekete@bbraun.com B.Braun Medical Ltd. Budapest 2
TARTALOM 1. Miért van szükség teszt automatizálásra? 2. Szoftvertesztelési szabvány 3. Mit és hogyan automatizáljunk? 4. Manuális tesztelés létjogosultsága 5. Code refactoring 6. Test Driven Development, Behaviour DD 7. Statikus / Dinamikus Kód analízis 8. Eszközök az automatizálásban 9. Continuous Integration 10. Tesztelés szimulátorral
Miért van szükség teszt automatizálásra? Gyors visszacsatolás a SW minőségéről Minél később derül ki a hiba, annál drágább a javítása, mert annál több állomáson kell újra végigmenni: User Requirement -> System Requirement -> Component Requirement->Design->Unit test->component test->system test -> UAT UR review-nál a legolcsóbb a javítás, System test-en talált hiba a legdrágább Hamarabb derülnek ki a hibák, jobb lesz a kód minősége Segít a gyors döntéshozatalban és a tervezésben ( hibák alapján priorizálhatunk ) Könnyen ellenőrizhető a tesztek állapota Tesztek frissítése: Féregirtó paradoxon-test Case maintenance, állandó feladat a fejlesztéssel párhuzamosan B.Braun Medical Ltd. Budapest 4
Miért van szükség teszt automatizálásra? ISO/IEC 62304 szabvány ( orvosi SW, SW életciklus) előírja regressziós tesztek elvégzését 5.6.6 Conduct regression tests [ ] When software items are integrated, the MANUFACTURER shall conduct REGRESSION TESTING appropriate to demonstrate that defects have not been introduced into previously integrated software. Minden új módosítás után végre kell hajtani Manuálisan lassú, és erőforrás-igényes! B.Braun Medical Ltd. Budapest 5
ISO/IEC 29119 SZOFTVERTESZTELÉSI SZABVÁNY
ISO/IEC 29119 Szoftvertesztelési szabvány* Orvosi eszközökben nem kötelező alkalmazni, de hasznos dolgokat tartalmaz! A szabvány publikált fejezetei: ISO/IEC 29119-1: Concepts & Definitions (published September 2013) ISO/IEC 29119-2: Test Processes (published September 2013) ISO/IEC 29119-3: Test Documentation (published September 2013) ISO/IEC 29119-4: Test Techniques (published December 2015 ) ISO/IEC 29119-5: Keyword Driven Testing (published November 2016) *A számokat nem kell megjegyezni, csak azt, hogy van ilyen szabvány B.Braun Medical Ltd. Budapest 7
ISO/IEC 29119 Szoftvertesztelési szabvány Test Processes A szabvány 3 szinten írja le a SW teszteléssel kapcsolatos folyamatokat: Szervezeti szint ( policy, stratégia ) Test management ( tervezés, monitorozás, report ) Dinamikus szint Teszt végrehajtás ( teszt implementálás, futtatás, report ) B.Braun Medical Ltd. Budapest 8
ISO/IEC 29119 Szoftvertesztelési szabvány Test Documentation dokumentációs mintákat tartalmaz, amelyek lefedik az összes tesztelési folyamatot a szervezetre szabható sémák pl. Test Plan (Ki-Mit-Mikor-Hol) meg kell határoznunk a SW elemeket, amiket tesztelni akarunk milyen funkciókat tesztelünk ( és miket nem ) elfogadási kritérium szerepkörök stb pl. Test Incident Reporting milyen hibák kerültek elő a tesztelés során ki az érintett mikor, milyen SW verzió tesztelésekor találtuk a hibát B.Braun Medical Ltd. Budapest 9
ISO/IEC 29119 Szoftvertesztelési szabvány Test Techniques tartalmazza az összes elfogadott SW-tesztelési technikát, amit a tesztek tervezése során alkalmazhatunk pl. határérték-ellenőrzés/elemzés: akkor használjuk, ha az adott kódrész bemenetei és kimenetei egy adott tartományon belül mozoghatnak. Az azonosított tartományhatárokon tesztelünk [0,..,24], akkor a 0, 1, 23, 24 lehet érdekes pl. állapotátmenetek: állapotgép esetén a lehetséges állapotátmeneteket bejárjuk pl. ekvivalencia partícionálás: a bemenetek egy halmaza egyforma eredményt ad, elég csak az egyik értékre lefuttatni a tesztet. Szoros kapcsolat a határérték-elemzéssel [0,,24], akkor pl 10 lehet egy teszt adat, vagy 0-24-50 esetén 12 és 30. nincs kimerítő tesztelés! Lehetetlen minden változó minden értékét végigpróbálni, túl sok lehetőség.) Keyword Driven Testing olyan módszer, amely olvashatóbbá (és érthetőbbé) teszi a teszteket a fejlesztés más résztvevői számára is (Managerek stb.), ugyanakkor lehetővé teszi az automatizálást. Pl. BBraun system teszt a kulcsszavak egy-egy lépést/akciót jelölnek a tesztben B.Braun Medical Ltd. Budapest 10
Mit teszteljünk? Tesztelés szintjei - bemenő paraméterek, elvárt értékek Unit ( legkisebb tesztelhető egység ) függvényparaméterek ( bemenet ), függvény visszatérési értékek ( kimenet ) Unit integráció több unit együttes működését vizsgálja egy magasabb működési egységként Alrendszer Alrendszer interface-e határozza meg, gyakorlatban egy sor adat, amit a többi alrendszer felé kommunikál Rendszer HW+SW integráció, pl. felhasználói felület gombja, pumpa forgása, hangjelzés, stb. A tesztekben ezeket a paramétereket kell előállítani / ellenőrizni! B.Braun Medical Ltd. Budapest 11
Unit white box ( kód alapján tesztelünk ) input unit 1 unit 2 helyett mock unit 3 helyett mock output Teszt keretrendszer ( tool / harness ) B.Braun Medical Ltd. Budapest 12
Unit integrációs teszt: white box/black box = grey box ( kód alapján tesztelünk ) input unit 1 unit 2 unit 3 output Teszt keretrendszer ( tool / harness ) B.Braun Medical Ltd. Budapest 13
Rendszer teszt: white box unit 3 interface unit 1 input unit 2 unit 4 unit 9 unit 10 Teszt keretrendszer ( tool / harness ) unit 6 unit 7 unit 5 unit 8 output B.Braun Medical Ltd. Budapest 14
Rendszer teszt: interface black box ( követelmény / specifikáció alapján tesztelek ) input Teszt keretrendszer ( tool / harness ) output B.Braun Medical Ltd. Budapest 15
MIT AUTOMATIZÁLJUNK? TESZTTERVEZÉS
Automatizált tesztelés előnyei / hátrányai Előnyök Az erőforrások átcsoportosíthatók. Több idő jut az exploratory és a User Interface tesztekre. A tesztek nem felejtődnek el, regressziós tesztek bármikor futtathatók. Éjszakára is ütemezhető (pl. performancia teszt, hosszú teszt futtatás) Gyors iteráció a fejlesztésben Hátrányok Nem lesz olcsóbb a tesztelés! Nem a munkát szüntetjük meg, csak a feladatokat csoportosítjuk át Elfelejtjük a teszt automatizációt projektként kezelni ezért valódi mérőszámok, adatok nem érhetőek el A kialakítás miatt költséges és a tapasztalatok szerint a költség nehezen becsülhető. A teszteket ugyanúgy meg kell írni*, csak a végrehajtás automatikus. *generált tesztek is léteznek, ott a teszt modellt kell elkészíteni B.Braun Medical Ltd. Budapest 17
Manuális tesztelés létjogosultsága Miért jó a manuális tesztelés? Az ember miatt fontos (intuíció, rugalmasság) Reaktív tesztelés: reagálni tudunk a gép viselkedésére Exploratory tesztek megkövetelik az emberi jelenlétet A végfelhasználó szempontjai is előkerülnek Teljes System teszt, Acceptance Test A Hardware-rel együtt teszteljük, nem megoldható az automatizálás Felesleges automatizálni A termék életének az elején és a végén Proof-of-concept esetén Prototípusoknál hiányos lehet a specifikáció Konklúzió: Manuális ÉS Automatikus B.Braun Medical Ltd. Budapest 18
Milyen teszteket automatizáljunk? Ki kell dolgoznunk egy stratégiát, hogy a tesztjeink közül mennyi legyen automatizált és mennyi manuális A hosszú teszteket automatizáljuk Meglévő terméket általában csak rendszer teszttel fedünk, új projektnél mehetünk alsóbb tesztelési szintekre is Amíg az automatizált tesztek kialakulnak, a manuális tesztekkel is foglalkozni kell! B.Braun Medical Ltd. Budapest 19
Code Refactoring és tesztelés A SW újra struktúrálása, az eredeti funkció változtatása nélkül. Célja a kód minőségének a javítása ( olvashatóság, karbantarthatóság ) Fenn áll a veszély a regresszióra Addig nem állunk neki a refactornak, amíg nincsenek tesztek az aktuális működésre Kívülről nézve mindennek ugyanúgy kell működnie, ahogy a refactor előtt, de sajnos ez a unit tesztek egy részére nem igaz A kód módosítása után/közben (gyors visszajelzés!) lefuttatjuk a teszteket Alkalmazás: Aktuális fejlesztés még nincs integrálva ( piszkozat ) Szeretnénk, ha a végleges kód letisztult lenne A tesztet is refaktoráljuk! B.Braun Medical Ltd. Budapest 20
Code Refactoring és tesztelés Legacy SW Újrahasznált / elhanyagolt kódok Időigényes a refaktorálás, ezért sokszor csak részleges Nem használunk unit tesztet Magas szintű ( funkcionális ) tesztek Gyorsabban elkészül A teszt kevésbé fog függeni a kód struktúrájától (black box tesztelés) B.Braun Medical Ltd. Budapest 21
HOGYAN AUTOMATIZÁLJUNK? TESZTVÉGREHAJTÁS, TESZTKIÉRTÉKELÉS
Automatizált tesztelés a fejlesztési folyamatban Tesztek végrehajtásához szükséges feltétel Kész kód Sikeres fordítás ( compile / build ) Smoke-teszt: ha elindítom, fut-e egyáltalán a SW Ha ezek nem teljesülnek, nincs értelme a teszteket futtani ( kivévétel: TDD, BDD ) A fejlesztési modell szerinti sorrendben futtatjuk a teszteket (pl. V-modell) Unit teszt Integrációs teszt Subsystem teszt System teszt B.Braun Medical Ltd. Budapest 23
Unit tesztek és TDD Unit tesztet MINDIG a fejlesztő írja (ha írok egy függvénytt és más is használja, akkor anna a függvénynek a minőségért én felelek) White-box tesztelés DE BlackBox test technikákat is alkalmazunk ( ismerjük a kód felépítését ) Fontos a gyors visszacsatolás A tesztet jellemzően a fejlesztő futtatja, de futhatnak szerveren is Azon a nyelven íródik, amin a SW is. Test Driven Development Kis lépésekben fejlesztjük le a funkciót ( 1-2 perces iterációk ) Előbb egy tesztet készítünk el, ami hibát fog jelezni ( még nincs kész a kód ) Ezután éppen annyi kódot fejlesztünk le, ami után sikeres a teszt B.Braun Medical Ltd. Budapest 24
Unit tesztek és TDD Forrás: http://lewandowski.io B.Braun Medical Ltd. Budapest 25
Behaviour Driven Development (BDD) TDD-hez hasonlít, de magasabb szinten alkalmazzuk, rendszerint rendszer teszt A SW viselkedését domain-specifikus nyelven írjuk le, kulcsszavak segítségével 3 amigo: A teszt írásakor fejlesztő-tesztelő-requirement engineer is részt vesz Olvashatóbbá (és érthetőbbé) teszi a teszteket, ugyanakkor lehetővé teszi az automatizálást A tesztet futtató szoftver értelmezni tudja a kulcsszavakat / mondatokat Az egyes mondatokhoz hozzárendelünk egy futtatható teszt kódot pl. Gherkin + Cucumber B.Braun Medical Ltd. Budapest 26
Behaviour Driven Development (BDD) B.Braun Medical Ltd. Budapest 27
Behaviour Driven Development (BDD) Gyorsan elkészíthető Élő dokumentáció Általában system szintű viselkedés leírására használjuk A funkció specifikációja maga a teszt is, nem csupán egy kiindulási pont - - ha elbukik a teszt, akkor elbukik a követelmény is, a bidirectional traceability teljes megvalósulása A fejlesztőnek úgy kell implementálnia egy funkciót, hogy átmenjen a teszten Bárki számára érthető, használható ( managerek, userek ) De: A gyakorlatban a managereknek / usereknek nincs rá idejük, ezért többnyire a tesztelők írják a fixture kódok karbantartása sok munka: FONTOS számukat korlátozni, minőségüket tesztekkel felügyelni B.Braun Medical Ltd. Budapest 28
Statikus kódanalízis Akkor alkalmazzuk, ha a kód elkészült Nem futtatjuk a kódot Coding standard eknek való megfelelés ( pl. Misra-C ) Lehetnek projekt-szintű előírások ( bekezdés, névkonvenciók, stb. ) A végeredmény feltétele kell legyen a Release-nek B.Braun Medical Ltd. Budapest 29
Statikus kódanalízis B.Braun Medical Ltd. Budapest 30
Dinamikus kódanalízis és egyéb teszt típusok Futtajuk a kódot, közben végezzük a méréseket Kódlefedettség ( pl. gcov ) unit tesztek minősége Milyen utasítások hajtódtak végre Milyen döntési ágakra futottunk rá Memóriahasználat - memcheck ( pl. valgrind ) Performancia tesztek Mennyi kérést képes kiszolgálni a SW Hosszú működés során mennyire stabil Futási idő De: Probe-effect! kódba beépülő tool-ok, befolyásoljuk a mérési eredményt! B.Braun Medical Ltd. Budapest 31
Dinamikus kódanalízis kódlefedettség mérés B.Braun Medical Ltd. Budapest 32
Continuous Integration Az automatizált folyamatok segítik az új funkciók gyors integrálását a rendszerbe eszköz: pl. Jenkins Egy lépés sikeressége triggereli a következő lépést Lehet több kilépési pont ( pl. nem sikerül a fordítás ) Minden esetben report készül, amit megkapnak az érintettek Több eszköz együttes használata ( version control, build szerver, teszt tool, stb. ) Code Compile / build Static code analysis / unit test Ingtegration tests Internal release Report B.Braun Medical Ltd. Budapest 33
Egyéb eszközök az automatizálásban Test recording Manuális tesztlépések felvétele, későbbi megismétlés céljából Hasznos, ha pontosan meg akarunk ismételni egy tesztet Exploratory tesztelés során fontos Gyorsan elévül, ha változik a szoftver, ezért az összes tesztet nem lehet erre építeni Mutation test A kódban végzünk módosításokat, és leellenőrizzük, hogy átmegy-e a teszten Ha egy módosított kód átmegy a teszteken, akkor nem elég jók a tesztjeink A tesztek minőségét azzal a mérőszámmal jellemezhetjük, hogy hány mutációt tud jelezni B.Braun Medical Ltd. Budapest 34
Egyéb eszközök az automatizálásban Fuzz testing / Monkey testing Véletlenszerű inputok generálása A lényeg, hogy nem várt működést idézzünk elő UI-on össze-vissza kattintgató alkalmazás Test Management tool-ok Tesztek rendszerezése Teszt riportok tárolása Tesztelési folyamat állapota ellenőrizhető Traceability melyik teszt melyik követelményhez tartozik Configuration Management melyik teszt melyik verzióra érvényes B.Braun Medical Ltd. Budapest 35
Szimulátor a tesztelésben SW szimulátor A SW valós környezetét utánozzuk ( pl. szenzorok, aktuátorok ) Költséghatékony nem kell a HW-nek rendelkezésre állnia Helyfüggetlen, minden alkalmazott használhatja A teszteket könnyebb szerveren futtatni Egyszerűsíti az automatizálást Hardware in the loop (HIL) A szenzorok, aktuátorok szimulációjára HW eszközt használunk Bizonyos szoftvereket az adott célhardveren kell tesztelni B.Braun Medical Ltd. Budapest 36
Összefoglalás 62304: kellenek regressziós tesztek 29119: folyamatok, dokumentumok, elméleti eszköztár a teszteléshez Fontos a gyors visszacsatolás a hibákról Nem lehet mindent automatizálni A refaktorálásnak elengedhetetlen előfeltétele a tesztek megléte Test First módszerek: TDD, BDD módszerek Statikus + dinamikus kód analízis Tesztek minőségére is figyelni kell ( mutation testing, tesztek review-ja ) Egyéb tool-ok ( fuzzy test, test management, szimulátor ) Folyamatos integráció B.Braun Medical Ltd. Budapest 37