Unalmas tesztelői blog: Negatív tesztforgatókönyvek. Tesztkép a negatív és pozitív gondolkodáshoz Pozitív eredményt adott a tesztelt termékeknek

Teszteléskor szoftver termék hatalmas mennyiséget használtak fel különféle fajták tesztek. A legszélesebb és legrészletesebb osztályozást a „Dot Com Testing” című könyv szerzője, Roman Savin javasolta. A tesztelés típusait olyan szempontok alapján kombinálta, mint a tárgy, a tesztelés tárgya, a szint, a tesztelés pozitivitása és a tesztelés automatizálásának foka. Az osztályozás kiegészítésre került olyan források alapján, mint Sam Kaner Software Testing című könyve és a Pro Testing - Software Testing online tesztelési forrás.

A tesztelés tárgyának megfelelően

· Funkcionális tesztelés. A funkcionális tesztelés napjainkban az egyik leggyakrabban használt tesztelési típus. Az ilyen tesztelés feladata annak megállapítása, hogy a kifejlesztett szoftver (SW) mennyire felel meg a funkcionalitás tekintetében a megrendelő igényeinek. Más szóval, a funkcionális tesztek elvégzése lehetővé teszi a képesség ellenőrzését tájékoztatási rendszer megoldani a felhasználói problémákat.
· Nem funkcionális tesztelés. Lehetővé teszi a szoftver tulajdonságainak a beállított nem funkcionális követelményeknek való megfelelőségének ellenőrzését. Így a nem funkcionális tesztelés a program minden olyan tulajdonságának tesztelése, amely nem kapcsolódik a rendszer funkcionalitásához. Az ilyen tulajdonságokat olyan jellemzőkkel lehet bemutatni, mint például:
- Megbízhatóság (a rendszer azon képessége, hogy előre nem látható helyzetekre reagáljon).
- Teljesítmény (a rendszer azon képessége, hogy nagy terhelés mellett is működjön).
- Kényelem (az alkalmazás felhasználói élményének kutatása).
- Skálázhatóság (az alkalmazás függőleges és vízszintes méretezésének lehetősége).
- Biztonság (az alkalmazás megzavarásának és a felhasználói adatok behatolók általi ellopásának lehetőségének vizsgálata).
- Hordozhatóság (az alkalmazás átvitele egy adott platformcsoportra)

És még sok más tulajdonság.

Tesztelés felhasználói felület. Ezzel teszteljük a felhasználói felület elemeinek megfelelő megjelenítését különféle eszközök, a felhasználó által végrehajtott különféle műveletekre adott válaszuk helyessége, valamint a program egészének várható viselkedésének értékelése. Az ilyen tesztelés lehetővé teszi annak értékelését, hogy a felhasználó milyen hatékonyan tud majd dolgozni az alkalmazással, és hogyan kinézet pályázat megfelel a tervezők által készített jóváhagyott dokumentumoknak. A felhasználói felület tesztelésekor a tesztelő fő feladata az alkalmazás grafikus felületének vizuális és szerkezeti hibáinak azonosítása, az alkalmazásban történő navigáció lehetőségének és egyszerűségének, valamint az alkalmazás billentyűzetről, egérről, ill. egyéb beviteli eszközök. A felhasználói felület tesztelése azért szükséges, hogy az interfész megfeleljen a jóváhagyott követelményeknek és szabványoknak, és hogy a felhasználó tudjon dolgozni GUI alkalmazások.
· Használhatósági tesztelés. Ez egy olyan tesztelési módszer, amellyel értékelhető az alkalmazás használhatóságának foka, a felhasználó tanulási sebessége a programmal való munka során, és azt is, hogy a kifejlesztett termék felhasználói az adott körülmények között mennyire tartják érthetőnek és vonzónak. Az ilyen tesztelésre azért van szükség, hogy az alkalmazással végzett munka során a lehető legpozitívabb felhasználói élményt biztosítsuk.
· Biztonsági tesztelés. Lehetővé teszi a fő szoftver sérülékenységek azonosítását a behatolók különféle támadásaival kapcsolatban. Számítógépes rendszerek gyakran kibertámadásoknak vannak kitéve az információs rendszer működőképességének megzavarása vagy bizalmas adatok ellopása érdekében. A biztonsági tesztelés lehetőséget ad a rendszerben alkalmazott védelmi mechanizmusok tényleges reakciójának és hatékonyságának elemzésére behatolási kísérlet esetén. A biztonsági tesztelés során a tesztelő ugyanazokat a műveleteket próbálja végrehajtani, amelyeket egy igazi cracker végezne. Amikor egy tesztelő megpróbálja feltörni a rendszert, bármilyen eszköz használható: támadások a rendszer ellen speciális közművek; külső eszközök segítségével próbálja megtanulni a bejelentkezéseket és jelszavakat; DDOS támadások; a hibák céltudatos generálása a rendszerbe való behatolás lehetőségének észlelésére a helyreállítás folyamatában; ismert, javítatlan rendszersebezhetőségek kihasználása.
· Telepítési tesztelés. Ez a kifejezés egy bizonyos szoftvertermék telepítésének (telepítésének) helyességének tesztelését jelenti. Az ilyen tesztelések általában mesterségesen kialakított környezetben zajlanak, annak érdekében, hogy meghatározzák a szoftver működési készenléti fokát. Az ilyen tesztek végrehajtásának fő okai a szoftvertermék megfelelő viselkedésének ellenőrzésének szükségességei az automatikus telepítés vagy frissítés során. A szoftver helyes telepítésének és stabilitásának biztosítása nagyon fontos tényező a szoftvertermék létrehozása során, mivel ez lehetővé teszi a felhasználók számára, hogy gyorsabban és kevesebb erőfeszítéssel kezdjék el használni a terméket, ugyanakkor biztosítják, hogy a termék minden tesztelt szoftverkörnyezetben egyformán megfelelően működjön.
· Konfiguráció tesztelése. A konfiguráció tesztelése a szoftver teljesítményének értékelésére szolgál különféle rendszerkonfigurációk mellett. A tesztelt szoftvertermék típusától függően a konfiguráció tesztelésének különböző céljai lehetnek. Általában ez vagy az optimális hardverkonfiguráció meghatározása, amely elegendő teljesítményparamétert biztosít a szoftver működéséhez, vagy egy adott hardverkonfiguráció ellenőrzése (vagy egy olyan platform, amely a hardveren kívül a program működéséhez szükséges, harmadik féltől származó szoftvereket is tartalmaz). a tesztelt termékkel való kompatibilitás érdekében. Ha beszélgetünk a kliens-szerverről szoftver, akkor a konfiguráció tesztelése külön a szerver és külön a kliens számára történik. Általában egy adott konfigurációval rendelkező szerver kompatibilitás tesztelésekor az optimális konfiguráció megtalálása a feladat, hiszen a szerver stabilitása és teljesítménye fontos. Míg a kliens tesztelésekor éppen ellenkezőleg, megpróbálják azonosítani a szoftverhibákat bármilyen konfigurációban, és lehetőség szerint kiküszöbölni azokat.
· Megbízhatóság és meghibásodások utáni helyreállítás tesztelése (stressz teszt). Az ilyen típusú tesztelést gyakran olyan szoftvereknél végzik, amelyek értékes felhasználói adatokkal dolgoznak, és amelyek működésének folyamatossága és a meghibásodásokból való felépülés gyorsasága kritikus a felhasználó számára. A meghibásodási és helyreállítási tesztek tesztelik a program azon képességét, hogy gyorsan és sikeresen helyreálljon hardverhibák, hálózati kimaradások vagy magának a szoftvernek a kritikus hibái után. Ez lehetővé teszi a meghibásodás lehetséges következményeinek és a rendszer későbbi helyreállításának időigényének felmérését. A tesztelés során nyert adatok alapján a rendszer egészének megbízhatósága értékelhető, és nem megfelelő teljesítmény esetén megfelelő intézkedésekkel lehet javítani a helyreállítási rendszereket.
Lokalizációs tesztelés. A lokalizációs tesztelés lehetővé teszi annak kiderítését, hogy a termék mennyire alkalmazkodik egyes országok lakosságához, és hogyan felel meg kulturális sajátosságainak. Általában a kulturális és nyelvi árnyalatokat veszik figyelembe, nevezetesen a felhasználói felület, a kapcsolódó dokumentáció és fájlok nyelvre fordítását, valamint a pénznemek, számok, idők és telefonszámok formátumának helyességét is tesztelik.
· Stresszteszt. A terhelési tesztelés lehetővé teszi, hogy azonosítsa a program által párhuzamosan végrehajtható azonos típusú feladatok maximális számát. A kliens-szerver alkalmazások kontextusában a terheléstesztelés legnépszerűbb célja az alkalmazás szolgáltatásait egyidejűleg igénybe vehető felhasználók maximális számának becslése.
· Stabilitásvizsgálat. A stabilitási tesztelés ellenőrzi az alkalmazás teljesítményét hosszú távú használat során közepes terhelés mellett. Az alkalmazás típusától függően bizonyos követelményeket támasztanak a megszakítás nélküli működés időtartamára. A stabilitásteszt célja az olyan alkalmazásproblémák azonosítása, mint például a memóriaszivárgás, a súlyos terhelési kiugrások és egyéb olyan tényezők, amelyek megakadályozhatják az alkalmazás hosszabb ideig történő működését.
· Térfogatvizsgálat. A volumenteszt feladata az alkalmazás reakciójának azonosítása és a szoftver működésében bekövetkező esetleges romlás értékelése az alkalmazás adatbázisban lévő adatmennyiség jelentős növekedésével. Általában ez a teszt a következőket tartalmazza:
- Adatbázis-adatok megszerzéséhez vagy módosításához kapcsolódó műveletek végrehajtási idejének mérése meghatározott intenzitású kérések esetén.
- A műveleti idő növekedésének az adatbázisban lévő adatmennyiségtől való függésének azonosítása.
- Azon felhasználók maximális számának meghatározása, akik egyidejűleg dolgozhatnak az alkalmazással anélkül, hogy az adatbázisból észrevehető késések keletkeznének.
Skálázhatósági tesztelés. Ez egy olyan szoftvertesztelés, amelyet arra terveztek, hogy tesztelje a termék azon képességét, hogy növelje (néha csökkentse) bizonyos nem funkcionális funkciók hatókörét. Bizonyos típusú alkalmazásoknak könnyen méretezhetőnek kell lenniük, és természetesen működőképesnek kell maradniuk, és támogatniuk kell egy bizonyos felhasználói terhelést.

Változással kapcsolatos tesztelés

A Sanity a tesztelés egyik fajtája, melynek célja egy adott funkció vagy modul teljesítményének bizonyítása a megrendelő által deklarált műszaki követelményeknek megfelelően. Az egészségügyi tesztelést gyakran használják egy program vagy alkalmazás egy részének ellenőrzésére, amikor bizonyos változtatásokat hajtanak végre a környezeti tényezők. Ez a típus a tesztelés általában manuálisan történik.
· A füstteszt egy rövid tesztciklus, melynek célja, hogy megbizonyosodjon arról, hogy a telepítendő alkalmazás az új vagy szerkesztett kód felépítése után elindul és végrehajtja a funkciókat. Az alkalmazás legfontosabb szegmenseinek tesztelésének befejezése után objektív információ áll rendelkezésre a tesztelt szegmensek működésében fellépő hibák meglétéről vagy hiányáról. A füstvizsgálat eredményei alapján döntenek arról, hogy a kérelmet felülvizsgálatra küldik-e, vagy szükséges-e további teljes körű vizsgálat.
· Regressziós tesztelés - olyan tesztelés, amely a már tesztelt területeken hibák feltárására irányul. A regressziós tesztelés ellenőrzi, hogy a termékben vannak-e olyan hibák, amelyek a program új szakaszának hozzáadása vagy más hibák javítása miatt származhatnak. Az ilyen típusú tesztelés célja annak biztosítása, hogy a build frissítése vagy a hibák javítása ne vezessen új hibákhoz.

Tesztszinten

· Egységteszt (Unit tests). Ez abból áll, hogy minden egyes modult (a rendszer eredeti elemét) egy mesterséges környezetben végzett automatizált tesztekkel ellenőriznek. Az ilyen tesztek megvalósítása gyakran különféle csonkokat és illesztőprogramokat használ, hogy utánozza egy valós rendszer működését. Az egységautomatizált tesztelés az első lehetőség a forráskód futtatására és tesztelésére. Egységtesztek létrehozása a rendszer összes moduljához lehetővé teszi, hogy nagyon gyorsan azonosítsa a kódban előforduló hibákat, amelyek a fejlesztés során jelentkezhetnek.
· Integrációs tesztelés. Ez a rendszer egyes moduljainak tesztelése a helyes interakció érdekében. Az integrációs tesztelés fő célja a hibák felkutatása és a modulok közötti interakció értelmezésének vagy megvalósításának hibáihoz kapcsolódó helytelen viselkedés azonosítása.
· Rendszertesztelés. Ez a program egészének tesztelése, ez a tesztelés ellenőrzi, hogy a program megfelel-e a megadott követelményeknek.
· Átvételi tesztelés. Ez egy átfogó teszt, amely meghatározza a rendszer tényleges készenléti szintjét a végfelhasználók általi működésre. A tesztelés a rendszer fő üzleti műveleteit lefedő tesztforgatókönyvek alapján történik.

Kód végrehajtásával

· Statikus tesztelés. Ez a szoftvertermék fejlesztése során megjelenő műtermékek azonosítása a forrásfájlok, például a dokumentáció vagy a programkód elemzésével. Az ilyen tesztelés a kód közvetlen futtatása nélkül történik, a forrásfájlok minőségét és a követelményeknek való megfelelést manuálisan vagy segédeszközök segítségével értékelik. A statikus tesztelést a dinamikus tesztelés előtt kell elvégezni, így a statikus tesztelés során talált hibák olcsóbbak. Szempontból forráskód, a statikus tesztelést kódrevízióban fejezzük ki. Általában a kód átdolgozása egyedi fájlokat A programozó ezeknek a fájloknak minden módosítása után elvégzi, magát a revíziót egy másik programozó és a vezető fejlesztő, vagy a kód átdolgozásában részt vevő egyéni alkalmazott is elvégezheti. A statikus tesztelés lehetővé teszi a szoftver minőségének fenntartását a fejlesztés minden szakaszában, és csökkenti a termékfejlesztés idejét.
· Dinamikus tesztelés. A statikus teszteléssel ellentétben ez a fajta tesztelés magában foglalja az alkalmazás forráskódjának futtatását. Így a dinamikus tesztelés számos más típusú tesztelést is tartalmaz, amelyeket fentebb már leírtunk. A dinamikus tesztelés lehetővé teszi a program működésében fellépő hibák azonosítását a végrehajtás eredményeinek elemzésével. Kiderült, hogy szinte minden létező tesztelési típus megfelel a dinamikus tesztelési osztálynak.

A vizsgálat tárgya szerint

· Alfa tesztelés. Ez a teszt a legtöbb korai változatai számítógépes szoftver (vagy hardvereszköz). Az alfatesztelést szinte mindig maguk a szoftverfejlesztők végzik. Az alfatesztelés során az alkalmazásfejlesztők megtalálják és kijavítják a programhibákat és problémákat. Általában az Alpha tesztelés során a teljes munkaidős fejlesztők utánozzák a programmal végzett munkát, ritkábban mind a potenciális felhasználók, mind az ügyfelek valódi munkát végeznek a termékkel. Az alfa-tesztelést általában a szoftverfejlesztés legkorábbi szakaszában végzik el, azonban ben egyedi esetek kész vagy már kész termékre alkalmazható, például átvételi tesztként.
· Bétatesztelés. Egy még fejlesztés alatt álló termék tesztelése. A béta tesztelés során ez a termék korlátozott számú felhasználó számára elérhető a felhasználók által tapasztalt felmerülő problémák kivizsgálása és jelentése érdekében. Az ilyen tesztelésekre azért van szükség, hogy megtalálják azokat a hibákat, amelyeket a fejlesztők esetleg figyelmen kívül hagytak. A bétatesztelés általában két fázisban zajlik: zárt béta tesztelés és nyílt béta tesztelés. A zárt bétateszt a kiválasztott felhasználók szigorúan korlátozott körén tesztel. Ilyen felhasználók lehetnek ismerős fejlesztők vagy kollégáik, akik nem állnak közvetlenül kapcsolatban a tesztelt termék fejlesztésével. A nyílt béta tesztelés a létrehozásról és a tárolásról szól nyílt hozzáférésű nyilvános béta. BAN BEN ez az eset Bármely felhasználó lehet bétatesztelő. Visszacsatolás Az ilyen bétatesztelőkből az oldalon található áttekintések és a programba épített felhasználói műveletek analitikai és naplózó rendszerei segítségével történik, ezek a rendszerek szükségesek a felhasználói viselkedés elemzéséhez, a felmerülő nehézségek és hibák észleléséhez.

A forgatókönyv pozitivitása szerint

· Pozitív teszt. A pozitív forgatókönyv-tesztek azt tesztelik, hogy egy program képes-e végrehajtani a tervezett funkcióit. Általános szabály, hogy az ilyen teszteléshez tesztforgatókönyveket dolgoznak ki, amelyek során a szoftver normál működési feltételei között nem merülhetnek fel nehézségek.
· Negatív teszt. Negatív szoftvertesztelés történik olyan forgatókönyveknél, amelyek a program rendellenes viselkedésének felelnek meg. Az ilyen tesztek vészhelyzetekben ellenőrzik a program helyességét. Ez lehetővé teszi, hogy megbizonyosodjon arról, hogy a program a megfelelő hibaüzeneteket generálja, nem sérti a felhasználói adatokat, és általában megfelelően viselkedik olyan helyzetekben, amelyekben a termék normál viselkedése nem a szándékos. A negatív tesztelés fő célja a rendszer különböző hatásokkal szembeni stabilitásának tesztelése, a bemeneti adatok helyes érvényesítésének és a kivételek kezelésének képessége, amelyek magukban a szoftveralgoritmusokban és az üzleti logikában egyaránt előfordulnak.

Az automatizáltság foka szerint

· Kézi tesztelés. A kézi tesztelés további eszközök használata nélkül történik szoftver eszközök, lehetővé teszi egy program vagy webhely tesztelését a felhasználói műveletek szimulálásával. Ebben a modellben a tesztelő felhasználóként működik, bizonyos forgatókönyveket követve, miközben elemzi a program kimenetét és általában a viselkedését.
· Automatizált tesztelés. Az ilyen tesztelés a tesztek automatizálására szolgáló további szoftverek használatával jelentősen felgyorsítja a tesztelési folyamatot. Az ilyen kiegészítő szoftverek lehetővé teszik a tesztek végrehajtásának ellenőrzését és kezelését, valamint a program várható és tényleges eredményeinek összehasonlítását. További részletekről később lesz szó.

A cikket a fórumon érkezett kritikák és ajánlások figyelembevételével módosítottuk.

Ezzel a cikkel szeretném leírni a szoftvertesztelési ismereteimet – a folyamat nem triviális, ahogy mindig is gondoltam, és el sem tudtam képzelni, nagyon érdekes.

Mindig is érdekelt, mi az a szoftvertesztelés. Miért fogadjunk fel valakit egy szoftvertermék tesztelésére, ha a fejlesztő maga is el tud tölteni pár órát egy ilyen alacsony prioritású feladattal. És végül: minek egyáltalán tesztelni? Végül is a programozók okos srácok – helyesen írnak. De

nem minden olyan egyszerű, mint amilyennek nekem tűnt.

Miután programozókból tesztelőkké váltam, nem volt elég elmélet a keblemben, sokáig próbáltam "megtörni" a szoftverterméket, szándékosan hibás bemeneti adatokat adva meg a bemenetnek. És furcsa módon elromlott. Hibaüzenet jött létre, és a következő nap jól megéltnek számított.

Később kezdtem szembesülni azzal a ténnyel, hogy akárhány tesztet futtatsz, a hibák továbbra is előkerülnek. Mivel fogalma sem volt arról, hogy mit és hogyan kell "inputként" megadni a tesztelt alkalmazáshoz, a tesztelési folyamat végtelennek tűnt. Ennek eredményeként - egy ördögi kör, amelyben a megszakadt határidők tesztelése, dühös PM és a fejlesztők fáradt a "nonszensz".

És csak sokkal később választottam ki magamnak egy világos műveletsort, amelyet el kell végezni a szoftver teszteléséhez:

A specifikáció tanulmányozása. Ez a szakasz a legfontosabb, és tervezési és/vagy követelményelemzésnek is nevezik. Néha a „specifikációs tesztelés” elnevezést használják, kicsit később megértjük, miért „tesztelés”. Itt gondosan el kell olvasnia az alkalmazás dokumentációját (specifikációját).
Füstvizsgálat. Ebben a szakaszban ellenőrizni kell, hogy a rendszer működik-e egyáltalán (megfelelően működik-e, helyesen „esküszik”, ha nem megfelelően van feldolgozva stb.). Ennek célja annak megértése, hogy az alkalmazás alkalmas-e további tesztelésre, vagy egyáltalán nem működik (nem működik megfelelően).
"Pozitív" teszt. Ebben a harmadik szakaszban ellenőriznie kell az alkalmazás eredményét, amikor megkapja a „helyes” bemeneti adatokat.
"Negatív" teszt. Ez a kezdeti tesztelés negyedik és egyben utolsó szakasza. Itt meg kell nézni, hogyan viselkedik az alkalmazás, „helytelen” adatokat kapva bemenetként. Ennek célja annak meghatározása, hogy az alkalmazás hogyan viselkedik ilyen esetben. Ha a specifikációban le van írva egy ilyen lehetőség, és le kell írni, akkor hasonlítsa össze a várt eredményt a kapott eredménnyel.

Tehát vegyünk mindent rendben.

Specifikáció, követelmények, SRS.

Hogyan határozható meg, hogy magának az alkalmazásnak mikor és hogyan kell működnie, mikor és hogyan kell „törnie” (vagyis hogyan reagáljon a rendszer vagy modulja érvénytelen adatokra vagy helytelen felhasználói viselkedésre)? Mi legyen a helyes feldolgozás eredménye, milyen feltételek mellett és milyen bemeneti adatok esetén történjen helyes feldolgozás? Mi lehet az eredménye a vizsgált kérelem hibás feldolgozásának, milyen feltételek mellett kell történnie?

Mindezekre a kérdésekre választ ad a tesztelés alatt álló pályázat dokumentációja. Mindenesetre neki, a válasznak ott kell lennie, különben nem teljes a dokumentáció, ami egyenlő a dokumentáció hibájával. Fenntartást szeretnék tenni, hogy már ebben a szakaszban előfordulhatnak az első hibák - a specifikáció hibája (a követelményekben) ugyanolyan fontos a rendszer számára (és néha magasabb prioritás szerint!) hiba. Érdemes megemlíteni azt is, hogy a követelmények tesztelése egy olyan teljes értékű tesztelés, amelyre méltatlanul kevés figyelmet fordítanak. A követelmények sikeres tesztelésének fő mutatója a teljesség (tesztelhetőség) és a követelmények következetessége kritériumainak teljesítése.

A dokumentáció lehetővé teszi, hogy Ön is megértse az alkalmazás ellenőrzésének fő lépéseit, hol és hogyan kell az alkalmazásnak működnie, hol „törik el”. És nem utolsósorban Hogyan szünet. Mit kell „mondani” sikeres feldolgozás esetén, milyen hibaüzenetek jelenhetnek meg/kell megjelenniük a feldolgozás során.

Miután megértette az alkalmazás követelményeinek összes "bölcsességét", és e követelmények fejlesztő általi végrehajtásának jellemzőit, megkezdheti a végeredmény tesztelését.

Tesztelési folyamat

Ez a folyamat a következő lépésekkel írható le:

Ellenőrizze, hogyan működik az alkalmazás, amikor „helyes” adatokat kap bemenetként (hogy megtudja, „mi a jó és mi a rossz”, olvassuk el a dokumentációt);
Ha minden működik és megfelelően működik (azaz pontosan a specifikációban leírtak szerint), a következő lépés a határértékek ellenőrzése (vagyis hol kezdődik a "helyes" adat, és hol ér véget);
Az alkalmazás működésének ellenőrzése olyan adatok megadásakor, amelyek nem szerepelnek az érvényes értékek tartományában (lásd ismét a specifikációt).

Az első és a második bekezdés a „pozitív” tesztelésnek nevezett folyamatot írja le. A „pozitív” tesztelés olyan adatokon vagy forgatókönyveken végzett tesztelés, amelyek megfelelnek a tesztelt rendszer normál (szokásos, várható) viselkedésének.

A harmadik pont a „pozitív” folyamattal ellentétes folyamatot írja le – a „negatív” tesztelést. Ez olyan adatok vagy forgatókönyvek tesztelése, amelyek megfelelnek a tesztelt rendszer rendellenes viselkedésének – különféle hibaüzenetek, kivételek, „túllépő” állapotok stb.

A „pozitív” és „negatív” tesztet azonban „füst” tesztnek kell megelőznie.

Az Információs szótár meglehetősen világosan meghatározza a „füstvizsgálat” fogalmát:

a szoftvertermék tesztelésének kezdetleges formája a konfiguráció megváltoztatása vagy magának (a szoftverterméknek) a megváltoztatása után. A füstteszt során a tesztelő ellenőrzi a szoftvert „füst” jelenlétére, pl. keresi bármelyiket kritikus hibák programok;
a program első futtatása a feltörés vagy „felépítés” után.

Prioritások a tesztelés során

Miért tekintik a „pozitív” tesztelést egy nagyságrenddel fontosabbnak, mint a „negatív” tesztet?

Tegyük fel, hogy a rendszer nem túl ellenálló a "rossz" bemenetekkel szemben. Ez félelmetes? Gyakran nem túl sokat. A felhasználók előbb-utóbb megtanulják kikerülni a "csapdákat", nem fognak "veszélyes" vagy "jogosulatlan" műveleteket végrehajtani, a szolgáltatás technikai támogatás hamarosan eszébe jut, hogy a felhasználók milyen problémákkal küzdenek, és olyan tanácsokat ad, mint „semmi esetre se hagyja üresen ezt a mezőt, különben…”.

De - mindez egyáltalán nem fog megtörténni, ha a rendszer nem tölti be fő célját, ha a felhasználók (ügyfelek) nem tudják megoldani üzleti problémáikat, ha mindent jól csinálnak, jó adatokat adnak meg, de nem érnek el eredményt. És ebben a helyzetben nincs mit tanácsolni nekik. És elmennek...

Ezért van az, hogy a "pozitív" tesztelés sokkal, de sokkal fontosabb, mint a "negatív" teszt.

Ez azonban nem jelenti azt, hogy a "negatív" tesztek elhanyagolhatók, mert. a szoftver életciklusának nem minden szakaszában, az értékek prioritásai változatlanok maradnak.

Összegzés

Most, miután megtette az első sikeres lépéseket az alkalmazás tesztelésében, és pozitív eredményt kapott, kifinomultabb módszerekre gondolhat az alkalmazás tesztelésére, ahogy mondják: "Továbbiak - tovább." Minden a szükséges tesztelési szint mélységétől, az alkalmazás tesztelésének vágyától és képességétől függ. Természetesen a fent leírt négy szakasz nem fedi le a teljes alkalmazástesztelési ciklust, de a kezdeti teszteléshez kötelezőek.

Mi (ez nem is olyan titok) nagyon aggódunk termékeink minősége miatt, és megrendülten figyeljük a rendszer összeomlását. Ez igazolja a tesztelők létezését a világban. Hősöknek érezzük magunkat: eljött a nagyszerű Tesztelő, és megmentette a felhasználóit a szörnyű kritikus hibáktól!

Tesztelőink pedig soha nem feledkeznek meg a negatív tesztekről, bár nem minden prognó örül ennek. De az ilyen ellenőrzések nem a "gonosz tesztelők" szeszélyei, hanem a sebezhetőségek bezárásának szükségessége, és meg kell védeni magát a rendszerbe belépő hackerek és botok, Dos / DDos támadások ellen.

Persze, mi a hivatása a tesztspecialistáknak? Meg kell találni a problémákat. Problémák, amelyekre a legtöbbször senkinek nincs ideje gondolkodni, nem akarja látni és foglalkozni velük. Ha pedig nem csak a rendszer megfelelő működését, hanem a rendellenes viselkedését is ellenőrizzük, akkor a csapatban feszültség lép fel.

Ugyanis a programozók az eredményt, a tervezett kiadást célzó szoftvereket írnak, az ihlet szárnyán repülnek! És ezután jön az ellenőrzés szakasza, valamint az "ideális" kód számos javítása és szerkesztése. És ennyi, bújj el minden irányba, a rendszer tesztelése folyamatban van.

Annak érdekében, hogy senkit ne bosszantsanak, egyes szakemberek későbbre halaszthatják a negatív tesztet, vagy teljesen figyelmen kívül hagyhatják (horror!) Az idő és a költségvetés csökkentése érdekében. Nos, minek ellenőrizni, ha a program nem is azt csinálja, amit kellene, igaz? Dehogy.

Pozitív és negatív teszt

De először a dolgok. A szoftver tesztesetekkel történő tesztelésekor kétféle ellenőrzés létezik: pozitív és negatív. És a második általában több, mint az első.

pozitív teszt- ez annak ellenőrzése, hogy a rendszer megfelel-e normál (szokásos, elvárt) viselkedésének, a TOR és a. Vagyis itt azt nézzük, hogy a szoftver azt csinálja-e, amit elvárnak tőle, a megvalósítás megfelel-e a modern követelményeknek, támogatottak-e a felhasználói felület irányelvei stb.

A negatív teszt- Ez a rendszer abnormális viselkedését teszteli. Megvizsgáljuk, hogy a szoftver ellenáll-e a helytelen adatbevitelnek, hogyan kezelik a kivételeket, milyen információk jelennek meg a hibaüzenetekben, lehetséges-e megzavarni a termék működését és/vagy befolyásolni a megoldás teljesítményét stb. .

Már mondtuk, hogy egyes szakértők a negatív tesztet későbbre hagyják, vagy teljesen megfeledkeznek róla, ami szinte ugyanaz. Tudod, amit későbbre halasztanak, az szinte mindig beteljesületlen marad.

Ezért véleményünk szerint

A negatív és a pozitív teszteket általában nem kell szétválasztani és idővel szétosztani.

Mert meg tudjuk állapítani, hogy egy rendszer úgy működik, ahogyan kell, ha csak a megfelelő bemenetekre teszteljük a válaszát?

pozitív-negatív teszt

Tesztelésekor ó, milyen fontosak az intuíció, az érzés, a vadászösztönek – nevezd, ahogy akarod. És itt ül egy ilyen mérnökünk, ellenőrzi például a regisztrációs lapot.

Mindent a műszaki előírásoknak és a tesztforgatókönyveknek megfelelően ellenőrzi, megnézi, hogyan dolgozzák fel az adatokat, amiket a felhasználónak be kell írnia a mezőkbe (nem mellesleg azt, hogy beírja) és tessék - insight! Úgy tűnik neki, hogy ha ebbe a bejelentkezési mezőbe beír egy „% adynadyn />”-t, és nem egyszerű szöveget, akkor valami biztosan történik. Valami sötét és komor rossz.

És akkor? Azt kell mondania magának: „Nem. Most pozitív tesztet kell csinálnom és semmi mást. Itt jövő hétre van beütemezve egy negatív, akkor jön el az idő% adynadyn />. Talán"?

Úgy véljük, hogy ez a negatív teszt megközelítése hatástalan, és a következő okok miatt:

Ha külön-külön végez pozitív és negatív tesztet, akkor hosszabb lesz. Legalábbis azért, mert két iteráció lesz a tesztelés.
A tesztelők és a kódolók élnek a határidőkkel. És ha az idő szigorúan korlátozott, akkor a negatív teszt későbbi elhalasztása növeli annak a kockázatát, hogy azt teljesen elfelejtik. Végtére is, minél közelebb van az X pillanathoz, annál gyorsabban repül az idő, annál hamarabb kell elvégeznie a feladatokat, kijavítani a hibákat, alkalmaznia kell a végső üzleti követelményeket (amelyek változhatnak) és egy csomó egyéb dolgot. Határidő - forró az idő!
A negatív és pozitív teszt szétválasztása véleményünk szerint egyszerűen ellentétes a tesztelő természetével! Végül is a fő feladata a rendszer ellenőrzése lehetséges cselekvések végfelhasználó. És az emberek többnyire logikátlanok, és sokféle illetlen dolgot tudnak csinálni a szoftverekkel;)

Mi, mint tesztelők nagyon aggódunk, ha a rendszer a negatív kategóriájú ellenőrzéseknél hibákat tartalmaz. És különösen, ha az ilyen hibák következményei kritikusak az egész rendszerre nézve. De nem félünk feljelenteni őket. Főleg egy ilyen trükk mellett – vannak női tesztelők a csapatunkban. És ki tudja makacsul megvédeni a kód „idealitását”, amikor szelíd hangokkal zúzzák szét a projekt teljesítményét? Ez ugyanaz.

Tehát milyen következtetéseket vonhatunk le?

Ne feledkezzen meg a negatív tesztekről, kombinálja pozitív tesztekkel, gyűjtsön csapatba tapasztalt szakembereket, és próbálja meg a lányok vállára hárítani a jelentéskészítés feladatát! Az utolsó kivételével minden 100%-ban ajánlott, és ezzel a projektvezetője fog foglalkozni.

És persze mindenképp nézd meg a termékedet, ne gondold, hogy a programozók azonnal tiszta és szép kódot írnak – bugok nélkül továbbra sem lehetsz! Nem beszélve a számos sebezhetőségről, amit a hálózatba rendszeresen kiszivárgó személyes és bizalmas adatok is megerősítenek.

Miért végeznek pszichológiai teszteket az emberek? Természetesen mindenkinek megvannak a saját indítékai. Valaki meg akarja érteni önmagát, és „meg akarja érteni, mi vagyok”. Valaki alig várja, hogy megerősítse a jelleméről uralkodó véleményt. Valaki csak megöli a szabadidejét és szórakozik. De mindenki, bár sokszor anélkül, hogy észrevenné, vagyis tisztán, valami jót akar hallani magáról. Miért? Igen, és ez feldobja a hangulatot. Az általunk kínált tesztnek az egyetlen célja, hogy egy csepp pozitívumot hozzon jelenlegi állapotába. Valójában ez egyáltalán nem teszt, hanem valami pozitív előrejelzés. És ezek, mint tudod, nagyon gyakran valóra válnak!

06.10.2018 16947 +67

Szeretné tudni, hogy mások hogyan látják a nevét? Ingyenes online szolgáltatás A fonoszemantikus elemzés lehetővé teszi, hogy megtudja, hogyan érzékelik egy adott szót a tudatalatti szinten. Ezzel például nevet választhat egy gyereknek vagy nevet egy cégnek.
Tudja meg, hogyan fog érezni magát egy hónap múlva! Jelenleg oldalunkon teljesen ingyenesen kiszámolhatja bioritmusait. A számítás eredménye alapján személyes ajánlásokat és ütemtervet kap a bioritmus megváltoztatására a következő hónapra.
Népszerű pszichológiai tesztek Hatalmas számú népszerű pszichológiai teszt minden ízléshez. Férfiaknak, nőknek, ezoterikus, profi... És mindezt online, ingyen és regisztráció nélkül!

Nagyon aggódik a termékek minősége miatt. Ez magyarázza a szoftvertesztelők világszerte elérhetőségét. Azáltal, hogy ezek az emberek biztosítják annak minőségét.

Sok tesztelő soha nem felejti el a negatív tesztelést, bár nem minden programozó elégedett ezzel. Ilyen vezérlés szükséges a hackerek, botok, Dos/DDos támadások elleni védelemhez.

Mi a tesztelők hivatása? Meg kell találniuk azokat a problémákat, amelyek mások számára nem láthatók. Ne halogassa a negatív tesztet, mert ezzel veszélybe sodorja a rendszert.

Pozitív és negatív teszt

Kezdjük a legelejéről. Kétféle kontroll létezik, amikor a tesztesetek szerepelnek a tesztelésben: pozitív és negatív. Ez utóbbinak van előnye.

pozitív teszt a specifikációk és a dokumentáció szerinti helyes viselkedés ellenőrzésének folyamata. Pozitív tesztelés történik annak biztosítására, hogy a rendszer pontosan azt teljesítse, amit elvárnak.

Negatív tesztelés a helytelen viselkedés ellenőrzésének folyamata. Az ilyen tesztelések során megtanulhatjuk, hogy a rendszer megbirkózik az előre nem látható helyzetekkel.

pozitív-negatív teszt

A szoftvertesztelés végrehajtásához intuícióra vagy vadászösztönre van szüksége. A tesztelő sokoldalú személy, aki üzleti elemzést és tesztelést is tud végezni.

A tesztelők ellenőrzik, hogy a folyamat megfelelően fut-e: megfelelnek-e a műszaki követelményeknek és a tesztforgatókönyveknek. A pozitív és negatív tesztek külön-külön történő futtatása tovább tart, mint egyszerre. Ez azért van, mert két teszt iteráció van.

Végtére is, minél közelebb van az X óra, annál gyorsabban telik az idő, és annál hamarabb kell elvégeznie a feladatokat, kijavítania a hibákat, alkalmaznia kell az üzleti követelményeket (amelyek változhatnak), és minél többet kell tennie. A határidő a legmelegebb idő!

A negatív és pozitív tesztek elkülönítése egyszerűen ellenkezik a tesztelő természetével! Feladata, hogy ellenőrizze a rendszert a végfelhasználó minden lehetséges műveletére.

Az emberek alapvetően logikátlanok, és problémákat okozhatnak a szoftverekben. A negatív teszt segít elkerülni a problémákat.

Tematikus anyagok: