Mi az a funkcionális tesztelés?
Ebben a szakaszban csatlakozik a Tailspin csapatához, amikor funkcionális teszteket határoznak meg a folyamatukhoz. A funkcionális tesztek ellenőrzik, hogy a szoftver minden egyes funkciója megteszi-e, amit kell.
A csapat először meghatározza, hogy mit fed le egy funkcionális teszt. A funkcionális tesztek bizonyos típusait vizsgálják. Ezután az első teszt mellett döntenek, hogy hozzáadják a folyamathoz.
Heti értekezlet
A csapat heti értekezletet tart. Andy bemutatja a kiadási folyamatot. A csapat figyeli a folyamat sikeres buildelt áthelyezését, egyik fázisból a másikba. Végül a webalkalmazást előlépteti az előkészítésre.
Amita: Nagyon örülök a folyamatnak. Sokkal könnyebbé teszi az életemet. Egyrészt automatikusan üzembe helyezek egy kiadást a tesztkörnyezetben . Ez azt jelenti, hogy nem kell manuálisan letöltenem és telepíteni a buildösszetevőket a tesztkiszolgálóimra. Ez jelentős időmegtakarítás.
Emellett a mara és Andy által írt egységtesztek kiküszöbölik az összes regressziós hibát, mielőtt megkapnám a kiadást. Ez eltávolítja a frusztráció fő forrását. Nem foglalkozom a regressziós hibák keresésével és dokumentálásával.
De aggódom, hogy az összes tesztelésem még mindig manuális. A folyamat lassú, és nem tudunk semmit mutatni a vezetőségnek, amíg be nem fejezem. Nehéz, mert a tesztelés fontos. A tesztelés biztosítja, hogy a felhasználók a megfelelő felhasználói élményt kapják. De a nyomás a gyorsabb szállításon van.
Andy: Biztos vagyok benne, hogy tudunk segíteni. Milyen tesztek veszik igénybe az idő nagy részét?
Amita: Azt hiszem, a felhasználói felület tesztek igen. Át kell kattintani minden lépésen, hogy biztosan a megfelelő eredményt kapjam, és ezt minden támogatott böngészőben meg kell tennem. Nagyon időigényes. És ahogy a webhely egyre összetettebbé válik, a felhasználói felület tesztelése hosszú távon nem lesz praktikus.
Mara: A felhasználói felületi tesztek funkcionális teszteknek minősülnek.
Tim: Mi ellen, nem funkcionális tesztek?
Mara: Pontosan. És a nem funkcionális tesztek olyan dolog, amit különösen érdekel.
Oké, összezavarodtam.
Mik azok a funkcionális és nem funkcionális tesztek?
Mara:Funkcionális tesztek ellenőrzik, hogy a szoftver minden funkciója azt teszi-e, amit kell. Ezekben a tesztekben nem fontos, hogy a szoftver hogyan implementálja az egyes függvényeket. Az a fontos, hogy a szoftver megfelelően viselkedjen. Adja meg a bemenetet, és ellenőrizze, hogy a kimenet a vártnak megfelelő-e. Amita így teszteli a felhasználói felületet. Ha például a ranglistán a legjobb játékost választja ki, azt várja, hogy lássa a játékos profilját.
A nem funkcionális tesztek olyan jellemzőket ellenőriznek, mint a teljesítmény és a megbízhatóság. Nem funkcionális teszt például annak ellenőrzése, hogy hány személy tud egyszerre bejelentkezni az alkalmazásba. A terheléstesztelés egy másik példa a nem funkcionális tesztekre. Ezek a teljesítmény- és megbízhatósági aggodalmak a fontos dolgok, Tim.
Tim: Valóban azok. El kell gondolkodnom ezen egy kicsit. Lehet, hogy némi automatizálást is hozzá szeretnék adni a folyamathoz, de nem tudom, mit szeretnék tenni. Milyen típusú automatizált teszteket futtathatok?
Mara: Egyelőre koncentráljunk a funkcionális tesztelésre. Ez az a fajta tesztelés, amit Amita csinál. És úgy hangzik, mint egy terület, ahol javítani szeretnénk.
Milyen funkcionális teszteket futtathatok?
Sokféle funkcionális teszt létezik. Ezek a teszteléshez szükséges funkcióktól, valamint a futtatásukhoz szükséges időtől vagy erőfeszítéstől függően változnak.
Az alábbi szakaszok néhány gyakran használt funkcionális tesztet mutatnak be.
Füsttesztelés
A füsttesztelés ellenőrzi az alkalmazás vagy szolgáltatás legalapvetőbb funkcióit. Ezeket a teszteket gyakran teljesebb és teljesebb tesztek előtt futtatják. A füsttesztek gyorsan lefutnak.
Tegyük fel például, hogy egy webhelyet fejleszt. A füstteszt segítségével curl ellenőrizheti, hogy a webhely elérhető-e, és hogy a kezdőlap beolvasása 200 (OK) HTTP-állapotot eredményez-e. Ha a kezdőlap beolvasása egy másik állapotkódot hoz létre, például a 404-et (nem található) vagy az 500-ast (belső kiszolgálóhiba), akkor tudja, hogy a webhely nem működik. Azt is tudja, hogy nincs ok más tesztek futtatására. Ehelyett diagnosztizálja a hibát, kijavítja és újraindítja a teszteket.
Egységtesztelés
Az Azure Pipelines-modullal a buildelési folyamat futtatási minőségi tesztjeiben dolgozott egységtesztekkel.
Röviden: az egységtesztelés ellenőrzi a program vagy a tár legalapvetőbb összetevőit, például az egyes függvényeket vagy metódusokat. Meg kell adnia egy vagy több bemeneti értéket és a várt eredményeket. A tesztfuttató minden tesztet végrehajt, és ellenőrzi, hogy a tényleges eredmények megfelelnek-e a várt eredményeknek.
Tegyük fel például, hogy van egy függvénye, amely egy osztást tartalmazó aritmetikai műveletet hajt végre. Megadhat néhány értéket, amelyeket a felhasználóktól elvárhat. Az él-kis- és nagybetűket is meg kell adnia, például a 0 és a -1 értéket. Ha egy bizonyos bemenet hibát vagy kivételt fog eredményezni, ellenőrizheti, hogy a függvény ezt a hibát okozza-e.
A modul későbbi részében futtatott felhasználói felületi tesztek egységtesztek.
Integrációs tesztelés
Az integrációs tesztelés ellenőrzi, hogy több szoftverösszetevő együttműködik-e egy teljes rendszer kialakításához. Egy e-kereskedelmi rendszer például tartalmazhat webhelyet, termékadatbázist és fizetési rendszert. Írhat egy integrációs tesztet, amely elemeket ad hozzá a bevásárlókocsihoz, majd megvásárolja a termékeket. A teszt ellenőrzi, hogy a webalkalmazás képes-e csatlakozni a termékek adatbázisához, majd teljesíteni a megrendelést.
Az egységtesztek és az integrációs tesztek kombinálásával rétegzett tesztelési stratégiát hozhat létre. Az integrációs tesztek futtatása előtt például mindegyik összetevőn futtathat egységteszteket. Ha minden egységteszt megfelel, nagyobb magabiztossággal léphet tovább az integrációs tesztekre.
Regressziós tesztelés
Regresszió akkor fordul elő, ha a meglévő viselkedés megváltozik vagy megszakad egy funkció hozzáadása vagy módosítása után. A regressziós tesztelés segít meghatározni, hogy a kód, a konfiguráció vagy más változások befolyásolják-e a szoftver általános működését.
A regressziós tesztelés azért fontos, mert az egyik összetevő módosítása hatással lehet egy másik összetevő viselkedésére. Tegyük fel például, hogy optimalizál egy adatbázist az írási teljesítményhez. Egy másik összetevő által kezelt adatbázis olvasási teljesítménye váratlanul csökkenhet. Az olvasási teljesítmény csökkenése regresszió.
A regresszió teszteléséhez különböző stratégiákat használhat. Ezek a stratégiák általában a futtatott tesztek számától függően változnak annak ellenőrzéséhez, hogy egy új funkció vagy hibajavítás nem szakítja-e meg a meglévő funkciókat. A tesztek automatizálásakor azonban a regressziós tesztelés magában foglalhatja az összes egységteszt és integrációs teszt futtatását minden alkalommal, amikor a szoftver megváltozik.
Higiénés tesztelés
A józan ész tesztelése magában foglalja a szoftver egyes fő összetevőinek tesztelését annak ellenőrzésére, hogy a szoftver működik-e, és alaposabb tesztelésen eshet át. Úgy gondolhatja, hogy a józansági tesztek kevésbé alaposak, mint a regressziós tesztek vagy az egységtesztek, de a higiéniatesztek szélesebb körűek, mint a füsttesztek.
Bár a józan ész tesztelése automatizálható, ezt gyakran manuálisan végzik el a funkcióváltozásra vagy hibajavításra válaszul. Egy hibajavítást érvényesítő szoftvertesztelő például bizonyos tipikus értékek beírásával is ellenőrizheti, hogy más funkciók működnek-e. Ha úgy tűnik, hogy a szoftver a várt módon működik, akkor egy alaposabb teszten megy keresztül.
A felhasználói felület tesztelése
A felhasználói felület (UI) tesztelése ellenőrzi az alkalmazás felhasználói felületének viselkedését. A felhasználói felületi tesztek segítenek ellenőrizni, hogy a felhasználói interakciók sorrendje vagy sorrendje a várt eredményhez vezet-e. Ezek a tesztek azt is ellenőrzik, hogy a beviteli eszközök, például a billentyűzet vagy az egér megfelelően befolyásolják-e a felhasználói felületet. Felhasználói felületi tesztekkel ellenőrizheti a natív Windows, macOS vagy Linux rendszerű alkalmazások viselkedését. Felhasználói felületi tesztekkel ellenőrizheti, hogy a felhasználói felület a várt módon működik-e a webböngészőkben.
Egy egységteszt vagy integrációs teszt ellenőrizheti, hogy a felhasználói felület megfelelően fogadja-e az adatokat. A felhasználói felület tesztelése azonban segít ellenőrizni, hogy a felhasználói felület megfelelően jelenik-e meg , és hogy az eredmény a felhasználó számára elvárt módon működik-e.
Egy felhasználói felületi teszt például ellenőrizheti, hogy a megfelelő animáció megjelenik-e egy gombkattintásra válaszul. Egy második teszt ellenőrizheti, hogy ugyanaz az animáció helyesen jelenik-e meg az ablak átméretezésekor.
Ebben a modulban kézzel kódolt felhasználói felületi tesztekkel dolgozik. A felhasználói felületi tesztek automatikus összeállításához azonban rögzítési és visszajátszási rendszert is használhat.
Használhatósági tesztelés
A használhatósági tesztelés a manuális tesztelés egyik formája, amely ellenőrzi az alkalmazás viselkedését a felhasználó szemszögéből. A használhatósági tesztelést általában a szoftvert összeállító csapat végzi.
Míg a felhasználói felület tesztelése arra összpontosít, hogy egy szolgáltatás a várt módon viselkedik-e, a használhatósági tesztelés segít ellenőrizni, hogy a szoftver intuitív-e, és megfelel-e a felhasználó igényeinek. Más szóval a használhatósági tesztelés segít ellenőrizni, hogy a szoftver használható-e.
Tegyük fel például, hogy van egy webhelye, amely a felhasználó profiljára mutató hivatkozást tartalmaz. A felhasználói felületi teszt képes ellenőrizni, hogy a hivatkozás megtalálható-e, és hogy a hivatkozás kattintásakor megjelenik-e a felhasználó profilja. Ha azonban az emberek nem tudják könnyen megtalálni ezt a hivatkozást, akkor frusztrálhatják őket, amikor megpróbálják elérni a profiljukat.
Felhasználói tesztelés
A felhasználói elfogadási tesztelés (UAT) – például a használhatósági tesztelés – az alkalmazás felhasználói szempontból való viselkedésére összpontosít. A használhatósági teszteléssel ellentétben az UAT-t általában valós végfelhasználók végzik.
A szoftvertől függően előfordulhat, hogy a végfelhasználóknak adott feladatok elvégzésére van szükség. Vagy bizonyos irányelvek betartása nélkül is felfedezhetik a szoftvert. Egyéni szoftverek esetén az UAT általában közvetlenül az ügyféllel történik. Általánosabb célú szoftverek esetén a csapatok bétateszteket futtathatnak. A bétatesztek során a különböző földrajzi régiókból származó vagy különleges érdeklődési körökkel rendelkező felhasználók korai hozzáférést kapnak a szoftverhez.
A tesztelők visszajelzései lehetnek közvetlenek vagy közvetettek. A közvetlen visszajelzések szóbeli megjegyzések formájában is megjelenhetnek. A közvetett visszajelzések lehetnek a tesztelők testbeszédének, szemmozgásainak mérése vagy bizonyos feladatok elvégzéséhez való idő formájában.
Már foglalkoztunk a tesztek írásának fontosságával. De csak hogy hangsúlyozzuk, íme egy rövid videó, amelyben Abel Wang, a Microsoft felhőtanácsadója ismerteti, hogyan biztosítható a minőség a DevOps-csomagban.
Kérdezd meg Ábelt
Mit választ a csapat?
Tim: Ezek a tesztek fontosnak tűnnek. Melyiket kell először kezelnünk?
Andy: Már rendelkezünk munkaegység-tesztekkel. Még nem áll készen a felhasználói elfogadás tesztelésére. A hallottak alapján úgy gondolom, hogy a felhasználói felület tesztelésére kellene koncentrálnunk. Jelenleg ez a folyamat leglassabb része. Amita, egyetért?
Amita: Igen, egyetértek. Még van egy kis időnk ebben az értekezletben. Andy vagy Mara, szeretne segíteni egy automatizált felhasználói felületi teszt megtervezésében?
Mara: Abszolút. De térjünk ki néhány előzményt az útból. Szeretném megvitatni, hogy milyen eszközt használjunk, és hogyan fogjuk futtatni a teszteket.
Milyen eszközökkel írhatok felhasználói felületi teszteket?
Mara: A felhasználói felületi tesztek írásakor mik a lehetőségeink? Tudom, hogy sokan vannak. Egyes eszközök nyílt forráskód. Mások fizetett kereskedelmi támogatást kínálnak. Íme néhány lehetőség, amely eszembe jut:
- Windows-alkalmazásillesztő (WinAppDriver): A WinAppDriver segítségével automatizálhatja a felhasználói felületi teszteket a Windows-alkalmazásokon. Ezek az alkalmazások Univerzális Windows-platform (UWP) vagy Windows Forms (WinForms) formában írhatók. Olyan megoldásra van szükségünk, amely egy böngészőben működik.
- Szelén: A szelén egy hordozható, nyílt forráskódú szoftvertesztelési keretrendszer webalkalmazásokhoz. A legtöbb operációs rendszeren fut, és minden modern böngészőt támogat. A szelénteszteket több programozási nyelven is megírhatja, beleértve a C#-ot is. Valójában olyan NuGet-csomagokat használhat, amelyek megkönnyítik a szelén NUnit-tesztekként való futtatását. Már használjuk az NUnitot az egységtesztekhez.
- SpecFlow: A SpecFlow .NET-projektekhez készült. Egy Uborka nevű eszköz ihlette. Mind a SpecFlow, mind az Uborka támogatja a viselkedésvezérelt fejlesztést (BDD). A BDD egy Gherkin nevű természetes nyelvű elemzővel segít a műszaki csapatoknak és a nem műszaki csapatoknak az üzleti szabályok és követelmények meghatározásában. A felhasználói felületi tesztek létrehozásához kombinálhatja a SpecFlow vagy az Uborka és a Selenium elemet.
Andy megnézi Amitát.
Andy: Tudom, hogy ezek a lehetőségek újak neked, szóval nem bánod, ha szelént választunk? Van némi tapasztalatom ezzel kapcsolatban, és támogatja a nyelveket, amelyeket már ismerek. A szelén automatikus támogatást is biztosít több böngészőhöz.
Amita: Persze. Jobb, ha egyikünknek van tapasztalata.
Hogyan funkcionális teszteket futtatni a folyamatban?
Az Azure Pipelinesban ugyanúgy futtat funkcionális teszteket, mint bármely más folyamatot vagy tesztet. Tegye fel magának a következő kérdéseket:
- Melyik szakaszban futnak a tesztek?
- Milyen rendszeren futnak a tesztek? Futnak majd az ügynökön vagy az alkalmazást üzemeltető infrastruktúrán?
Csatlakozzunk a csapathoz, amikor válaszolnak ezekre a kérdésekre.
Mara: Egy dolog, amit izgatott vagyok, hogy most már tesztelhet egy olyan környezetben, mint az éles környezetben, ahol az alkalmazás ténylegesen fut. A funkcionális teszteknek, például a felhasználói felületi teszteknek van értelme ebben a kontextusban. Futtathatjuk őket a folyamat tesztelési szakaszában.
Amita: Egyetértek. Ugyanazt a munkafolyamatot fenntarthatjuk, ha automatizált felhasználói felületi teszteket futtatunk ugyanabban a szakaszban, amelyben manuális teszteket futtatok. Az automatizált tesztek időt takarítanak meg, és lehetővé teszik, hogy a használhatóságra összpontosítsak.
Tim: Amita teszteli a webhelyet a Windows laptopjáról, mert a felhasználók többsége így látogatja meg a webhelyet. De Linuxra építünk, majd üzembe helyezünk Azure-alkalmazás Szolgáltatást Linuxon. Hogyan kezeljük ezt?
Mara: Nagy kérdés. Azt is választhatjuk, hogy hol futtatjuk a teszteket. Futtathatjuk őket:
- Az ügynökön: egy Microsoft-ügynök vagy egy üzemeltetett ügynök
- Tesztinfrastruktúra: a helyszínen vagy a felhőben
A meglévő tesztszakaszunk egy feladatot tartalmaz. Ez a feladat linuxos ügynökből telepíti a webhelyet az App Service-ben. Hozzáadhatunk egy második feladatot, amely windowsos ügynöktől futtatja a felhasználói felületi teszteket. A Microsoft által üzemeltetett Windows-ügynök már be van állítva szeléntesztek futtatására.
Andy: Ismét, maradjunk azzal, amit tudunk. Használjunk Microsoft által üzemeltetett Windows-ügynököt. Később ugyanazokat a teszteket futtathatjuk a macOS-t és Linuxot futtató ügynököktől, ha további tesztelési lefedettségre van szükségünk.
A terv
Mara: OK. A következő lépéseket hajtjuk végre:
- Selenium felhasználói felületi tesztek futtatása Microsoft által üzemeltetett Windows-ügynökből
- Kérje meg a teszteket, hogy lekérjék a webtartalmat az App Service-ben futó alkalmazásból a Teszt szakaszban
- Futtassa a teszteket az összes támogatott böngészőn
Andy: Ezen dolgozom Amitával. Amita, találkozzunk holnap reggel. Szeretnék egy kis kutatást végezni, mielőtt találkozunk.
Amita: Nagy! Akkor találkozunk.
Funkcionális tesztterv létrehozása
Láttuk, hogy a csapat dönti el, hogyan valósítják meg az első funkcionális teszteket. Ha csapata éppen most kezd funkcionális teszteket beépíteni a folyamatba (vagy ha már ezt teszi), ne feledje, hogy mindig szüksége van egy tervre.
Sokszor előfordul, hogy amikor valaki megkérdezi a csapattagokat a teljesítménytesztelési tervéről, gyakran előfordul, hogy a csapattagok a használni kívánt eszközök listájával válaszolnak. Az eszközök listája azonban nem terv. Azt is meg kell dolgoznia, hogyan lesznek konfigurálva a tesztelési környezetek. Meg kell határoznia a használni kívánt folyamatokat, és meg kell határoznia, hogy milyen a siker vagy a sikertelenség.
Győződjön meg arról, hogy a csomag:
- Figyelembe veszi az üzleti elvárásokat.
- Figyelembe veszi a célfelhasználók elvárásait.
- Meghatározza a használni kívánt metrikákat.
- Meghatározza a használni kívánt KPI-ket.
A teljesítménytesztelésnek már a kezdetektől a tervezés részét kell képeznie. Ha egy történetet vagy Kanban-táblát használ, érdemes lehet egy olyan területet létrehozni a közelében, ahol megtervezheti a tesztelési stratégiát. Az iterációs tervezés részeként ki kell emelni a tesztelési stratégia hiányosságait. Az is fontos, hogy az alkalmazás üzembe helyezése után hogyan monitorozza a teljesítményt, és ne csak a kiadás előtt mérje a teljesítményt.