Egy frissítés után ritkán az a baj, hogy az oldal teljesen leáll. Azt perceken belül észreveszi valaki. A drágább hiba csendes. Elcsúszik a fejléc mobilon, eltűnik az ajánlatkérő űrlap, a kosár gombja kilóg a képernyőről, és hetekig senki nem szól, mert az oldal amúgy betölt. A vizuális regressziós teszt erre a csendes hibatípusra való. Ebben a cikkben végigmegyünk a logikáján, a mintaoldalak kiválasztásán, a téves riasztások kezelésén, és azon, hogyan lesz belőle rutin.
Mi az a vizuális regressziós teszt, és miért kell frissítés után?
A vizuális regressziós teszt ugyanarról az oldalról készít képernyőképet a frissítés előtt és után, majd képpontról képpontra összeveti a kettőt, és megjelöli az eltérést. Így azt is észreveszed, amit egy elérhetőség-figyelő soha, hiszen a szerver 200-as választ ad, miközben a látogató törött oldalt lát.
A WordPress oldal három rétegből áll össze, a magból, a sablonból és a bővítményekből. Ezek külön ütemben, külön fejlesztőktől kapnak frissítést, a megjelenésbe pedig mindhárom beleszól. Egy oldalépítő bővítmény új verziója átírhatja a generált CSS-osztályokat. Egy sablonfrissítés felülírhatja azokat a módosításokat, amelyeket valaki közvetlenül a sablonfájlokba írt gyermeksablon helyett. Egy gyorsítótár-bővítmény másképp fűzheti össze a stíluslapokat, mint addig. Egyik sem jár hibaüzenettel, az eredmény csak a szemnek látszik.
- Hivatalosan igazolt: a WordPress dokumentációja szerint a kisebb (karbantartási és biztonsági) magfrissítések alapértelmezés szerint automatikusan települnek, az 5.5-ös verzió óta pedig a bővítményekre és a sablonokra is bekapcsolható az automatikus frissítés az admin felületen. A kinézet tehát úgy is megváltozhat, hogy senki nem nyúlt az oldalhoz.
- Saját tapasztalat: a frissítés utáni hibák nagyobb része megjelenési vagy űrlaphiba, a teljes leállás a ritkább eset. Leggyakrabban oldalépítő, gyorsítótár- és űrlapbővítmény frissítése után látunk eltérést.
- Szakmai feltételezés: minél több bővítmény dolgozik a megjelenésen, annál valószínűbb az ütközés. Erre nem ismerünk általános érvényű mérést, a gyakorlat viszont ebbe az irányba mutat.
Hogyan működik a képernyőkép-összevetés a gyakorlatban?
Az eszköz egy fej nélküli böngészőben megnyitja a megadott címeket rögzített ablakméretben, elmenti a referenciaképet, a frissítés után újra lefényképezi ugyanazokat az oldalakat, majd kiszámolja, a képpontok mekkora hányada változott. Ha az eltérés átlépi a megadott küszöböt, a teszt elbukik, és kapsz egy különbségképet, amelyen színnel jelölve látszik a változás helye.
A folyamat négy lépésből áll.
- Referencia rögzítése. A frissítés előtt, ismert jó állapotban lefut a fényképezés. Ez lesz az alap, amihez minden későbbi képet mérsz.
- Frissítés. Lehetőleg tesztkörnyezetben (staging). Ha ilyen nincs, akkor friss mentés után az éles oldalon, alacsony forgalmú időszakban.
- Újrafényképezés és összevetés. Ugyanazok a címek, ugyanazok az ablakméretek, ugyanaz a böngésző és ugyanaz a gép.
- Emberi döntés. Az eltérést valaki megnézi, és eldönti, hogy hiba vagy szándékos változás. Ha szándékos, az új kép lesz a referencia.
A negyedik lépést nem lehet megspórolni. A gép annyit tud, hogy valami más lett. Azt már neked kell megítélned, hogy az új gombszín a sablon fejlesztőjének döntése, vagy egy szétesett stíluslap következménye.
Milyen eszközzel lehet megcsinálni?
Hivatalosan igazolt: a Playwright tesztkeretrendszer beépítve tartalmaz képernyőkép-összevetést (toHaveScreenshot). Az első futáskor elmenti a referenciát, a későbbi futásoknál ahhoz hasonlít. A nyílt forráskódú BackstopJS kifejezetten erre a feladatra készült, egy konfigurációs fájlban adhatod meg a címeket és az ablakméreteket, a végén pedig böngészőben megnyitható jelentést kapsz az egymás mellé tett képekkel. Léteznek felhős szolgáltatások és WordPress-karbantartó eszközök is hasonló funkcióval, a logikájuk ugyanez.
Egy Playwright-teszt a kapcsolat oldalra nagyjából így néz ki.
test('kapcsolat oldal', async ({ page }) => {
await page.goto('/kapcsolat/');
await expect(page.locator('form.wpcf7-form')).toBeVisible();
await expect(page).toHaveScreenshot('kapcsolat.png', { fullPage: true, maxDiffPixelRatio: 0.01 });
});
A harmadik sor azt ellenőrzi, hogy az űrlap egyáltalán jelen van-e és látszik-e (a szelektor a használt űrlapbővítménytől függ, a példában a Contact Form 7 osztályneve áll). A negyedik sor készíti a teljes oldalas képet, és legfeljebb egy százaléknyi képpont-eltérést enged meg.
Mely oldalakat érdemes mintának választani?
Nem kell minden oldalt fényképezni. Sablontípusonként egy mintaoldal és az üzletileg legfontosabb oldalak együtt lefedik a hibák túlnyomó részét, mert az azonos sablonból épülő oldalak jellemzően együtt romlanak el. Egy átlagos céges oldalnál vagy kisebb webáruháznál ez nagyjából 8-15 címet jelent (saját tapasztalat).
- Főoldal. Itt találkozik a legtöbb elem (fejléc, menü, csúszka, ajánlók, lábléc), ezért a legtöbb eltérés is itt jön elő.
- Kapcsolat vagy ajánlatkérő oldal. Az űrlap miatt. Ha ez eltűnik, megszűnnek a megkeresések, és a forgalmi adatokban semmi nem utal a bajra.
- Kosár és pénztár. Webáruháznál ez a bevétel útja, a fizetési és szállítási bővítmények pedig gyakran frissülnek.
- Egy termékoldal és egy kategóriaoldal. Lehetőleg olyan termék, amelynek van variációja, galériája és értékelése is.
- Egy blogbejegyzés és egy archívumoldal. A tartalmi sablonok külön fájlból épülnek, mint a főoldal.
- Egy szolgáltatásoldal vagy landing oldal. Különösen az, amelyikre fizetett hirdetés visz forgalmat.
- A 404-es oldal és a keresési találati oldal. Ritkán nézi meg bárki, ezért sokáig rejtve marad rajtuk a hiba.
- A köszönőoldal. Sok mérés erre az oldalra épül, a szétesése a konverziókövetést is elviheti.
Minden címet legalább három ablakszélességben érdemes rögzíteni, például 375, 768 és 1440 képponton. Saját tapasztalat: a frissítés utáni megjelenési hibák jelentős része kizárólag mobil nézetben jelentkezik, jellemzően a lenyíló menünél és a többhasábos blokkoknál, asztali böngészőből nézve pedig semmi nem látszik belőle.
Mi a helyzet a kosárral és a belépés mögötti oldalakkal?
Az üres kosár fényképe keveset ér. A tesztnek előbb kosárba kell tennie egy terméket, és csak utána fényképezhet, a pénztár oldalon pedig a szállítási és fizetési módok megjelenése a lényeg. Éles oldalon a teszt ne adjon le rendelést. A teljes vásárlási folyamat végigpróbálása a tesztkörnyezetbe való, teszt fizetési móddal. A belépés mögötti oldalakhoz (fiókom, tagsági tartalom) külön tesztfelhasználót hozz létre minimális jogosultsággal.
Hogyan kerülhetők el a téves riasztások?
A téves riasztások túlnyomó részét a mozgó vagy változó elemek okozzák, ezeket az összevetés előtt rögzíteni, elrejteni vagy maszkolni kell. Ha a teszt minden futásnál pirosat mutat, a csapat néhány hét alatt megszokja, és a valódi hibát is átengedi.
- Csúszkák, animációk, videók. Állítsd le őket, vagy rejtsd el az érintett blokkot a fényképezés idejére.
- Sütisáv, csevegőbuborék, felugró ablak. Maszkold ki, vagy a teszt elején fogadtasd el és zárasd be.
- Változó tartalom. Dátumok, készletszám, véletlenszerűen ajánlott termékek, friss bejegyzések listája. Ezekre maszk kerüljön.
- Késleltetett betöltés. A lustán töltődő képek és a webes betűtípusok miatt a teszt várja meg a teljes betöltést, mielőtt fényképez.
- Gyorsítótár. Frissítés után ürítsd az oldal- és a CDN-gyorsítótárat, különben a régi állapotot fényképezed újra.
Hivatalosan igazolt: a Playwright dokumentációja kiemeli, hogy a böngésző megjelenítése függ az operációs rendszertől, a verziótól, a beállításoktól és a hardvertől, ezért a referenciát és az összevetést ugyanabban a környezetben kell futtatni. A toHaveScreenshot alapból leállítja a CSS-animációkat, a mask beállítással pedig megadott elemeket takarhatsz ki a képről.
A küszöbérték kérdése kényesebb. Kiindulásnak a fél és egy százalék közötti megengedett eltérés szokott működni (saját tapasztalat), de egy hosszú, teljes oldalas képen egy eltűnt gomb a képpontok ezrelékét sem teszi ki. A túl engedékeny küszöb tehát pont a legdrágább hibát engedi át. Erre két megoldás van. Az egyik, hogy a fontos blokkokról (fejléc, űrlap, kosárösszesítő) külön, elemszintű képet készítesz szigorú küszöbbel. A másik a következő szakasz témája.
Miért nem elég a képernyőkép az űrlapok ellenőrzéséhez?
A képernyőkép azt mutatja meg, hogy az űrlap ott van és jól néz ki. Arról semmit nem mond, hogy el is küldi-e az üzenetet. Egy frissítés után az űrlap látszólag hibátlan maradhat, miközben a beküldés JavaScript-hibára fut, a spamvédelem minden kitöltést elutasít, vagy az értesítő levél nem indul el.
A vizuális teszt mellé ezért néhány funkcionális ellenőrzést is érdemes tenni.
- Az űrlap elem létezik, látható, és megvan benne a várt számú mező és a küldés gomb.
- A böngészőkonzol nem jelez új JavaScript-hibát az oldal betöltésekor.
- Tesztkörnyezetben egy próbabeküldés sikeres visszajelzést ad, és az értesítő levél megérkezik a tesztcímre.
- A beküldés után a köszönőoldal betölt, és a mérőkód lefut rajta.
- Webáruháznál a kosárba tétel után frissül a kosár darabszáma és végösszege.
Saját tapasztalat: az űrlaphibák egy része kimondottan a spamvédelmi és a levélküldő bővítmények frissítéséhez kötődik, ezért ezek után a próbabeküldést akkor is megcsináljuk kézzel, ha a képek egyeznek.
Hogyan illeszthető be a karbantartási rutinba?
A teszt akkor ér valamit, ha minden frissítési körnek kötelező része, és van felelőse. A bevált keret egy rögzített frissítési ablak, előtte mentéssel és referenciaképpel, utána összevetéssel és dokumentált döntéssel.
A frissítéseket ne egyszerre futtasd le. Ha húsz bővítmény frissül egy lépésben és utána eltérést látsz, nem tudod, melyik okozta. A megjelenést érintő bővítményeket (oldalépítő, sablon, WooCommerce, gyorsítótár, űrlap) egyenként frissítsd, mindegyik után összevetéssel, a többit mehet csoportban. WP-CLI-vel ez jól követhető.
wp plugin list --update=available
wp plugin update elementor
wp theme update --all
wp core update
Ha egy bővítmény frissítése hibát okoz és a fejlesztő még nem adott ki javítást, a korábbi verzió visszatehető a wp plugin install bovitmeny-neve --version=1.2.3 --force paranccsal, vagy a mentés visszaállításával (hivatalosan igazolt, a parancsok a WP-CLI dokumentációjában szerepelnek).
Ha az oldalon be van kapcsolva az automatikus frissítés, a frissítés időpontját nem te választod meg. Ilyenkor érdemes az összevetést ütemezve, naponta futtatni a legutóbb jóváhagyott referenciához képest, így legfeljebb egy nap telik el a hiba és az észlelés között. Szakmai feltételezés: a megjelenést erősen befolyásoló bővítményeknél a kézi, ellenőrzött frissítés jó eséllyel kevesebb meglepetést okoz, mint az automatikus, a biztonsági javításoknál viszont a gyorsaság többet ér. A kettő között oldalanként kell egyensúlyt találni.
Mit érdemes ellenőrizni frissítés előtt és után?
Az alábbi két rövid lista a legtöbb WordPress oldalra változtatás nélkül alkalmazható, és egy frissítési kör jegyzőkönyvének is megfelel.
Frissítés előtt
- Friss, visszaállítható mentés készült a fájlokról és az adatbázisról, és tudod, hogyan kell visszatölteni.
- Megnézted a frissülő bővítmények változásnaplóját, különösen a főverzió-váltásokat.
- Lefutott a referencia-fényképezés minden mintaoldalon és ablakméretben, ismert jó állapotban.
- Feljegyezted a jelenlegi verziószámokat (mag, sablon, bővítmények, PHP).
- Van tesztkörnyezet, vagy alacsony forgalmú időpontot választottál az éles frissítéshez.
Frissítés után
- Ürítetted az oldal-, az objektum- és a CDN-gyorsítótárat.
- Lefutott az összevetés, és minden eltérést megnézett egy ember.
- Megtörtént a próbabeküldés az űrlapon, webáruháznál a kosárba tétel és a pénztár megnyitása.
- Átnézted a hibanaplót és a böngészőkonzolt új hibák után.
- A szándékos változásokat jóváhagytad új referenciaként, a hibákat javítottad vagy visszaállítottad.
- Rögzítetted, mi frissült, mit találtál és mi lett vele.
Mit jelent mindez a keresők és az AI-válaszmotorok szempontjából?
Egy megjelenési hiba a látogatón túl a gépi olvasókat is érintheti, ha a frissítés tartalmi blokkot vagy strukturált adatot tüntet el. Hivatalosan igazolt: a Google dokumentációja szerint az elrendezés váratlan elmozdulását mérő CLS a Core Web Vitals mutatók egyike, az oldalélmény jelzéseit pedig a rangsoroló rendszerek figyelembe veszik. Ez nem jelent garantált helyezésváltozást egyik irányban sem.
Szakmai feltételezés: ha egy bővítményfrissítés után eltűnik a GYIK-blokk, a szerzői doboz vagy a bővítmény által kiírt schema-jelölés, az oldal kevesebb idézhető, jól azonosítható tartalmat ad a keresőknek és a válaszmotoroknak. Ezért a frissítés utáni ellenőrzésbe érdemes felvenni azt is, hogy a mintaoldalak forrásában megvan-e a várt strukturált adat és a fő tartalmi szakaszok szövege. Ez segítheti a láthatóság megőrzését, de önmagában nem garantál megjelenést egyik felületen sem.
Források és további olvasnivalók
- WordPress.org dokumentáció, a WordPress frissítése és az automatikus frissítések beállítása
- WordPress Developer Resources, WP-CLI parancsreferencia (plugin, theme, core)
- Playwright dokumentáció, Visual comparisons (képernyőkép-összevetés)
- BackstopJS projektdokumentáció
- Google Search Central, Core Web Vitals és oldalélmény
- web.dev, Cumulative Layout Shift (CLS)
- Schema.org, strukturált adatok szókészlete
- A frissítés utáni hibák jó része csendes megjelenési vagy űrlaphiba, amelynél a szerver hibátlan választ ad, miközben a látogató törött oldalt lát.
- Sablontípusonként egy mintaoldal és az üzletileg fontos oldalak (főoldal, kapcsolat, kosár, pénztár) elegendő lefedettséget adnak.
- A képernyőkép mellé funkcionális ellenőrzés is kell, mert egy eltűnt gomb a teljes oldalas kép töredék százaléka, az űrlap pedig attól még nem küld, hogy jól néz ki.
- A mozgó elemeket maszkolni vagy rögzíteni kell, különben a téves riasztások miatt a csapat hamar megszokja a piros jelzést.
- Az eltérésről mindig ember dönt, a gép csak azt jelzi, hogy valami megváltozott.
Gyakori kérdések
Mi a különbség a vizuális regressziós teszt és az elérhetőség-figyelés között?
Az elérhetőség-figyelés azt nézi, hogy a szerver válaszol-e és milyen állapotkóddal. A vizuális regressziós teszt azt vizsgálja, hogy az oldal ugyanúgy néz-e ki, mint korábban. Egy szétesett elrendezésű vagy űrlap nélküli oldal az elérhetőség-figyelés szerint hibátlan, a képernyőkép-összevetés viszont jelzi az eltérést.
Hány oldalt érdemes bevonni a tesztbe?
Sablontípusonként egyet, kiegészítve az üzletileg legfontosabb oldalakkal. Egy átlagos céges oldalnál vagy kisebb webáruháznál ez tapasztalatunk szerint 8-15 cím, mindegyik legalább három ablakszélességben. Ennél több oldal ritkán talál több hibát, az átnézési idő viszont megnő.
Kell hozzá tesztkörnyezet, vagy éles oldalon is futtatható?
A fényképezés éles oldalon is biztonságosan futtatható, mert csak olvas. A frissítést viszont jobb előbb tesztkörnyezetben elvégezni, és a rendelés leadásával vagy űrlapbeküldéssel járó próbákat is oda érdemes tenni. Ha nincs tesztkörnyezet, friss mentés és alacsony forgalmú időpont mellett az éles oldalon is elvégezhető a kör.
Miért jelez a teszt eltérést, amikor semmi nem romlott el?
Jellemzően mozgó vagy változó elem miatt, ilyen a csúszka, a sütisáv, a csevegőbuborék, a dátum, a véletlenszerű termékajánló vagy a későn betöltődő betűtípus. Ezeket maszkolni vagy rögzíteni kell. Eltérést okozhat az is, ha a referencia és az új kép más gépen vagy más böngészőverzióval készült.
Észreveszi a teszt, ha az űrlap látszik, de nem küld?
A képernyőkép önmagában nem. Ehhez funkcionális ellenőrzés kell, vagyis próbabeküldés tesztkörnyezetben, az értesítő levél megérkezésének ellenőrzése és a böngészőkonzol hibáinak átnézése. A kettő együtt ad megbízható képet.
Mi a teendő, ha az eltérés szándékos változás?
Ha a sablon vagy a bővítmény fejlesztője szándékosan módosított a megjelenésen, és az új állapot megfelel, akkor az új képet kell jóváhagyni referenciaként. Érdemes röviden feljegyezni, mi változott és ki hagyta jóvá, hogy a következő körben egyértelmű legyen az alap.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.