Tesztelés

Question 1

Tesztelés

Answer 1

A mai világban nőttek az elvárások a szoftverekkel kapcsolatban: minőségben, elérhetőségben, megbízhatóságban, biztonságban, teljesítményben. A tesztelési igény ezért is nőtt meg. Automatizálni kell a teszteket, a tesztelésnek a folyamat részének kell lennie.
QA(quality assurance) tesztelőket vesznek fel a cégek, akik szintén fejlesztők, csupán teszteket írnak. A fejlesztőknek is kell teszteket írniuk. A fejlesztők és tesztelők szorosan együttműködnek.

Question 2

Mi a szoftvertesztelés?

Answer 2

• Egy nyomozási folyamat, melynek célja, hogy információkat derítsen ki a szoftver minőségéről.
• Követelményekkel írjuk le a szükséges tulajdonságokat, amitől függ a minőség.
• A tesztelés legyen
  
  • Objektív: a teszt jelentése legyen mindenki számára egyértelmű
  • Független: A teszteknek egymástól függetlennek kell lenniük.
• A tesztek célja
  
  • Validáció: mit csinál a szoftver? Azt csinálj, amit szeretnénk?
  • Verifikáció: hogyan csinálja?

Question 3

Követelmények

Answer 3

● Technikai: A funkció elérhető-e, elérési ideje megfelel-e?
● Üzleti: Működik-e a funkció? (Pl. Tudok-e felvenni admint).

Írjunk jó kódot: legyen tesztelve, kövessük a clean code szabályait.
Vannak tesztek, amiket nem lehet automatizálni. Automata teszteknél lehet szimulálni a valós user-ek viselkedését.

Question 4

Szoftver teszt attribútumok

Answer 4

• Scope
• Funkcionális vagy nem funkcionális
  
  • Funkcionális: Üzleti funkcionalitást tesztelünk
  • Nem funkcionális: Mit kell egy metódusnak tartalmaznia
    
    • teljesítmény: hogy viselkedjen adott terhelés alatt
    • stabilitás: mikor kell újraindítani?
    • használhatóság
    • biztonság
    • nemzetköziség
    • destruktivitás: pl: mit lesz az alkalmazással, ha megszűnik az adatbázis kapcsolat
• Statikus vagy dinamikus lehet a teszt.
  
  • Statikus: Nem futtatjuk a kódot(pl code review)
  • Dinamikus: Minden más
• Verifikáció, és/vagy validáció

Question 5

Teszt fajták

Answer 5

• Unit teszt: a legalapvetőbb, amit a fejlesztő ír. Egy dolgot tesztel, így, ha valami elromlik, könnyű megtalálni. Fejlesztők ettől magabiztosabbak lehetnek. Segít megérteni a kódot az újaknak. Legalább annyi tesztet kell írni, amennyire komplex valami. Ha többféleképpen futhat le akkor több teszt kell.
• Komponens teszt: Unitnál feljebb, modul tesztek.
• Integrációs tesztek: Integrációs környezetbe rakjuk az alkalmazást, komponensek együttműködését vizsgáljuk. Dep. Injection frameworkökkel jól használható, a konfigurációban lenyesegetjük a komponenseket.
• Rendszer teszt: Egész alkalmazás tesztje egyben.
• Acceptance teszt: Utolsó fázisba lévő teszt, ellenőrzi, hogy mehet-e élesbe. QA-sok a rendszer teszteket írják, a többit általában sima fejlesztők.

Question 6

Unit test, FIRST

Answer 6

Unit test
* Jól működik-e egy adott funkcionalitás, változtatás nem rontja-e el
* Egy metódus egy lehetséges lefutását(use case-ek) teszteli (1 metódus lehet több teszt)
* 100%-os lefedettség ha minden use-casere van teszt
* Leegyszerűsíti a fejlesztést- visszajelzést ad
* Segít megismerni a kódot, mint egy doksi
FIRST: A unit teszt szabályai, amik a
* Fast
* Independent/Isolated
* Repeatable (ne használjunk random értékeket)
* Self-validating
* Thorough (teljes átfogó)

Elvárások: bármikor le lehet futtatni időtől és helytől függetlenül. Utólag is lehessen futtatni, másét is lehessen futtatni, hamar fusson le (egy gombnyomásra) és gyorsan meg lehessen írni.

Question 7

Unit test frameworkok

Answer 7

(pl JUnit): segítenek Unit tesztek megírásában.
* egyszerre lehet mindet futtatni,
* eredményeket reprezentálja,
* nem csak unit tesztet lehet ezekben írni.

Question 8

Unit teszt vs integrációs teszt

Answer 8

Unit teszt vs Integrációs teszt:
● Unit: egy egység van a scopeban, gyorsan lefut, specifikus hibák, csak unitot kell inicializálni, egy változás egy unitba egy tesztet befolyásol.
● Integrációs: - több rész van interakcióban, lehet lassabb, nehéz a hibákat lokalizálni, konfiguráció, setup lehet, változtatás több tesztre is hathat.

Question 9

Mockolás és mock frameworkok:

Answer 9

• Lényege, hogy függőségektől függetlenül lehessen tesztelni. Mi csak a szolgáltatást akarjuk tesztelni. Ehhez Stub/Mock kell. Ezek helyettesítő objektumok. Ugyanazt implementálják, mint a dependencia.
• Két féle hozzáállás van:
  
  • Klasszicista: állapotok, visszatérési értékek megfelelnek-e a követelménynek, ha beadok egy objektumot a változások megegyeznek-e az elvárttal.
    
    • Assertion-ök
  • Mockista: viselkedést vizsgál, interakciók vizsgálása, leellenőrzése. Megtanítjuk a mockot/stubot, hogy hogyan kellene viselkednie, majd leellenőrizzük. Beépített osztályokat nem szokás mockolni, és a getter/setter osztályokat sem.
    
    • Stub: Helyettesítő objektum, semmit nem tudnak csak kielégítik a dependenciát. Nem tudja rögzíteni az interakciókat.
    • Mock: Szintén helyettesítő, de figyeli az interakciókat, megmondhatjuk hányszor kell meghívva legyen és ezt ellenőrizhetjük. Mock framework létre tudja ezeket hozni, kontrollálni, hozzáadni tudja őket.

Question 10

Tesztelhető kód

Answer 10

● Ha tesztelhető kódot írunk, attól a minősége is javul.
● A könnyen átlátható függőség hierarchia fontos.
● Egyszerű metódusok legyenek.
● Csak a publikus metódusokat teszteljük Unit teszttel.
● Teszt ellenes feature-ök: adatbázis, hálózati kapcsolat, hosszú számítások, GUI-n megjelenő dolgok.
● Teszt ellenes constructok: final metódusok, osztályok, statikus, privát metódusok, statikusan inicializált blokkok, kifejezések, konstruktorok, objektum inicializáló blokkok, new kulcsszó használata.
● A teszt unfriendly feature-öket sose rakjuk teszt unfriendly constructokba!
● A tesztelhető kód minőségibb, tiszta függőségeket tartalmaz, alacsonyabb komplexitású, felelősségek jól láthatóak.

A lényeg, hogy a teszt minél közelebb legyen a fejlesztéshez.
1. production osztály/ metódus elkészítése
2. unit teszt azonnal (meg is előzheti a teszt, ez a test driven development)
3. teszteljük a feltételt
4. tesztek futtatása
5. ha elhasalt, elégítsük ki a feltételt
6. futtassuk le, nézzük meg újra, hogy átmegy-e
7. refaktorálás  

Question 11

Ha egy osztályban van függőség, mit lehet tenni?

Answer 11

Két dolgot lehet tenni:
1. Leválasztjuk
2. Mockolás

Ha nem lehet ezeket megtenni, akkor az már integrációs teszt.
A teszt nem unit teszt, ha
* adatbázissal, vagy hálózattal beszél,
* fájlrendszerhez nyúl,
* nem tud többi teszttel egyszerre futni,
* környezettel speciális dolgokat csinál.