Download to read offline
Szoftver tesztelés
- 1. Szoftver tesztelés Az ORENBIrendszer back-end fejlesztésének tapasztalatai alapján Tóth Krisztián Gyula Horváth Gábor
- 2. • Tesztvezérelt fejlesztés •Miért, hogyan, és milyen teszteket írjunk? • Kód lefedettség problémája • ORENBI back-end • Teszt struktúra és környezet • Modul fejlesztés és tesztelés
- 3. Szoftver tesztelésről általában Aszoftver alkalmazási területe kritikus szempont a tesztelési módszerek és alapelvek meghatározásakor! Az emberek a szoftverre támaszkodnak ezért fontos, hogy : Ne produkáljon hibákat Gyors és megbízható legyen
- 4. Miért írjunk teszteket!? „Plusz munka, van anélkül is elég igény a megrendelőtől” mondhatnánk… • De!! ▫ Fejlesztés = A kód változik! ▫ Nincsenek tesztek!? -> Biztos minden jól működik még most is? ▫ Minél később jelentkezik egy hiba annál drágább a javítása Furcsa hibajelenségekről számol be a megrendelő ▫ Át merjek írni bármit is? Amelyik szoftver kódja nem változik azt vagy nem használják sehol, vagy nem meri senki módosítani! • Ha vannak tesztek: ▫ A hibák döntő része már az üzemi kód írásakor javításra kerül ▫ Minél nagyobb területet fedtünk le annál kevésbé van mitől félnünk egy módosítás után.
- 5. Hogyan írjunk teszteket? • Egyszerű és érthető legyen, nem kell hogy hatékony • F.I.R.S.T elvek ▫ Gyors – Fusson le gyorsan ▫ Független – Ne befolyásolják egymást ▫ Megismételhető – Környezet függetlenül ▫ Egyértelmű – Siker vagy kudarc ▫ Időszerű – Üzemi kód írás előtt/kor/utána/félévvel … -> De a lényeg, hogy legyen a kódunk bármikor tesztelhető
- 6. Milyen teszteket írjunk? • Front-end oldaltól induló tesztek, mintha valaki használná az alkalmazástEnd-to-end • A rendszer architektúra több réteg/egység együttes működését teszteli Integration • A rendszer egységei egymástól függetlenül kerülnek tesztelésre Unit
- 7. Tesztek összehasonlítása Adatbázis Külső rendszer1 (IBM Maximo) Külső rendszer 2 (Libra) Rendszer architektúra MOCK Alkalmazás réteg 1 elemei Alkalmazás réteg 2 elemei Külső rendszerek Egység teszt Integrációs teszt End-to-End teszt
- 8. Unit Vs Integrációstesztek Egység tesztelés Integrációs tesztelés • Rész funkciót tesztel • Szimulált környezetben ▫ Nincs adatbázis ▫ Függőségekre dummy objektumok • Gyors lefutás ▫ Futtassuk őket gyakran • Nem teszteljük az összeköttetést • Egyszerű következtetés a hiba okára és helyére ▫ Egyszerűen javítható • Minél nagyobb egészét próbáljuk lefedni • Valós környeztet hozunk létre ▫ Tényleges adatbázis kapcsolat, stb.. ▫ A függőségekre nincsenek dummy objektumok • Lassú lefutás • Drága (megírni) • Összeköttetést teszteljük • Nehezebb beazonosítani, hogy a hiba honnan származik • Hibákat nem tudunk vele szimulálni
- 9. Különböző típusú tesztekviszonya • Helyettesíthetők-e a Unit tesztek csupán Integration tesztekkel? ▫ Nem, mind a két tesztre szükség van! ▫ Együtt lehet velük jól lefedni a rendszer működését. • Mit érdemes Unit tesztelni? ▫ Lehetőleg mindent. • Mikor írjunk Integration tesztet? ▫ Ha már írtunk Unit tesztet, minden kapcsolódó rétegben.
- 10. Hogyan döntsem el,hogy mit teszteljek? • A tesztek írása is idő, ami költség. • A lehetőségek költségébe kerül amit teszt írás helyett végezhetne egy fejlesztő. ▫ (Pl: további funkció tervezése és implementálása) • Át kell gondolni, hogy mit van értelme tesztelni és mit nincs!
- 11. Kód lefedettség • Mitis takar ez valójában? ▫ O%-os lefedettség = Nincs automatizált tesz ▫ 100%-os lefedettség = Minden kódsort legalább egyszer meghajtottunk automatizált tesztel • Minél magasabb az érték annál jobb érzés • DE! Csak az általunk írt összes használati eset teljesül! 100%
- 12. Túl tesztelünk vagyalul ha kitűzünk egy értéket? Hibahatása Hiba valószínűsége 50% 25% 55% 35%43% 67% 22% 90%
- 13. Mi javíthat akód minőségen és a csapaton ? 1. Csak Unit tesztelt kód kerüljön a repository-ba! 2. Kötelező jellegű, gyakori code review! • A csapattagok bemutatják, hogy az adott problémát, hogy oldották meg. • Tanítva a többieket és magukat. 3. Kód szétfűzés, egyszerűsítés! • Dependency Injection és Facade-ek használata • „Túl komplex Unit tesztelni” -> Legyen Simple! (K.I.S.S) • Interfészek kisebb egységekre bontása
- 14. Mikor nincs értelmea tesztvezérelt fejlesztésnek ? „Olyan sok csúnya kódot láttam már rengeteg pénzt termelni, hogy azt kell hinnem, hogy a kód minősége vagy nem szükséges, vagy nem elégséges az üzleti sikerek eléréséhez.” Kent Beck – Implementációs minták • Ha nem futtatjuk a teszteket • Ha az első sikeres lefutás után eldobjuk A fejlesztő felelőssége, hogy a kódolással töltött óráit jól használja fel. • A tesztek a szoftver érdekelt személyei részére készülnek. • Nem elég azt mondani, hogy a kód jó, bizonyítsuk.
- 16. Amiről szó lesz: •Tesztelési struktúra (Visual Studio-ban) • Egyszerű példák • Alkalmazott segéd eszközök és keretrendszerek • A tesztelés és a fejlesztés ciklus kapcsolata
- 17. Tesztelési struktúra • Különprojektekben • Külön futtathatóak ▫ Integration tesztek ▫ Unit tesztek • Tesztek elnevezése (specifikáció is egyben) • {FüggvényNeve}_{Tesztelt Állapot}_{VártViselkedés} • {FüggvényNeve}_When{Tesztelt Állapot}_Should{VártViselkedés} • Tesztek szerkezete • AAA szerint BDD: GIVEN, WHEN, THEN Arrange, Act, Assert
- 18.
- 19.
- 20. Segéd eszközök éskeretrendszerek • Nunit • Moq - https://github.com/Moq/moq4/wiki/Quickstart • FluentAssert - http://fluentassertions.com/documentation.html • NBuilder • Faker • Resharper ▫ dotCover • ReportUnit
- 21. Tesztelés és afejlesztés kapcsolata Continuous Testing / Delivery • Automatizálás a barátunk ▫ Időzíthető ▫ A fejlesztőknek nem kell minden tesztet futtatni • Az éles környezettel identikus helyen történik a tesztek futtatása. ▫ Nem kell végig várni a lefutásra. ▫ A hibák nem csak akkor jönnek elő, ha a teszteket a fejlesztők futtatják. ▫ A tesztek eredmény biztosan eljut a csapathoz. Le merjem futtatni a többit is? Kinek kell kijavítani?
- 22. ORENBI Software DevelopmentLifecycle
- 23. Mitől lesz valamikönnyen és hatékonyan tesztelhető? Élmények, tapasztalatok Példa tesztek
- 24. Végső gondolatok • Legyünkjobb fejlesztők! • Írjunk jobb minőségű kódot! • Ne nyűg legyen a teszt írás, hanem szokás! • Oktatni kell, szoktatni kell ▫ Házi feladatok tesztvezérelten (nem kell javítani!) ▫ A tesztelés ne az utolsó lépés legyen. ▫ Lassan elvárás lesz a cégeknél! „Amit nem lehet tesztelni az nem feature.” //by autóipar
Editor's Notes
- #2 A teszteket nagyon nehéz gyakorlatiasan bemutatni, mert meg kell hozzá érteni az üzemi kódot, annak szerkezetét, a tesztek szerkezetét…..
- #8 Van bent adatbázis, van bent külső rendszer, amit nem mockolsz ki, vagy nem tudsz vagy nem akarsz
- #24 Köszöntök mindenkit! Most kicsit gyakorlatiasabb vizekre evezünk, és arra próbálok meg választ adni, hogy mitől lesz a kód könnyen és hatékonyan tesztelhető. Ez lehetne egy következő előadás…
- #25 Ha nem tesztelünk, lehet hogy soha nem jövünk rá bizonyos dolgokra. Jöjjön a kód, amit körbeküldtünk, vagy körbe fogunk küldeni, nagyon sok jó példa van bent, akit részletesebben is érdekel az keressen minket…