Mi az a Front End tesztelés?

⚡ Okos összefoglaló

A front-end tesztelés a megjelenítési réteg grafikus felhasználói felületét, funkcionalitását, használhatóságát és teljesítményét ellenőrzi, így az elrendezési hibákat, a hibás szkripteket és a lassú oldalakat még azelőtt észlelik, hogy a valódi felhasználók találkoznának velük.

  • 🔘 Először is hatókör: Egy írásos terv rögzíti a böngészőket, operációs rendszereket és eszközöket, amelyeket a szkriptelés megkezdése előtt le kell fedni.
  • ☑️ Három kiváltó ok: CSS regresszió, JavaA legtöbb front-end csomagot szkripttörési és teljesítmény-ellenőrzések vezérlik.
  • ✅ Réteges lakosztályok: Az egység-, komponens-, végpont-végpont, vizuális regressziós és akadálymentességi ellenőrzések mindegyike más-más hibát észlel.
  • 🧪 Eszközkeverék: Jázmin, SeleniumA CSSLint és a BackstopJS a Jest mellett helyezkedik el, Cypress és drámaíró.
  • 🇧🇷 Gyorsabb futások: A fej nélküli böngészők, a kevesebb DOM-renderelés és az elszigetelt tesztesetek lerövidítik az összes regressziós ciklust.
  • 📈 Teljesítményfókusz: A PageSpeed ​​Insights segítségével mért alapvető webes vitals-mutatók azt mutatják, hogy a felület gyorsan eléri-e a felhasználókat.

Webes alkalmazás grafikus felületének, funkcionalitásának és használhatóságának front-end tesztelése

Mi az a Front End tesztelés?

Elülső tesztelés egy olyan tesztelési technika, amelyben a grafikus felhasználói felület (GUI), funkcionalitás és használhatóság egy webalkalmazás tesztelve vannak. A cél annak megerősítése, hogy a megjelenítési réteg hibamentes marad a egymást követő frissítések során.

Például, ha beírod a neved egy űrlapmezőbe, számokat nem szabad elfogadni. A grafikus felhasználói felület elemeinek igazításának ellenőrzése egy másik mindennapi eset.

Ezen kívül front-end tesztelést végeznek a következők esetében:

  • CSS regressziós tesztelés: kisebb CSS-módosítások, amelyek tönkreteszik a kezelőfelület elrendezését.
  • JavaSzkriptmódosítások ami működésképtelenné teszi az előlapot.
  • Teljesítményellenőrzések attól függően, hogy milyen gyorsan válik használhatóvá a felület.

Hogyan készítsünk frontend webhely tesztelési tervet?

Egy front-end tesztelési terv létrehozása egy egyszerű, négylépéses folyamat.

Step 1) Ismerje meg a tesztelési terv kezeléséhez szükséges eszközöket.

Step 2) Határozza meg a front-end tesztelés költségvetését.

Step 3) Állítsa be az egész folyamat ütemtervét.

Step 4) Határozza meg a projekt hatókörét. A hatókör a következőket tartalmazza:

  • Operaa felhasználók által használt rendszereket és böngészőket
  • A közönség által használt népszerű eszközök
  • A közönség technikai jártassága
  • A közönség internetkapcsolatának sebessége

Miért érdemes front-end tesztelési tervet készíteni?

Az alábbi ábra azt a két dimenziót mutatja, amelyeket egy tervnek rögzítenie kell.

Front-end tesztelési terv, amely a böngészőket és az operációs rendszereket is lefedi.

A terv határozza meg, hogy mely böngészők és operációs rendszer a projektnek le kell fednie. A lehetséges kombinációk száma végtelen, így egy terv csökkenti az erőfeszítést és a költségeket is.

A terv két egyértelmű előnnyel jár:

  • Teljes körű tájékoztatást nyújt a projekt terjedelméről.
  • Bizalmat ad a projekt megvalósítása során.

Tippek a jobb front-end teszteléshez

Tippek egy jobb front-end tesztelési terv kidolgozásához:

  • Megfontoltan készítse elő költségvetését, erőforrásait és idejét.
  • Használj fej nélküli böngészőt, így a tesztek gyorsabban futnak.
  • Csökkentse a DOM-megjelenítés mennyiségét a tesztekben a gyorsabb végrehajtás érdekében.
  • Izolálja a teszteseteket, így a hiba kiváltó okát gyorsan megtalálják, és a javítási ciklus rövid marad.
  • Tedd a tesztszkripteidet újrafelhasználhatóvá a gyorsabb működés érdekében regressziós ciklusok.
  • Használjon következetes elnevezési konvenciót a tesztszkriptekhez.
  • Kötsd össze mindegyiket próbaper egy látható viselkedésre.

Front-end tesztelési eszközök

Nincs egyetlen eszköz sem, amely lefedné a szkriptelést, a stíluslapokat és a vizuális elemeket, ezért a csapatok többet kombinálnak.

JS tesztelőeszköz: Jasmine

Jázmin egy viselkedésvezérelt fejlesztési keretrendszer teszteléshez JavaForgatókönyv kód. Az üzleti értékre összpontosít a technikai részletek helyett, tiszta szintaxissal rendelkezik, és semmilyen más keretrendszertől nem függ. Olyan egységtesztelési keretrendszerekre támaszkodott, mint a JSSSpec, a ScrewUnit, a JSpec és az RSpec. A Jest és a Vitest a ma széles körben használt alternatívák.

Funkcionális tesztelő eszköz: Selenium

Selenium végponttól végpontig tartó tesztelést végez böngészőkön és platformokon, például Windows, macOS és Linuxon, és lehetővé teszi tesztek írását Java, Python, C# és más nyelveken. Selenium IDE hozzáadja a felvételt és a lejátszást, így az első szkripthez nincs szükség kódra. Cypress és a drámaíró ugyanazt a területet fedi le beépített várakozással és tracIng.

CSS és vizuális eszközök: CSSLint és BackstopJS

CSSLint egy nyílt forráskódú linter, amelyet a következő nyelven írtak: JavaBöngészőben és parancssorból is futtatható szkript. Már nem aktívan karbantartják, ezért a csapatok mostantól a Stylelint vagy az ESLint CSS-támogatásával lint-elik a stíluslapokat.

BackstopJS Vizuális regressziós tesztelést kezel. Oldalakat jelenít meg headless Chrome-ban, összehasonlítja az egyes képernyőképeket egy jóváhagyott referenciaképpel, és lehetővé teszi a nézetablak-méretek és a sikeres/sikertelen feltételek konfigurálását.

Két kihívás vonatkozik minden front-end tesztelő eszközre:

  • Tesztelés automatizálása kezdeti szakaszban sok erőfeszítést igényel.
  • Az eszközök kompatibilitási problémákat okozhatnak bizonyos operációs rendszerekkel és böngészőverziókkal.

Front-end teljesítményoptimalizálás

A front-end teljesítménytesztelés egyetlen kérdésre ad választ: milyen gyorsan töltődik be és válik használhatóvá az oldal? Jó gyakorlat egyetlen felhasználóra hangolni, mielőtt az alkalmazás nagy terhelésnek indulna. Teljesítményfelmérés.

Miért fontos a front-end teljesítményoptimalizálás?

A teljesítményoptimalizálás egykor a szerver finomhangolását jelentette, mivel a legtöbb weboldal statikus volt, és a feldolgozás a szerveroldalon történt.

Ahogy a webes alkalmazások dinamikussá váltak, sokkal több munka került a böngészőbe: keretrendszer kódja, harmadik féltől származó szkriptek, képek és betűtípusok. A kliensoldali kód önmagában is szűk keresztmetszetet jelentett.

Milyen előnyökkel jár a front-end teljesítményoptimalizálás?

  • A kliensoldali problémák ugyanolyan közvetlenül rontják a felhasználói élményt, mint a szerveroldali szűk keresztmetszetek, így mindkettő figyelmet érdemel.
  • A látogató várakozásának nagy része a szerver válasza – letöltés, elemzés és megjelenítés – után történik, így a front-end munka gyakran nagyobb látható nyereséget eredményez.
  • Az olyan javítások, mint a képek tömörítése, a szkriptek elhalasztása és a média számára fenntartott hely olcsóbbak, mint a háttér újratervezése.
  • Alapvető webes vitals-mutatók – Legnagyobb tartalomkitöltés, interakció a következő kitöltésekkel és összesített elrendezés Shift — az eredményeket egy közös ponttáblázaton kell megjeleníteni.

Front-end teljesítménytesztelő eszközök

1. PageSpeed ​​Insights

PageSpeed ​​Insights is Googleingyenes oldalelemző szolgáltatása. Lighthouse auditot futtat, jelentéseket készít a Core Web Vitals mutatókról, és javaslatokat tesz a betöltési idő csökkentésére. A Lighthouse a Chrome DevTools részeként is elérhető.

2. Pingdom

Pingdom egy weboldal- és teljesítményfigyelő szolgáltatás. Értesíti az ügyfeleket, ha egy oldal lelassul vagy offline állapotba kerül, így a problémák még azelőtt felszínre kerülnének, mielőtt a felhasználók jelentenék azokat.

Jellemzők:

  • Egy weboldal minden részét megvizsgálja
  • Teljesítmény áttekintést nyújt
  • Traca teljesítményelőzményeid
  • Lehetővé teszi több helyről történő tesztelést

GYIK

A front-end tesztelés azt vizsgálja, amit a felhasználó lát – elrendezést, interakciókat és reszponzivitást. A back-end tesztelés a felület mögötti szervereket, API-kat és adatbázisokat ellenőrzi. A kettő kiegészíti egymást, és egy kiadáshoz mindkettőre szükség van.

Egy tipikus csomag rétegenkénti egységteszteket végez függvényeken, komponensteszteket renderelt widgeteken, végponttól végpontig teszteket a felhasználói utazásokon, vizuális regressziót végez képernyőképeken, és akadálymentesítési vizsgálatokat végez. Minden réteg olyan hibákat észlel, amelyeket a többi nem.

Egy alap képernyőképet jóváhagynak, majd a későbbi futtatásokat pixelről pixelre összehasonlítják vele. A különbségeket egy ember fogadja el vagy utasítja el, olyan elrendezési hibákat észlelve, amelyeket a funkcionális állítások soha nem látnak.

Igen. A szkennerek ugyanabban a folyamatban jelzik a hiányzó címkéket, a gyenge kontrasztot és a hibás fókuszsorrendet. A billentyűzet és a képernyőolvasó manuális áthaladása továbbra is folyamatban van, így... akadálymentesítési tesztelés soha nem teljesen automatizált.

A mesterséges intelligencia felhasználói történetekből származó teszteset-vázlatokat, stabil szelektorokat javasol, önjavító lokátorokat használ a jelölőnyelvi változások után, és közel azonos vizuális különbségeket klaszterez. RevAz view továbbra is számít: egy generált állítás zárolhat egy hibát.

GitHub másodpilóta Egy nyitott fájlból vázlatokat készít komponenstesztekről, mockokról és page objektumokról, eltávolítva a sablonos verziók nagy részét. Az aszinkron viselkedés és az üzleti szabályok, amelyeket korábban nem látott, továbbra is fejlesztői ellenőrzést igényelnek.

Mindkettő. Az ismétlődő ellenőrzések – űrlapok, navigáció, elrendezési pillanatképek – minden buildnél automatizáltak. A feltáró munka, a vizuális megítélés és a használhatóság megfigyelése manuális marad, mivel emberi értelmezésre támaszkodnak.

Bízd az analitikára a döntést. Fedezd le a legtöbb valós forgalmat bonyolító böngészőket, verziókat és képernyőméreteket, adj hozzá egy régebbi alapértéket, a többit pedig kezeld szúrópróbaszerű ellenőrzésként. mobil tesztelés.

Foglald össze ezt a bejegyzést a következőképpen: