„Szoftvertesztelés - Vizsga 2011.05.31.” változatai közötti eltérés

A VIK Wikiből
Szikszayl (vitalap | szerkesztései)
a kategória javítva
Szikszayl (vitalap | szerkesztései)
aNincs szerkesztési összefoglaló
 
(2 közbenső módosítás ugyanattól a felhasználótól nincs mutatva)
1. sor: 1. sor:
{{Vissza|Szoftvertesztelés}}
===1. Strukturális tesztelési technikak ismertetése, milyen gráfok vannak (mi a csomópont és az él) + hogyan alakul egymáshoz mérten a tesztesetek száma, kidolgozottsága (8p)===
===1. Strukturális tesztelési technikak ismertetése, milyen gráfok vannak (mi a csomópont és az él) + hogyan alakul egymáshoz mérten a tesztesetek száma, kidolgozottsága (8p)===


30. sor: 32. sor:
-- [[FaPe|FaPe]] - 2011.05.31.
-- [[FaPe|FaPe]] - 2011.05.31.


[[Category:InfoMsc]]
[[Kategória:Mérnök informatikus MSc]]

A lap jelenlegi, 2014. március 13., 13:53-kori változata


1. Strukturális tesztelési technikak ismertetése, milyen gráfok vannak (mi a csomópont és az él) + hogyan alakul egymáshoz mérten a tesztesetek száma, kidolgozottsága (8p)

2. Két sajátos technika az integrációs tesztelésben (2p)

Nagy bumm teszt: az integrációs tesztelés egyik fajtája, ahol a szoftver és a hardver elemeket akár egyetlen rendszerbe integrálva teszteljük ( big-bang testing) (HTB)

Integrációs teszt:

  • Az egységeket integráljuk, és az integrált részek interfészeit teszteljük a specifikációval szemben.
  • Általában az egységtesztet követi és a rendszertesztet előzi meg
  • Az egységteszten sikeresen „átesett” modulokat veszi alapul
  • Célja, hogy a nagyobb elemekkel szemben támasztott, funkcionalitásra, teljesítményre, megbízhatóságra vonatkozó követelményeket ellenőrízze
  • A modulok közötti interfészek kerülnek kipróbálásra
  • A modulok / alrendszerek közötti együttműködést szimulálva történik a tesztelés
  • Alapötlet: mindig tesztelt, ellenőrzött alapelemekből építkezünk

3. Az öröklődés hatása a tesztelésre (2p)

Megnehezíti a unit tesztelést (ha unit = osztály), lehetetlenné teszi a unit teszt során, hogy egy osztályt önmagában fordítsunk és teszteljünk.

Lehetőségek:

  • Binder (1996) javaslata: „flattened classes” – „simított osztályok” létrehozása: eredeti osztály + az osztály által öröklött attribútumok és műveletek
    • Többszörös öröklődés tovább komplikálja a helyzetet
    • A simított osztály nem része a rendszernek, a tesztelés tehát nem ad teljes bizonyosságot
    • Megtörténhet, hogy a simított osztály metódusai nem elegendőek az osztály teszteléshez
  • Az osztály kiegészítése a tesztelhetőséget biztosító metódusokkal
    • Az így kiegészített osztály ne legyen része az átadott rendszernek
    • A tesztelés megkönnyítésére bevezetett metódus maga is hibás lehet

4. A Google Speciális keresésről volt egy screenshot és ott kellett ekvivalencia osztály, határérték, döntési tábla tesztet készíteni. Valamint kombinatorikus tesztre teszt eset számot írni. (10p)

-- FaPe - 2011.05.31.