Testmiljö – testa innan det går live
Av CodexierPublicerad 5 min läsning
De flesta fel på hemsidor uppstår på samma sätt: någon uppdaterar ett tillägg, ändrar en mall eller lägger till ett skript direkt på den skarpa sajten, och något annat slutar fungera. En testmiljö (staging) är en privat kopia av sajten där sådana ändringar görs och testas först. Här förklarar vi vad en testmiljö är, hur den hålls i takt med den skarpa sajten, hur den hålls borta från Google och när en liten sajt klarar sig utan.
Vad en testmiljö är
En testmiljö ser ut och beter sig som den skarpa sajten, men ligger på en separat adress, till exempel en underdomän, och syns inte för allmänheten. Många webbhotell för WordPress skapar en med ett klick. För egenutvecklade sajter och appar är testmiljön oftast en del av publiceringsflödet: varje ändring hamnar automatiskt i testmiljön, kontrolleras där och släpps sedan till produktion.
Därför testar du innan publicering
Att testa i en testmiljö gör en överraskning till ett beslut. Förstör en uppdatering kassan i testmiljön får du veta det innan någon kund gör det, och du kan vänta, åtgärda eller backa utan stress. På den skarpa sajten kostar samma fel ordrar, förfrågningar och förtroende, och åtgärden görs i all hast. Testmiljön ger också sajtägaren en plats att granska nya sidor och ny design innan de publiceras.
- Uppdateringar av tillägg, tema och WordPress-kärna
- Uppgradering av PHP- eller serverversion
- Nya funktioner, mallar och designändringar
- Nya spårningsskript och samtyckesinställningar
- Integrationer med betalning, frakt, CRM eller bokningssystem
Håll testmiljön i takt
En testmiljö är bara användbar om den liknar den skarpa sajten. En kopia som är ett år gammal klarar tester som den skarpa sajten skulle fallera på. Regeln som förhindrar de flesta olyckor: kod och konfiguration flyttas upp från test till skarpt, och data flyttas ner från skarpt till test. Skicka aldrig upp en testdatabas till en skarp webbshop – då skriver du över varje order och kund som tillkommit sedan kopian gjordes.
| Vad | Riktning | Varför |
|---|---|---|
| Kod, tema, tillägg | Från test till skarpt | Testade ändringar publiceras |
| Inställningar och konfiguration | Från test till skarpt, med försiktighet | Vissa inställningar ska skilja sig, till exempel testläge för betalningar |
| Innehåll, ordrar, användare | Från skarpt till test | Den skarpa datan är sanningen; testmiljön får en färsk kopia |
| Personuppgifter | Från skarpt till test, minimerade | Anonymisera eller begränsa kunddata i testmiljön när det går |
Tänk på bieffekterna av en kopierad sajt. Testmiljön får inte skicka mejl till riktiga kunder, dra pengar från riktiga kort eller skicka ordrar till lagret. Sätt betalningarna i testläge, stäng av utgående mejl eller led det till en testinkorg, och stäng av integrationer eller peka dem mot testkonton.
Dölj testmiljön för Google
En indexerad testmiljö skapar duplicerat innehåll, förvirrar besökare som hamnar där och kan visa ofärdigt arbete eller personuppgifter. En regel i robots.txt eller en noindex-inställning räcker inte ensam: robots.txt ber bara sökrobotar att hålla sig borta, och länkar till testadressen kan ändå få den listad. Det pålitliga skyddet är ett lösenord framför hela sajten, så kallad HTTP-autentisering, som stänger ute både sökmotorer och människor.
Lösenordsskydd
HTTP-autentisering på hela testmiljön. Det starkaste och enklaste skyddet.
Noindex som reserv
En noindex-inställning ifall lösenordet tas bort av misstag. Kom ihåg att inte kopiera den till skarpt.
Kontrollera efter lansering
Efter varje release, bekräfta att den skarpa sajten går att indexera och att testmiljöns noindex inte följde med koden.
När en testmiljö är överkurs
För en liten företagssajt med få tillägg och sällsynta ändringar kan ett fullständigt arbetssätt med testmiljö kosta mer än det sparar. Där ger en färsk säkerhetskopia före varje uppdatering, ett tillägg i taget och en kontroll av de viktigaste sidorna efteråt det mesta av skyddet. Testmiljön blir nödvändig när sajten tar emot betalningar eller bokningar, har integrationer eller egen kod, eller när flera personer gör ändringar.
När du inte ska köpa av oss: är sajten liten och ändras några gånger om året räcker en bra rutin för säkerhetskopior, och du behöver inte betala för en hanterad testmiljö. Vårt månatliga underhållspaket omfattar testade uppdateringar för sajter där ett fel kostar riktiga pengar. Vår guide om säkerhetskopior och återställningstester täcker skyddsnätet i båda fallen.
Vanliga frågor
Kostar en testmiljö extra?
Många webbhotell för WordPress inkluderar testmiljö i sina paket. För egenutvecklade sajter ingår den i publiceringsflödet, med en mindre driftkostnad för den andra miljön.
Kan jag testa på en lokal kopia i stället?
En lokal kopia fungerar för utveckling men matchar sällan den skarpa servern exakt. En testmiljö på samma typ av server fångar problem som en lokal kopia missar.
Vad händer om testmiljön och den skarpa sajten glider isär?
Uppdatera testmiljön från den skarpa sajten före viktiga tester. En inaktuell testmiljö ger falsk trygghet.
Är det ett GDPR-problem att kopiera kunddata till testmiljön?
Det kan vara det. Testmiljön ska ha samma skydd som den skarpa, åtkomsten ska vara begränsad och kunddata bör minimeras eller anonymiseras när testerna tillåter det.
Trött på uppdateringar som förstör den skarpa sajten?
Femton minuter: vi tittar på hur ändringar når din sajt i dag och säger om du behöver en testmiljö eller bara en säkrare rutin.
Boka ett kostnadsfritt 15-minuterssamtal