Bevezetés

A QA tesztelő élettartama hiányosnak tekinthető, ha a “Füstvizsgálat”, a “Józanságvizsgálat” és a “regressziós vizsgálat” kifejezések nem kerülnek bele. Bár ezek néhány rendszeresen használt kifejezések, vannak Közös Tévhitek körülöttük is.

mielőtt elkezdenénk a füst, a józanság és a regressziós tesztelés részleteit, és amit valójában jelentenek, átmegyünk néhány általános tévhiten és mítoszon körülöttük:

1. a Füstvizsgálat és a józanság vizsgálata ugyanaz, és felcserélhető módon használható: ez nem igaz, és soha nem szabad megtenni, miért? erről ebben a cikkben fogunk beszélni.
2. Józanság Vizsgálat egyenértékű elfogadási teszt: Átvételi Vizsgálatok tenni annak érdekében, hogy a fordítás megfelel minden követelménynek, hogy az ügyfél meghatározott kiadás előtt, míg a Józan ész a vizsgálatot végzik, hogy biztosítsák a termék ésszerű, racionális további, részletesebb vizsgálatra. Ezeket nem és nem szabad felcserélhetően használni.
3. Ha Füstvizsgálatot végzek, kihagyhatom a józansági tesztet: A füstvizsgálat nagyon magas szintű tesztelés, mivel ez a tesztelés annak biztosítására történik, hogy ez az építmény bármilyen más típusú vizsgálat megkezdésére alkalmas legyen. Például ez csak egy teszt lehet az építmények telepítésének biztosítására, majd megkezdődhet a józanság tesztelése. Bár néha, a füst teszt esetek futnak együtt józanság teszt esetek, ezeket nem szabad összekeverni, hogy az egy és ugyanaz a dolog.
4. a regressziós tesztelés nem kapcsolódik a Füstvizsgálathoz vagy a józansági teszteléshez: elméletileg a józansági tesztelés a regressziós tesztelés egy részhalmaza. Néhány magas prioritású regressziós vizsgálati esetek alkotják józanság teszt esetében általában.
5. ha a teljes regressziós tesztcsomagot kívánom futtatni – nem kell füstvizsgálatot vagy józansági tesztet futtatnom: bár ez bizonyos esetekben igaz lehet, mivel a józansági tesztelés egyébként a regressziós tesztelés részhalmaza, továbbra is tanácsos először végrehajtani a józansági vizsgálati eseteket, majd követni őket a regressziós vizsgálati esetek többi részével.

ebben a cikkben megpróbáljuk tisztázni a fenti zavarokat egyszer s mindenkorra.

abban az esetben, ha többet szeretne olvasni a kézi tesztelésről, olvassa el a linket itt.

Megjegyzés: Mivel a cikkben sokszor használjuk a “szoftverfejlesztés” kifejezést, itt definiálhatjuk. A ” Software Build “A forráskód felhasználói alkalmazásba történő átalakításának folyamata, több revízió és kódváltozás után, valamint a szoftverfejlesztés több folyamatot is magában foglal, mint például:”Verzióvezérlés, Kódminőség & összeállítás ” és a szoftverfejlesztés is ennek az építési folyamatnak az eredménye. Ebben a cikkben a build fogják hivatkozni, mint egy tesztelhető változata a szoftver.

Füsttesztelés

a Füsttesztelés olyan megközelítés, amelyet általában a szoftverfejlesztési életciklus(SDLC) kezdeti fejlesztési szakaszaiban hajtanak végre annak biztosítása érdekében, hogy a program alapvető funkciói problémamentesen működjenek. Ezt a szoftver részletes funkcionális tesztjeinek elvégzése előtt hajtják végre.

a füstvizsgálat fő célja nem a mély tesztelés elvégzése, hanem annak ellenőrzése, hogy a program vagy a szoftver alapvető vagy fő funkciói jól működnek-e. A füstvizsgálat célja, hogy a kezdeti szakaszban elutasítsa a rosszul törött építményt, hogy a tesztelő csapat ne pazarolja az időt a & szoftveralkalmazás tesztelésére.

A Füstvizsgálatot Építésellenőrzési tesztnek is nevezik.

nézzünk egy egyszerű példát, ahol kapsz egy e-mail alkalmazást a teszteléshez. A fontos funkciók az e-mail alkalmazásba való bejelentkezés, egy e-mail írása és elküldése, igaz? Abban az esetben, ha az e-mail nem kerül elküldésre, van-e értelme más funkciók, például tervezetek, törölt üzenetek, archívumok stb. tesztelésére? Ez azt jelenti, hogy további ellenőrzés nélkül le kell dobnia az építményt. Ezt nevezik Füstvizsgálatnak.

a füstvizsgálat fő célja a kritikus területek tesztelése, nem pedig a teljes alkalmazás.

mikor kell Füstvizsgálatot végezni

• amikor a fejlesztők friss felépítést biztosítanak a QA csapatnak. A friss építmény itt azt jelenti, hogy az építmény új változtatásokat hajt végre a fejlesztők által.
• amikor egy új modul kerül hozzáadásra a meglévő funkciókhoz.

automatizálás & Füstvizsgálat:

általában ez a tesztelés típusa, amelyet a tényleges automatizálási tesztesetek futtatása előtt hajtanak végre. A szervezet, hogy a folyamatos tesztelés-ben épült, füst vizsgálat egyenértékű sikeres telepítés a build, a futó teszt esetek, illetve a végrehajtás, az első próba. Tehát ez nem olyan típusú tesztelés, amelyet szándékosan automatizálnak, de ha a tesztautomatizálás a helyére kerül, a tesztautomatizálás csak akkor futhat sikeresen, ha a szoftver átment a füstvizsgálaton. Vagy egyébként az első végrehajtandó teszt eset sikertelen lehet.

Sanity Testing

a Sanity testing egyfajta tesztelés, amelyet annak ellenőrzésére végeznek, hogy egy szoftvertermék megfelelően működik-e, amikor egy új modul vagy funkcionalitás egy meglévő termékhez kerül. A Sanity testing egy szoftver tesztelési technika, amely gyors értékelést végez a szoftver kiadásának minőségéről annak meghatározására, hogy jogosult-e további tesztelési fordulókra, vagy sem.

a józanság tesztelését általában egy meglehetősen stabil szoftverfejlesztés kézhezvétele után hajtják végre, vagy néha, amikor egy szoftverfejlesztés kisebb változásokon ment keresztül a kódban vagy a funkcionalitásban. Dönt arról, hogy a szoftvertermék végső tesztelését tovább kell-e végezni vagy sem.

a Sanity tesztelés szintén felületi szintű tesztelés, amely segít annak eldöntésében, hogy a szoftver felépítése elég jó-e ahhoz, hogy a következő tesztelési szintre kerüljön.

miért végezzen józansági vizsgálatot

• az újonnan hozzáadott funkciók és funkciók megfelelőségének ellenőrzéséhez és érvényesítéséhez a meglévő kódban.
• annak biztosítása érdekében, hogy a bevezetett változások ne befolyásolják a termék egyéb meglévő funkcióit.
• annak eldöntéséhez, hogy a további tesztelés tovább folytatható-e vagy sem.

amikor végre józanság tesztelés

• Build után kapott sok regresszió, vagy ha van egy kisebb változás a kódot.
• az építmény a hibajavítás után érkezik.
• közvetlenül a gyártás üzembe helyezése előtt.

automatizálás & józansági tesztelés:

figyelembe véve, a józansági tesztelés a regressziós tesztelés részhalmazának tekinthető, ezek az automatizálható vizsgálati esetek. A javasolt megközelítés az, hogy végre ezeket a vizsgálati esetek futtatása előtt a teljes regressziós teszt suite. Ennek az az előnye, hogy ha bármilyen hiba van a józansági tesztesetekben, akkor a hibákat inkább előbb, mint később lehet jelenteni.

regressziós tesztelés

a regressziós tesztelés a “hibajavítások vagy a követelmény bármilyen változása” ellenőrzése, valamint annak biztosítása, hogy azok ne befolyásolják az alkalmazás egyéb funkcióit. A regressziós tesztelés hatékony az automatizálásnál, és általában azután történik, hogy néhány módosítást elvégeztek a szoftverfejlesztésben a követelménymódosítások vagy hibajavítások után.

miután a megváltozott funkcionalitás józansági tesztelése befejeződött, az alkalmazás összes érintett funkciója teljes tesztelést igényel. Ezt regressziós tesztelésnek nevezik.

Ha a meglévő szoftverben hibajavításokat végeznek, néhány tesztforgatókönyvet végre kell hajtani a hibajavítások ellenőrzéséhez. Ezen felül a QA csapatnak a kódváltozások alapján ellenőriznie kell az érintett területeket is. A regressziós tesztelés során ezeket a tesztforgatókönyveket végre kell hajtani, hogy gondoskodjanak a kapcsolódó funkciókról.

mikor kell elvégezni a regressziós tesztet

• a kód módosítása után a szükséges változtatások szerint
• után néhány új funkció hozzáadódik az alkalmazáshoz
• Néhány hibajavítás beépül a build

automatizálás & regressziós tesztelés:

regressziós tesztesetek valójában ideális tesztesetek az automatához. Általában, amikor egy szervezet elkezdi az automatizálást, ezek a tesztesetek, amelyek először automatizálódnak. Ha a regressziós tesztelés olyan tevékenység, amely sok időt vesz igénybe a tesztelők számára, és ugyanazokat a teszteseteket többször megismételik, akkor itt az ideje, hogy az automatizálásra is gondolkodjon.

Ha olyan eszközt keres, amely segít az automatizálási utazás megkezdésében, akkor gondoskodnia kell arról is, hogy a megfelelő eszközt válassza. Olyan eszköz, amely ROI-t is biztosít a befektetett erőfeszítésekről. Megvan az útmutató, amely segíthet ott:

10 Points to Help You Choose the Right Test Automation Tool

Differences Between Smoke vs Sanity vs Regression Testing

főbb Pontok

• a Füst, a Józan ész vizsgálat segít a QA csapat időt takaríthat meg gyorsan a vizsgálatot, hogy ellenőrizze, ha egy alkalmazás megfelelően működik-e, vagy sem. Ezenkívül biztosítja, hogy a termék további tesztelésre jogosult legyen. Míg a regressziós tesztelés segít növelni a szoftver minőségével kapcsolatos bizalmat egy adott változás után. Különösen, hogy a kódváltozások nem érintik a kapcsolódó területeket.

• A Füstvizsgálatot mind a dev csapat, mind a QA csapat végzi, és a szigorú tesztelés részhalmazaként vehető igénybe. Míg mindkét józanság & a regressziós vizsgálatot csak a QA csapat végzi. Továbbá, a józanság tesztelése az elfogadási tesztelés részhalmazának tekinthető.

• A Füstvizsgálatot az SDLC kezdeti szakaszában hajtják végre, hogy ellenőrizzék az alkalmazás alapvető funkcióit. Míg a józanság & regressziós tesztelés az SDLC utolsó szakaszában történik, az alkalmazás fő funkcióinak ellenőrzéséhez.

• Mint egy a követelmény vizsgálati & rendelkezésre állást, a QA csapat lehet, hogy végre Józan ész, Füst & Regressziós vizsgálatok a szoftver építeni. Ilyen esetekben először a Füstvizsgálatokat hajtják végre, majd a & józansági vizsgálatot követik, majd a rendelkezésre álló idő alapján regressziós vizsgálatot terveznek.

a gyakorlatban minden QA csapatnak füstöt, józanságot és regressziós vizsgálatot kell végeznie. Mindezek a vizsgálati típusok előre meghatározott számú tesztesetet tartalmaznak, amelyek többször is végrehajtásra kerülnek. Ez az ismétlődő végrehajtás ideális jelöltet jelent a tesztautomatizáláshoz. Ha automatizálást keres, javasoljuk, hogy olyan eszközt használjon, amely a kezdeti szakaszoktól kezdve biztosítja a ROI-t az automatizálásról. A Testsigma egy ilyen eszköz.