Informatika | Tesztelés, Minőségbiztosítás » Pócza Krisztián - Alkalmazások tesztelésének módszerei

.Net 2 előadás jegyzet – 11 óra (2012-ből) 1.oldal .NET Microsoft .Net Framework és programozása II. Előadás jegyzet Előadó: Pócza Krisztián ELTE,2012 Alkalmazások tesztelésének módszerei 1. Teszt típusok Tesztelés  Már közepes méretű alkalmazásoknál is nehéz lenne a rendszer helyességéről csak és kizárólag formális verifikáció útján meggyőződni. Hogy megtudjuk, programunk jól működik e, más módszerekhez kell folyamodnunk. A tesztelés lényege, hogy programunkat a lehetséges bemenő adatok nagy tömegével bombázzuk és figyeljük a rendszer válaszait. Unit test (egység teszt)  A software egységeinek, komponenseinek egymástól függetlenül végzett működési tesztje. Célja az adott komponens helyességének vizsgálata Általában ezt kell a fejlesztőnek elvégeznie, a többi automatizálható. Coverage (kód lefedettség)  A kód lefedettségének a vizsgálata, azaz hogy a tesztadatok folyamán hány százaléka

futott le a kódunknak. Általában 90% felett jó az arány Integration (integrációs) testing  A letesztelt modulok közti „együttműködési” teszt. Célja az egységek/modulok közti kommunikáció, működés, integráció, kapcsolat stb. helyességének vizsgálata. System testing (rendszerteszt)  o funkcionális: megfelel-e a specifikációnak, user interface megfelelően működik e (pl. webservice) o nem funkcionális: ide tartoznak a következő teszt típusok System integration (rendszerintegrációs) test  A külső rendszerekkel való kapcsolatot vizsgálja. Mennyire könnyen lehet hozzácsatolni más rendszerekhez, mivel tud kommunikálni (XML, SOAP), mennyire stabil/gyors más rendszerekkel együtt dolgozva. Performance/load/stress (teljesítmény/terhelés) test  A rendszer válaszidejét (nagy terhelésre való reakcióját) vizsgálja. Nagy terhelés esetén több dolog is történhet a rendszerrel: lelassul, kitilt user -eket, leállít

szolgáltatásokat, vagy timeout -ot dob. User interface (felhasználói felület) test  A felhasználói felület megfelel-e az elvárásoknak, elvégezhető-e vele az implementált üzleti folyamat. Mennyire kényelmes elérni a funkciókat, működnek-e a bill. kombinációk stb .Net 2 előadás jegyzet – 11 óra (2012-ből) 2.oldal Regression (regressziós) test  Ha változik valami a rendszerben (funkciók módosulása, új verzió megjelenése), akkor a régi teszteseteket újra kell futtatni, hogy meggyőződjünk a változtatás helyességéről. Főleg karbantartásoknál és újabb fejlesztéseknél fontos Emotional (emócionális, felhasználói elégedettség) test  A felhasználó elégedett a programmal? Mi a programhoz való viszonya? Ritkán fordítanak rá jelentősebb figyelmet, inkább SW ergonómiai szempontból fontos. A teszteseteknél fontos, hogy megismételhetőek legyenek. Ha az eredményből kiderül valami, akkor javítás után ugyanazokat

a bemenő adatokat tudjuk odaadni a programnak. A piacon vannak olyan SW -ek amik képesek felvenni és eltárolni a bemeneti eszközök jeleit (billentyű, egér. stb), majd újabb tesztelésnél előhívni 2. Unit test elméletben A Unit test a SW egységek egymástól függetlenül végzett működési tesztje. Egyenként, külső rendszerkapcsolatokat kizárva pl. bevezetünk egy interface -t, ami esetleg üres definíciókkal valósul meg. Másik lehetőség a lazán kapcsolás módszere, azaz függőséget injektálunk a rendszerbe(dependancy injection). Dependancy injection container -ek: programok vannak rá, indításkor beállítható, hogy mely interface -t és mely kódrészletet akarjuk beregisztrálni. Az egység Objektum Orientált Programozási környezetben (OOP) általában az osztály. A teszt úgy történik, hogy a szolgaltatás rétegbe hívogatunk bele, azok úgyis osztályokból épülnek fel. A teszteset a következőkből épül fel: o Paraméterek o

Műveletvégzés o Eredmények ellenőrzése Tesztesetek: milyen környezetben, milyen eredményt várunk? (logikai változtatás nem változtathatja meg az eredményt) - bemenő paraméterek alapján - elvégzett műveletek - eredményének vizsgálata - egymástól függetlenek Stub  szimulálja az éles környezetet, valamilyen választ ad vissza a tesztelt objektumnak A teszteseteknek egymástól függetlennek kell lenniük. Ha kötegelten futtatunk (pl: éjjel) egy tesztfolyamatot, akkor ha az egyik meghal az elején ne vigye magával az egész processzt. Mock objektumok  A rendelkezésre nem álló objektumok szimulálása egy objektummal, ami reálisnak tűnő válaszokat ad a kérésekre. Tulajdonképpen azt vizsgálja meg, hogy a program megfelelő paraméterezéssel hívja e meg a mock objektumot. .Net 2 előadás jegyzet – 11 óra (2012-ből) 3.oldal 3. Unit test a gyakorlatban Feed Reader alkalmazás  Van benne egy Test Project! (Nem minden Visual Studio

ismeri ezt a project típust, de pl. a Team Edition for Developers -ben benne van) A FeedReader testében írtunk egy TestClass -t (FeedServiceTest), amit attributummal jelöltünk meg. Van egy inicializáló metódus [TestInitialize], ami rendbe teszi az adatbázist, és van egy [TestCleanup()] művelet is. A számunkra fontos műveletek a tesztműveletek, amiket [TestMethod] attributummal jelölünk, ezekben hívjuk a szolgáltatásréteg szolgáltatásait. A tesztelést lehet direktbe is futtatni, de időzíteni is lehet, hogy pl. minden éjjel a program kicheckolja a SourceControl -ról az egész projektet, lefordítja, tesztel, összegyűjti az eredményeket. majd visszateszi a projektet a SourceControl -ra Más segédalkalmazások is léteznek erre a célra. Pl: NUnit, NCovert ComplexNetDemo tesztelése  létrehozunk egy új szolgáltatást, student osztályt, majd egy listát. Az [Assert.method()] -al tudunk tesztelni A Menüsor alatti gombokkal lehet különféle teszteket

futtatni, jelen esetben 4 db service teszt van benne: - attribútumok: [TestMethod], [TestInitialize] - assert-ek: [Assert.AreEqual()] - teszteset/tesztosztály előtt/után lefutó előkészítő/teardown funkciók - coverage: NUnit + NCover 4. Szoftverfejlesztés során használatos technikák Test Driven Dev. (TDD) - előbb a unit teszteket készítjük el és utána a kódot Domain Driven Dev. (DDD) - DeveloperDriven Design: egy szoftverfejlesztési folyamat, amely egy nagyon rövid fejlesztési ciklus ismétléses tesztelésére támaszkodik. build (nightly,., környezet) - saját komponens együttműködikik e a többivel Continous Integration Tool: nem fordítjuk le a teljes programot, mert az sokáig tartana PM: agilis, nem agilis Módszertanok: oldschool: vízesés(ügyfél igényeinek megfelelően - adatgyűjtés, dokumentáció, specifikáció, programozás - és itt lehet előlről kezdeni, ha az ügyfél nem elégedett) spirális: az ügyfél "futamonként" tud

visszajelezni és csak a futamok után kezdünk új programrészletbe Megjegyzés: Csak annyi doksit szabad írni, ami feltétlenül szükséges(minek olyat, amit rövid időn belül kidobunk). Folyamatos kommunikáció, visszajelzések figyelembe vétele. .Net 2 előadás jegyzet – 11 óra (2012-ből) 4.oldal 5. Profilerek A profilerek valamilyen nem .NET környezetben megírt performancia debugger programok, amik .NET-es alkalmazások futás közbeni vizsgálatára írtakVannak COM-os interfacek, amiket ha implementálunk, a .NET Framework kibocsájt egy eseményt, amire rákapcsolódva értesülhetünk pl. memórafoglalásról, assembly betöltődéséről, objektum felszabadításáról stb. Ezzel az eszközzel gyorsan javíthatjuk programunk memóriafelhasználását és futásidejét is. További olvasnivaló: http://kpoczanet/