what is cross browser testing
En komplett nybörjarguide för testning av flera webbläsare:
Cross Browser Testing är en typ av test för att verifiera om en applikation fungerar i olika webbläsare som förväntat och försämras graciöst. Det är processen att verifiera din applikations kompatibilitet med olika webbläsare.
Många gånger har jag stött på ett problem med en webbplats och när jag ringde teknisk support ber de mig bara att prova det i en annan webbläsare? När jag gör det fungerar det och jag känner mig som en total idiot, även om jag tjänar mitt arbete i mjukvarubranschen.
Jag slår vad om att detta har hänt er alla, eller hur?
Jag slutar alltid tänka ”varför tänkte jag inte på det?” Men lita på mig, med tiden har jag insett att det inte är mitt fel; det är bara att webbplatsen inte har testats i stor utsträckning med avseende på kompatibilitetstestning mellan webbläsare och som slutanvändare har jag just hittat ett fel.
Vad du kommer att lära dig:
- Introduktion
- Vad är Cross Browser Testing?
- Varför utförs det?
- Vem utför denna testning?
- Hur utför jag testning av webbläsare?
- Rekommenderade verktyg
- När ska man börja med denna testning?
- Vad ska jag testa?
- För att sammanfatta 'hur' att testa webbläsare
- När är bästa tiden att göra detta?
- Slutsats
- Rekommenderad läsning
Introduktion
Vi kanske alla har observerat att vissa webbplatser inte visas korrekt i vissa webbläsare och vi tror bara att webbplatsen är trasig. Men så snart du öppnar den i en annan webbläsare öppnas webbplatsen helt bra. Således förklarar detta beteende kompatibiliteten för en webbplats med olika webbläsare.
Varje webbläsare tolkar informationen på webbplatsens sida på olika sätt. Således kan vissa webbläsare sakna de funktioner som din webbplats försöker visa och få din webbplats att se trasig ut i den webbläsaren.
Till exempel , som visas nedan, är felen i registreringsformulärerna inte desamma i båda webbläsarna. Dessutom är textfärgen, teckensnittet etc. annorlunda om du tittar på dem noggrant.
Med teknikutvecklingen finns det flera alternativ tillgängliga för webbläsare, och det räcker inte bara för att en webbplats ska fungera på en av webbläsarna.
Användare bör inte begränsas till att använda någon specifik webbläsare för att komma åt din applikation. Därför blir det nödvändigt att testa din webbplats kompatibilitet med olika webbläsare. Några av de vanliga webbläsarna inkluderar Chrome, Safari, Firefox, Internet Explorer etc.
Det är bakgrundshistorien, jag slår vad om att ni alla har kommit fram till ämnet för dagens diskussion - Cross Browser Testing.
Som det är en allmän praxis på STH, kommer vi att fokusera på grunderna. Vi tror att alla begrepp kommer att ge en värld av mening när vi ställer de grundläggande frågeorden som - 'Vad, varför, hur, vem, när, var'.
Låt oss göra just det när vi går.
Vad är Cross Browser Testing?
# 1) Testning över webbläsare är helt enkelt vad namnet betyder - det vill säga att testa din webbplats eller applikation i flera webbläsare - och se till att den fungerar konsekvent och som den är avsedd utan beroenden eller kompromisser i kvalitet.
#två) Detta är tillämpligt på båda webb och mobilapplikationer .
# 3) Vilka typer av applikationer genomgår detta? - Kundinriktade applikationer är det bästa valet. Du kanske undrar vid den här tiden, 'Är inte alla applikationer kundinriktade?' Men ja. Dom är. Men låt oss titta på ett exempel.
Tillämpning 1: En applikation utvecklad för ett företag för att internt hålla reda på sitt lager
Tillämpning 2: Detta är för slutanvändarna att köpa produkter från detta företag
- Det är uppenbart att den bästa idén skulle vara att testa applikation 2 för testning av webbläsarkompatibilitet, eftersom det är omöjligt att kontrollera vilka webbläsare / plattformar / versioner slutanvändaren ska använda.
- Å andra sidan, om alla datorer internt i företaget använder Windows 8-maskiner med Chrome-webbläsare - finns det inget behov av att leta efter eller testa något annat med avseende på applikation 1.
Varför utförs det?
För den delen, varför görs någon form av testning?
- Att veta vad som är fel och kunna fixa det.
- För att förbättra effektiviteten och användarupplevelsen och därmed affärer.
- Att få information om eventuella fallgropar
Men specifikt, om vi tänker: Vad är avsikten med testning över webbläsare? - Det här är dubbelt.
- Sidans återgivning eller utseende i olika webbläsare - är det samma, är det annorlunda, om den ena är bättre än den andra etc.
- Funktionaliteten och hur den fungerar. (Självklart!)
Vem utför denna testning?
- Tänker du: 'Det finns en miljon webbläsare, versioner och plattformar där ute - vilka som ska väljas?' - Detta är tack och lov inte ett beslut som är testarens ansvar. Kunden, affärsanalysgruppen och marknadsföringsteamet har en viktig roll i detta beslut. Dessutom samlar företag in användnings- / trafikstatistik för att begränsa vilka webbläsare, miljö och enheter som mest används.
- Hela projektgruppen bör ha ett investerat intresse, tid, pengar och infrastruktur för att stödja denna strävan.
- QA-teamet kan vara involverat i denna process eller det kan vara designteamet som är angelägna om att veta hur applikationen går i flera webbläsare.
- Oavsett om det utförs av QA eller något annat team tolkas resultaten av design- och utvecklingsteamen och relevanta ändringar görs.
Hur utför jag testning av webbläsare?
Nu snackar vi!
Första saker först - görs det manuellt eller med hjälp av ett verktyg?
Det kan säkert göras manuellt - flera maskiner, flera operativsystem, flera webbläsare, flera maskiner och men tydligt, detta leder till flera problem, flera investeringar och flera utmaningar.
Manuell metod
I det här fallet identifierar ett företag de webbläsare som applikationen måste stödja. Testare kör sedan igen samma testfall med hjälp av olika webbläsare och observerar applikationens beteende och rapporterar eventuella fel.
I denna typ av testning är det inte möjligt att täcka många webbläsare, och applikationen kan inte testas på större webbläsarversioner.
Att utföra kontroll över webbläsare manuellt är också dyrt och tidskrävande.
Automatiserad metod
Testning i flera webbläsare kör i princip samma uppsättning testfall flera gånger i olika webbläsare.
vad är säkerhetsnyckel för wifi
Denna typ av upprepad uppgift är bäst lämpad för automatisering. Således är det mer kostnadseffektivt och tidseffektivt att utföra denna testning med hjälp av verktyg.
Så det finns många verktyg på marknaden för att underlätta detta.
Verktygen hjälper oss med ett eller flera eller alla av följande beroende på själva verktyget och licensieringstyperna:
- De tillhandahåller en VPN (Virtual Private machine) där du kan ansluta till fjärrmaskiner och kontrollera hur JAVA, AJAX, HTML, Flash och andra sidor fungerar. De flesta av dessa är säkra, men eftersom du skickar din information till en tredje part rekommenderas en viss analys av diskretion.
- Skärmdumpar tillhandahålls för de sidor och länkar som skickas in om hur de visas i flera webbläsare. Detta är naturligtvis statiskt.
- Flera webbläsare synkroniseras med avseende på operationer som utförs på en och resultaten presenteras i webbläsaren.
- Visa återgivningen av en sida med flera skärmupplösningar
- När ett problem uppstår spelas in en video eller skärmdumpar för att transportera problemet för vidare analys.
- Support finns i allmänhet för både webb- och mobilappar
- Privata sidor som kräver autentisering för att komma åt kan också testas
- Lokalt, inom ett privat nätverk / brandväggssidor, kan också testas
Rekommenderade verktyg
# 1) LambdaTest
LambdaTest är molnbaserad testplattform för webbläsare som använder vilken användare som kan utföra automatiserad och manuell testning av sin webbplats eller webbapp i en kombination av 2000+ olika webbläsare och operativsystem.
Användare kan köra Selen-automatiseringstester på ett skalbart, säkert och pålitligt molnbaserat Selen-nät och utföra interaktiva live-webbtestning av sina offentliga eller lokalt hostade webbplatser och webbapp i molnet.
=> Besök LambdaTest webbplats# 2) CrossBrowserTesting
CrossBrowserTesting tillhandahålls av företaget SmartBear. CrossBrowserTesting låter dig göra varje webbupplevelse perfekt, i vilken webbläsare eller mobil enhet som helst med deras molnbaserade verkliga enhetslaboratorium. Ditch dina virtuella datorer och enhetslaboratoriet. Kör enkelt manuella, visuella och Selen-tester i molnet på 2050+ riktiga stationära och mobila webbläsare.
Vill du påskynda dina tester som en icke-teknisk användare? Kolla in deras Record & Replay-funktion så att du kan spela in ett live-test och köra det inspelade testet parallellt.
=> Besök CrossBrowserTesting webbplats# 3) Selen
Selen är välkänt för automatiserad testning av webbaserade applikationer. Bara genom att byta webbläsare som ska användas för att köra testfall, gör selen det mycket enkelt att köra samma testfall flera gånger med olika webbläsare.
# 4) BrowserStack
BrowserStack är en molnbaserad webb- och mobil testplattform som möjliggör testning av applikationer i on-demand-webbläsare, operativsystem och riktiga mobila enheter.
# 5) Webbläsare
Det är en live interaktiv tjänst som ger enkel testning för webbutvecklare och webbdesigners.
Det finns olika webbläsare och operativsystem och Browserling ger snabb åtkomst till alla de mest populära webbläsarna på de mest populära operativsystemen.
=> Ytterligare läsning: Komplett lista över testverktyg för webbläsare
När ska man börja med denna testning?
Tiden för att starta Cross-Browser-test beror helt på din testmetod och din testtidslinje.
Detta test kan utföras:
# 1) Så snart som möjligt:
Starta denna testning även när en enda sida är redo för testning.
hur man går in i qa-testning
Testa den sidan i varje webbläsare. När nästa sida är tillgänglig testar du den också i flera webbläsare. Detta kommer att öka ansträngningarna, men det hjälper till att åtgärda felen så tidigt som möjligt i livscykeln. Således är fixning av fel, i det här fallet, mycket kostnadseffektivt.
# 2) När ansökan är klar:
Starta denna testning när applikationsutvecklingen är klar.
Detta kommer att testa applikationen som helhet i olika webbläsare. Åtgärda felen blir inte lika kostnadseffektiva som i ovanstående fall men det kommer fortfarande att hjälpa till att åtgärda felen innan du släpper applikationen till användarna.
# 3) När ansökan släpps:
Det här är den minst gynnade tiden för att utföra ett webbläsartest för din applikation. Men det är bättre att göra det än att inte göra det och låta slutanvändarna ha en dålig upplevelse.
Efter att applikationen släppts för slutanvändarna kan denna testning utföras och buggar kan åtgärdas som en del av ändringsförfrågningarna i applikationen. Detta är mycket kostsamt och kräver flera distributioner beroende på buggfixar.
Rigorös testning i flera webbläsare kan endast göras när testteammedlemmarna som har kunskap om verktyg gör denna testning. Hög nivå eller att kontrollera vissa specifika webbläsare kan också göras av företagsanvändare eller till och med utvecklare.
Denna testning innebär att testa applikationen grundligt med olika webbläsare. Testning omfattar grundligt funktionell och icke-funktionell testning av applikationen.
I de flesta företagen har ett produktteam separata team för funktionell och icke-funktionell testning. Således måste denna testning utföras av teamet / grupperna som är ansvariga för funktionell och icke-funktionell testning av applikationen.
För denna testning behöver en testare de webbläsare som applikationen måste testas på.
Dessa webbläsare kan antingen tillhandahållas testaren som:
- Lokalt installerat på testarens maskin.
- En virtuell maskin eller andra maskiner som en testare har tillgång till.
- Verktyg som tillhandahåller sina egna webbläsare och deras versioner för testning.
- På molnet - så att flera testare kan använda webbläsarna efter behov.
Denna testning är oberoende av installationsmiljöerna. Således kan det göras i dev, test, QA eller till och med produktionsmiljö beroende på tillgängligheten av applikationen i var och en av dessa miljöer.
Vad ska jag testa?
- Basfunktionalitet: Länkar, dialoger, menyer etc.
- Grafiskt användargränssnitt: Applikationens utseende och känsla.
- Svar: Hur bra applikationen svarar på användarens åtgärder.
- Prestanda: Att ladda sidorna inom tillåten tidsram.
Om din applikation fungerar bra i en webbläsare innebär det inte att den också fungerar bra på andra webbläsare. Således hjälper denna testning dig att se till att ett program körs i olika webbläsare utan några fel.
För att identifiera vilka avbrott i vilken webbläsare och för att fixa webbplatsen måste vi utföra denna testning. Om en webbläsare inte alls stöds kan användarna enkelt informeras om det.
För att sammanfatta 'hur' att testa webbläsare
# 1. Trafikstatistik hjälper till att avgöra vilka webbläsare som ska testas.
#två. En detaljerad analys bör göras på AUT (ansökan under test) för att avgöra vilka delar av applikationen eller om allt måste genomgå detta. Det rekommenderas att allt testas på flera webbläsare, men återigen måste kostnader och tid övervägas. En bra strategi är att utföra 100% testning på en webbläsare per plattform och för den andra bara testa den mest kritiska / allmänt använda funktionen.
# 3. När beslutet 'Vad' ska testas och 'Var (webbläsare)' fattas - infrastrukturbeslut ska göras - förvärvar vi verktyg eller utför detta manuellt etc. Återigen måste kostnaden beaktas. Lönsamhet, risker, säkerhetsproblem, människor som ska vara inblandade, tid, acceptanskriterier, utfärdande / fixering av scheman / process - är få saker som måste åtgärdas.
# 4. Utför testningen. De vanliga testtestfallen för funktionstestning kan användas för att validera systemets effektivitet. För utseende och känsla / återgivning är testfall inte nödvändiga.
Operationen jag pratade om i början av den här artikeln som misslyckades för mig var en online banköverföring. Jag loggade in på mitt bankkonto, valde beloppet för överföring som ungefär en lakh och försökte utföra överföringen och ett servletfel dyker upp oavsett hur många gånger jag försökte.
Så om överföringsoperationen väljs för testning av webbläsarkompatibilitet, så kommer testskriptet att se ut.
- Logga in på online bankkontot
- Välj det konto från vilket överföringen ska göras
- Ange överföringsbeloppet: 100.000
- Välj betalningsmottagare och klicka på 'Överför'
- Förväntat resultat: Överföringen ska lyckas
- Detta körs helt enkelt på alla valda webbläsare.
Återigen, notera att detta inte ser annorlunda ut än ett funktionellt testfall. Vänligen kolla denna icke-funktionella testartikel för mer information om detta.
# 5. Rapportera resultaten tillbaka till designteamet om de inte var inblandade i testprocessen. Förändring följer.
När är bästa tiden att göra detta?
Alla tester skördar de bästa fördelarna när det görs tidigt. Därför är branschrekommendationen att börja med den så snart siddesignerna är tillgängliga.
Men det kan också utföras när webbplatsen är helt integrerad och funktionell.
Om du har missat bussen när du utför testet över webbläsare under design-, utvecklings- och QA-faser kan det fortfarande göras medan applikationen är i produktion. Detta är dock det dyraste av alla och riskabelt också.
Var utförs testning av webbläsarkompatibilitet?
Vanligtvis skulle svaret på denna fråga vara ett av- Dev / QA / produktionsmiljöer . Men för kontroll av webbläsare är detta inte en bestämd och irrelevant (om jag får säga det). Det kan göras i någon eller alla av dem.
Slutsats
Några punkter att notera,
- Efter att ha varit QA-lärare ett tag nu kan jag berätta vad som kommer nästa och det är - frågan, är det funktionell och icke-funktionell testning? Jag tror att det är varken och båda.
- Det bör inte heller förväxlas med Tvärplattform testning, som testar din applikation i flera målmiljöer som Windows, Linux, Mac etc. Även om de två ibland måste integreras tillsammans, eftersom vissa av de äldre webbläsarversionerna endast kan vara kompatibla med de äldre versionerna av plattformarna.
- Det fortsätter också att bearbetas när mjukvarumiljöer, webbläsare och enheter utvecklas varje dag och för att se till att det inte finns några obehagliga överraskningar bör denna webbläsartest läggas till i repressionen av regressionssviter.
Som ni vet hjälper varje typ av testning till att förbättra applikationens kvalitet och det gör också webbläsartestet.
Tester över webbläsare hjälper till att skapa ett bra intryck på användarna genom att ge dem en konsekvent upplevelse i hela applikationen oavsett webbläsare eller operativsystem.
Att fixa buggar är kostnadseffektivt under de tidiga stadierna av utvecklingslivscykeln, och detsamma gäller även de defekter som finns i denna testning.
Denna testning hjälper till att förbättra ditt företag vilket i sin tur resulterar i glada kunder, glada dig !!
Detta är ännu ett bevis på konceptet att QA-fält eller mjukvarutestning är ett flerdimensionellt fält och att det finns något för alla att utmärka sig i.
Skicka dina kommentarer och frågor nedan. Vi är alltid glada över att höra från dig!
Rekommenderad läsning
- Alpha Testing och Beta Testing (En komplett guide)
- Byggverifieringstestning (BVT-testning) Komplett guide
- Funktionell testning mot icke-funktionell testning
- Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
- Typer av programvarutestning: Olika testtyper med detaljer
- Parrot QA Tutorial: Cross Browser Functional Testing Tool Review
- ETL Testing Data Warehouse Testing Tutorial (En komplett guide)
- Topp 10 verktyg för testning av flera webbläsare 2021 (senaste rankning)