Miért van szükségük a programozóknak tesztelésre?
A következő néhány szintet a programozóknak szükséges módon történő tesztelésnek szentelik . De először nézzük meg, mi az a vizsgálat, és miért van rá szükség.
A szoftverrel kapcsolatban elmondhatjuk, hogy a tesztelés feladata annak ellenőrzése, hogy a program:
- megteszi, amit tennie kell
- nem teszi azt, amit nem kellene
A második pont egyébként nem kevésbé fontos, mint az első, de erről majd később.
Kezdjük az első ponttal. Mit jelent az, hogy "a program azt csinálja, amit tennie kell"?
Először valakinek listát kell készítenie a program összes használati esetéről. Másodszor, le kell írniuk, hogyan kell működnie a programnak, hogyan kell a felhasználónak viselkednie, és milyen eredményeket kell várni. Nem folytathatja tovább.
Amint megírtuk, hogy „hogyan kell viselkednie a felhasználónak”, a jó dokumentáció írásának gondolata szétesett. Az emberek nem gépek, sőt gyakran úgy viselkednek a szoftverekkel, ahogy akarnak . Senki sem kezdi a technológiával való ismerkedést az utasítások tanulmányozásával. Ez egy tény.
Ezért kapunk egy új tényt: a szoftver sajátossága, hogy nagyon sokféle munkaforgatókönyvet tartalmaz. Ezek egy része nyilvánvaló, mások dokumentálhatóak, mások feltételezhetők, mások sejthetők, a másik 50% pedig eszedbe sem jut.
Programozói szempontból a legtöbb hiba egyáltalán nem hiba. Hiba az, ha egy program nem úgy működik, ahogyan kellene, vagy nem a várt módon. És sok olyan helyzet van, amikor nem világos, hogyan kell működnie a programnak, vagy olyan forgatókönyvek vannak, amelyek ellentmondanak egymásnak ...
Végtelen számú forgatókönyv létezik, és mindig lesznek olyan esetek a termékben, amikor a program nem a várt módon működik (a programozó csak néhány tucat forgatókönyv kódját írta). Ezért vitatható, hogy minden programban mindig vannak hibák , és bármely termék a végtelenségig javítható .
Ezek után minden a célszerűségen múlik. Először a programozó javítja a legnagyobb hibákat, majd a kisebb hibákat, és így tovább. És végül eljön az a szakasz, amikor a termék tulajdonosa úgy véli, hogy gazdaságilag nem kivitelezhető a további munka.
De térjünk vissza azokhoz a hibákhoz, amelyeket mindenki hibaként ismer fel: a program nyilvánvalóan valamit rosszul csinál, leesett, eltört, stb. Az ilyen hibák feltételesen három kategóriába sorolhatók: nagy, közepes és kicsi.
És nagyon gyakran előfordul, hogy egy programozó közepes vagy akár kisebb hibák kijavításán dolgozik, bár még mindig sok komolyabb probléma van a projektben. Egyszerűen nem találta őket , ezért a legnagyobbakon dolgozik, amelyekről tud.
Ezért minden projektben tesztelőknek kell lenniük. Ezek az emberek kifejezetten megtanulják, hogy különböző szemszögekből nézzék a terméket. Így több forgatókönyvet láthat a programról. Feladatuk a hibák megtalálása és lejegyzése (hogy ne találják meg többször ugyanazt a hibát).
A tesztelés egy olyan folyamat, amelynek célja a hibák megtalálása. Ezeket a hibákat meg kell találni, le kell írni és rangsorolni kell. Csak a hibák rangsorolása után beszélhetünk hatékony szoftverfejlesztési folyamatról.
Ne feledje, a probléma megoldásának első lépése annak elismerése, hogy van probléma . Nem tudod kijavítani azt a hibát, amelyről nem tudsz.
Teszt automatizálás
Azt hiszem, mindannyian egyetértettünk abban, hogy a tesztelés fontos, ezért nézzük a tesztelést, mint a programozókat. Hogyan látják a programozók a tesztelést? A programozók automatizálják mások munkáját. Az utolsó szakma, amely eltűnik, a programozói szakma lesz.
Automatizálunk minden folyamatot, amellyel találkozunk. Tehát a tesztelést automatizálni kell. És hogyan lehet automatizálni a hibakeresést? Rövid válasz: nem. De itt ismét segítségünkre van az a tény, hogy programozók vagyunk.
A szoftverfejlesztési folyamat állandó változtatásokból áll. éppen a folyamatos változtatások folyamatában a programozók nagyon gyakran eltörnek valamit, ami egészen a közelmúltig jól működött.
A tesztelők pedig ahelyett, hogy új hibákat keresnének, kénytelenek folyamatosan ellenőrizni, hogy elrontottunk-e valamit, ami már régóta jól működik. Az úgynevezett regressziós tesztelés. Ez az ilyen típusú tesztelés, amelyet automatizálni lehet és kell is.
Itt minden szoftver két részre osztható:
- a program interakcióba lép az emberrel
- program kölcsönhatásba lép egy másik programmal
Az első lehetőség nehezebben automatizálható, speciális automata tesztelőket igényel, ezeket QA Automationnak vagy Software Test Engineernek is nevezik.
De a második opciót önállóan lehet és kell automatizálni. Ha olyan szoftverrel rendelkezik, amely:
- jól működik
- már tesztelve
- külön modulként vagy logikai blokkként valósul meg
- nem tervez változást
- más modulok vagy programok függenek tőle
- a funkcionális meghibásodás költséges
Azt javaslom, hogy szánjon időt a tesztek megírására, amelyek rögzítik a jelenlegi funkcionalitás kulcsfontosságú szempontjait. Indokolt lenne erre a munkaidejének 5%-át , vagy havi 1 napot szánni.
Nem kell teszteket írni a tesztek kedvéért.
Senki nem fogja támogatni a tesztjeit. Nem más programozók, nem te magad. Senki nem csinál ilyet. Az összes írásbeli teszt 99%-a félbehagyott és/vagy letiltott. Ha nem tudsz teszteket írni - ne írj. Csak akkor írj, ha egyáltalán nem tudsz nélkülük meglenni.
A tesztelés típusai
Minden programozó, ha nem vett részt speciális képzésen, saját szavaival tudja megmondani, mi a tesztelés: annak ellenőrzése, hogy a program azt csinálja-e, amit kell. Az ezen a területen dolgozó szakemberek azonban a tesztelés egész területeit (típusait) különböztetik meg.
Valójában minden tesztelés a szoftver megbízhatósága és elérhetősége körül forog, de a tesztelés irányának jobb megértése érdekében nézzünk meg néhány példát.
Tegyük fel, hogy egy tipikus online áruházat tesztel. Ezután a tesztelési területek a következő típusokra oszthatók: teljesítményteszt, funkcionális tesztelés, integrációs tesztelés és egységteszt.
Ha az oldal tulajdonosa úgy dönt, hogy komoly reklámkampányt indít, akkor egyszerre sok felhasználó érkezik az oldalra. Könnyen előfordulhat, hogy a webhely nem fog leesni, de egyes részei lassúak, vagy akár le is állhatnak.
Ennek elkerülése érdekében az ilyen problémákat előre meg kell határoznia, és lépéseket kell tennie azok megszüntetésére. Ez terhelési teszteléssel történik , vagy teljesítménytesztnek is nevezik.
Azt is érdemes tesztelni, hogyan működik a háttér API, és tesztelje minden funkcióját: regisztráció, bejelentkezés, kosárba helyezés, fizetés feldolgozás, adatbázis írás stb. Mindennek a TOR szerint kell működnie. Ebben az esetben funkcionális tesztelést kell végeznie .
Az Ön online áruháza nagy valószínűséggel integrálva van harmadik féltől származó szolgáltatásokkal: levélküldés és SMS-küldés, fizetési rendszerek, online ügyfélszolgálati csevegés, visszajelzések gyűjtése a felhasználóktól, hirdetési rendszerek stb. Ahhoz, hogy megbizonyosodjon arról, hogy mindez megfelelően működik, integrációs tesztelést kell végeznie .
Végül az összetett termékeket gyakran független modulokra bontják. Az ilyen modulokból összeállíthatja a végterméket, akár egy konstruktőrből. Ha ilyen modult fejleszt, vagy ilyen modulokkal kommunikál, akkor egységtesztet kell végeznie .
Összegezve elmondható, hogy funkcionális tesztelésre van szükség az oldal minden egyes funkciójának teszteléséhez. Integráció – a termék nagy moduljai és rendszerei közötti interakció tesztelésére. Moduláris - egy külön modul teszteléséhez, nos, teljesítményteszt -, hogy ellenőrizze webhelye terhelés alatti működését.
A tesztelésnek még többféle fajtája is lehet: minél összetettebb a termék, annál több szempontot kell a fejlesztésében ellenőrizni.