tesztmodell egy logikai struktúra, amely leírja a rendszer funkcionalitását és/vagy a felhasználói viselkedést, amely szerint tesztesetek generálódnak. A tesztmodell felépítése egy szerkezet felépítésével kezdődik, majd a jóváhagyott szerkezetet tesztesetekkel töltjük fel.

A modellek általában a követelmények és/vagy a rendszer elvárt viselkedése alapján készülnek. A tesztmodell felépítése és kezelése összetett üzleti logikával rendelkező nagy rendszerek számára alkalmas, és nehezen alkalmazható agilis módszertanokat alkalmazó projektekben, mert a tesztmodell-kezelési és minőségbiztosítási folyamat fenntartásának költsége túl magas lesz.

A tesztmodell-kezelés olyan folyamat, amely szabályozza a tesztmodell lefedettségét, a tesztmodellt leíró forgatókönyvek minőségét és annak aktualizálását.

A tesztmodell-kezelés végig folyamatos folyamat életciklus termék.

Tesztmodell lefedettsége

Az összes követelmény lefedettségének szabályozásához nyomkövetési mátrixokat használhat, amelyek meghatározzák a követelmények lefedettségét tesztforgatókönyvek szerint (lásd a példát).
A tesztesetek ismertetése előtt a tesztmodell felépítését jóvá kell hagyni az ügyféllel.

Szkript minősége

A forgatókönyvek minőségének kezeléséhez nem csak a tesztesetek leírásának szintjét kell ellenőrizni, hanem azok minőségét is.

A tesztesetek leírásának megkezdése előtt meg kell határozni az egyes leírási szintekre vonatkozó követelményeket és a tesztesetek leírásának minőségi kritériumait.

A tesztesetek leírásának lehetséges szintjei:

4. szinten a megrendelővel való megállapodás helyettesíthető megállapodással.

A tesztesetek leírásának minőségi kritériumai a következők lehetnek:

• A teszteseteket a követelményeknek megfelelően kell megírni

A tesztelés annak ellenőrzése, hogy egy termék megfelel-e a követelményeknek. Ezért a teszteset általános leírásának részében (a tesztkövető rendszerekben általában az „Összefoglalás” kifejezést használják) a követelményszöveg töredékeivel összefüggésben egy konkrét követelményre kell hivatkozni. Így a projekt minden résztvevője számára világos lesz a teszteset megírása alapján.

• Használja a részletes előfeltételeket

Hogyan takaríthat meg időt a tesztesetekkel?

Állítson be formázási szabályokat az összes tesztesethez. Így a teszteset könnyen érthető és olvasható lesz a projekt bármely résztvevője számára. Például egy projektnél a következő szabályokat adhatja meg:

• Minden bemeneti paramétert pirossal kell jelölni.
• Minden szkriptet kékkel kell kiemelni,
• A gombok, mezők, blokkok nevei dőlt és félkövér betűkkel vannak szedve.
• A fontos részek aláhúzottak.
• Minden végrehajtott lépésnek várt eredménnyel kell járnia.
• A tesztesetek minden lépése csak egy műveletet írjon le, és annak várható eredményét. Azok. amikor egy adott lépésben sikertelen tesztesetet kap, egyértelműen egyértelműnek kell lennie, hogy melyik műveletnél fordul elő a hiba.
• A várt eredménynek egyértelműnek kell lennie.

A teszteseteknek egyértelműnek kell lenniük, pl. úgy kell megfogalmazni és megfogalmazni, hogy ne tegyenek lehetővé félreérthető értelmezést, de minden résztvevő számára világosan érthetőek legyenek.

Ha a tesztesetek írása sokáig tart, akkor olyan helyzet állhat elő, amikor a szakember nem látja a hibáit. Ehhez oldalról kell néznie - itt ez segít keresztértékelés. Ezt a szakaszt olyan esetekben javasoljuk elvégezni, amikor egy tesztmodell kidolgozása időben elnyújtott és hosszú ideig tart. Például, ha a tesztforgatókönyvek kidolgozása több mint 1 hónapot vesz igénybe.

A szkript minőség-ellenőrzési folyamata végrehajtható tesztmodell vezérléssel- speciálisan elkészített sablon.

Tesztmodell frissítés

A követelményeknek való megfelelés érdekében rendszeresen frissíteni kell a tesztmodellt és magukat a teszteseteket, valamint felül kell vizsgálni a tesztesetek prioritásait.

Frissítéshez fenntarthat egy "követelménymátrixot"(Követelmény Nyomon követhetőségi mátrix): egy bizonyos követelmény minden változása után a tesztkövető rendszerből kiválasztásra kerül az ehhez a követelményhez kapcsolódó összes tesztforgatókönyv, amelyet frissítenek.

Tesztmodell vezérlői:

• próbavasút
• teszt link
• Jira+Zephyr
• Microsoft Test Manager (MTM)
• excel

A tesztelés olyan folyamat, amely lehetővé teszi az előállított termék minőségének értékelését. Egy jó minőségű szoftverterméknek meg kell felelnie a vele szemben támasztott követelményeknek, mind funkcionálisan, mind nem funkcionálisan. A PS-nek meg kell valósítania az összes szükséges VI-t, és nem lehetnek hibái - eltérések a valós tulajdonságok vagy viselkedés között az előírtaktól. Ezenkívül a PS-nek rendelkeznie kell a megbízhatóság (nem lehetnek leállások, összeomlások stb.), a biztonság, a kívánt teljesítményt, könnyen használható, bővíthető stb. tulajdonságokkal. Így a tesztelés a PS elemzésének folyamata. , amelynek célja a hibák azonosítása és a PS tulajdonságainak felmérése.

A tesztelési folyamat céljai

A tesztelés célja a minőség értékelése szoftver termék keresztül

• Az alkatrészek kölcsönhatásának ellenőrzése;
• Az alkatrészek helyes integrációjának ellenőrzése;
• Az összes követelmény végrehajtásának pontosságának ellenőrzése és a hibák azonosítása.

A tesztelési folyamat jellemzői a RUP-ban

A tesztelés egy iteratív folyamat az életciklus minden szakaszában. A tesztelés elölről kezdődik kezdeti szakaszban egy jövőbeli termék követelményeinek meghatározása és a jelenlegi feladatokkal való szoros integráció. Minden iterációhoz meghatározzák a tesztelés célját és az eléréséhez szükséges módszereket. Minden iteráció végén megállapítják, hogy ez a cél milyen mértékben valósult meg, szükség van-e további tesztekre, szükséges-e változtatni az elveken és a tesztelési eszközökön.

Minden talált hiba rögzítésre kerül a projekt adatbázisban, a helyzet leírásával együtt, amelyben megtalálták. Az elemző megállapítja, hogy ez valódi hiba, és hogy egy korábban felfedezett hiba megismétlődése-e. A talált hiba hozzárendelésre kerül prioritás A, amely a javítás fontosságát jelzi. Az alrendszer, alkatrész vagy osztály fejlesztéséért felelős tervező, vagy a menedzser által kijelölt más személy végzi el a hiba elhárítását. A hibák javításának sorrendjét azok prioritásai határozzák meg. A tesztelő megismétli a teszteket, és meg van győződve arról (vagy nincs meggyőződve), hogy a hibát kijavították.

Teszt fejlesztő a tesztek tervezéséért, fejlesztéséért és végrehajtásáért felelős. Vizsgálati tervet és modellt, vizsgálati eljárásokat készít (lásd alább), és kiértékeli a vizsgálati eredményeket.

tesztelő (tesztelő) felelős a rendszer teszteléséért. Feladatai közé tartozik a tesztek beállítása és végrehajtása, a tesztek teljesítményének értékelése, a hibák helyreállítása, valamint a feltárt hibák rögzítése.

Műtárgyak

A tesztelés során a következő dokumentumok jönnek létre:

Teszt terv– egy dokumentum, amely minden iterációban meghatározza a tesztelési stratégiát. Tartalmazza a tesztelés céljainak és célkitűzéseinek leírását az aktuális iterációban, valamint a használni kívánt stratégiákat. A terv jelzi, hogy milyen erőforrásokra lesz szükség, és felsorolja a teszteket.

Tesztmodell azt mutatja be, hogy mit és hogyan fognak tesztelni. A modell vezérlési feladatokat, tesztmódszereket, tesztforgatókönyveket és várt eredményeket (tesztesetek), tesztszkripteket és tesztinterakciók leírását tartalmazza.

• Ellenőrző feladat– tesztadatok, tesztvégrehajtási feltételek és várt eredmények összessége.
• Teszt módszer– az ellenőrzési feladatok felállítására és végrehajtására, valamint a kapott eredmények értékelésére vonatkozó utasításokat tartalmazó dokumentum.
• Teszt szkript- ez a teszt egyszerűsített leírása, amely tartalmazza a kezdeti adatokat, a feltételeket és a műveletek sorrendjét, valamint a várható eredményeket.
• Teszt szkript egy olyan program, amely teszteszközökkel végzett automatizált tesztelés során fut le.
• A teszt interakció leírása a sorozatok vagy együttműködések diagramja, amely a tesztkomponensek és a tesztobjektum közötti időben rendezett üzenetek áramlását tükrözi.

Vizsgálati eredményekés a tesztek végrehajtása során kapott adatok.

Munkaterhelési modell a végfelhasználók által végrehajtott külső funkciók, ezeknek a funkcióknak a hatókörének és a funkciók által generált munkaterhelésnek a modellezésére szolgál. A modell a rendszer valós körülmények közötti működését szimuláló terhelési és/vagy igénybevételi tesztek elvégzésére szolgál.

Hibák- ezek a tesztelés során megállapított követelményeknek való rendszer nem megfelelő tényállások leírásai. Ezek egyfajta változtatási kérelmek.

A tesztelési munkák minden iterációban minden fázisban megtörténnek, de a projekt különböző fázisaiban a célok és célkitűzések jelentősen eltérnek.

A projektbe való belépés fázisa. Ebben a fázisban történik a tesztelésre való felkészülés. Magába foglalja:

• Hozzon létre egy teszttervet, amely tesztkövetelményeket és tesztelési stratégiákat tartalmaz. Minden típusú teszteléshez (funkcionális, terhelési stb.) készíthető egyetlen terv, vagy minden típushoz külön terv.
• A tesztelés terjedelmének elemzése.
• Minőségi kritériumok megfogalmazása és a vizsgálatok elvégzése.
• Vizsgálóeszközök telepítése, üzembe helyezése.
• A PS fejlesztési projekt követelményeinek megfogalmazása, a tesztelési igények alapján.

Fejlesztési szakasz. Ennek a fázisnak az iterációiban megkezdődik a tesztmodell és a kapcsolódó műtermékek felépítése. Mivel a VI modell már jelen van ebben a fázisban, elkezdheti a tesztforgatókönyvek tervezését. Ugyanakkor nem célszerű teszteket végezni, mivel általában ebben a fázisban még nincsenek kész PS-töredékek. A következő tevékenységeket végzik:

• Tesztforgatókönyvek kidolgozása.
• Tesztszkriptek készítése.
• Ellenőrzési feladatok fejlesztése.
• Vizsgálati módszerek fejlesztése.
• Munkaterhelési modell kidolgozása.

Építési fázis. Ebben a fázisban megjelennek az elkészült rendszertöredékek, prototípusok, amelyeket tesztelni kell. Ugyanakkor szinte minden iterációban minden modult ellenőriznek (mind a korábban kifejlesztett, mind a tesztelt, illetve az új iterációban hozzáadott modulokat). A korábbi iterációk során alkalmazott teszteket a következő iterációkban is felhasználják regressziós tesztelésre, vagyis annak ellenőrzésére, hogy az új iterációban megmarad-e a korábban megvalósított rendszer funkcionalitása. A következő tevékenységeket végzik:

• Készítsen teszttervet minden iterációhoz.
• A tesztelési modell finomítása és kiegészítése.
• Tesztek végrehajtása.
• A talált hibák leírása.
• A vizsgálati eredmények leírása.
• A vizsgálati eredmények értékelése.

A tesztelés eredményei alapján a feltárt hibák kiküszöbölése érdekében változtatásokat hajtanak végre a programkódon, majd a tesztelést megismétlik.

Telepítési szakasz. Ennek a fázisnak az iterációi során a teljes PS-t szoftvertermékként tesztelik. Az elvégzett tevékenységek hasonlóak az előző szakasz tevékenységeihez. A hibaészlelés meghatározza a változtatások és az újratesztelés szükségességét. Az iteratív folyamatot addig ismételjük, amíg a teszt befejezési kritériumai teljesülnek.

A teszteredményeket olyan tesztelési mutatók alapján értékelik, amelyek lehetővé teszik a tesztelt PS minőségének és magának a tesztelési folyamatnak a meghatározását.

Instrumentális támogatás

Mivel az iteratív tesztelési folyamat a tesztek többszöri megismétlését foglalja magában, a kézi tesztelés hatástalanná válik, és nem teszi lehetővé a szoftvertermék minőségének alapos értékelését. Ez különösen igaz a terhelési és stressztesztekre, ahol szimulálni kell a munkaterhelést és jelentős mennyiségű adatot kell felhalmozni. A megoldást olyan eszközök használata jelenti, amelyek támogatják a tesztek összeállításának és végrehajtásának automatizálását.

A fejlesztési folyamathoz hasonlóan a szoftver utótesztelési folyamata is meghatározott módszertant követ. Módszertan alatt ebben az esetben az elvek, ötletek, módszerek és koncepciók különféle kombinációit értjük, amelyekhez egy projekten való munka során folyamodunk.

Jelenleg meglehetősen sok különböző megközelítés létezik a tesztelésre, mindegyiknek megvan a maga kiindulópontja, a végrehajtás időtartama és az egyes szakaszokban alkalmazott módszerek. Az egyik vagy a másik kiválasztása pedig komoly kihívást jelenthet. Ebben a cikkben megvizsgáljuk a szoftvertesztelés különböző megközelítéseit, és beszélünk főbb jellemzőikről, amelyek segítenek eligazodni a meglévő változatban.

Vízesés modell (Lineáris szekvenciális szoftver életciklus modell)

A Waterfall Model az egyik legrégebbi modell, amely nem csak szoftverfejlesztésre vagy tesztelésre használható, hanem szinte bármilyen más projekthez is. Övé alapelv a feladatok végrehajtásának sorrendje. Ez azt jelenti, hogy csak az előző sikeres befejezése után léphetünk tovább a következő fejlesztési vagy tesztelési lépésre. Ez a modell kis projektekhez alkalmas, és csak akkor alkalmazható, ha minden követelmény egyértelműen meghatározott. Ennek a módszernek a fő előnyei a következők gazdasági hatékonyság, egyszerű használat és dokumentációkezelés.

A szoftver tesztelési folyamata a fejlesztési folyamat befejezése után kezdődik. Ebben a szakaszban az összes szükséges teszt átkerül az egységekből a rendszertesztelésbe, hogy az alkatrészek működését külön-külön és összességében ellenőrizni lehessen.

A fent említett előnyök mellett ennek a tesztelési megközelítésnek vannak hátrányai is. Mindig fennáll a lehetőség, hogy kritikus hibákat találjunk a tesztelési folyamatban. Ez ahhoz vezethet, hogy teljesen meg kell változtatni valamelyik rendszerelemet vagy akár a projekt teljes logikáját. De egy ilyen feladat a vízesés modell esetében lehetetlen, mivel ebben a módszertanban tilos visszatérni az előző lépéshez.

Tudjon meg többet a vízesés modellről az előző cikkből..

V-modell (ellenőrzési és érvényesítési modell)

A vízesés modellhez hasonlóan a V-modell is egy közvetlen lépéssorozaton alapul. A fő különbség a két módszer között az, hogy a tesztelést ebben az esetben a megfelelő fejlesztési szakaszsal párhuzamosan tervezzük. Ezen szoftvertesztelési módszertan szerint a folyamat azonnal elindul, amint a követelmények meghatározásra kerülnek, és lehetővé válik a statikus tesztelés elindítása, pl. ellenőrzés és felülvizsgálat, amely elkerüli az esetleges szoftverhibákat a későbbi szakaszokban. A szoftverfejlesztés minden szintjéhez megfelelő tesztterv készül, amely meghatározza az adott termék várható eredményeit és belépési és kilépési kritériumait.

Ennek a modellnek a sémája a feladatok két részre osztásának elvét mutatja be. A tervezéssel és fejlesztéssel kapcsolatosak a bal oldalon helyezkednek el. A szoftverteszttel kapcsolatos feladatok a jobb oldalon találhatók:

Ennek a módszernek a fő lépései eltérőek lehetnek, de jellemzően a következőket tartalmazzák:

• Színpad követelmények meghatározásai. Az átvételi tesztelés ehhez a szakaszhoz tartozik. Fő feladata a rendszer végső felhasználásra való alkalmasságának felmérése.
• Az a szakasz, amelyben magas szintű tervezés vagy magas szintű tervezés (HDL). Ez a fázis a rendszer tesztelésére vonatkozik, és magában foglalja az integrált rendszerek követelményeinek való megfelelés értékelését.
• Részletes tervezési fázis(Részletes tervezés) párhuzamos az integrációs tesztelési fázissal, melynek során a rendszer különböző összetevői közötti interakciókat tesztelik.
• Után kódolási szakasz Egy másik fontos lépés kezdődik – az egységteszt. Nagyon fontos megbizonyosodni arról, hogy a szoftver egyes részeinek és összetevőinek viselkedése helyes és megfelel a követelményeknek.

A vizsgált tesztelési módszertan egyetlen hátránya, hogy hiányoznak a kész megoldások, amelyekkel a tesztelési fázis során feltárt szoftverhibáktól megszabadulni lehetne.

inkrementális modell

Ez a módszer több kaszkádos szoftvertesztelési modellként írható le. A munkafolyamat több ciklusra van felosztva, amelyek mindegyike szintén modulokra oszlik. Minden iteráció bizonyos funkciókat ad a szoftverhez. A növekedés három ciklusból áll:

1. tervezés és fejlesztés
2. tesztelés
3. végrehajtás.

Ebben a modellben lehetőség van a termék különböző verzióinak egyidejű fejlesztésére. Például az első verzió tesztelési fázisban lehet, míg a második verzió fejlesztés alatt áll. A harmadik verzió ezzel egy időben mehet át a tervezési fázison. Ez a folyamat a projekt végéig folytatódhat.

Nyilvánvaló, hogy ez a módszertan megköveteli, hogy a lehető legtöbb hibát a lehető leggyorsabban észleljék a tesztelt szoftverben. Valamint a megvalósítási szakasz, amelyhez a végfelhasználóhoz eljuttatott termék készenlétének megerősítése szükséges. Mindezek a tényezők jelentősen növelik a tesztelési követelmények súlyát.

A korábbi módszertanokhoz képest az inkrementális modell számos fontos előnnyel rendelkezik. Rugalmasabb, a követelmények változása csökkenti a költségeket, a szoftvertesztelési folyamat pedig hatékonyabb, mivel a tesztelés és a hibakeresés sokkal egyszerűbb kis iterációkkal. Azt azonban érdemes megjegyezni összköltsége még mindig magasabb, mint a kaszkád modell esetében.

spirál modell

A spirálmodell egy szoftvertesztelési módszer, amely inkrementális megközelítésen és prototípus-készítésen alapul. Négy szakaszból áll:

1. Tervezés
2. Kockázatelemzés
3. Fejlődés
4. Fokozat

Közvetlenül az első ciklus befejezése után kezdődik a második. A szoftvertesztelés a tervezési szakaszban kezdődik és az értékelési szakaszig tart. A spirálmodell fő előnye, hogy minden ciklus harmadik szakaszában a vizsgálatok eredménye után azonnal megjelennek az első vizsgálati eredmények, ami segít a minőség helyes értékelésében. Fontos azonban szem előtt tartani, hogy ez a modell meglehetősen drága lehet, és nem alkalmas kis projektekhez.

Bár ez a modell meglehetősen régi, továbbra is hasznos a tesztelés és a fejlesztés szempontjából. Továbbá, a fő cél számos szoftvertesztelési módszer, köztük a spirálmodell is megváltozott a közelmúltban. Nemcsak az alkalmazások hibáinak feltárására használjuk őket, hanem arra is, hogy kiderítsük azokat az okokat, amelyek ezeket okozták. Ez a megközelítés segít a fejlesztőknek hatékonyabban dolgozni és gyorsan kijavítani a hibákat.

A spirálmodellről bővebben az előző blogbejegyzésben olvashat..

Agilis

Az agilis szoftverfejlesztési módszertan és a szoftvertesztelés olyan megközelítések összességeként írható le, amelyek az interaktív fejlesztés alkalmazására, a követelmények dinamikus kialakítására és megvalósításának biztosítására irányulnak az önszerveződő szervezeten belüli folyamatos interakció eredményeként. munkacsoport. A legtöbb agilis szoftverfejlesztési módszer célja a kockázat minimalizálása a rövid iterációkban történő fejlesztés révén. Ennek a rugalmas stratégiának az egyik fő alapelve az, hogy a lehetséges változásokra gyorsan tudunk reagálni, nem pedig a hosszú távú tervezésre hagyatkozni.

Tudjon meg többet az Agile-ről(megjegyzés - angol nyelvű cikk).

Extrém programozás (XP, extrém programozás)

Az extrém programozás az agilis szoftverfejlesztés egyik példája. Ennek a módszernek a megkülönböztető jellemzője a "páros programozás", egy olyan helyzet, amikor az egyik fejlesztő dolgozik a kódon, miközben kollégája folyamatosan felülvizsgálja az írott kódot. A szoftvertesztelési folyamat nagyon fontos, mert még az első kódsor megírása előtt elkezdődik. Minden alkalmazásmodulnak rendelkeznie kell egy egységteszttel, hogy a legtöbb hiba javítható legyen a kódolási szakaszban. Egy másik megkülönböztető tulajdonság, hogy a teszt határozza meg a kódot, és nem fordítva. Ez azt jelenti, hogy egy bizonyos kódrészlet csak akkor tekinthető befejezettnek, ha minden teszt sikeres. Ellenkező esetben a kód elutasításra kerül.

Ennek a módszernek a fő előnye az állandó tesztelés és a rövid kiadások, ami segít biztosítani jó minőség kód.

Dulakodás

Scrum – Az Agile módszertan része, egy iteratív növekményes keretrendszer, amelyet a szoftverfejlesztési folyamat kezelésére hoztak létre. A Scrum alapelvei szerint a tesztcsapatot a következő lépésekben kell bevonni:

• Részvétel a Scrum tervezésében
• Egységtesztelés támogatása
• Felhasználói történet tesztelése
• Együttműködjön az ügyféllel és a terméktulajdonossal az elfogadási kritériumok meghatározásához
• Automatizált tesztelés biztosítása

Ezenkívül a minőségbiztosítási tagoknak jelen kell lenniük minden napi megbeszélésen, a többi csapattaghoz hasonlóan, hogy megvitassák, mit teszteltek és mit csináltak tegnap, mit fognak tesztelni ma, valamint a tesztelés általános előrehaladását.

Ugyanakkor a Scrum Agilis módszertanának elvei sajátos jellemzők megjelenéséhez vezetnek:

• Az egyes felhasználói történetekhez szükséges erőfeszítések becslése kötelező
• A tesztelőnek figyelmesnek kell lennie a követelményekre, mivel azok folyamatosan változhatnak.
• A regresszió kockázata a gyakori kódváltoztatással nő.
• Tesztek egyidejű tervezése és lebonyolítása
• Félreértés a csapat tagjai között, ha az ügyfél igényei nem teljesen egyértelműek

Tudjon meg többet a Scrum módszertanáról egy korábbi cikkből..

Következtetés

Összefoglalva, fontos megjegyezni, hogy manapság az egyik vagy másik szoftvertesztelési módszer használatának gyakorlata multiverzális megközelítést feltételez. Más szóval, ne számítson arra, hogy egyetlen módszertan minden típusú projekthez megfelelő lesz. Az egyik választása számos szemponttól függ, például a projekt típusától, a vevői követelményektől, a határidőktől és sok mástól. Szoftvertesztelési szempontból gyakori, hogy egyes módszerek a fejlesztés korai szakaszában kezdik meg a tesztelést, míg mások esetében megvárják, amíg a rendszer elkészül.

Akár szoftverfejlesztésben, akár tesztelésben van szüksége segítségre, a fejlesztőkből és minőségbiztosítási mérnökökből álló elkötelezett csapat készen áll a munkára.

Webszolgáltatás tesztelése

A legtöbb A legjobb módértékelje, hogy jól teszteltük-e a terméket – elemezze a hiányos hibákat. Azok, amelyekkel a felhasználóink, megvalósítóink, vállalkozásaink szembesülnek. Sok mindent ki lehet értékelni belőlük: mit nem ellenőriztünk elég alaposan, a termék mely területeire kell jobban odafigyelni, általában hány százalékos a kihagyás, és milyen a változásainak dinamikája. Ezzel a mérőszámmal (talán a legelterjedtebb a tesztelésben) minden rendben van, de... Amikor kiadtuk a terméket és megtudtuk a kimaradt hibákat, lehet, hogy már késő lesz: dühös cikk jelent meg rólunk a Habrén, a versenytársak rohamosan terjedő kritika, az ügyfelek elvesztették a belénk vetett bizalmukat, a vezetőség elégedetlen.

Hogy ez ne forduljon elő, általában igyekszünk előre, a megjelenés előtt értékelni a tesztelés minőségét: mennyire jól és alaposan ellenőrizzük a terméket? Mely területeken nem kell figyelni, hol vannak a fő kockázatok, milyen előrelépés? És hogy megválaszoljuk ezeket a kérdéseket, értékeljük a tesztek lefedettségét.

Miért értékelni?

Minden értékelési mérőszám időpocsékolás. Ebben az időben tesztelhet, indíthat el hibákat, készíthet automatikus teszteket. Milyen varázslatos hasznot húzunk a tesztlefedettség mutatóiból, ha feláldozzuk a tesztelési időt?

1. A gyenge pontok megtalálása. Természetesen ez kell nekünk? nem csak gyászolni, hanem tudni, hol van szükség fejlesztésre. Milyen funkcionális területeket nem fednek le a tesztek? Mit nem ellenőriztünk? Hol a legnagyobb a hiányzó hibák kockázata?
2. Ritkán kapunk 100%-os lefedettséget az értékelési eredményekből. Min javítani? Hová menjen? Mennyi most a százalék? Hogyan tudjuk bármilyen feladattal növelni? Milyen gyorsan érhetjük el a 100-at? Mindezek a kérdések átláthatóbbá és egyértelműbbé teszik folyamatunkat., és a válaszokat a lefedettségi becslés adja.
3. A figyelem fókusza. Tegyük fel, hogy termékünk körülbelül 50 különböző funkcionális területtel rendelkezik. színt vall egy új verzió, és elkezdjük tesztelni az 1-et, és ott találunk elírási hibákat, meg pár pixelt mozgató gombokat, meg egyéb apróságokat... És most lejárt a tesztelés ideje, és ezt a funkciót részletesen teszteltük. És a maradék 50? A lefedettség felmérése lehetővé teszi, hogy a feladatokat az aktuális valóság és határidők alapján rangsoroljuk.

Hogyan kell értékelni?

Mielőtt bármilyen mérőszámot alkalmazna, fontos eldönteni, hogyan fogja használni. Kezdje pontosan ennek a kérdésnek a megválaszolásával - valószínűleg azonnal megérti, hogyan lehet a legjobban kiszámítani. Ebben a cikkben csak néhány példát és tapasztalatomat osztom meg arról, hogyan lehet ezt megtenni. Nem azért, hogy vakon lemásoljuk a megoldásokat – hanem azért, hogy a fantáziája erre a tapasztalatra támaszkodjon, átgondolva az Ön számára ideális megoldást.

A követelmények lefedettségének felmérése tesztekkel

Tegyük fel, hogy elemzők vannak a csapatodban, és nem töltik hiába az idejüket. munkaidő. Munkájuk eredménye alapján követelményeket hoztak létre az RMS-ben (Requirements Management System) - HP QC, MS TFS, IBM Doors, Jira (további bővítményekkel), stb. Ebben a rendszerben olyan követelményeket állítanak fel, amelyek megfelelnek a követelmények követelményeinek (elnézést a tautológiáért). Ezek a követelmények atomi, nyomon követhetőek, specifikusak… Általában ideális körülmények a teszteléshez. Mit tehetünk ilyen esetben? Parancsfájl-megközelítés használata esetén kapcsolja össze a követelményeket és a teszteket. Ugyanabban a rendszerben végezzük a teszteket, hozunk létre követelmény-teszt kapcsolatot, és bármikor láthatunk egy jelentést arról, hogy melyik követelménynek van tesztje, melyiknek nincs, mikor és milyen eredménnyel.
Lefedettségi térképet kapunk, minden lefedett igényt lefedünk, mindenki boldog és elégedett, nem hagyjuk ki a hibákat...

Oké, térjünk vissza a földre. Valószínűleg nincsenek részletes követelményei, nem atomi, a követelmények egy része általában elveszett, és nincs idő az egyes tesztek, vagy legalábbis minden második dokumentálására. Lehet kétségbeesni és sírni, vagy elismerni, hogy a tesztelés egy kompenzációs folyamat, és minél rosszabbul állunk a projekt elemzésével és fejlesztésével, annál inkább magunknak kell megpróbálnunk és kompenzálni a folyamat többi résztvevőjének problémáit. Elemezzük külön a problémákat.

Probléma: A követelmények nem atomi.

Az elemzők is néha vétkeznek egy salátával a fejükben, és ez általában tele van problémákkal az egész projekttel kapcsolatban. Például egy szövegszerkesztőt fejleszt, és két követelmény lehet a rendszerben (többek között): „a html formázást támogatni kell” és „egy nem támogatott formátumú fájl megnyitásakor egy felugró ablak kérdéssel. meg kell jelennie." Hány teszt szükséges az 1. követelmény alapvető ellenőrzéséhez? És a 2-ra? A válaszok különbsége nagy valószínűséggel százszoros!!! Nem mondhatjuk, hogy ha legalább 1 teszt van az 1. követelményen, akkor ez elég - de a 2-ról valószínűleg teljesen.

Így a követelményteszt megléte egyáltalán nem garantál számunkra semmit! Mit jelent ebben az esetben a lefedettségi statisztikáink? Majdnem semmi! Nekünk kell döntenünk!

1. Ebben az esetben a követelmények lefedettségének tesztekkel történő automatikus kiszámítása eltávolítható - még mindig nem hordoz szemantikai terhelést.
2. Minden követelményhez a legmagasabb prioritástól kezdve teszteket készítünk. A felkészülés során elemezzük, hogy ehhez a követelményhez milyen vizsgálatokra lesz szükség, mennyi lesz elég? Teljes körű tesztelemzést végzünk, és nem ecseteljük, hogy „van egy teszt, de rendben”.
3. A használt rendszertől függően igény szerint exportálunk/töltünk fel teszteket és… teszteljük ezeket a teszteket! Elegendők? Ideális esetben természetesen az ilyen tesztelést elemzővel és a funkció fejlesztőjével kell elvégezni. Nyomtassa ki a teszteket, zárja be kollégáit a tárgyalóba, és ne engedje el addig, amíg azt nem mondják, hogy „igen, ezek a tesztek elég” (ez csak írásos beleegyezéssel történik, amikor ezeket a szavakat mondják ki a leiratkozásért, a tesztek elemzése nélkül is). Egy szóbeli megbeszélés során kollégái kádkritikát, kimaradt teszteket, félreértett követelményeket stb. öntenek ki – ez nem mindig kellemes, de teszteléshez nagyon hasznos!)
4. Az igény szerinti tesztek véglegesítése és teljességük egyeztetése után a rendszerben ez a követelmény „tesztekkel lefedett” státusszal jelölhető. Ez az információ sokkal többet jelent, mint "legalább 1 teszt van itt".

Természetesen egy ilyen megállapodási folyamat sok erőforrást és időt igényel, különösen eleinte, amíg a gyakorlat kialakul. Ezért csak kiemelt követelményeket és új fejlesztéseket hajtson végre rajta. Idővel szigorítsa meg a többi követelményt, és mindenki boldog lesz! De... és ha egyáltalán nincsenek követelmények?

Probléma: Egyáltalán nincsenek követelmények.

Hiányoznak a projektből, szóban megbeszélik, mindenki azt csinál amit akar/tud és ahogy ért. Ugyanezt teszteljük. Ennek eredményeként rengeteg problémát kapunk nemcsak a tesztelés és a fejlesztés során, hanem a funkciók kezdetben hibás megvalósítása is – valami egészen mást akartunk! Itt tudom tanácsolni a „határozza meg és dokumentálja a követelményeket saját maga” opciót, és még a gyakorlatom során is alkalmaztam ezt a stratégiát néhányszor, de az esetek 99%-ában nincs ilyen erőforrás a tesztelő csapatban - tehát menjünk sokkal kevesebbet. erőforrásigényes módszer:

1. Hozzon létre egy szolgáltatáslistát. Sami! Google-tábla formájában, PBI formátumban TFS-ben - válasszon bármelyiket, amennyiben az nem szöveges formátum. Még státuszokat kell gyűjtenünk! A termék összes funkcionális területét felvesszük ebbe a listába, és megpróbálunk egy általános bontási szintet választani (szoftverobjektumokat, felhasználói szkripteket, modulokat, weboldalakat, API metódusokat vagy képernyőformákat írhat ki. .) - de nem mindezt egyszerre! EGY bontási formátum, amely megkönnyíti és áttekinthetővé teszi, hogy ne maradjon le fontos dolgokról.
2. A lista TELJESSÉGÉT elemzőkkel, fejlesztőkkel, üzletemberekkel, csapatunkon belül egyeztetjük... Próbáljon meg mindent megtenni, hogy ne veszítse el a termék fontos részeit! Az, hogy milyen mélységű elemzést végez, az Önön múlik. A praxisomban csak néhány olyan termék volt, amelyhez több mint 100 oldalt készítettünk a táblázatban, ezek pedig óriási termékek. Leggyakrabban 30-50 sor is elérhető eredmény a további gondos feldolgozáshoz. Egy kis csapatban elkötelezett tesztelemzők nélkül több fichelista elemeket túl nehéz lenne fenntartani.
3. Ezt követően végigmegyünk a prioritásokon, és feldolgozzuk a fichelista minden sorát a fent leírt követelmények szakaszban leírtak szerint. Teszteket írunk, megbeszéljük, megbeszéljük az elégségességet. Jelöljük az állapotokat, hogy melyik funkcióhoz van elég teszt. A csapattal folytatott kommunikáción keresztül kapjuk meg a tesztek állapotát, előrehaladását és bővítését. Mindenki boldog!

De... Mi van, ha a követelményeket fenntartják, de nem nyomon követhető formátumban?

Probléma: A követelmények nem követhetők.

Hatalmas mennyiségű dokumentáció van a projektről, az elemzők 400 karakter/perc sebességgel gépelnek, vannak specifikációi, műszaki specifikációi, utasításai, referenciái (leggyakrabban ez a megrendelő kérésére történik), és mindez úgy működik, mint követelményeknek, és már régóta minden benne van a projektben. Zavarban van, hol és milyen információkat keressen?
Az előző szakasz megismétlése, segítve az egész csapatot a takarításban!

1. Létrehozunk egy jellemzőlistát (lásd fent), de a követelmények részletes leírása nélkül.
2. Minden egyes funkcióhoz összegyűjtjük a műszaki specifikációkra, specifikációkra, utasításokra és egyéb dokumentumokra mutató hivatkozásokat.
3. A prioritások szerint haladunk, teszteket készítünk, és megegyezünk azok teljességében. Minden ugyanaz, csak az összes dokumentum egy lapon való kombinációjának köszönhetően növeljük a hozzáférést, az átláthatóságot és a tesztek konzisztenciáját. A végén minden szuper, és mindenki boldog!

De… Nem sokáig… Úgy tűnik, az elmúlt héten az elemzők 4 különböző specifikációt frissítettek az ügyfelek kérései alapján!!!

Probléma: A követelmények folyamatosan változnak.

Természetesen jó lenne tesztelni valamilyen fix rendszert, de a termékeink általában élesek. Az ügyfél kért valamit, valami megváltozott a termékünkön kívüli jogszabályban, és valahol az elemzők egy tavalyelőtti elemzési hibát találtak... A követelmények élik a maguk életét! Mit kell tenni?

1. Tegyük fel, hogy már összegyűjtötte a TK-hoz mutató hivatkozásokat és a specifikációkat jellemzőlista, PBI, követelmények, Wiki megjegyzések stb. formájában. Tegyük fel, hogy már rendelkezik ezekre a követelményekre vonatkozó tesztekkel. És most megváltozik a követelmény! Ez jelenthet változást az RMS-ben vagy egy feladatot a TMS-ben (Feladatkezelő rendszerben), vagy egy levelet levélben. Akárhogy is, ugyanarra az eredményre vezet: a tesztjei elavultak! Vagy lehet, hogy irrelevánsak. Ez azt jelenti, hogy frissítést igényelnek (tesztekkel való lefedettség régi verzió a terméket valahogy nem tartják túl nagynak, igaz?)
2. A jellemzőlistában, RMS-ben, TMS-ben (Test Management System - testrails, sitechco stb.) a teszteket azonnal és hiba nélkül irrelevánsként kell megjelölni! A HP QC-ben vagy MS TFS-ben ez automatikusan megtehető a követelmények frissítésekor, google-táblagépen vagy wikiben pedig tollat ​​kell letenni. De azonnal látnia kell: a tesztek lényegtelenek! Ez azt jelenti, hogy teljes újraútra várunk: frissítés, tesztelemzés újrafuttatása, tesztek átírása, változtatások egyeztetése, és csak ezután jelöljük meg újra a szolgáltatást/követelményt „tesztekkel lefedettnek”.

Ebben az esetben a tesztlefedettség felmérésének minden előnyét megkapjuk, sőt dinamikában is! Mindenki boldog!!! De…
De annyira a követelményekkel való munkára összpontosított, hogy most nincs elég ideje a tesztek tesztelésére vagy dokumentálására. Véleményem szerint (és van helye vallási vitának is!) a követelmények fontosabbak, mint a tesztek, és jobb is így! Legalább rendben vannak, és az egész csapat tájékozott, a fejlesztők pedig pontosan azt teszik, amit kell. DE NINCS IDŐ A TESZTEK DOKUMENTÁLÁSÁRA!

Probléma: Nincs elég idő a tesztek dokumentálására.

Valójában a probléma forrása nem csak az időhiány lehet, hanem az is, hogy tudatosan nem dokumentálod ezeket (nem szeretjük, kerüljük a növényvédő hatást, túl gyakran változik a termék stb.). De hogyan lehet ebben az esetben értékelni a teszt lefedettségét?

1. Továbbra is szüksége van a követelményekre teljes követelményként vagy szolgáltatáslistaként, így a fenti szakaszok egyikére, a projekt elemzőinek munkájától függően, továbbra is szükség lesz. Van követelménye/szolgáltatási listája?
2. Leírunk és szóban megállapodunk egy rövid tesztelési stratégiában, konkrét tesztek dokumentálása nélkül! Ez a stratégia megadható egy táblázat oszlopában, egy wiki oldalon vagy egy követelményben az RMS-ben, és ismét meg kell állapodni. Ennek a stratégiának a részeként a felülvizsgálatokat különböző módokon hajtják végre, de Ön tudni fogja: mikor lesz utoljára tesztelve és milyen stratégiával? És ez, látod, szintén nem rossz! És mindenki boldog lesz.

De… Mi más "de"? Melyik???

Mondjuk, mindent körüljárunk, és jó minőségű termékek legyenek velünk!

| Óratervezés a tanévre | A modellezés főbb szakaszai

2. lecke
A modellezés főbb szakaszai

A téma tanulmányozásával megtudhatja:

Mi a modellezés;
- mi szolgálhat prototípusként a modellezéshez;
- mi a helye a modellezésnek az emberi tevékenységben;
- melyek a modellezés főbb szakaszai;
- mi az a számítógépes modell;
Mi az a számítógépes kísérlet.

számítógépes kísérlet

Az új tervezési fejlesztések életre keltéséhez, új műszaki megoldások gyártásba való bevezetéséhez vagy új ötletek teszteléséhez kísérletre van szükség. A kísérlet egy tárggyal vagy modellel végzett kísérlet. Ez abból áll, hogy végre kell hajtani néhány műveletet, és meghatározni, hogy a kísérleti minta hogyan reagál ezekre a műveletekre.

Az iskolában kísérleteket végez a biológia, kémia, fizika, földrajz órákon.

Kísérleteket végeznek új termékminták vállalkozásoknál történő tesztelésekor. Általában erre a célra egy speciálisan kialakított elrendezést használnak, amely lehetővé teszi a kísérlet elvégzését laboratóriumi körülmények között, vagy magát a valódi terméket vetik alá mindenféle vizsgálatnak (teljes körű kísérlet). Például egy egység vagy szerelvény teljesítményi tulajdonságainak tanulmányozásához termosztátba helyezik, speciális kamrákba fagyasztják, vibrációs állványokon tesztelik, leejtik stb. Jó, ha új óra vagy porszívó - a pusztítás közbeni veszteség nem nagy. Mi van, ha repülő vagy rakéta?

A laboratóriumi és teljes körű kísérletek nagy anyagköltséget és időt igényelnek, de jelentőségük ennek ellenére igen nagy.

Fejlődéssel számítógépes technológia egy új, egyedülálló kutatási módszer jelent meg - a számítógépes kísérlet. A számítógépes szimulációs tanulmányok sok esetben a kísérleti minták és próbapadok segítségére, sőt esetenként pótlására is szolgáltak. A számítógépes kísérlet végrehajtásának szakasza két szakaszból áll: a kísérleti terv elkészítése és a vizsgálat elvégzése.

Kísérleti terv

A kísérleti tervnek egyértelműen tükröznie kell a modellel végzett munka sorrendjét. Egy ilyen terv első lépése mindig a modell tesztelése.

A tesztelés a megszerkesztett modell helyességének ellenőrzésének folyamata.

Teszt - kezdeti adatok halmaza, amely lehetővé teszi a modell felépítésének helyességének meghatározását.

Ahhoz, hogy megbizonyosodjunk a kapott modellezési eredmények helyességéről, szükséges: ♦ ellenőrizni a modell felépítéséhez kidolgozott algoritmust; ♦ győződjön meg arról, hogy a megszerkesztett modell megfelelően tükrözi az eredeti szimuláció során figyelembe vett tulajdonságait.

A modellalkotási algoritmus helyességének ellenőrzésére a kezdeti adatokból álló teszthalmazt használjuk, amelynek végeredménye előre ismert vagy más módon előre meghatározott.

Például, ha számítási képleteket használ a modellezésben, akkor több lehetőséget kell kiválasztania a kiindulási adatokhoz, és „kézileg” kell kiszámítania azokat. Ezek tesztelemek. A modell felépítésekor ugyanazokkal a bemenetekkel tesztel, és a szimuláció eredményeit összehasonlítja a számítással kapott következtetésekkel. Ha az eredmények egyeznek, akkor az algoritmus helyesen van kidolgozva, ha nem, akkor meg kell keresni és meg kell szüntetni az eltérés okát. Előfordulhat, hogy a tesztadatok egyáltalán nem tükrözik a valós helyzetet, és nem hordozhatnak szemantikai tartalmat. A tesztelési folyamat során kapott eredmények azonban arra késztethetik, hogy elgondolkozzon az eredeti információs vagy jelmodell megváltoztatásán, elsősorban annak azon részén, ahol a szemantikai tartalom le van fektetve.

Ahhoz, hogy megbizonyosodjunk arról, hogy a megszerkesztett modell tükrözi az eredeti szimuláció során figyelembe vett tulajdonságait, ki kell választani egy tesztpéldát valós forrásadatokkal.

Kutatások végzése

A tesztelés után, ha megbizonyosodott a felépített modell helyességéről, közvetlenül folytathatja a vizsgálatot.

A tervnek tartalmaznia kell egy kísérletet vagy kísérletsorozatot, amely megfelel a szimuláció céljainak. Minden kísérletet az eredmények megértésének kell kísérnie, amely alapul szolgál a modellezés eredményeinek elemzéséhez és a döntéshozatalhoz.

A számítógépes kísérlet elkészítésének és lefolytatásának sémája a 11.7. ábrán látható.

Rizs. 11.7. Egy számítógépes kísérlet vázlata

Szimulációs eredmények elemzése

A modellezés végső célja egy olyan döntés meghozatala, amelyet a szimulációs eredmények átfogó elemzése alapján kell kidolgozni. Ez a szakasz döntő – vagy folytatja a tanulást, vagy befejezi. A 11.2. ábra azt mutatja, hogy az eredményelemzési szakasz nem létezhet önállóan. A kapott következtetések gyakran járulnak hozzá egy további kísérletsorozathoz, és néha a probléma megváltoztatásához.

A tesztek és kísérletek eredményei szolgálnak alapul a megoldás kidolgozásához. Ha az eredmények nem felelnek meg a feladat céljainak, az azt jelenti, hogy az előző szakaszokban hibák történtek. Ez lehet a probléma helytelen megfogalmazása, vagy egy információs modell túlságosan leegyszerűsített felépítése, vagy a modellezési módszer vagy környezet sikertelen kiválasztása, vagy a technológiai módszerek megsértése a modell felépítése során. Ha ilyen hibákat azonosítanak, akkor a modellt ki kell javítani, vagyis vissza kell térni az előző szakaszok egyikéhez. A folyamatot addig ismételjük, amíg a kísérlet eredményei el nem érik a szimuláció céljait.

A legfontosabb, hogy ne feledje, hogy az észlelt hiba egyben az eredmény is. Ahogy a közmondás mondja, a hibáiból tanul az ember. Erről a nagy orosz költő, A. S. Puskin is írt:

Ó, mennyi csodálatos felfedezésünk van
Készítsd fel a megvilágosodás szellemét
És a tapasztalat, a nehéz hibák fia,
És zseniális, paradoxon barát,
És a véletlen, Isten a feltaláló...

Ellenőrző kérdések és feladatok

1. Mi a modellezési problémafelvetés két fő típusa.

2. G. Oster jól ismert "Problémakönyvében" a következő probléma van:

A fáradhatatlanul dolgozó gonosz boszorkány naponta 30 hercegnőt csinál hernyókká. Hány nap kell neki, hogy 810 hercegnőt hernyókká változtassanak? Hány hercegnőt kellene naponta hernyóvá varázsolni, hogy 15 nap alatt elvégezzék a munkát?
Melyik kérdés tulajdonítható a "mi lesz, ha ..." típusának, és melyik a "hogyan kell csinálni, hogy ..." típusnak?

3. Sorolja fel a modellezés legismertebb céljait!

4. Formalizálja a játékos problémát G. Oster „Problémakönyvéből”:

Két, egymástól 27 km-re lévő fülkéből egyszerre két bunkó kutya ugrott ki egymás felé. Az első 4 km / h sebességgel fut, a második pedig 5 km / h.
Meddig kezdődik a harc?

5. Nevezzen meg minél több jellemzőt a "pár cipő" tárgynak. Készítsen információs modellt egy objektumról különböző célokra:
■ lábbeli kiválasztása túrázáshoz;
■ megfelelő cipős doboz kiválasztása;
■ cipőápoló krém vásárlása.

6. Milyen tulajdonságok szükségesek egy tinédzserhez a szakmaválasztási ajánláshoz?

7. Miért használják széles körben a számítógépet a szimulációban?

8. Nevezze meg a számítógépes modellezés általa ismert eszközeit!

9. Mi az a számítógépes kísérlet? Adj egy példát.

10. Mi az a modelltesztelés?

11. Milyen hibák fordulnak elő a modellezési folyamat során? Mi a teendő, ha hibát talál?

12. Mi a szimulációs eredmények elemzése? Milyen következtetéseket szoktak levonni?