„Szoftvertesztelés - Vizsga 2011.05.31.” változatai közötti eltérés
A VIK Wikiből
Új oldal, tartalma: „{{GlobalTemplate|Infoszak|SzoftvertesztelesVizsga20110531}} Azért került külön oldalra, hátha valaki kidolgozza. ===1. Strukturális tesztelési technikak ismer…” |
aNincs szerkesztési összefoglaló |
||
| (7 közbenső módosítás, amit 2 másik szerkesztő végzett, 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)=== | ||
===2. Két sajátos technika az integrációs tesztelésben (2p)=== | ===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)=== | ===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 [http://www.google.com/advanced_search 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)=== | ===4. A [http://www.google.com/advanced_search 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)=== | ||
| 15. sor: | 32. sor: | ||
-- [[FaPe|FaPe]] - 2011.05.31. | -- [[FaPe|FaPe]] - 2011.05.31. | ||
[[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.
