Statikus vs dinamikus tesztelés: különbség köztük

Különbség a statikus és a dinamikus tesztelés között

  • A statikus tesztelés a program végrehajtása nélkül történik, míg a dinamikus tesztelés a program végrehajtásával történik.
  • A statikus tesztelés ellenőrzi a kódot, a követelménydokumentumokat és a tervezési dokumentumokat, hogy megtalálja a hibákat, míg a dinamikus tesztelés a szoftverrendszer funkcionális viselkedését, a memória/CPU-használatot és a rendszer általános teljesítményét ellenőrzi.
  • A statikus tesztelés a hibák megelőzéséről, míg a dinamikus tesztelés a hibák megtalálásáról és javításáról szól.
  • A statikus tesztelés végzi az ellenőrzési folyamatot, míg a dinamikus tesztelés az érvényesítési folyamatot.
  • A statikus tesztelést a fordítás előtt, míg a dinamikus tesztelést a fordítás után hajtják végre.
  • A statikus tesztelési technikák strukturális és utasítási lefedettséget jelentenek, míg a dinamikus tesztelési technikák a határérték-elemzés és az ekvivalencia-particionálás.

Különbség a statikus és a dinamikus tesztelés között

Mi az a statikus tesztelés?

Statikus tesztelés egy olyan szoftvertesztelési típus, amelyben a szoftveralkalmazást kódvégrehajtás nélkül tesztelik. A hibák felkutatása érdekében a kód, a követelménydokumentumok és a dokumentumtervezés kézi vagy automatizált áttekintése történik. A statikus tesztelés fő célja a szoftveralkalmazások minőségének javítása azáltal, hogy a szoftverfejlesztési folyamat korai szakaszában hibákat talál.

Statikus tesztelés magában foglalja a dokumentumok kézi vagy automatikus ellenőrzését. Ezt az áttekintést a tesztelés kezdeti szakaszában végzik el, hogy korán felismerjék a hibát STLC. Megvizsgálja a munkadokumentumokat és véleményezi. Nem végrehajtási tesztelésnek vagy ellenőrző tesztelésnek is nevezik.

Példák munkadokumentumokra-

  • Követelmény specifikációk
  • Tervezési dokumentum
  • Source Code
  • Teszttervek
  • Tesztsorozat
  • Tesztparancsok
  • Súgó vagy felhasználói dokumentum
  • Weboldal tartalma

Statikus tesztelési technikák

  • informális Revnézetek: Ez az egyik olyan felülvizsgálati típus, amely nem követ semmilyen eljárást a dokumentumban található hibák megtalálására. Ennél a technikánál csak át kell tekinteni a dokumentumot, és informális megjegyzéseket kell tenni hozzá.
  • Műszaki információk Revnézetek: Egy munkatársaiból álló csapat átnézi a szoftvertermék műszaki specifikációját és ellenőrzi, hogy az alkalmas-e a projektre. Megpróbálnak minden eltérést megtalálni a követett specifikációkban és szabványokban. Ez az áttekintés főként a szoftverrel kapcsolatos műszaki dokumentációra összpontosít, mint például a Tesztstratégia, Teszt terv és követelményspecifikációs dokumentumokat.
  • Végigjátszás: A munkatermék szerzője elmagyarázza a terméket csapatának. A résztvevők kérdéseket tehetnek fel, ha vannak. A találkozót a szerző vezeti. Scribe feljegyzi a felülvizsgálati megjegyzéseket
  • ellenőrzés: A fő cél a hibák feltárása, és az értekezletet képzett moderátor vezeti. Ez az áttekintés egy formális felülvizsgálati forma, ahol szigorú eljárást követ a keresés hibák. RevAz olvasóknak van egy ellenőrző listája a munkatermékek áttekintésére. Rögzítik a hibát, és értesítik a résztvevőket, hogy javítsák ki a hibákat.
  • Statikus kód Revazaz: Ez a szoftver forráskódjának szisztematikus áttekintése a kód végrehajtása nélkül. Ellenőrzi a kód szintaxisát, a kódolási szabványokat, a kódoptimalizálást stb. Ezt fehérdobozos tesztelésnek is nevezik. Ez az áttekintés a fejlesztés során bármikor elvégezhető.

Mi az a dinamikus tesztelés?

Alatt Dinamikus tesztelés, egy kód végrehajtásra kerül. Ellenőrzi a szoftverrendszer funkcionális viselkedését, a memória/cpu használatát és a rendszer általános teljesítményét. Innen a „dinamikus” elnevezés

A tesztelés fő célja annak megerősítése, hogy a szoftvertermék az üzleti követelményeknek megfelelően működik. Ezt a tesztelést végrehajtási technikának vagy érvényesítési tesztelésnek is nevezik.

Dinamikus tesztelés végrehajtja a szoftvert és érvényesíti a kimenetet a várt eredménnyel. A dinamikus tesztelést a tesztelés minden szintjén végrehajtják, és lehet fekete vagy fehér dobozos tesztelés.

Dinamikus tesztelés

Dinamikus tesztelési technikák

Dinamikus tesztelés

  • Egység tesztelése: Alatt Egység tesztelése, az egyes egységeket vagy modulokat a fejlesztők tesztelik. Ez magában foglalja a forráskód fejlesztők általi tesztelését.
  • Integrációs tesztelés: Az egyes modulokat a fejlesztők csoportosítják és tesztelik. A cél annak meghatározása, hogy mely modulok működnek a várt módon, miután integrálták őket.
  • Rendszertesztelés: Rendszer tesztelés a teljes rendszeren úgy történik, hogy ellenőrizzük, hogy a rendszer vagy az alkalmazás megfelel-e a követelményspecifikációs dokumentumnak.

Ezenkívül nem funkcionális tesztelés, például teljesítmény, Biztonsági tesztelés a dinamikus tesztelés kategóriájába tartozik.

Statikus tesztelés vs. Dinamikus tesztelés

Statikus tesztelés Dinamikus tesztelés
A tesztelés a program végrehajtása nélkül történt A tesztelés a program végrehajtásával történik
Ez a teszt végzi el az ellenőrzési folyamatot A dinamikus tesztelés elvégzi az érvényesítési folyamatot
A statikus tesztelés a hibák megelőzésére irányul A dinamikus tesztelés a hibák megtalálásáról és kijavításáról szól
A statikus tesztelés értékeli a kódot és a dokumentációt A dinamikus tesztelés hibákat/szűk keresztmetszeteket okoz a szoftverrendszerben.
A statikus tesztelés egy ellenőrző listát és egy követendő folyamatot tartalmaz A dinamikus tesztelés teszteseteket foglal magában a végrehajtáshoz
Ezt a tesztelést az összeállítás előtt is el lehet végezni A dinamikus tesztelés az összeállítás után történik
A statikus tesztelés lefedi a szerkezeti és nyilatkozatlefedettség tesztelését A dinamikus tesztelési technikák a határérték-elemzés és az ekvivalencia-felosztás.
A hibakeresés és a javítás költsége alacsonyabb A hibák feltárásának és kijavításának költsége magas
A beruházás megtérülése magas lesz, mivel ez a folyamat korai szakaszban zajlik A beruházás megtérülése alacsony lesz, mivel ez a folyamat a fejlesztési szakasz után következik be
További vélemények megjegyzései erősen ajánlottak a jó minőség érdekében A jó minőség érdekében erősen ajánlott több hiba.
Rengeteg találkozót igényel Viszonylag kevesebb találkozót igényel